An AI agent is only as useful as the actions it can take, and only as trustworthy as the information it acts on. Ask a language model whether an address is real and it will give you a confident answer. It may even “correct” the address into something plausible. Neither tells you whether a parcel will actually arrive.
The fix is not a better prompt. It is to give the agent a tool that knows the answer. This post explains what an MCP server is, why it has become the standard way to give agents tools, and what we learned building one for address validation.
Key takeaways
- An MCP server exposes tools and data to AI agents through a standard protocol, so any compatible agent can use them.
- Let the model handle language; let tools handle facts. The agent turns free text into structured input, and a validated service gives the answer.
- Our address-validation MCP server took structured addresses (one or many), checked them against a dedicated validation service and returned whether each was valid.
- For enterprises, MCP is a way to connect agents to existing systems without rebuilding them, as long as the tools are designed with the same care as any API.
What is an MCP server?
The Model Context Protocol (MCP) is an open standard for connecting AI applications to external tools and data. An MCP server is a small service that implements it: it describes the tools it offers (their names, what they do and the exact input they expect) and runs them when an AI agent calls them.
Before MCP, every AI application needed its own custom integration for every tool. With MCP, a tool is built once, as a server, and any MCP-compatible agent or assistant can use it. That is why MCP servers now exist for everything from code repositories to design tools to databases.
For a CTO, the important part is what an MCP server is not: it is not AI. It is ordinary, deterministic software with a well-defined interface, which is exactly why it makes agents more reliable.
The problem: addresses in free text
Addresses arrive in free text all the time: in emails, support tickets, chat messages and order notes. Before an address can be used to ship an order, update a customer record or verify an identity, it has to be split into its parts and confirmed as real.
A language model is good at the first half of that job. It is not reliable at the second. It has no way to know whether a given street number exists in a given postal code, and it will not tell you when it is guessing.
The approach: split the work
At Runner Technologies, I built a proof-of-concept MCP server that gave AI agents a single, well-defined tool: validate addresses.
- The agent does the language work: finding the address in the text and turning it into structured fields.
- The MCP server defines the contract: a JSON object, or an array of objects for several addresses at once, with address line 1, address line 2, city, state, postal code and country.
- A dedicated service gives the answer: the server passes each address to CLEAN_Address, a validation service, and returns whether it is correct.
An illustrative request to the tool:
{
“address_line_1”: “123 Example Street”,
“address_line_2”: “Suite 4”,
“city”: “Springfield”,
“state”: “IL”,
“postal_code”: “62701”,
“country”: “US”
}
]
In testing, the proof of concept performed very well: the agent handled the language, and every validity answer came from the validation service rather than the model’s judgement.
Why this design works
- Each part does what it is good at. The model handles messy language; the validation service handles facts.
- The result is auditable. Every decision traces back to a specific tool call with a specific input and output, not to a model’s reasoning.
- Batching is built in. Accepting an array means an agent can validate a whole list of addresses in one call.
- The tool is reusable. Any MCP-compatible agent can use the same server, and it can be improved without changing the agents.
It is the same principle behind every project in this series: don’t ask a model to guess what a deterministic system can tell you.
MCP in the enterprise: connecting agents to the systems you already have
Most organisations already have the data and services an agent would need: databases, internal APIs, CRM and ERP systems. MCP servers are a way to put a controlled, well-defined interface in front of those systems, so agents can use them without direct access to everything behind them. If you are considering it, treat each MCP tool like any other API:
- Keep tools narrow. “Validate an address” is safer and easier to test than “run a database query”.
- Define strict input schemas. A clear JSON contract is what lets the model call the tool correctly.
- Start read-only. Add tools that change data only once the read-only ones have proven themselves, and with the right approvals.
- Apply least privilege. The server should have access to what its tools need, and nothing more.
- Log every call. Inputs, outputs and the calling agent, so every action can be audited.
- Test with real inputs. Real-world data is messier than any example, as every project in this series has shown.
AI workflow design
An agent is only as reliable as the workflow around it. We work with you to identify the processes worth automating, decide which steps an agent should handle and which need a validated tool, a rule or a person, and design an architecture that fits around your existing systems.
- A map of your process showing where an agent adds value, and where it doesn’t
- The tools an agent needs, with narrow scopes, validation and least-privilege access
- Approval and review routes for any action that changes data
- A plan to test the design with real inputs before it goes live
Want agents to work with your existing systems?
We connect AI agents to the databases, APIs and business systems you already run, with tools that are narrow, validated and auditable.
Talk to us about your systems →