MCP API — Kindo extensions

By default, POST /v1/mcp is a stock spec-conformant MCP server. Kindo adds two opt-in extensions on top of the spec:

1. Integration filter — narrow tools/list to a specified subset of your integrations.
2. Connection management REST endpoints — list connections and select a preferred connection for each integration.

Use these when you need them; ignore them and the gateway still works.

1. Integration filter

Pass an explicit allow-list as either a query parameter or a header, and tools/list returns only those integrations’ tools:

# Query parameter
curl -X POST "https://api.kindo.ai/v1/mcp?integrations=linear,github" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -H "Authorization: Bearer $KINDO_API_KEY" \
  -d '{ "jsonrpc": "2.0", "method": "tools/list", "id": 1 }'

# Header (equivalent)
curl -X POST https://api.kindo.ai/v1/mcp \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -H "Authorization: Bearer $KINDO_API_KEY" \
  -H "x-kindo-integrations: linear,github" \
  -d '{ "jsonrpc": "2.0", "method": "tools/list", "id": 1 }'

The filter narrows the set you would otherwise see — it never grants access. If your account can’t reach github and you ask for ?integrations=linear,github, you get only Linear tools back (no error). Both forms accept comma-separated values; the query parameter also accepts the array repetition form (?integrations=linear&integrations=github). If both query and header are present, the query parameter wins.

For the underlying rules — which integrations your account can reach in the first place — see Scoping.

2. Connection management REST endpoints

These are regular Kindo REST endpoints, not MCP methods. Use them to list your connections and select a single preferred connection for an integration. Your active connections also serve as personal defaults for Kindo chats and agents.

GET /v1/integrations/connections

Returns all integration connections accessible to the API-key holder, including shared group connections. Each entry’s is_preferred field indicates whether it belongs to your active connection set for that integration. Several connections can have is_preferred: true.

curl https://api.kindo.ai/v1/integrations/connections \
  -H "Authorization: Bearer $KINDO_API_KEY"

{
  "data": [
    {
      "id": "conn_abc123",
      "display_name": "Charlie's Linear",
      "integration_config_id": "linear",
      "nango_connection_id": "nango_conn_1",
      "is_preferred": true,
      "created_at": "2026-03-10T18:45:23.000Z"
    }
  ]
}

POST /v1/integrations/connections/{integration_id}/default

Sets the specified connection as your only active connection for an integration. {integration_id} is the same value as integration_config_id returned by the list endpoint (e.g., linear, github).

This replaces your entire active connection set for that integration with the specified connection. It also changes the personal defaults used by Kindo chats and agents that do not have pinned connections.

curl -X POST https://api.kindo.ai/v1/integrations/connections/linear/default \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $KINDO_API_KEY" \
  -d '{ "connection_id": "conn_abc123" }'

{
  "integration_config_id": "linear",
  "connection_id": "conn_abc123"
}

Code	Meaning
400	Invalid request body — connection_id is required, or connection_id does not belong to integration_id.
403	Forbidden — you are not authorized to use this connection.
404	Integration connection not found (or you do not have access to view it).

Once set, the default flows through to tools/call resolution. See Scoping → Default-connection resolution for where your preferred connection sits in the resolution chain.

RFC9728 discovery

Kindo serves an RFC 9728 Protected Resource Metadata document so MCP clients can auto-discover the bearer-token authentication mode:

• GET https://api.kindo.ai/.well-known/oauth-protected-resource
• GET https://api.kindo.ai/.well-known/oauth-protected-resource/v1/mcp

Both return the same document, with the second path provided for clients that follow RFC9728’s path-scoped lookup rule. The body confirms bearer-header mode:

{
  "resource": "https://api.kindo.ai/v1/mcp",
  "bearer_methods_supported": ["header"],
  "authorization_servers": ["https://api.kindo.ai/oauth"],
  "scopes_supported": ["kindo.mcp"]
}

Tokens are plain bearer tokens — Kindo does not support DPoP-bound tokens on this resource.

The authorization_servers entry is a real issuer, not a placeholder — but a narrow one. It supports only the ID-JAG urn:ietf:params:oauth:grant-type:jwt-bearer grant, and only for an organization with Cross App Access enabled: an admin approves an Okta app to redeem an Okta-issued ID-JAG for a short-lived Kindo MCP access token scoped to kindo.mcp, on behalf of a signed-in user. It does not support authorization_code or dynamic client registration, and static Kindo API keys remain the default way to call /v1/mcp — most integrations never need this issuer.

See also

• Scoping — the deeper read on what tools your account can reach.
• Errors — the WWW-Authenticate header tied to RFC9728 discovery.