What an MCP Server Actually Does for an AI Coding Assistant
Why Your Assistant Cannot See Your Ticket Tracker
The short answer: an MCP server hands your assistant one outside system through a standard interface. You want two or three of them, not ten. If you spend your day checking a database, an issue tracker, or an error dashboard, that is where the payoff sits.
Model Context Protocol is an open standard for connecting AI applications to external systems. Its own documentation compares it to a USB-C port, which is a fair analogy for what the standard is trying to end.
Before it existed, every integration was bespoke. Each editor shipped its own plugin format, each vendor wrote its own connector, and none of that work moved across tools.
What the Protocol Standardises, in Plain Terms
Three participants matter. The host is the AI application you already use, such as Claude Code or Visual Studio Code, and it creates one client per server. Each client holds a dedicated connection to a single server.
The server is the piece that provides context. It is a program, not a machine, and the word carries none of its usual infrastructure baggage here.
Underneath, messages travel as JSON-RPC 2.0 requests and responses. That choice sounds dry, but it is why any compliant host can talk to any compliant server without either side knowing the other exists.
The problem being solved is a multiplication problem. Ten AI tools and ten internal systems used to imply a hundred separate integrations, each written and maintained by somebody.
A shared protocol turns that into twenty pieces of work. Vendors implement the client half once, integration authors implement the server half once, and the pairings take care of themselves.
How a Server Gets Wired Into Your Editor
Configuration is less dramatic than the concept. For a local server, you name it, give the command that launches it, and pass whatever arguments and environment variables it needs.
{
"mcpServers": {
"postgres-readonly": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-postgres"],
"env": { "DATABASE_URL": "postgres://reader@localhost:5432/app" }
}
}
}
Field names vary between hosts, so check the documentation for yours before copying anything. The shape stays recognisable: an identifier, a launch command, and credentials supplied through the environment rather than the prompt.
That last detail is worth pausing on. Secrets belong in the environment or a credential store, never pasted into a chat window where they enter the transcript and every later request that replays it.
The Three Things a Server Can Hand Over
- ● Tools perform actions
- ● Resources supply context
- ● Prompts package templates
Servers expose exactly three primitives, and the distinction between them matters more than the names suggest.
Tools are executable functions the model can invoke, such as running a query or opening a pull request. Resources are read-only context, such as a schema, a file, or an API response. Prompts are reusable templates that structure a request the same way every time.
Clients discover each type with a list call before using it, which is why a newly connected server can appear without a restart. Under the current revision, a client can also fetch a server identity and capabilities in one round trip through a discovery request.
Traffic runs in the other direction too. A server can ask the user a question through elicitation, which is how a careful server confirms something consequential before it acts.
Local Servers, Remote Servers, and Why Transport Matters
- ● Stdio runs beside your editor
- ● Streamable HTTP reaches vendors
- ● Remote servers need real auth
Two transports exist, and the choice shapes both performance and risk. Stdio runs the server as a local process beside your editor, talking over standard input and output with no network in the path.
Streamable HTTP is the remote option, using HTTP POST with optional server-sent events for streaming. A local stdio server typically serves one client, while a remote HTTP server serves many at once.
Authentication follows that split. Remote servers accept bearer tokens, API keys, and custom headers, and the protocol recommends OAuth for obtaining those tokens. That is the point where an integration stops being a local convenience and becomes an access decision, a theme our data privacy checklist for coding assistants covers in more depth.
| Approach | Works across tools | Live data | Can take actions | Setup cost |
|---|---|---|---|---|
| Pasting output into chat | Yes | Only what you paste | No | None |
| Editor-specific plugin | No, one product only | Yes | Sometimes | Medium, per product |
| Custom API script | Only where you wire it | Yes | Yes | High, and you maintain it |
| Local MCP server, stdio | Yes, any MCP host | Yes | Yes | Low, one config entry |
| Remote MCP server, HTTP | Yes, any MCP host | Yes | Yes | Low, plus auth setup |
| Rules file or project doc | Yes | No, static text | No | Very low |
The bottom row deserves a note. A rules file is not a competitor to a server, and the two solve different problems, since one carries standing instructions and the other carries live facts.
What Adding a Server Costs You in Context
Every connected server publishes its tool list, and that list enters the context the model reads. Ten servers with a dozen tools each can consume a serious share of the window before you type a word.
The protocol softens this in two ways. List responses carry a freshness hint, so a tool list can be cached rather than refetched, and clients that federate many servers can discover tools progressively instead of loading everything up front.
Neither trick removes the underlying trade. More surface area means more choices for the model, and more chances to pick a plausible wrong tool. The discipline is the one that governs good prompting, and our guide to writing effective prompts makes the same argument from the input side.
When the Server Connects but the Tools Never Appear
The common first failure is silence. The host reports a connection, the assistant behaves as before, and nothing in the interface explains the gap.
Version mismatch causes a share of these. Every request declares the protocol version it speaks, and a server that does not support that version rejects the request outright. The rejection lists the versions the server does accept, which is a useful error once you find where your host writes its logs.
Capability mismatch causes another share. A server advertises which primitives it supports, and a client that never asked for tools will not show them, so a server built around resources looks empty in a host focused on tool calling.
Then there is the plainest cause of all. The launch command fails, the process dies immediately, and the host shows a connection entry for something that is not running.
Two habits shorten this loop. Run the server command by hand in a terminal first and watch what it prints, then check the host log before changing any configuration.
The reflex to avoid is editing the config repeatedly on instinct. These failures are ordinary process and version problems wearing unfamiliar names, and reading the actual error beats guessing every time.
The Permission Question Nobody Asks Until Later
Resources are inert; tools are not. A tool call can write to a database, close a ticket, or push a branch, and the model decides when to call it based on text it read moments earlier.
That is a real change in the threat model, not a theoretical one. Content the assistant reads can steer what it does next, so a server holding write credentials to production deserves the scrutiny you would give a deploy key.
Practical mitigations are unglamorous and effective. Scope credentials narrowly, prefer read-only tokens for anything exploratory, keep production and development servers apart, and read the tool descriptions before you approve a server.
Which Developers Should Bother Wiring One Up
- ● Database work gains most
- ● Solo scripts gain least
- ● Two servers beat ten
Backend developer working against a real schema: The clearest win. A database server lets the assistant read your actual tables instead of inventing columns, and schema invention is the failure mode it removes outright.
Developer on call for production incidents: Worth it for the error tracker alone. Pulling a live stack trace and its recent occurrences into the session beats pasting fragments, especially under time pressure.
Frontend developer working from designs: Situational. A design-tool server helps if your components track a design system closely, and adds noise if your work is mostly hand-tuned CSS.
Solo developer on small scripts: Skip it for now. Your context fits in the editor already, and the setup time buys little when the whole project is a few hundred lines.
Team lead standardising a toolchain: Care about governance more than capability. Agree which servers are approved, where credentials live, and who reviews new ones, using the rollout thinking our team adoption guide applies to assistants themselves.
Developer weighing local against cloud tooling: Note that the transport choice mirrors that decision. Stdio keeps everything on your machine, and our local versus cloud comparison covers the trade in full.
What to Do Before You Install Your First Server
Start from a question you actually ask several times a week. If you keep checking a schema, a ticket queue, or a log stream, that system is your first server, and the value shows up in the first session.
Add servers one at a time and watch what changes. A server nobody uses still costs context, so removing it later is as much a maintenance task as adding it was.
The protocol itself keeps moving, and revisions have already renamed methods and deprecated whole client features. The architecture overview is the reference to check when your host and your server disagree about what is supported.
What is unlikely to change is the shape of the win. Assistants fail most often because they cannot see something, and a server is the cheapest way to let them see one more thing on purpose.
FAQ
What is an MCP server in simple terms?
An MCP server is a small program that exposes one outside system to an AI application through a standard interface. It can run on your own machine over the stdio transport or on a vendor platform over Streamable HTTP. The word server does not imply a data centre here.
How is an MCP server different from a plugin or extension?
A plugin is written for one product and dies with it. An MCP server speaks a shared protocol, so the same server works in any host that supports MCP, including Claude Code, Cursor, and Visual Studio Code. You build the integration once instead of once per vendor.
What can a server actually give the assistant?
Servers expose three things: tools that the model can call to perform actions, resources that supply context data, and prompts that package reusable templates. Clients discover each of them with a list method before anything runs.
Is it risky to connect an MCP server to a production system?
Yes, because tools execute real actions under model direction. Grant a server the narrowest scope that still works, prefer read-only credentials for anything exploratory, and check what each tool can reach before you approve it.
Does adding more servers make the assistant worse?
Every connected server adds its tool list to the context the model reads, and long tool lists crowd out your code. Two or three well-chosen servers usually beat ten, and some clients now load tools progressively to soften the cost.
Sources
- Model Context Protocol — checked 2026-09-07
Some links may be affiliate links. We may earn a commission at no extra cost to you.
This article was written with AI assistance. It is researched and fact-checked, not based on personal hands-on testing unless explicitly stated.
Comments
Post a Comment