Connecting AI agents to your systems, not your whole database

Every owner asks the same thing first: can it see everything? No. An agent sees the list of operations you wrote for it, one call at a time. On a platform we work on, that list is a set of named tools, each with typed inputs, a mutation class and a hard cap on how much it can return. No connection string appears anywhere in it.

MCP, the Model Context Protocol, is an open standard for handing an AI client a specific, named set of capabilities, so any agent can drive your system without somebody building a bespoke integration first. It went to the Linux Foundation's new Agentic AI Foundation in December 2025, with AWS, Google, Microsoft and Bloomberg among the platinum members and over 10,000 servers already published (Linux Foundation, 9 December 2025).

None of that is the first question, though. The first is whether you need an agent at all, and an agent, a chatbot and a workflow are three different purchases. A workflow with a model in one step needs no tool protocol; your code already owns the order. What follows assumes that argument is settled and the thing has to reach into systems people depend on.

A tool is a verb, not a connection

The unit of access is an operation with a name, typed inputs and a response shape you decide. A table is the wrong unit, and so is a read-only database user plus good intentions.

The tools on that platform sort by domain: the operational lifecycle after a deal is contracted, matching the two sides of the marketplace, inventory, fleet and sites. The rest cover identity, suppliers, customers and a couple of utilities. Nothing in that set says run a query. An agent that wants a number nobody gave it a verb for does not get the number, it gets to ask a person.

Every response carries a hard character limit. One unbounded list fills the caller's context window, and an agent whose context is stuffed with rows is worse at everything for the rest of the conversation. Truncating with a note is kinder to the model than being complete.

One of the tools makes no API call at all. It takes a compact pasted postcode range, the sort that lives in a sales spreadsheet, and expands it into a flat deduplicated list, warning on ranges that run backwards or cover half the country. A language model does that badly. A short function does it perfectly, for nothing, every time. Tools are where the deterministic parts go too.

Label every tool by what it can break

Every tool carries one of four annotations: read-only, create, mutate, destructive.

Annotating is cheap, and the payoff is that your write policy stops being a list of tool names that goes stale by the next release. Four rules get written once, and the next tool inherits whichever one applies on the day it ships. The class travels with the tool, so a client that has never met your product can sort a search from an archive before calling either.

Be clear about what an annotation is: a claim about a tool, not a control on it. It tells a well behaved caller what to expect and does nothing to a badly behaved one. Enforcement lives in the server, on the far side of the model, which is the whole argument in prompts instruct, code enforces.

Should the same tool answer differently for different callers?

Yes, and teams get this wrong by writing two tools where they need one. On that server, a single raw handler makes the API call, and two thin formatters render the result. Plain JSON goes to a desktop AI client connected over stdio, and formatted text goes to the assistant embedded in the product, served over HTTP. One source of truth, two audiences, and nothing that can drift apart.

Role comes out of the caller's token, so the same tool answers differently for the two sides of a marketplace. One side sees the capacity it owns; the other sees capacity it can book. Different heading, different suggested next steps, one implementation. When the same noun means opposite things to two user types, that is a modelling decision, and it will leak into your schema if you leave it as a copy decision.

That is all formatting, though, and the distinction bites. Which rows a caller may see is not a formatting question and must never live in the formatter. Filter server-side, in the same code path that filters the same request from your web app, then let the presentation layer be polite about what survives.

Anything that changes state should ask first

We also built a much smaller server for a client's internal assistant, and only some of its tools write. It sits over the client's knowledge base and the workspace where the roadmap lives, with a chat bot in front. A product conversation can end with a ticket in the backlog.

The rule on every write tool is that the model may not call one as its opening move. It reads back the title, the destination and everything it collected, asks whether to go ahead, and writes only once a person says yes. The ceiling on what those tools can touch at all lives in code, outside that conversation.

Confirmation matters most for the failures nobody notices. A tool that cannot reach your system fails loudly, with a stack trace. A tool that writes something plausible to the right place fails silently and gets found a fortnight later by an accountant. The same asymmetry runs through the faults a green build hides.

Read-only by default, and what "just this once" costs

Start read-only and stay there longer than feels necessary. A read tool that returns the wrong rows is a bug you fix on Tuesday. A write tool that writes the wrong rows is a phone call with a customer.

Two mechanics make the default hold. When configuration is missing, capability should disappear. The internal assistant we built for a client registers the workspace tools only when the workspace credential is present at boot, so a half configured deployment answers questions and physically cannot write. And any write permission granted for a specific reason gets an expiry date attached at the same time.

The temporary exception is how incidents start. Someone needs a write during a deadline week, the scope gets widened in a shared environment, nobody puts a date on it, and months later an agent holds standing permission nobody remembers granting.

A widely reported incident in April 2026 had that shape. An account-wide token created for a narrow job was found by an agent in an unrelated file and used to delete a production database in a single call. The provider says it recovered all the data (Railway, 2026), so the loss was temporary, but the permission was real.

In regulated work the same instinct shows up as a rule about what AI may retrieve rather than conclude, which we set out for compliance and inspection businesses.

When we did not put tools behind MCP

The team that exposed that platform to agents through scoped tools did not put the assistant's own tools behind MCP, and wrote down why. Those are plain JSON schema function definitions, dispatched in the same process as the agent. No network hop, no second service to deploy, no protocol version to track, no transport to debug at two in the morning.

The threshold they recorded: MCP earns its keep when tools are called by clients you do not control, or when they need to be discovered or installed at runtime. A set of more than about ten or twelve tools also qualifies. Below that it is ceremony, and a handful of tools that only ever run inside one service are a function call wearing a costume. That threshold is a judgement call, and it moves. If people in your building already work in a desktop AI client every day, the number that justifies the protocol drops fast.

A less flattering reason to stay sober about it: the MCP client we built for that platform processes requests through one serial queue. That is fine for one person at a desktop and a known bottleneck the moment a few people use it together. It is documented, which is the right way to carry a limitation. Adopting a standard buys portability, not throughput, and portability is worth paying for later than most teams do.

Start with three read-only tools on the system of record

Pick the system people argue about in meetings, usually whichever one holds customers or jobs. Write three read tools against it: fetch one record by id, search with the filters people use in practice, and one rollup for a question somebody now answers by exporting a spreadsheet on a Friday.

Give it to one team for a fortnight, then count how often somebody wanted a fourth tool and what it was. That list is your roadmap and it will not match the one you would have written up front. Ours never does.

Add the first write after that, behind a confirmation, with an audit entry naming the tool, the caller and the arguments. Then budget for the unglamorous part: deciding what a customer is when the finance system and the operations system disagree, and getting somebody senior to sign that definition. The protocol is a weekend. The definitions are the project.

Common questions

Does an MCP server give an AI access to our database?

No. It gives the AI the operations you implemented and nothing else, each with typed inputs, a response you control and whatever filtering your API already applies. If nobody writes a tool that returns salaries, no amount of clever prompting produces salaries.

What should we check before installing somebody else's MCP server?

Read every tool description, because tool metadata is an instruction channel that reaches your agent. Research published in 2026 identifies tool poisoning, meaning malicious instructions hidden in that metadata, as a primary attack class against MCP (arXiv:2603.22489). Pin versions and prefer servers whose source you can read.

Do we need MCP, or is our existing API enough?

Your API is what the tools call, so you need it either way. The protocol earns its place when more than one AI client has to reach your system, when tools should be discovered at runtime, or once you pass roughly ten tools. One agent with a handful of tools does not need it.

How many tools should one server expose?

Fewer than you think, grouped by what a caller wants to do rather than by your table names. A large set still works when the tools sort by domain and every response is capped, as it does on that platform. A few vague tools are worse than many precise ones, because a vague tool makes the agent guess.