When an MCP server fails, it looks like the model is being stupid. It calls a tool, gets nothing, apologises. It is almost never the model.
Step 1: run the command yourself
Take the `command` and `args` from your config and run them in a terminal. Three outcomes tell you everything.
If it prints a version and exits, it is a CLI, not a server for this transport. If it waits silently, it is a stdio server and it is working. If it exits with an error, you have your answer before touching the client.
Step 2: read the first line it writes
Servers usually print a startup line to stderr. If it says a key, path, or token is missing, you are done: no prompt fixes a missing credential.
Step 3: call one tool by hand
Use the client's inspector or a one-line JSON-RPC request to list tools, then call the simplest one. If listing works and calling fails, the problem is arguments — a different class of bug from a broken connection, and the error message looks identical from the model's side.
Step 4: check the working directory
Relative paths resolve against the client's launch directory, not your terminal. This bites hardest with the filesystem server and with anything that reads a local config.
Step 5: only now suspect the model
If tools list, arguments are right, and results are wrong, you have a genuine reasoning problem. That is the point where comparing models or adding context tools is worth doing — and not before.
The pattern
Eliminate in this order: **transport, credentials, arguments, context**. Ninety percent of MCP bugs die in the first three, and none of them are fixed by a better prompt.