Expose an API as MCP

An MCP server on RequestRocket is a record plus a tool catalog. The URL is:

https://{region}.requestrocket.com/mcp/{mcpId}

{mcpId} can be the server id or its alias. There is no separate deployment. Setting the server inactive stops traffic.

Credentials

Inbound authentication is one of: API key, bearer token, basic auth, a static JWT string, or IdP Verify.

A credential type named JWT does not check a signature. It compares the header to a stored string. Use IdP Verify when the token is minted by your own identity provider. IdP Verify needs an https issuer, the audience your provider actually puts on the token, and a JWKS URI. It does not use a shared secret. For Microsoft Entra ID sign-in from Claude, see Sign in with Microsoft Entra ID.

Agents that use a pasted header must not be offered discovery metadata, because clients that find it can ignore the configured header. IdP Verify keeps discovery off unless you turn it on for that credential. When discovery is on, an unauthenticated call gets a 401 whose protected-resource metadata names your identity provider as the authorization server. When discovery is off, the gateway does not publish an authorization server, and the caller must send a token that credential can verify. A failed check, including a token that misses required claims, is a plain rejection. The gateway does not return a separate insufficient_scope body, and it does not show a RequestRocket sign-in page for an external provider. OAuth credentials publish path-scoped discovery for that server only, and the authorization server issuer is https://{region}.requestrocket.com/oauth2. The root well-known authorization-server document stays absent. API key, bearer, basic, and static JWT credentials do not publish discovery. A missing or wrong header is rejected, and there is no sign-in page for them.

Cursor mcp.json:

{
  "mcpServers": {
    "example": {
      "url": "https://ap-southeast-2.requestrocket.com/mcp/your-id",
      "headers": { "Authorization": "Bearer your-token" }
    }
  }
}

Claude Code:

claude mcp add example --transport http https://ap-southeast-2.requestrocket.com/mcp/your-id --header "Authorization: Bearer your-token"

Claude Desktop adds remote servers through Connectors, not the stdio config. A url entry with no type is treated as stdio and skipped. Claude Code accepts streamable-http as an alias for http.

OpenAPI quality

Paste an OpenAPI 3.x document to generate tools. The first paste enables every operation that is not marked deprecated. You turn off the ones you do not want, then save.

Pasting a new document over an existing catalog does not replace your edits. The default is merge:

• Descriptions, names, and schemas you changed stay as you left them.
• Enabled and disabled stay as you set them.
• New operations are added, enabled unless the spec marks them deprecated.
• Operations that disappeared are kept and marked removed until you delete them.

Overwrite is a separate choice. It replaces generated names, descriptions, and schemas, and it still keeps each tool's enabled flag unless you also reset those flags. Manual tools are left alone. Nothing is written until you save the preview.

Prefer stable operationId values. A renamed id looks like a removed tool plus a new one.

Server URL and target matching

The OpenAPI spec's servers[0].url should match the base URL of the target you selected. Tool paths are relative to the target's base URL, so a mismatch means requests will be sent to the wrong path. For example, if your spec declares servers: [{url: "https://api.example.com/v2"}] but your target is https://api.example.com, tool paths like /users will resolve to https://api.example.com/users instead of https://api.example.com/v2/users.

The builder warns you when the spec's server URL does not match the target. If you see this warning, either update your target's base URL to include the full path prefix, or adjust the spec's servers entry to match the target.

Policy tabs

A direct MCP owns Connect, Control, Govern, and Observe itself. Rules, filters, meters, overrides, alerts, transforms, and request history are stored against the MCP id and run when a tool is called.

A proxy-backed MCP shows the same tabs, but those settings belong to the backing proxy. The MCP page links to the proxy's matching tab. MCP tool telemetry still appears on the MCP Observe tab.

Switching from direct to proxy-backed replaces the active policy with the proxy's configuration. The direct policy is kept as a fallback and does not run until the MCP is switched back. Switching from proxy-backed to direct removes the proxy from the MCP execution path. Later requests use the MCP's own actions, including any direct policy that was kept as a fallback.

When a reference is deleted

Deleting a credential, target, or proxy does not delete the MCP server or any other proxy that points at it. The list shows a reference status. A missing inbound credential or backing proxy fails before a session starts. A missing target still allows tool listing, and the tool call explains which resource is missing.

Proxies that were previously marked to expire after a target deletion can still be removed for up to 30 days unless that expiry is cleared. New deletions do not schedule that expiry.

Consumers

An MCP server that uses OAuth identifies each caller as a consumer. You invite consumers from the MCP page. The invitation email contains a temporary password. The consumer chooses their own password the first time they sign in, and they reset a forgotten password from that same sign-in page.

A consumer is one person for your organisation. Assigning them to an MCP server is a separate step. The same person can be entitled to more than one server, including servers in different regions. They keep a single password.

Removing an entitlement stops that person from calling that server. On the next call, a token they already hold is challenged and sign-in explains whether access was never granted, turned off, or has expired. The page names the signed-in account, the server, and the app that sent them. It links back to that app with error=access_denied, and it offers sign-in with a different account. A bad or expired token is rejected without that page. Removing the consumer deletes every entitlement they have with you. If no other organisation still uses that same identity, the sign-in account is removed as well.

Deleting an MCP server removes the entitlements that pointed at it. It does not delete the consumer. The sign-in account is removed only when that person has no entitlements left anywhere and is not invited by another organisation.