MCP Servers Explained: Connect AI Assistants to Your Tools

Here is a number that surprised me the first time I measured it: I copied and pasted context between my AI assistant and my actual tools roughly 60 times a day. Error logs, database rows, file paths, GitHub issue text. Each round trip took maybe 20 seconds and broke my concentration. That is 20 minutes of pure copy-paste tax daily, before the assistant does anything useful.

The Model Context Protocol, or MCP, exists to kill that tax. Introduced by Anthropic in late 2024 and adopted at speed by OpenAI, Google, and a wave of tool vendors through 2025, MCP is a standard way for AI assistants to talk directly to your files, databases, APIs, and apps. Instead of you being the messenger, the assistant connects to an MCP server and reads or acts on your tools itself.

In this guide I will explain what MCP servers actually are, how they work under the hood, how to set one up step by step, and where the sharp edges hide. I have run these in production on my own machine for months, so expect honest tradeoffs, not marketing gloss.

Key Takeaways

• MCP is a protocol, not a product. It standardizes how AI assistants connect to external tools, the way USB-C standardized charging.
• An MCP server exposes three things: tools (actions), resources (readable data), and prompts (reusable templates).
• Local (stdio) servers are simplest and most private; remote (HTTP/SSE) servers scale to teams but expand your attack surface.
• Setup is a JSON config file plus a command. You can have a working filesystem or GitHub server running in under 10 minutes.
• Permissions are the whole ballgame. An MCP server can run commands and read files, so treat every server like installed software and vet it accordingly.

What Are MCP Servers for AI Assistants?

An MCP server is a small program that sits between an AI assistant (the client) and some capability you want the assistant to use. When your assistant needs to read a file, query a database, or hit an API, it sends a structured request to the MCP server, which does the work and returns a clean result.

Think of it as a universal adapter. Before MCP, every AI tool integration was a bespoke plugin written for one specific product. If you switched from Claude to a different assistant, your integrations broke. MCP defines one contract, so any compliant client can talk to any compliant server.

The three things an MCP server exposes

• Tools — actions the assistant can invoke, like create_issue, run_query, or send_email. These have side effects.
• Resources — read-only data the assistant can pull in, like the contents of a file, a config, or a documentation page.
• Prompts — reusable prompt templates the server offers, such as a "summarize this PR" workflow with the right context already wired in.

That separation matters. Reading a resource is low risk. Invoking a tool that deletes records is not. Good clients ask for confirmation before a tool runs, and you should never disable that.

How MCP Servers Actually Work

Under the hood, MCP uses JSON-RPC 2.0 messages over one of two transports. Understanding the transport choice is the single most useful thing for deciding how to deploy.

Local transport: stdio

With stdio, the client launches the server as a child process and communicates over standard input and output. Nothing touches the network. This is how most desktop setups work, and it is the most private option because your data never leaves the machine.

Remote transport: HTTP and SSE

With Streamable HTTP (which replaced the older HTTP+SSE approach in the 2025 spec), the server runs somewhere reachable over the network. This suits shared team servers, cloud-hosted tools, and SaaS integrations. It also means authentication, TLS, and access control become your responsibility.

Here is the typical request flow, simplified:

1. The client connects and asks the server, what can you do? The server lists its tools, resources, and prompts.
2. The assistant, working on your task, decides it needs a tool, say read_file with a path.
3. The client sends a tools/call request. If the tool has side effects, the client prompts you to approve.
4. The server executes and returns a structured result.
5. The assistant folds that result into its reasoning and continues.

The whole loop is fast enough to feel conversational. The assistant behaves as if it can genuinely see your environment, because in a controlled sense it now can.

A Worked Example: From Copy-Paste to Connected

Let me make this concrete with the exact scenario that sold me on MCP. I maintain a mid-sized web app with a Postgres database of about 40 tables. Before MCP, a typical debugging session looked like this:

• Notice a bug in the app.
• Open a SQL client, write a query, run it, copy 30 rows of output.
• Paste into the assistant with a paragraph explaining the schema.
• Assistant suggests another query. Copy it back to the SQL client. Repeat.

A single investigation ran 8 to 12 of these round trips. At roughly 25 seconds each, that is about 4 minutes of pure shuffling per bug, plus the mental cost of losing my place each time.

After connecting a read-only Postgres MCP server, the same investigation looked like this: I described the bug in plain English, and the assistant queried the database itself, explored the schema on its own, and returned a diagnosis with the offending rows. The shuffling dropped to zero. Over a week with maybe 15 such investigations, I got back close to an hour and, more importantly, kept my focus intact.

The one rule I enforced: the database credential was read-only. The assistant could look but never write. That single constraint made the whole thing safe to trust.

How to Set Up Your First MCP Server

You do not need to write code to use MCP. Dozens of prebuilt servers exist for filesystems, GitHub, Slack, Postgres, Google Drive, and more. Here is a complete walkthrough using the official filesystem server, which is the best starting point.

Step 1: Confirm your prerequisites

• An MCP-capable client. Claude Desktop, several code editors, and a growing list of assistants support it.
• Node.js version 18 or later, since most reference servers ship as npm packages run through npx.

Step 2: Locate your client's config file

Most desktop clients read a JSON config. For Claude Desktop it lives at ~/Library/Application Support/Claude/claude_desktop_config.json on macOS and the equivalent AppData path on Windows. If it does not exist yet, create it.

Step 3: Add a server definition

Paste a block like this, adjusting the path to a folder you actually want the assistant to access:

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

Notice you scope it to /Users/you/projects, not your whole home directory. Scope narrowly. The server can only see what you point it at.

Step 4: Restart the client and verify

Restart the app fully. Look for a tools or plugin indicator that shows the filesystem server connected. Ask the assistant to list files in your project folder. If it returns them, you are live.

Step 5: Add a second server, carefully

Once comfortable, add something like the GitHub server, which needs a personal access token. Create a token scoped to the minimum permissions, store it as an environment variable rather than pasting it raw, and give the token an expiry date. If you are wiring up assistants for coding work, our companion guide on securing AI coding assistants covers token hygiene in depth.

Local vs Remote vs Managed MCP Servers

Choosing where your server runs shapes both your security posture and your maintenance burden. Here is how the three common approaches compare.

Criteria	Local (stdio)	Self-hosted remote	Managed / vendor-hosted
Setup effort	Low	High	Very low
Data privacy	Excellent, stays on device	Good, you control it	Depends on vendor
Team sharing	Poor	Good	Excellent
Attack surface	Small	Large, network exposed	Outsourced, opaque
Best for	Solo devs, sensitive data	Teams with ops staff	Quick SaaS integrations

My advice for most individuals: start local. You get 90 percent of the value with a fraction of the risk. Move to remote only when a real team need forces it, and then bring the same rigor you would apply when vetting any open-source dependency before install.

The Security Reality of MCP Servers

This is the section people skip and later regret. An MCP server is code running with your permissions. It can read files, hit networks, and execute tools. If you install a shady one, you have handed an attacker a foothold.

The real risks

• Overbroad access. A filesystem server pointed at your home directory can read SSH keys, browser cookies, and password vaults.
• Prompt injection into tools. Malicious content in a file or web page can trick the assistant into calling a tool it should not. This is the AI equivalent of a supply-chain attack.
• Credential leakage. Tokens stored in plaintext config files get committed to Git or synced to the cloud by accident.
• Unvetted third-party servers. The npm and community ecosystem is young. Not every published server is trustworthy.

A practical hardening checklist

1. Install only servers from sources you can inspect. Read the code or pick well-known publ

   Cover image: Software value feedback loop by jakuza, licensed under BY-SA 2.0 via Openverse.