# Why Is My MCP Tool List Empty? A Practical Diagnostic Guide [Read the original article]() By Garry · Founder Published: 2026-09-29T20:06:24.105Z Updated: 2026-09-29T20:13:22Z 7 min read Categories: Social media tools Separate client display issues, discovery failures, narrow grants, account limits, and unsupported features before changing access. ![A mint component sits behind a transparent blue panel in the center of an ivory display with empty recesses.]() ## Key takeaways - A client showing no tools is different from the server returning an empty list. - Compare the expected operation with the actual task, grant, and account eligibility. - Check supported refresh and pagination behavior before treating missing tools as a server defect. The client says it is connected, but no Caroush tools appear. That symptom does not identify one cause. The interface may be filtering tools, the connection may have a narrow grant, discovery may have failed, or the client may be showing a cached result from an earlier attempt. The useful first move is to separate “the client displays no tools” from “the server returned an empty tool list.” Once you know which statement is true, you can investigate the relevant layer without granting unnecessary access or inventing a different endpoint. ## Verify the connection you are actually inspecting Start with the configured server identity and endpoint. A client can contain several similarly named connections, including old experiments or a local development server. The visible label alone does not establish which service it contacted. Confirm the current Caroush setup path through the [client documentation](). Record the installed client version and whether authorization completed. A saved configuration entry is not the same as a successful protected connection. If the client has a per-task or per-workspace tool setting, inspect that supported control. Some interfaces can hide or disable tools locally even when the server exposes them. Avoid assuming a specific setting exists in every product; consult the client's current documentation. The [Caroush MCP selector]() is an entry point to setup information. It does not prove that the active client instance is connected to the right resource or has completed the required OAuth flow. ## Distinguish discovery from invocation The [MCP tools specification]() describes tools/list for discovery and tools/call for invoking a named operation. Discovering a tool and successfully using it are separate checks. If tools/list failed, inspect the actual protocol or authorization error. If it returned an empty list, compare that response with the granted scopes and service behavior. If it returned tools that the interface does not display, investigate client filtering or caching rather than immediately changing the server. A natural-language request such as “show your tools” can be a useful interface action, but the assistant's answer is not necessarily the raw discovery result. It may summarize what the model currently knows or omit disabled capabilities. Use the client's supported connection diagnostics when a precise distinction is needed. For a team using an [AI content workflow](), keep discovery troubleshooting separate from creative prompting. Rephrasing the desired caption does not make an absent tool appear. ## Compare the grant with the operation you expect Caroush documents scopes for reading context, creating content, generating assets, requesting publication, and other actions. The authenticated tool list can depend on the connection's grant. A draft-only connection should not be expected to expose every consequential operation in the public catalog. The [MCP authorization specification]() describes scope selection and insufficient-scope handling. Read the service's tool reference to identify the permission associated with the expected operation. Do not grant all scopes merely to see whether the list grows. First write down the task and the specific tool required. If that capability belongs in the workflow, update the grant through the documented consent flow. If it does not, the missing tool may be an intentional protection. A connection used to inspect drafts does not need publishing authority just because the team also uses a [social scheduler](). Different roles can have different legitimate tool sets. ## Check account eligibility and workspace context A valid login does not override account conditions. Caroush documents API/MCP access for eligible active paid plans and excludes the seven-day trial. Saved analytics has its own Pro requirement. Current account and membership checks still apply after consent. Confirm the selected user and workspace. A teammate may have authorized a different account in the browser, or a previously valid membership may have changed. The tool list and subsequent operations should reflect the actual grant, not the brand mentioned in the prompt. Use the application and permitted context reads to verify what the connection represents. Do not attempt to repair an ownership mismatch by guessing object identifiers or borrowing another person's token. A [multi-account workflow]() should make the expected workspace explicit in its setup notes. That helps distinguish an unexpectedly narrow connection from a correctly restricted connection to the wrong context. ## Inspect pagination, caching, and list changes Tool discovery can be paginated. A client that reads only the first page may show an incomplete list rather than a truly empty one. The tools specification also defines optional list-change behavior for servers that declare support. These details matter when a client appears to have some capabilities but is missing a particular category. Confirm that the client handles the server's discovery contract and uses its supported refresh behavior. Do not repeatedly reconnect without knowing whether the old list is simply cached. Avoid asserting that a particular server emits list-change notifications unless its declared capabilities establish that behavior. A general protocol feature is not proof that Caroush implements every optional update mechanism. After refreshing through the supported client path, compare the newly observed list with the task's required operations. Keep a short record of which tools are expected and why. This makes a change visible without requiring the team to memorize the entire catalog. ## Separate missing tools from unsupported features An assistant can expect a tool that does not exist. For example, a plan might mention an arbitrary upload-link operation or a web-research tool even though Caroush's verified catalog does not provide that capability. Check the [current tool reference]() before treating the absence as an installation failure. A service can support image-post creation from existing owned media without exposing arbitrary file upload through MCP. It can support content preparation without supplying general web browsing. The correct remedy may be a manual handoff or another separately authorized capability. It is not to invent a tool name, try undocumented routes, or widen the grant until a speculative operation becomes available. This distinction protects product expectations too. A logo in a client selector does not establish a vendor partnership or a fully tested connector. Diagnose actual protocol support rather than treating a marketing label as a compatibility contract. ## Work through a draft-only example A writer connects an assistant to prepare product captions. The client shows workspace reads and draft creation, but no publication tool. The writer assumes the setup failed because the public reference includes publication. First, compare the assigned task with the grant. If the writer is responsible only for drafts, the available list may be correct. The account owner can review the draft in Caroush and handle publication through the normal approval process. If the writer's role has explicitly expanded to preparing publication requests, review the required scope and current plan conditions, then update authorization through the documented flow. Afterward, refresh discovery and verify the expected operation without making a real post. The same symptom therefore leads to different decisions depending on the task. Tool absence is not inherently a defect; the question is whether the connection exposes exactly the capabilities its authorized purpose requires. ## Escalate with a minimal, reproducible report If the expected tool remains unavailable after the relevant checks, provide the server endpoint, client version, authorization stage, expected operation, observed discovery result, and redacted error or request reference. State whether the server returned an empty list or the interface merely displayed one. Exclude bearer tokens, full prompts, and unrelated workspace records. A controlled reproduction is more useful than a large screenshot collection that obscures the original symptom. Once corrected, verify one harmless operation from the expected list and confirm the workspace. Do not use publication as a discovery test. If reconnection occurred, reconcile any earlier mutations before repeating them because action identity can depend on the original connection. A precise diagnosis keeps a missing-tool problem small. It helps you fix a client display issue, adjust a legitimate grant, resolve account eligibility, or acknowledge an unsupported feature without confusing those very different outcomes. Keep the expected-tool list tied to a purpose. A maintainer can investigate “draft creation is missing from an authorized writing connection” more effectively than “some tools are missing.” The first statement identifies the operation and responsibility that should be present; the second leaves both assumptions untested. ## Sources - [Tools - Model Context Protocol]() - [Authorization - Model Context Protocol]() - [Caroush MCP quickstart and implementation boundaries]() ## Frequently asked questions ### Does an empty tool list mean the server is broken? Not necessarily. Client filtering, cached discovery, narrow scopes, account conditions, or an incomplete authorization flow can produce a similar symptom. ### Should I grant all scopes to make tools appear? No. Identify the specific operation the task needs and review its documented permission. A missing consequential tool can be an intentional least-privilege boundary. ### What if the expected tool is absent from the public catalog? Treat it as unsupported unless current documentation establishes it. Use a documented capability or manual handoff rather than inventing a tool name or endpoint. ### What information helps support diagnose the problem? Provide the endpoint, client version, authorization stage, expected operation, observed discovery result, and redacted error. State whether the server response or only the interface was empty. ## About the author Garry Gaurav Sapkota builds Caroush, a workspace for creating, scheduling, and publishing social content. - [https://x.com/gauravsapkotanp]()