Start a Project ->
All posts
Blog

MCP servers, plainly: what they are and which ones are worth wiring up

By Anil Dongre, Founder, Think and Form Limited//5 min read
mcpai engineeringagentstooling

The Model Context Protocol — MCP — is the most under-explained piece of new infrastructure in AI right now. Every other launch tweet mentions it. Most write-ups about it explain in a paragraph what could fit in a sentence and then trail off into philosophy. So: a plain one.

What MCP is, in one sentence

MCP is a standard way for an AI agent to talk to a tool that runs somewhere outside the agent — your Slack, your database, your filesystem, your Linear, your design files — without the agent needing to know in advance what the tool can do.

That's it. The rest is implementation detail.

Why it matters

The problem MCP solves is the one every agent builder has run into for two years: how do you give an agent access to the tools it needs without re-implementing the integration each time?

Before MCP, every agent product had its own way of wiring in tools. Cursor's. Claude Desktop's. ChatGPT's. Every one was a slightly different shape. If you wanted your team's Linear plugged into three different agents, you wrote the same integration three times in three different shapes. None of the integrations would survive the next product update.

MCP collapses this into a single interface. An MCP server speaks a defined protocol over stdio or HTTP. Any MCP-aware client — Claude Code, Cursor, Claude Desktop, Windsurf, Zed, whatever ships next month — can connect to it and use its tools. Write the Linear MCP server once; every agent in your stack can read your tickets.

This is plumbing. It's also the kind of plumbing that quietly determines whether agents are useful for work or stay locked to demos.

The shape of an MCP server

An MCP server exposes three things to a client:

Tools — functions the agent can call. Each one has a name, a description, and an input schema (JSON Schema). The agent decides when to call them; the server decides what they do. "Read this Linear ticket. Update its status. Search Slack for messages from this user." Tools are the work.

Resources — read-only data the agent can pull, named by URIs. "Give me file D:\projects\foo\README.md. Give me the contents of channel eng-platform." Resources are the context.

Prompts — pre-written templates the user can invoke. "Run the standup-summary prompt against the last 7 days of commits." Prompts are reusable starting points.

That's the entire surface. Most servers in production right now are mostly tools, sometimes with a few resources, rarely with prompts.

Three categories of MCP servers worth wiring up today

Knowledge tools — your team's brain on tap. Slack, Linear, Notion, Confluence, GitHub Discussions — wherever your team's actual decisions live. These are the highest-value MCP servers, because the work the agent does without them is informed by training data, and the work it does with them is informed by your team's reality. The difference shows up immediately. An agent answering "why did we pick Postgres over MySQL last year?" by reading your actual Slack debate is wildly more useful than one guessing from training data.

Workspace tools — the things you'd otherwise context-switch to. Linear, Asana, Jira, Calendly, Gmail, Google Calendar. These let the agent take actions on your behalf — file a ticket, read your calendar, send a follow-up — without you having to alt-tab. The wins are smaller per-action but compound. A typical product manager spends 30+ minutes a day shuffling between four of these tools; an agent with MCP access to the right ones can collapse that.

Code tools — your repos and your platforms. GitHub, GitLab, Vercel, Supabase, Sentry. These are the highest-value category for engineering teams. An agent that can read your Sentry errors, cross-reference the failing endpoint against your latest commits, and propose a fix in a draft PR is doing real work, not demo work.

What MCP servers aren't good for yet

Anything time-sensitive or transactional. MCP tools are still slow on the round-trip. Don't use them in the middle of a customer-facing request path. Use them for asynchronous "agent does work in the background" patterns.

Things that need fine-grained permissions. MCP gives you connect-or-don't, with most servers exposing all-or-nothing access to the underlying system. If you need "this agent can read tickets but not close them, and only in this project," you're going to have to enforce that yourself, server-side. Don't trust the surface.

Anything involving secrets the agent shouldn't see. This is the big footgun. An MCP server has whatever credentials it was configured with. If you wired up the production database MCP server with admin creds because that was easier, the agent now has admin creds. Audit what each server can do, before you connect it.

Setup that actually saves time

Three things separate teams getting value from MCP from teams who set it up once and forget:

  1. Restrict scope at the server, not the agent. If a server can write to production, lock it down at the credential level. Don't rely on prompting the agent not to.
  2. Use one MCP-aware tool as the primary agent surface. Pick Claude Code, Cursor, or Claude Desktop and route most of your MCP usage through it. Spreading across four clients fragments your context and your audit trail.
  3. Log every tool call. Most clients can dump the tool call transcript. Save it. When something goes wrong — and something will — you'll want to know what the agent did and when.

What's coming

The MCP spec is still moving. Expect: better permissioning (scoped tokens per tool, not per server), prompt and sampling becoming first-class, and a wave of MCP servers from product companies who've realised that "MCP support" is the new "API support" — the bar for being usable by agents at all.

If you're building a product right now, especially a developer tool, the question to ask is: would my customers' agents want to talk to me? If yes, an MCP server is the answer. The pull is real, and being late to it is starting to look like being late to having a public API in 2010.

If you're trying to wire MCP into a product or workflow and want a senior read on the right scope, security, and integration plan, that's the kind of thing we help with at Think and Form. Get in touch at admin@thinkandform.co.nz.