Access & limits

Three kinds of credential, for three different callers.

| Credential | Held by | Used for | | --- | --- | --- | | OAuth 2.1 | your MCP client | calling connectors from your own agent | | API key | your backend | clients that cannot do OAuth | | Embed key (wk_…) | a page you published | a widget or hosted app calling one app |

Manage keys at Access.

OAuth 2.1

The preferred path. Connectors support PKCE and dynamic client registration, so a capable client registers itself, you approve once in a browser, and tokens refresh without anyone storing a long-lived secret.

Metering

Every call — from an agent, an app, or a widget — passes the same ladder before anything expensive happens:

  1. Origin — cheapest check first, a string compare
  2. Credential — one lookup
  3. Per-visitor burst — a counter, to blunt a flood
  4. Per-app concurrency — this one queues rather than refusing
  5. Monthly allowance — what your plan actually entitles you to

Two properties worth knowing:

Every refusal is counted by reason. Activity has to be able to tell "nobody used it" apart from "everybody was turned away", and it can only do that if each rung records why it said no.

Concurrency is not an error. Rung 4 makes a caller wait rather than fail, because a burst of legitimate traffic is not abuse.

Before you sign in

You can use the catalogue without an account: browse everything, read every connector page, and get one free question per connector.

Twenty-two connectors, so up to twenty-two tastes — but never two against the same one. The second question to a connector you have already tried is where you are asked to sign in, because at that point you have already seen it work.

The count is per browser, not per IP. An office behind one shared address would otherwise have its first visitor consume a connector for everyone else in the building.

Rate limits on your own apps

A published app carries its own limits: burst per visitor, concurrency, and a monthly allowance. Set them in the app's Publish tab. They apply wherever the app is called from, because every path goes through the same gateway.

What we do not do

We do not accept an unsigned subject from a query parameter, an attribute, or a postMessage. An embedded app's caller is either presenting a signed token or is anonymous — there is no third path, and an anonymous visitor is never promoted to a named one as a side effect of anything.