Remote MCP server setup: connect Invoke Human

A remote MCP server is a URL. The client learns how to sign in from a 401.

Updated October 17, 2026

1. Call the MCP endpoint with no token. POST to the MCP URL. A protected server returns 401 and a WWW-Authenticate header pointing at protected-resource metadata.
2. Read the protected-resource metadata. GET the resource_metadata URL. It names the resource, the authorization servers, and the scopes.
3. Read the authorization-server metadata. GET the authorization server's well-known URL. It lists the authorize, token, register, and revoke endpoints.
4. Register, then sign in with PKCE. If the client has no client id, it uses dynamic client registration, then authorization code with S256 PKCE and the resource indicator.
5. Send the bearer token on MCP calls. Later requests put the access token in the Authorization header. Refresh and revoke are ordinary OAuth.

Most MCP tutorials start with npx something and a subprocess. That is stdio: the client owns the process, and the spec says that kind of server should take credentials from the environment, not from OAuth.

A remote server is the other shape. It is already running. The client sends MCP messages over HTTP, which for current servers means streamable HTTP. SSE is the older transport. Invoke Human is streamable HTTP at https://invokehumantool.com/mcp.

The useful part is what happens when the client has no token yet. The numbers below were read from the live server on October 14, 2026. If a field is added later, the metadata URLs win over this page.

The 401 is the instruction

An initialize with no Authorization header does not return a tool list. It returns 401 and:

WWW-Authenticate: Bearer realm="handoffs", resource_metadata="https://invokehumantool.com/.well-known/oauth-protected-resource/mcp"

That header is RFC 9728. The MCP authorization spec (2025-06-18) says a protected HTTP server must send it, and the client must be able to read it. The client is not supposed to guess where login lives.

The same call from a shell:

curl -sS -D - -o /dev/null -X POST https://invokehumantool.com/mcp \
  -H 'content-type: application/json' \
  -H 'accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"curl","version":"0"}}}'

The body is a JSON-RPC error, Unauthorized. That is expected. curl is not going to open a browser.

What the metadata says

Protected resource metadata, at the URL from the header:

{
  "resource": "https://invokehumantool.com/mcp",
  "authorization_servers": ["https://invokehumantool.com"],
  "scopes_supported": ["handoffs"],
  "bearer_methods_supported": ["header"],
  "resource_documentation": "https://invokehumantool.com/"
}

One resource, one authorization server, one scope. Tokens travel in the Authorization header, not in the query string.

The client then loads OAuth authorization server metadata (RFC 8414):

{
  "issuer": "https://invokehumantool.com",
  "authorization_endpoint": "https://invokehumantool.com/authorize",
  "token_endpoint": "https://invokehumantool.com/token",
  "registration_endpoint": "https://invokehumantool.com/register",
  "revocation_endpoint": "https://invokehumantool.com/revoke",
  "response_types_supported": ["code"],
  "grant_types_supported": ["authorization_code", "refresh_token"],
  "code_challenge_methods_supported": ["S256"],
  "token_endpoint_auth_methods_supported": ["none"],
  "revocation_endpoint_auth_methods_supported": ["none"],
  "scopes_supported": ["handoffs"]
}

Read that as a contract:

• Authorization code only. No implicit grant, no password grant.
• Refresh tokens exist. So does revocation.
• PKCE is S256, which is the method OAuth 2.1 requires for a public client.
• token_endpoint_auth_methods_supported is none. The client has no secret. Anyone who copies a client secret into a desktop config has invented a credential the server did not ask for.
• registration_endpoint is dynamic client registration. A client that has never seen this server can POST to /register and get a client id. The MCP spec recommends this because the client cannot ship a client id for every server a person might add.
• The metadata does not advertise Client ID Metadata Documents. Clients that prefer CIMD when a server says it supports it should fall through to DCR here. Codex documents that choice explicitly.

The spec also requires the OAuth resource parameter (RFC 8707) on the authorization request and the token request, set to the MCP resource URL. That binds the token to https://invokehumantool.com/mcp rather than to “whatever resource feels like it”.

What you do, and what the client does

You do not perform those HTTP calls by hand. Cursor, Claude, Codex, and ChatGPT do, once you give them the MCP URL. The guides are the clicks:

• Cursor wants the URL in mcp.json and no static client id.
• Claude wants “Register automatically” on the connector, or claude mcp add --transport http for Claude Code.
• Codex wants url under mcp_servers and codex mcp login.
• ChatGPT on the web wants a custom MCP plugin with OAuth and no pasted client id.

A custom agent is the same sequence: 401, resource metadata, authorization server metadata, register if you have no client id, authorization code with S256 PKCE and the resource parameter, then Authorization: Bearer on MCP requests. The MCP authorization spec is the checklist. Client install for Cursor, Claude, Codex, and ChatGPT is on the guides, and the short version is on Support.

After the token is in place, initialize and tools/list succeed. The tools are send_handoff, send_ui_handoff, send_html_handoff, validate_ui, share_handoff, delegate_handoff, get_handoff_status, get_handoff_result, and wait_for_handoff. send_handoff sends a handoff to the signed-in person, or to other people. send_ui_handoff sends a structured form the person answers on a device or a signed link. send_html_handoff sends an HTML handoff the person answers by tapping or typing. validate_ui checks a UI document before it is sent. share_handoff invites more people to a handoff, or forwards it. delegate_handoff forwards a handoff to new recipients. get_handoff_status reads the type, title, and status of one handoff. get_handoff_result fetches the answer, or the current status if it is not finished. wait_for_handoff waits until the person finishes that handoff. Parameter names come from that tool list. The inbox those calls land in is described on the agent inbox page.