Why is a tool missing from tools/list?
A tool is missing from tools/list because this caller cannot call it now: app not connected, capability off, agent key reach, or a stale session.
A tool is missing from tools/list because the caller who asked cannot call it right now. On CoreSpeed the list is caller-specific: it returns exactly what this sign-in can invoke. Absence is a decision, made by a connection that does not exist, a capability that is off, a key with narrower reach, or a session that started before the change.
- 1Is the app connected for this caller?no notion__* tools at allConnect it in Dashboard, Connectors, or use a sign-in that has the connection.
- 2Is the capability on?no memory__*, media__*, web__* or social__*Dashboard, Tools. A member setting only narrows the org ceiling.
- 3Is the caller an agent key?a teammate sees it, the sk-csa- key does notAn agent reaches shared connections only. Share the connection.
- 4Did the session start before the change?you connected an app, the list did not moveStart a new session, or reconnect the server in the client.
- 5Is the server registered twice?some tools vanish or collideKeep one corespeed entry, at user scope.
- 6Right environment, right org?keys are per environment404 endpoint_not_found means not offered here. Switch orgs with manage__switch_org.
Why is tools/list different for each caller?
Every request resolves to one principal inside one organization, and that pair decides which connectors, accounts, memories and tools the response contains. A member with a private Notion connection sees notion__create_page. A teammate without one does not. An agent key sees the organization's shared connections only. A member who turned Web off in Dashboard → Tools sees no web__* tools at all.
So there is no catalog to compare against. The right move is to run tools/list after authentication and use the names and input schemas that come back, as the MCP server page recommends. Never construct a tool inventory in application code.
What are the usual causes?
| What you see | Likely cause | Fix |
|---|---|---|
No connector tools for an app, such as notion__* | The app is not connected for this caller | Connect it in Dashboard → Connectors, or use a sign-in that has the connection |
No memory__*, media__*, web__* or social__* tools | The capability is off for this member, or at the org level | Turn it on in Dashboard → Tools; a member setting only narrows the org ceiling |
| Tools appear for a teammate, not for an agent key | The connection is private; an agent reaches shared only | Share the connection, or connect a shared one |
| You connected an app, the list did not change | The client read tools/list when the session started | Start a new session, or reconnect the server in the client |
| Some tools are there, others vanish or collide | Two registrations of the server in the client | Keep one corespeed entry, at user scope |
| Tools appear in one environment, not another | Keys are per environment; a connector may not be offered there | Use the key for that environment; 404 endpoint_not_found says the connector is not offered |
A connector errors with not_configured | This environment lacks an app registration | Support; reconnecting does not help |
Everything is missing, including manage__* | The request is not authenticated, or reached the wrong organization | Check the header form; switch with manage__switch_org or cs switch |
Work the table top to bottom. The first three rows cover most reports.
When the tool is present but still fails
The opposite case is just as common and is worth separating. Presence is not health: a connector account in needs_reauth still contributes its tools, and those calls fail until the member reauthorizes in Dashboard → Connectors. Presence is not permission: the session-gated manage__keys_*, manage__agents_*, manage__accounts_*, manage__whoami and manage__switch_org tools are listed for an API key and answer jwt_session_required when called.
And a tool with several accounts behind it answers ambiguous_account until the call names one with the account argument; the aliases are in structuredContent.error.aliases. None of these are discovery problems. The tool is there; the call needs a different caller, a reauthorized account, or one more argument. The remedies are collected on the error handling page.
How do you check from the command line?
Two authenticated reads answer the question. The connector index says which apps this caller can connect and what account state exists. tools/list says which tools this caller can invoke now. For the first:
curl https://api.corespeed.io/connectors -H "Authorization: Bearer $CORESPEED_API_KEY"Each account in the response carries its status, which is where needs_reauth shows up. For the second, the cs CLI runs cs mcp search and cs mcp get against your own sign-in, so you see the list your agent sees without reading a client's debug output. An MCP OAuth token from browser sign-in works only on POST /mcp; the connector route takes an API key or a session JWT.
If the list is right from the command line and wrong in the client, the client is holding a stale session or a duplicate entry. If the list is wrong in both places, the cause is in the organization: a connection, a capability setting, or the key's reach, as the capability controls page and the connectors page describe.
FAQ
Is a missing tool a bug? Usually not. The list says what this caller can do. Find the decision that removed it: a connection, a setting, or the credential's reach.
Does disabling a capability delete its data? No. Disabling unregisters the tools from tools/list. The data stays.
Why does an agent key see fewer tools than I do? An agent principal reaches the organization's shared connections only, never a member's private ones.
Do I need to restart the client after connecting an app? Clients read tools/list at session start. Start a new session or reconnect the server to pick up the new tools.