What MCP Servers actually is

MCP stands for Model Context Protocol. It is an open standard, originally introduced by Anthropic in late 2024, that defines how a language model client connects to external tools, data sources, and services. The protocol itself is just a specification for JSON-RPC messages exchanged over a transport like stdio, HTTP, or Server-Sent Events.

In practice, an MCP server is a small program that exposes three things to an LLM. Resources, which are read-only data the model can pull in such as files, database rows, or API responses. Tools, which are functions the model can call with arguments and receive structured results back from. Prompts, which are reusable prompt templates the host can surface to users.

The MCP host is the application running the model, typically Claude Desktop, Claude Code, or an IDE plugin. The host spawns or connects to one or more MCP servers, lists what they offer, and lets the model use them during a conversation.

The mental model worth holding onto: an MCP server is a function-calling adapter with a standard interface. Instead of writing bespoke glue code for every tool you want Claude to use, you write one server that speaks MCP and any MCP-compatible client can use it. The protocol handles discovery, capability negotiation, and the request-response loop.

This matters because before MCP, every integration was a one-off. A Claude Desktop plugin for GitHub did not talk to a Cursor plugin for GitHub. With MCP, the same server works across hosts that implement the protocol.

Setup and authentication

The fastest path is Claude Desktop. Download it from Anthropic, install it, and make sure you are signed into a paid account, since MCP servers currently work in the paid Claude Desktop app rather than the free web tier.

Configuration lives in a JSON file. On macOS the path is ~/Library/Application Support/Claude/claude_desktop_config.json. On Windows it lives under %APPDATA%\Claude. The file does not exist by default, so you create it. The shape is a top-level mcpServers object where each key is a server name you choose and each value describes how to launch that server, including the command, arguments, and any environment variables.

For a stdio-based server, the command field is the executable and args is the array of arguments. The official filesystem server from Anthropic, for example, is launched with npx and a path argument pointing at a directory you want to expose. For an HTTP-based server, you set a url field instead.

Authentication depends on the server. Some servers are local and need no auth. Others need API keys, OAuth tokens, or database credentials. These go in the env block of the config and the server reads them at startup. A common pattern is to keep secrets in a separate .env file and reference them, or to use your operating system’s keychain.

After editing the config, fully quit Claude Desktop and reopen it. The servers appear in the chat input as a small hammer icon, and clicking it shows the tools each server exposes. If a server does not appear, the logs at ~/Library/Logs/Claude/ on macOS usually show the launch error within the first few lines.

First working example

The cleanest first server to run is the filesystem server Anthropic ships. It lets Claude read and write files inside a directory you specify. This is enough to prove the plumbing works without needing any external API keys.

Install Node.js if you do not have it, since the official reference servers are distributed as npm packages. Then create the config file with the filesystem server pointing at a folder you want to work in, for example ~/mcp-playground.

Open Claude Desktop, confirm the filesystem tools appear in the tool menu, and ask Claude something concrete like “list the files in my playground folder and create a new file called notes.md with a short summary of what you see.” Claude will call the list_directory tool, then the write_file tool, and you will see the file appear on disk.

If that round trip works, the rest of MCP is just variations on the same pattern. A server, a config entry, and tools you can call from chat.

A second example worth running early is the GitHub MCP server. It requires a personal access token from GitHub, which you generate under Developer Settings with the scopes you need. Repo and read:user are typical for read-heavy workflows. Drop the token into the env block of your config, restart Claude Desktop, and you can ask Claude to list open issues, summarize recent pull requests, or open a new issue from a conversation.

Key settings that matter

The dials most people ignore are not in the protocol itself but in how you configure and operate servers.

Transport choice. Stdio is simplest for local servers because the host spawns the process directly. HTTP and SSE are required when the server runs remotely, for example a shared database gateway on a company server. The trade-off is operational complexity, since a remote server needs to be reachable, authenticated, and monitored.

Tool allowlists. A server can expose dozens of tools, but you usually only want a subset active in any given session. Some hosts let you toggle tools per server. Disabling tools you do not need reduces the chance of the model calling something destructive and shrinks the context window consumed by tool descriptions.

Resource scoping. For the filesystem server, the directory argument is the security boundary. Anything outside that path is invisible to the model. Treat that path like a chroot. For database servers, scope to read-only roles where possible.

Timeout and retry behavior. Long-running tools, like a SQL query against a slow warehouse, can exceed default timeouts. Most MCP server implementations let you configure request timeouts. Set them generously for batch operations and tightly for interactive ones.

Logging. Stdio servers inherit the host’s logging. Point Claude Desktop’s logs at a file you actually read. When something breaks, the error is almost always in the launch command or in a missing environment variable, and the logs will say so.

Version pinning. Reference servers on npm move fast. Pin a version in your config rather than letting npx pull the latest, otherwise a breaking change in the server can silently change tool behavior between sessions.

Where it shines

MCP is genuinely useful when you have a stable, recurring interaction between Claude and a specific system, and you are tired of copy-pasting context into the chat.

Code and repository work. The GitHub, GitLab, and filesystem servers turn Claude into something close to a pair programmer that can read your actual repo, open pull requests, and respond to review comments. This is the single most common production use case.

Database querying. A Postgres or SQLite MCP server, scoped to a read-only role, lets analysts ask natural-language questions and get SQL the model writes and runs. The round trip is fast and the audit trail is the SQL itself.

Internal documentation. Companies running a Confluence, Notion, or custom docs server through MCP let Claude answer questions grounded in their own knowledge base rather than the open internet. The retrieval quality is bounded by the server’s search implementation, but the workflow is straightforward.

Local development tooling. Anything you would normally script, like running tests, formatting files, or calling a CLI, can be wrapped as an MCP tool. This is useful when you want non-technical teammates to trigger those scripts through chat.

Multi-host reuse. A server you write once works in Claude Desktop, Claude Code, Cursor, and any other MCP-compatible host. This is the long-term payoff and the reason to invest in MCP rather than a one-off plugin.

Where it fails

Honest list of where MCP struggles or is the wrong tool.

Latency. Every tool call is a process or network hop. A chat that triggers five tools sequentially will feel slow compared to a direct API call. For tight inner loops, MCP is the wrong layer.

Context bloat. Servers expose tool descriptions to the model on every turn. A server with 30 tools can consume a meaningful slice of the context window before the user types anything. Trim aggressively.

Error handling maturity. The protocol is young and many reference servers return errors as plain strings. The model has to interpret them, which works for simple cases and falls apart for anything subtle. Expect to read server logs.

No fine-grained authz at the protocol level. MCP does not define how a host should authorize a specific user to call a specific tool. Hosts implement their own policies, which means behavior varies. Do not assume a tool exposed by a server is safe for every user who can reach the host.

Local-only assumption in many servers. A surprising number of community servers