What is MCP? Model Context Protocol for coding agents

Your coding agent can refactor a module it has never seen. Ask it whether the migration actually ran against your local database and it goes quiet, or worse, guesses confidently.

That gap has a name now. MCP (the Model Context Protocol) is the standard that closes it, and it's the difference between an agent that reads your code and one that can actually operate your stack.

What MCP actually is

Strip the acronym away and it's a plug format.

Before it, every tool that wanted to give an AI model access to something (your database, your tracker, a browser) had to build a bespoke integration for every agent. MCP replaces all of that with one socket: a tool exposes an MCP server, and any agent that speaks the protocol can use it.

In practice, an MCP server is a small program advertising a list of tools: run_query, get_issue, take_screenshot, each with a description and expected inputs. Your agent reads that list, decides when one is relevant, calls it, and gets structured data back. No pasting rows into chat, no describing your error message in prose.

Support is broad and still moving fast, so check your agent's docs for how to add one: the concept is portable, the config file isn't quite yet.

What changes when you plug one in

Take an ordinary bug: orders from Tuesday show the wrong total.

With no tools, your agent reads source and reasons about it. It finds three plausible causes, can't tell which is real, and hands you all three.

With a read-only database server connected, it queries the actual rows and finds the ones with a null discount. With a browser server, it loads the page and reads the console error itself. With your tracker connected, it notices the linked ticket saying this started after Tuesday's deploy.

Same model, same prompt. The difference is whether it's guessing from code or working from evidence, which is also the difference between a diff you have to verify line by line and one that arrives with its reasoning attached.

The servers worth adding first

Start wherever you do the most copy-pasting:

• Your database, read-only. Turns "what does the data actually look like?" into a lookup.
• A browser. Lets the agent load the page it just changed and read the console, instead of asserting that it works.
• Your issue tracker or repo host. The agent reads the ticket itself and writes the PR description with the context already in hand.
• Docs search for your framework. Cuts the confident, outdated API guesses.

Each one removes something you were manually ferrying into a chat box. For named picks per job, and the bar each server has to clear first, see our shortlist of the best MCP servers.

The rule nobody puts in the README: fewer servers

Every connected server's tool list is loaded into your agent's context before you type a word: names, descriptions, parameter schemas. Twelve servers with a dozen tools each is a wall of definitions the model reads and chooses between on every turn.

The symptoms: slow starts, a bigger token bill, and an agent reaching for a strange tool because two of them sounded alike.

Treat servers like dependencies. Add one, live with it for a week, keep it if it earned its place. Three good ones beat twelve you've forgotten you installed. It's the same discipline as writing an AGENTS.md file: the scarce resource is context, and everything sitting in it is rent.

Two things to be honest about

Permissions are real. A server runs with whatever access you handed it. One holding write credentials can drop a table if the agent misreads a request. Start read-only, scope credentials tightly, and keep approval prompts on for anything that mutates state.

Tool output is untrusted input. When an agent fetches a web page or reads an issue, that text lands in its context, and text can contain instructions. Treat what a server returns as data, not orders, and think twice before wiring an unattended agent to a source strangers can write to.

Neither is a reason to skip MCP; they're the reason to add servers deliberately.

Where it stops being about data

Once tools are on the table, the better move is to hand agents your process, not just your data.

That's the bet SanuDesk makes. It's a desktop app where your Claude Code and Codex sessions tile into one grid, each workspace pointed at a project folder, with a Kanban board the agents take their work from. The board isn't only for you: a bundled sanudesk MCP server lets an agent open a workspace, file and deploy cards, tick off acceptance criteria, and check status or diff its own changes before it commits, since git is exposed the same way.

So the loop closes. You deploy a card, the agent picks it up, does the work, moves the card and lands the commit, a result you can review instead of reconstruct from scrollback. Loops handle the recurring version, running the same brief on a schedule with nobody watching. It drives the agent subscriptions you already pay for, so nothing here is metered by us, and the free tier is a real one.

This compounds fastest when you're running several agents at once. A fleet with shared tools and a shared board behaves like a team; the same fleet without them behaves like five terminal tabs you keep losing.

Start with one server

Pick the thing you pasted into a chat box most often this week. Find the MCP server for it, connect it, use it for a few days. You'll know quickly whether it changed the shape of the work or just added noise, and that judgment matters more as the list of servers keeps growing faster than your context window.

Download SanuDesk free and point a workspace at your repo, or see how the grid, the board and Loops fit together on the features page.