MCP tools not showing: check tools/list and client filters

Separate connection from usable tools

Successful initialization confirms protocol contact. It does not promise that the server offers every tool you want or that your account can use every operation. First record which server and version you connected to. Then check whether initialization declares the tools capability. A service can expose other MCP features. A missing tool therefore does not automatically indicate a transport failure, and changing an HTTP endpoint is not the first useful response.

Read the complete tool list

The protocol method tools/list returns available tools with their names, descriptions and input schemas. If a response contains nextCursor, further results can be requested with that cursor. Do not compare only the first page with your expectations. The list may depend on authorization context, so record the account used as well. If you maintain your own client, preserve the returned cursor unchanged and stop paging when the response no longer supplies another one.

Compare server output with the client interface

If the tool exists in the complete server response but is absent from the interface, inspect the client’s selection and filters. Some setups enable only a subset of available functions. If it is already absent from the server response, compare the server version, provider documentation, account permissions and any configured tool groups. Use the same transport and account context for a comparison test. A test made with a different account answers a different question and should be recorded separately.

Call a visible tool in a controlled test

Read the input schema before making a call. Choose a known test resource and a bounded read operation. Inspect the result content: a technically successful response can still report an application tool failure through isError. Record the tool name, sanitized input, expected result and actual result. MCP Inspector can help examine connection, discovery and invocation separately; it actually executes the calls you choose. Treat that as an operation against your environment, rather than a static configuration check.

1. Record the server version, account and declared capabilities.

2. Compare the full tool list with the client interface.

3. Check one bounded read operation and record application failures as well.

Use the troubleshooting navigator for other symptoms and their next checks. The configuration builder helps compare formats. Use the registry comparison when similarly named entries declare different packages or launch paths. A registry declaration describes its source; it does not replace your connection test.

Can the tool list change?

Yes. A server can notify the client of a list change when it declares that capability. Check whether the client refreshes its list afterwards.

Does a visible tool prove access?

No. The operation may still fail because of the target resource or missing permissions.

Why do two tool lists differ?

Compare server version, account, complete pagination and enabled tool groups before assuming a protocol failure.

How can I check the server independently?

MCP Inspector can inspect tool discovery and invocation separately. Use the same account context and a bounded test.

Sources checked on 1 October 2026. The checks are editorial suggestions for your environment.

1. MCP 2025-11-25: Tools
   Show retrieval command

   curl -s https://modelcontextprotocol.io/specification/2025-11-25/server/tools
2. MCP 2025-11-25: Lifecycle
   Show retrieval command

   curl -s https://modelcontextprotocol.io/specification/2025-11-25/basic/lifecycle
3. MCP Inspector
   Show retrieval command

   curl -s https://modelcontextprotocol.io/docs/tools/inspector

All posts