Ingram Cloud
Sign inGet started

Documentation

Connectors

OpenAPI spec
Docs

Connectors

An mcp deployment is a standard MCP server. Connector OAuth makes it connectable from an MCP host — Claude custom connectors and ChatGPT developer-mode connectors today — with no out-of-band token handling: the host gets one URL, discovers the rest, and each person authorizes their own connection.

Connect in Claude

  1. Deploy the agent:

    # Authorization: tenant-admin token (server-side only)
curl -X POST https://api.cloud.ingram.tech/v1/deployments \
  -H "Authorization: Bearer $IC_TOKEN" \
  -H "IC-Api-Version: 2026-05-01" \
  -H "Content-Type: application/json" \
  -d '{ "target": { "type": "agent", "id": "agt_…" }, "kind": "mcp" }'
# → 201 { "id": "dep_…", "kind": "mcp", … }

  2. In Claude, open Add custom connector (Customize → Connectors → + → Add custom connector; Team and Enterprise plans: Settings → Organization settings → Connectors) and fill it in:

    • Name — anything; the agent's name reads best.
    • Remote MCP server URL — https://api.cloud.ingram.tech/v1/deployments/dep_…/mcp.
    • Advanced settings (OAuth Client ID / Client Secret) — leave empty. Claude registers itself with the API automatically.

  3. Claude opens the Ingram Cloud consent page. The person pastes their connect token (below) and clicks Authorize. Done — Claude holds its own short-lived credentials from here on and refreshes them itself.

The console has the same walkthrough with the URL pre-filled: Deployments → Connect on any mcp deployment.

Connect in ChatGPT

Same server, same URL. In ChatGPT, Settings → Apps & Connectors → Advanced → Developer mode (once), then Create connector with the deployment's MCP URL. ChatGPT runs the identical OAuth flow through the same consent page.

The connect token

The consent page authenticates the person with a token you already mint — nothing new to build:

  • agent target — the smith token you minted for that person's smith. The smith must run the deployment's agent; the connection is bound to it, so the person talks to their smith — own memory, own threads.
  • smith target — that smith's token, or a tenant-admin token.

The pasted token authorizes once. Afterwards the connection runs on tokens the API mints for it: 1-hour access tokens (ordinary smith tokens scoped to runs:write) and a rotating refresh token that lapses after 90 days unused. So a short-TTL connect token is fine — mint it, show it to the person, let it expire.

What the host sees

Exactly the MCP server surface: the ask tool and the smith's working memory as a read-only resource. Isolation is the deployment's: distinct people authorize distinct smiths.

How discovery works

Everything is a published standard; no Ingram-specific client code exists in the loop:

  1. The host POSTs the MCP URL unauthenticated → 401 with a WWW-Authenticate header naming the Protected Resource Metadata (RFC 9728).

  2. That metadata names the authorization server; its AS metadata (RFC 8414) lists the endpoints:

    # Unauthenticated (discovery)
curl https://api.cloud.ingram.tech/.well-known/oauth-authorization-server
# → { "authorization_endpoint": "…/oauth/authorize",
#     "token_endpoint": "…/oauth/token",
#     "registration_endpoint": "…/oauth/register", … }

  3. The host registers itself (Dynamic Client Registration, RFC 7591) and runs the authorization-code flow with PKCE (S256 only).

  4. The tokens it receives verify against /.well-known/jwks.json — the same RS256 key family as every Ingram Cloud token.

Claude's connector directory and the ChatGPT Apps SDK (rich in-chat UI, app-store listing) are distribution steps on top of this same server and are not available yet; a connector needs nothing beyond the URL.

Deployments & schedulesPulumi provider