The model is the agent's brain. It reasons, plans, writes code. But on its own it does exactly one thing: turn text in into text out. Ask it what's in your database — it doesn't know. Ask it to hit an internal API — it will write you the request code, but it won't run it. A brain without hands.
A product engineer who works hand in hand with an agent hits this limit sooner or later. The agent reasons beautifully about your system — based on what you told it. But it doesn't see it. And then the question becomes: how do you give it hands, so it doesn't just reason about the system but actually reaches into it.
The answer, which became an industry standard within a couple of years, is MCP, the Model Context Protocol. This article is about how to equip an agent without shooting yourself in the foot. Not about how to write an MCP server (that's a separate craft, links at the end) — about why it matters to you as a product engineer and where the boundaries run.
The problem before MCP: every tool a custom hack
The idea of "give the model tools" is older than MCP. Function calling, plugins, homemade wrappers — all gave the agent some capacity to act. The problem was that every integration was written from scratch.
Want the agent to read files — you write a wrapper for your agent. Want it to hit Postgres — another wrapper, for the same agent, from zero. Switch from one agent to another — you rewrite both wrappers, because their tool description formats differ. A new tool appears — a new integration for every agent you use.
You ended up with an M agents × N tools matrix, and every cell held its own code. This is exactly the combinatorics that HTTP solved for the web and common-interface drivers solved for databases. Until there's a shared plug like that, everyone wires their agent's hands by hand, and those hands are compatible with no one.
The MCP idea: one protocol, servers as adapters
MCP is a standard (originally from Anthropic, now open and adopted broadly) that removes the matrix. Instead of "every agent for every tool" there's one shared plug between them.
The analogy that usually clicks: MCP is USB-C for an agent's tools. Every device used to have its own port and its own cable. USB-C set one physical contract: any device with that port connects to any host with that port. MCP does the same for the "agent ↔ tool" pair. Write a tool once to the protocol — it works with any MCP-compatible agent. Your agent understands the protocol — it connects to any tool written for it.
The M × N matrix collapses to M + N. A tool is written once. An agent learns the protocol once. From there they connect like plug to plug.
Server and client: who's who
The protocol has two sides.
An MCP server is an adapter to a single tool or data source. It wraps the file system, or a database, or git, or an external API and exposes three things in the protocol's terms: tools (actions the agent can perform — "read this file," "run this query"), resources (data it can read — contents, schemas), and prompts (prepared scenarios). A server is small, narrow, knows about one world.
An MCP client lives inside the agent (Claude Code, an IDE, your own app with a model). It does discovery: connects to a server, asks "what can you do," gets back a list of tools with descriptions and argument types. From there the model sees those tools as part of its arsenal and decides on its own when to call which.
The key point: the model doesn't know the server's internals. It sees a tool query_database with a description and parameters — that's all. How exactly the server reaches the database, what the credentials are, what the connection pool looks like — all behind the protocol. Exactly the way code working through a port doesn't know what sits behind it: HTTP, a queue, or a stub in a test. MCP is port/adapter raised to the level of agent tooling.
What's out there: files, database, git, HTTP
The server ecosystem is already large, but it's more useful to hold in your head not a list but a few typical classes — you'll rate the risk along the same lines.
- File system. The agent reads and writes files in an agreed directory. The most common — and the most harmless, as long as the directory is scoped.
- Database. The agent runs queries, reads the schema, sometimes writes. This is where it gets interesting: a read-only connection and full access are two different universes in terms of consequences.
- git. History, diffs, branches, commits. The agent sees the evolution of the code, not just a snapshot.
- HTTP / external APIs. The agent hits a payment gateway, a search index, your own service. Here the agent's hands reach outside your perimeter.
- Internal systems. Tickets, CI, observability, feature flags. The agent stops being a "code editor" and becomes a participant in your working loop.
The craft of writing such a server is out of scope here. What matters is that you, as a product engineer, more often need to connect an existing server and decide what access it gets than to write your own.
Why this matters to a product engineer
A product engineer owns the slice from problem to user. The agent is the lever across that whole path. Without hands the lever is short: the agent helps write code but stops at the edge of your text. Everything you haven't told it doesn't exist for it.
MCP lengthens the lever — it increases the agent's reach:
- Not "explain the DB schema to the agent in words," but the agent reads the schema itself and writes a query against real tables, not imagined ones.
- Not "paste the API response here," but the agent hits the endpoint itself and works with the actual response.
- Not "tell it what's in the ticket," but the agent opens the ticket itself and ties it to the code.
This is a qualitative shift, not a quantitative one. The agent stops being an interlocutor you narrate the system to and becomes a participant that is inside the system. Exactly what methodology and AI is about: the agent gives its best when it works not in a vacuum but in your context. MCP is the channel through which context flows live, not retold.
And the link to memory is direct. The Memory Bank gives the agent durable project knowledge — what we decided and why. MCP gives the current slice — what's in the system right now. Memory is "who we are," MCP is "what's around this second." Together they cover what a bare model lacks by definition.
Security boundaries: what you hand over
Giving the agent hands means giving it the ability to break something or leak something. That's not a reason not to give — it's a reason to give deliberately. When you connect an MCP server, you answer three questions.
What access you give. Read-only or write? One table or the whole database? One directory or the disk root? The default is the minimum privilege that covers the task. A database for analysis — a read-only role, not a superuser. The agent almost never needs as much as it gets handed by inertia.
What the agent can break. A tool with write access is an agent that can run a DROP, overwrite a file, fire a live request at a payment gateway. The model errs plausibly: it generates a confident query that does the wrong thing. Destructive actions should be either unavailable, or behind a confirmation, or in a sandbox where the cost of a mistake is zero.
What can leak. Everything the agent reaches ends up in its context, and from there — to the model provider, into logs, into subsequent responses. Production with personal data, secrets, keys — that's what should never be in the agent's context. A separate threat is untrusted MCP servers: someone else's server in your tooling is someone else's code with your privileges. Install servers as fussily as you vet dependencies in production.
The healthy stance: treat an agent's tooling as a service's privileges. The same principle of least privilege as for access between services. The agent is one more actor in your system. Give it exactly the rights the task needs, and not one more.
In short
- The model is the agent's brain; without tools it can only write text. MCP gives it hands.
- Before MCP every "agent × tool" pair was written from scratch — a matrix of hacks. MCP is one protocol that collapses it into "tool once, agent once."
- An MCP server is an adapter to one world (files, DB, git, API), exposing tools and resources. A client inside the agent discovers the tools and lets the model use them. The model doesn't know the internals behind the protocol — it's port/adapter at the tooling level.
- For a product engineer MCP lengthens the lever: the agent doesn't retell the system from your words, it reads the database, hits the API, opens tickets itself. Memory answers "who we are," MCP answers "what's around now."
- Security boundaries are three questions: what access (least privilege), what can break (writes behind confirmation/sandbox), what can leak (no prod, no secrets, no untrusted servers). Agent tooling = service privileges; least privilege.
- How to write your own MCP server is a separate craft; a product engineer more often needs to connect an existing one well and decide what hands to give it.