MCP explained, and connecting your first server

MCP is an open standard for connecting agents to external systems. An MCP server exposes a set of tools, and any agent that speaks the protocol can use them. It exists so that every tool does not need custom integration code for every agent.

Why it exists

Before MCP, connecting an agent to GitHub meant someone writing GitHub support into that specific agent. Ten agents and ten services meant a hundred integrations.

MCP turns that into ten servers and ten clients. Write a GitHub MCP server once, and every MCP capable agent can use it. That is the entire value proposition, and it is why the ecosystem grew quickly.

The pieces

Server: a program exposing tools, such as "search issues" or "read file". Usually a small process on your machine, sometimes a hosted URL.

Client: your harness. Claude Code, Cursor, and Cline are all MCP clients.

Transport: how they talk. stdio means the server runs locally as a subprocess. http and sse mean it is remote.

When your agent starts, it asks each connected server what tools it offers. Those tools become available to the model, described in its context.

Connecting your first one

The filesystem server is the usual starting point. For Claude Code:

claude mcp add filesystem -- npx -y @modelcontextprotocol/server-filesystem ~/projects

Check it registered:

claude mcp list

Now ask the agent to do something that requires it, such as reading a file outside your current project. If it works, you are connected.

Other harnesses use a JSON config file with the same information:

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

Which servers are worth adding

Start with almost none. Every connected server adds its tool definitions to your context on every single request, which costs tokens and can make the model worse at choosing, because it has more options to consider.

A reasonable starting set for a developer:

• Context7 for current library documentation, which fixes the model writing code against APIs that changed after its training cutoff
• GitHub if you work with issues and pull requests daily
• Playwright if you need the agent to check things in a browser

Add a server when you notice yourself doing something manually and repeatedly. Not before.

The security decisions you are making

This is the part that gets skipped, so be deliberate here.

A server runs with your permissions. An MCP server installed via npx is arbitrary code running on your machine as you. It can read your SSH keys and your environment variables. Install servers from vendors you would trust with a dependency, and prefer official ones.

Tokens you provide are the blast radius. A GitHub token scoped to all repositories lets the agent act on all of them. Scope every token down to the minimum.

Data returned by a server reaches your model provider. Querying a production database or reading a Slack channel sends that content to whoever runs your model. Check whether that is acceptable for the data involved.

Content from a server is untrusted input. A web page, a GitHub issue, or a Slack message can contain text crafted to instruct your agent. This is prompt injection, and it is a live risk once your agent has both external content and real capabilities. The dangerous combination is an agent that can read attacker-influenced content and also take consequential actions.

Practical rule: be cautious about connecting a server that reads public content and a server that can write to something important in the same session.

When it does not work

Tools do not appear. Restart the session. Most clients only enumerate tools at startup.

The server fails to start. Run the command manually in a terminal. A missing runtime or a bad path shows up immediately there and is invisible through the harness.

The agent ignores the tools. Ask for the thing more explicitly. If it still does not, the tool descriptions may be unclear, which is a server side problem.