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

RedirHub MCP integration

Point any MCP-compatible client at one authenticated RedirHub endpoint so an agent can discover redirect-management tools and run them behind your client’s approval flow.

MCP endpoint
POST https://api.redirhub.com/mcp/v1
Protocol
JSON-RPC 2.0 over HTTP
Credential
Authorization: Bearer <token>
Install flow
https://account.redirhub.com/mcp
REST source
https://api.redirhub.com/v1

5-minute setup

A token, the endpoint, and one verification call get an agent talking to RedirHub. Do them in that order — a failed verification is much cheaper to read before a client is in the way.

# Service discovery — no token required, returns no workspace data
curl -s "https://api.redirhub.com/mcp/v1"
Treat the token like workspace access. A RedirHub token acts inside 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.

Endpoint and authentication

GET https://api.redirhub.com/mcp/v1 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.

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 /mcp/v1 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 /mcp/v1 with no bearer token returns {"message":"Unauthenticated."}. 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 block below is the canonical RedirHub server information — the endpoint plus a bearer header — written in the shape many clients use. Treat it as a pattern, not a schema: field names, environment-variable syntax, and credential storage belong to each client. Keep the endpoint and the header, then map the rest to your client’s current docs.

{
  "mcpServers": {
    "redirhub": {
      "url": "https://api.redirhub.com/mcp/v1",
      "headers": {
        "Authorization": "Bearer ${REDIRHUB_MCP_TOKEN}"
      }
    }
  }
}

Claude

Claude connects to remote MCP servers through the custom-connector UI rather than a hand-edited config file: add a custom connector, give it the remote MCP URL, connect, then enable it in the conversation. Follow the remote MCP connector docs for the current flow, and prefer any Claude-specific configuration the RedirHub install flow generates for you.

Claude credential handling is version-dependent. The connector UI is built around OAuth-style connection flows, and where a plain bearer header can be supplied varies by Claude surface and version. Confirm what your build accepts before assuming the JSON pattern above applies.

Cursor

Cursor reads MCP config from project .cursor/mcp.json or global ~/.cursor/mcp.json, supports remote servers by url, and 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://api.redirhub.com/mcp/v1",
      "headers": {
        "Authorization": "Bearer ${env:REDIRHUB_MCP_TOKEN}"
      }
    }
  }
}

Codex CLI

Codex reads ~/.codex/config.toml, or a trusted project-scoped .codex/config.toml. For Streamable HTTP servers it documents url and bearer_token_env_var, so the token stays 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.

[mcp_servers.redirhub]
url = "https://api.redirhub.com/mcp/v1"
bearer_token_env_var = "REDIRHUB_MCP_TOKEN"
default_tools_approval_mode = "prompt"

Any other MCP client

For any other host, register RedirHub as a remote HTTP (Streamable HTTP) server at https://api.redirhub.com/mcp/v1 and send Authorization: Bearer <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://api.redirhub.com/mcp/v1",
  "headers": {
    "Authorization": "Bearer ${REDIRHUB_MCP_TOKEN}"
  }
}

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, OAuth support, and any per-token scoping 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. Check the header spelling, the token value, env expansion, token revocation, and whether the client forwards custom headers at all.
403
Authenticated but refusedThe request was understood and rejected. Re-check which account issued the token and what that account can reach; RedirHub does not publish the specific conditions, so confirm with the workspace owner rather than guessing.
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://api.redirhub.com/mcp/v1 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.