# Why is a tool missing from tools/list? (/blog/why-is-a-tool-missing-from-tools-list)

![Illustration: A small friendly robot with a round camera-eye head looks into an open toolbox with one empty outlined slot where a tool should be.](/blog/why-is-a-tool-missing-from-tools-list/hero.webp)

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.

**Work the checklist top to bottom**

1. **Is the app connected for this caller?** (no notion\_\_\* tools at all) — Connect it in Dashboard, Connectors, or use a sign-in that has the connection.
2. **Is the capability on?** (no memory\_\_*, media\_\_*, web\_\_\* or social\_\_\*) — Dashboard, Tools. A member setting only narrows the org ceiling.
3. **Is the caller an agent key?** (a teammate sees it, the sk-csa- key does not) — An agent reaches shared connections only. Share the connection.
4. **Did the session start before the change?** (you connected an app, the list did not move) — Start a new session, or reconnect the server in the client.
5. **Is the server registered twice?** (some tools vanish or collide) — Keep one corespeed entry, at user scope.
6. **Right environment, right org?** (keys are per environment) — 404 endpoint\_not\_found means not offered here. Switch orgs with manage\_\_switch\_org.

The first three rows cover most reports.

## Why is tools/list different for each caller? \[#why-is-toolslist-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](/docs/mcp) recommends. Never construct a tool inventory in application code.

## What are the usual causes? \[#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 \[#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](/docs/errors).

## How do you check from the command line? \[#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:

```bash
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](/docs/capability-controls) and the [connectors page](/docs/connectors) describe.

## FAQ \[#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.