Capability discovery
Ask the two authenticated discovery questions instead of reading a static catalog that cannot know who is calling.
Discovery is caller-specific in v0. There is no public catalog to read: the answer to "what is available" depends on which member of which organization is asking, so both discovery surfaces are authenticated.
| Question | Source of truth |
|---|---|
| Which connectors exist, and which accounts can this caller see? | GET /connectors |
| Which tools can this caller see right now? | MCP tools/list on POST /mcp |
The two are not interchangeable. GET /connectors describes potential — what
could be connected and what account state exists. tools/list describes
visibility — the surface this caller is offered right now. It is not a
guarantee of execution: see the caveats below before treating a listed tool as
callable.
Full request and response contracts: GET /connectors and tools/list.
tools/list is the visibility authority
It already reflects connected accounts, hidden registrations, and organization plus member capability settings. So:
- Do not build a static tool inventory in application code. Read the names and input schemas back from the response.
- Absence is a decision, not a bug. If a tool is missing, this caller cannot invoke it — the capability is off, or the account is not connected.
- Presence is not health. A connector account in
needs_reauthstill contributes tools; those calls fail until the account is reauthorized. Check accountstatusinGET /connectorswhen a visible tool keeps failing. - Presence is not permission either. The session-gated
manage__*tools (keys_*,whoami,accounts_*) are listed for an API-key caller but answerjwt_session_requireduntil the request carries a user session. The fourmanage__remote_*tools are the exception — they accept API keys, subject to their own role and hold checks.
An authenticated GET /engines inventory does not exist yet. Do not infer a
built-in tool list from the retired /catalog; only advertise or call a
built-in when it appears in tools/list.
The index is the availability authority
GET /connectors is the only place that answers "what can I connect here". A
connector withheld from it — upstream OAuth approval still in progress,
credentials not present on this environment — is not reachable through any
other door: GET /connectors/:id answers 404 for it, identically to an id
that does not exist, and starting its connect flow fails. Whether a connector
is offered is internal operations state and is published nowhere.
(One exception, so a grant can always be revoked: if you still hold accounts on a connector that stopped being offered, it stays in the index and on its own route until you disconnect them.)
Nothing about the connector count or list belongs in a client. Both change without notice as approvals land.