How to Use MCP Servers (And How to Tell Which Ones Actually Work)

You wire up an MCP server, restart your client, and the tools never show up. Or they show up, and every call times out. The usual advice is to go check your config syntax, and that is often not the problem at all.

Most of the time the server was never running in the first place.

What MCP actually is

Model Context Protocol is a standard way for an AI client to discover and call tools that live outside itself. Your client asks a server what it can do, the server answers with a list, and from then on the model can invoke any of those as if they had been built in.

The important word is discover. You are not writing per-tool glue code. You point a client at a server, and whatever that server exposes becomes available. Swap the server and the capability set changes with no edit on your side.

Two transports matter in practice. A stdio server runs as a local subprocess on your machine and talks over standard input and output. A remote server speaks HTTP and lives somewhere else. Stdio is the common default for filesystem and developer tooling. Remote is what you use for hosted services.

Setting one up

The config is a JSON file whose location depends on your client. Claude Desktop keeps it in the application support directory. VS Code reads it from workspace or user settings. Claude Code takes it from a project file or from the CLI.

A stdio entry names a command and its arguments:

"filesystem": {
  "command": "npx",
  "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/you/projects"]
}

That trailing path is not decoration. Filesystem servers take the directories they are allowed to touch as arguments, and a server started with no path argument can reach nothing. This is the most common cause of a server that connects and then does nothing.

Restart the client fully after editing. Most clients read this file once at launch, and a window reload will not pick up changes.

Windows deserves its own warning, because it comes up constantly. npx often needs wrapping through cmd, and paths need either forward slashes or doubled backslashes, since the file is JSON. A path written with single backslashes is not valid JSON. Some clients fail silently rather than saying so.

Verify before you debug

Before touching config again, confirm the server runs at all. Run its command directly in a terminal. A stdio server that starts correctly will sit there waiting for input rather than exiting or printing a stack trace. If it crashes standalone, no config will save it.

For remote servers, call tools/list yourself. That is the same handshake your client performs, and doing it by hand separates a dead server from a misconfigured client. What comes back is a JSON list of tools with their schemas, which is also the fastest way to see what a server really offers rather than what its README claims.

This ordering saves hours. Client logs for MCP failures tend to be thin, and it is easy to spend an afternoon rewriting a config file when the package was never published anywhere.

The part that should change how you choose

Here is the number worth knowing before you build on any of this. Of the MCP servers listed in the official registry, 42% answered a live handshake when we called them.

That figure needs its caveat attached, because it is easy to misread. The population is registry-listed servers, not every endpoint we crawl. Many registry entries are package metadata rather than hosted servers, which is part of why the rate is low.

Read properly it still tells you something useful. A registry listing proves somebody published a description once. It does not prove anything is listening today. Some entries were demos. Some are packages that were never hosted anywhere. Some worked in spring and quietly stopped.

So treat any registry as a source of candidates, not a source of truth, and verify before you commit to one.

Scale is not the constraint here. Across servers that do respond, we have read 51,486 callable tools from live tools/list responses across 3,928 servers. There is plenty out there. The work is separating what runs from what is merely listed.

Choosing well

Prefer servers that answered a handshake recently. A recent real response beats star counts, because a repository can be popular while its hosted instance has been dead for months.

Read the tool schemas rather than the README. tools/list gives you the actual parameter names and types the model will see. If those descriptions are vague, your model will misuse the tool, and no amount of prompting repairs a badly described parameter.

Scope permissions at the server, not in the prompt. Filesystem servers take allowed directories as arguments. Database servers usually accept a read-only flag. Set the boundary where it is enforced rather than asking a model to behave.

Be wary of servers that document nothing. Of the hosts we profile, 7,376 of 12,850 publish no readable description of themselves. A server that cannot explain what it does is a server you cannot audit.

Start with two or three and add more only when a task actually needs them. Every connected server puts its tool list into the model's context. Twenty servers means a long menu the model reads before every decision, which costs tokens and makes tool selection worse rather than better.

When it breaks later

Working setups break for dull reasons. An npx-based server pulls a new version and changes its interface overnight. A hosted endpoint lets its certificate expire. A local process dies and the client never surfaces it.

Build for that. Pin versions rather than letting a package manager fetch the latest into a setup that already works. Check tools/list when behaviour changes, because a silently updated server is more likely than a model regression. Keep a fallback for anything a workflow genuinely depends on.

Where to look

Specific servers churn, so a list frozen into a guide ages badly within weeks. We keep the live version instead. AgentIndex tracks MCP servers, which ones answered when we last probed them, and what tools they actually expose. You can browse it at agents.traderszone.net, and it speaks MCP itself if you would rather your agent search it directly.

Get one server working before you add a second. The failure modes are far easier to read when there is only one thing that can be wrong.