Why an MCP connection can show the wrong tools
A connected server can legitimately expose different tools to different credentials. When a tool is missing, inspect discovery and access scope before assuming that the tool was removed.
Compare the intended and observed catalog
Write down the expected operation, the credential used by the client, and the returned tool names. Check whether the client retains an earlier discovery result after a connection changes. Also distinguish the remote server's catalog from tools exposed by an application's own inference gateway: they may be separate discovery surfaces with different naming and availability rules.
- 1List tools using the same credential as…List tools using the same credential as the failing client.
- 2Confirm the scope required for the missing…Confirm the scope required for the missing operation.
- 3Refresh discovery through the client's supported mechanism…Refresh discovery through the client's supported mechanism and compare results.
Try it on a small example
- List tools using the same credential as the failing client.
- Confirm the scope required for the missing operation.
- Refresh discovery through the client's supported mechanism and compare results.
What to verify
Do not solve missing read access by immediately granting every write scope. Determine which permission is required and test it narrowly. Baleybots documents one remote MCP endpoint with tools gated by service scopes. Pipeline event discovery requires pipelines:read; credentials lacking it receive an empty event catalog. A connector's account being linked does not by itself prove that every chat has refreshed its tool inventory.
Product details checked against the MCP reference on October 4, 2026. These guides describe documented behavior; availability depends on your account and the deployed service. Baleybots is in invite-only beta.