Skip to content
RedirHub/API
Sign inGet API key
Agent integrations

RedirHub MCP integration

Point any MCP-compatible client at one RedirHub endpoint, sign in, and choose what the agent may do. It then discovers redirect-management tools and runs them behind your client’s approval flow.

MCP endpoint
POST https://mcp.redirhub.com
Protocol
JSON-RPC 2.0 over HTTP
Sign-in
OAuth 2.1 (PKCE, dynamic client registration)
Or
Authorization: Bearer <API token>
Connected assistants
https://account.redirhub.com/mcp
REST source
https://api.redirhub.com/v1

Plans, limits and capabilities in one page: Product facts.

5-minute setup

Most assistants need only the endpoint: they sign you in to RedirHub and receive their own token, so there is nothing to copy. Scripts and clients that cannot sign in use an API token instead.

# Service discovery — no token required, returns no workspace data
curl -s "https://mcp.redirhub.com"
Grant what the assistant needs. A signed-in assistant only sees the tools it was granted, and only in the workspace you picked. An API token has every tool in the workspace that issued it: keep it local to a trusted client or server-side process, use a separate token per client and environment so revocation stays isolated, and follow the REST Authentication guide for the rest of the token rules.

Permissions

The consent screen asks which of these the assistant may use. What you can grant depends on your role in the workspace; to change a grant later, disconnect the assistant and connect it again.

links:read
See your links, domains and click statsEvery read tool: links, QR codes, domains and their DNS, the workspace, members, the account, stats and access logs. Always granted.
links:write
Create and edit linksBranded links, QR codes and redirects; updates, bulk updates and imports. On by default; editor role and up.
links:delete
Delete linksSingle and bulk deletes. Editor role and up.
domains:write
Add and change domainsConnect, update and re-check domains. Editor role and up.
workspace:admin
Manage members and workspace settingsInvite, remove and change members, and update workspace and account settings. Manager role and owner.

Endpoint and authentication

GET https://mcp.redirhub.com returns unauthenticated service discovery — server name, version, the advertised endpoints, and a quick-start block. POST to the same URL is the JSON-RPC endpoint: every call is a JSON-RPC 2.0 envelope with jsonrpc, id, method, and optional params, and it requires the Authorization header.

Sign-in follows the MCP authorization spec. A POST without a token answers 401 with a WWW-Authenticate header pointing at the protected resource metadata, which names https://account.redirhub.com as the authorization server. Its /.well-known/oauth-authorization-server metadata advertises dynamic client registration (/oauth/register) and the authorization code flow with PKCE (S256). Access tokens last an hour; refresh tokens 30 days, and they rotate on use.

Two paths reach the same tools. The cURL checks above are the direct shortcut: one authenticated tools/list or resources/read POST answers 200 on its own, which is what makes them a good first check. A client instead runs the full MCP lifecycle — initialize, which returns the server capabilities and a session id, then a notifications/initialized acknowledgement, then tools/list and the tool calls. Your client library handles that for you; it matters when you read MCP logs, because a failure at initialize looks nothing like a failure at tools/list.

200
Discovery is reachableGET on the server URL returns service metadata and the quick-start commands. It exposes no workspace data, so it is a safe first reachability check from any network.
401
JSON-RPC without a valid tokenPOST to the server URL with no bearer token returns {"message":"Unauthenticated."} and the WWW-Authenticate header an OAuth client follows to sign you in. Use this to prove the client is reaching RedirHub even before a token works.
202
Notification acceptednotifications/initialized returns 202 with no body. JSON-RPC notifications carry no id and get no result — an empty response there is success, not a dropped request.

Client setup

The blocks below are the canonical RedirHub server information written in the shape many clients use: the endpoint alone for a client that signs in, or the endpoint plus a bearer header for an API token. Treat them as a pattern, not a schema: field names, environment-variable syntax, and credential storage belong to each client.

{
  "mcpServers": {
    "redirhub": {
      "url": "https://mcp.redirhub.com"
    }
  }
}

Claude

RedirHub is in Claude's connectors directory. Open RedirHub in the directory (or Settings → Connectors → Browse connectors and search for RedirHub) and choose Connect. Claude opens RedirHub to sign in, you pick a workspace and what Claude may do, and it comes back connected; then enable the connector in a conversation. No token or header is needed.

If your organization has turned off the directory, an owner can still add it as a custom connector: Settings → Connectors → Add custom connector (open it directly), name it RedirHub and paste https://mcp.redirhub.com. See the remote MCP connector docs.

ChatGPT

RedirHub is in ChatGPT's app directory. Open RedirHub in ChatGPT and choose Connect. ChatGPT opens RedirHub to sign in, you pick a workspace and what ChatGPT may do, and it comes back connected. No server URL, token or header is needed. On a Business, Enterprise or Edu workspace, an admin may first have to allow the app.

To add RedirHub as a custom MCP app instead, follow the steps below.

Use ChatGPT on the web. UI, rollout and permissions can change: OpenAI’s Developer mode and MCP apps in ChatGPT is the source of truth for current setup and plan availability.

ChatGPT plan matrix
ChatGPT planCustom MCP access
ProRead/fetch only, with developer mode enabled. No create, update or delete actions.
BusinessFull MCP, including writes, in beta. Admins/owners create and publish; members use published apps.
Enterprise / EduFull MCP, including writes, in beta. Admins/owners publish; RBAC can authorize members to develop and control app access/actions.

When creating the app, name it RedirHub, enter https://mcp.redirhub.com, and choose OAuth (recommended). Select Scan Tools, complete RedirHub sign-in and workspace consent, wait for the scan, then select Create. Admins publish from Workspace settings → Apps → Drafts. Select the app in a new chat and test a read first.

ChatGPT access and server permissions are separate. The matrix describes ChatGPT plans, not RedirHub subscriptions. The server scopes above do not unlock ChatGPT write access. On Pro, grant only links:read; on supported workspace plans, writes also need the matching server grant and enabled app actions. ChatGPT may request confirmation. Deep research remains read/fetch-only; agent mode does not use custom apps.

If OAuth stops working after the initial session, reconnect. OpenAI requires refresh-token issuance and advertised offline_access (or equivalent refresh access) for persistent connectivity; see the official OAuth guidance. Advertising the refresh_token grant alone does not verify renewal in ChatGPT.

Cursor

Cursor reads MCP config from project .cursor/mcp.json or global ~/.cursor/mcp.json and supports remote servers by url. Install RedirHub in Cursor in one click, or add it by hand. With the URL alone, Cursor shows a login button for the server that runs the RedirHub sign-in. With an API token, it expands environment variables inside headers using ${env:NAME}. See the Cursor MCP docs for the current UI and enterprise policy controls.

{
  "mcpServers": {
    "redirhub": {
      "url": "https://mcp.redirhub.com"
    }
  }
}

VS Code

Install RedirHub in VS Code in one click, or run MCP: Add Server from the command palette, choose HTTP and paste https://mcp.redirhub.com. VS Code signs you in when the server first asks for it.

Codex CLI

Codex reads ~/.codex/config.toml, or a trusted project-scoped .codex/config.toml. Add the server by URL and run codex mcp login to sign in; with an API token instead, bearer_token_env_var keeps the token in the environment rather than the file. Keeping default_tools_approval_mode at prompt leaves every tool call behind an approval. See the Codex MCP docs.

codex mcp add redirhub --url https://mcp.redirhub.com
codex mcp login redirhub

Any other MCP client

For any other host, register RedirHub as a remote HTTP (Streamable HTTP) server at https://mcp.redirhub.com. A host that implements MCP authorization signs you in on its own; otherwise send Authorization: Bearer <API token> with each JSON-RPC request. Field names below are illustrative — check your host’s schema and the official MCP remote-server docs. Custom clients should initialize, discover capabilities, then call tools; the MCP server guide covers tools, resources, prompts, and approval expectations.

{
  "name": "redirhub",
  "transport": "streamable-http",
  "url": "https://mcp.redirhub.com"
}

Verify the connection

Capabilities and limits

The tool surface is discovered from the server at connection time, so this page documents the connection rather than a catalog that would drift. tools/list and resources/list on your own authenticated connection are the authority on what the agent can reach.

Discovery is the contract, not this page. Tool names, argument schemas, response shapes and the permissions behind each tool belong to the server version you are connected to. Read them from tools/list and resources/list, or from the server repository, and treat a change in the discovered surface as a breaking change until you have re-checked. Whatever the annotations say, your client’s approval flow is the boundary that stops an unwanted write.

A safe operating workflow

Redirects are production routing. The same loop works for a one-off edit and for a bulk migration, and it is worth following even when the agent sounds confident.

Prompt examples

These describe intent and leave tool selection to the client and server, which keeps them working as the tool surface changes. Start read-only, then move up the list.

Using the RedirHub MCP server, list the redirects in my workspace with
their source hosts, destinations, and status. This is a read-only
inventory — do not create, update, or delete anything.

Troubleshooting

Config
The client will not load the serverValidate the file first — commas, quotes, and the top-level key. Clients disagree here: mcpServers in JSON, [mcp_servers.<name>] in Codex TOML, UI fields in Claude. A pattern copied from another client is the usual cause.
Env
The token is not being expandedConfirm the variable is exported in the process that launches the client, not just in your interactive shell. Cursor expands ${env:NAME} inside headers; Codex reads the variable named by bearer_token_env_var.
401
UnauthenticatedThe server was reached but no valid bearer token arrived. A signed-in client should start sign-in again; one that does not was disconnected or never supports OAuth, so reconnect it or use an API token. With an API token, check the header spelling, the token value, env expansion, revocation, and whether the client forwards custom headers at all.
403
Authenticated but refusedThe request was understood and rejected. For a signed-in assistant, the person who connected it may no longer belong to the workspace: connect it again. Otherwise re-check which account issued the token and what that account can reach, and confirm with the workspace owner rather than guessing.
-32602
A tool needs another permissionThe assistant called a tool its connection was not granted; the error names the permission. Disconnect it under AI assistants and connect it again with that permission, if your role allows it.
Tools
Connected, but no tools appearRun the tools/list cURL check. Tools in cURL but not in the client is a client discovery problem — reload or restart the client after any config change and read its MCP logs.
Network
Cannot reach the serverConfirm the machine can reach GET https://mcp.redirhub.com at all, that outbound HTTPS is allowed through any proxy, and that TLS interception is not breaking the connection.

REST API and next steps

MCP and the REST API are two doors into the same workspace. Use MCP when an agent should discover and operate tools conversationally; use REST when you need an exact, versioned contract — request fields, response bodies, error payloads, filtering, pagination, and rate-limit headers. Where MCP coverage stops, REST is the fallback rather than a workaround.