"It's not showing up" and "it's showing up but the model won't use it right" are the two complaints that cover nearly every MCP debugging session. Both have a small set of usual suspects, and both are far easier to diagnose with the right tooling than by guessing from a host's chat window alone.
Start outside the host, not inside it
The single most useful debugging tool is the MCP Inspector, a standalone developer tool that connects directly to a server the same way a host would, but exposes every tool, resource, and prompt for manual inspection and testing - you can call a tool directly with hand-picked arguments and see the raw response, without a model's interpretation in the way. Debugging through a chat interface conflates two different questions (does the server work? does the model use it well?) - the Inspector lets you answer the first one in isolation.
Testing directly against the server isolates "does the tool work" from "does the model call it correctly."
The usual suspects for "it's not showing up"
A newly added server that simply doesn't appear in the host is almost always one of three things: a JSON syntax error in the config file (a missing comma silently breaks the entire file, not just the new entry), the host not being fully restarted after the config change, or the server process itself failing to start - check that the command in your config actually runs successfully on its own, outside the host, before assuming the problem is on the host's side.
Schema mismatches
A tool call that fails partway through, or returns an error the model can't make sense of, is frequently a mismatch between what the tool's input schema promises and what the handler function actually expects - an argument documented as a string that the handler tries to parse as a number, or a required field the schema marks optional. Since the model constructs its calls based on reading the schema, any drift between schema and implementation shows up as calls that look reasonable but fail.
Tool-selection quality: the harder problem
Once a server is technically working, the deeper question is whether the model reaches for the right tool at the right time - and this genuinely can't be verified by reading code, only by running realistic requests through a real host and watching what happens. Give it a few ambiguous or edge-case prompts on purpose: does it pick the narrow tool over a broader one when both could technically apply? Does it call a destructive tool without being asked to? A confusing or overlapping set of tool descriptions (see the building guide's note on treating descriptions as a trust boundary) tends to surface exactly this way - not as an error, but as the model making a plausible-but-wrong choice.