What an MCP server actually is, and why one holding a payment credential needs care
TL;DR: key takeaways
- An MCP server is a small program that exposes tools, data or prompts to an AI agent over a standard protocol, so the agent doesn't need bespoke integration code for every source.
- The protocol has three roles: host (your application), client (the connector inside it) and server (the thing you're reading about), talking over stdio or HTTP.
- Most MCP servers are read-only by design. The moment one exposes a tool that spends money, it stops being a convenience and starts being an attack surface.
- You rarely need to write one from scratch. You need to know which of the thousands already published you can trust with a payment credential, and which you cannot.
An MCP server is a small program that hands an AI agent a defined, discoverable set of tools, data or prompt templates, using a shared protocol instead of a one-off integration written for that agent alone. It sounds like a small idea and it has turned out to be one of the fastest-adopted pieces of agent infrastructure going: our own Google Ads Keyword Planner measurement on 8 August 2026 put US search volume for "mcp server" at 60,500 a month, low competition, well ahead of almost every other term in the agentic-AI space. This is what the phrase actually means, how the pieces fit together, and — because Spend7 spends its days thinking about agents that can move money — the specific place one stops being a convenience and starts being something to watch carefully.
What an MCP server actually does
Strip away the acronym and the job is ordinary. Before an agent can act on the world, something has to tell it what actions exist, how to call them, and what came back. Historically that meant a developer writing bespoke glue for every tool: one integration for a calendar, another for a database, another for a payments API, each with its own auth, its own quirks, none of it reusable across agent frameworks.
An MCP server replaces that bespoke glue with a standard contract. Connect a client to one and it can ask, in a uniform way, "what can you offer me?" The server answers with a list of tools (functions the model can invoke), resources (data it can read) and prompts (templates it can use), each described in enough detail that a model reasons about them the same way it reasons about anything else in its context. Written once, it works with Claude, the OpenAI Agents SDK, LangChain, CrewAI and most other frameworks worth naming, because they've all adopted the same protocol rather than inventing their own.
Host, client and server: the three roles
The Model Context Protocol specification defines three parts, and mixing them up is the most common source of confusion when people first read about this.
The host is your application: the agent, the chat interface, the automation that has an LLM inside it. The host embeds one or more clients, and each client holds exactly one connection to exactly one server. The server is the program actually being discussed here — it doesn't know or care which host is talking to it, only that whoever connects speaks MCP.
That separation is what makes the ecosystem composable. A host can run five clients side by side, each wired to a different server (one for a filesystem, one for a search index, one for a payments risk check), and the model reasons across all five without the host needing bespoke code for any of them individually.
Tools, resources and prompts: what gets exposed
Not everything a server like this offers is the same kind of thing, and the distinction matters more than it looks.
Tools are functions the model can call, with arguments and a return value; this is where the money question lives, because a tool is an action, not just information.
Resources are read-only data the host can pull in, more like a file the model gets handed than a button it presses.
Prompts are reusable templates a user or host can select, standardising a task rather than automating it outright.
Most published servers stick to the first two and stay firmly read-only: a documentation search server returns text, a database server returns rows. The moment a server's tool list includes something that changes state in the real world (sends an email, books a meeting, moves money) the calculus around trusting it changes completely, which is the thread this piece is really about.
| Piece | Runs where | Model can do with it |
|---|---|---|
| Host | Your application | Owns the agent loop and the model call |
| Client | Inside the host, one per server | Holds the connection and routes calls |
| MCP server | Wherever you or a vendor runs it | Advertises tools, resources, prompts |
| Tool | Exposed by the server | Called with arguments, returns a result — an action |
| Resource | Exposed by the server | Read into context — information, not action |
Table: the moving parts of this kind of integration and what each one is actually allowed to do.
Wiring one in, in outline
The exact registration syntax differs by framework, but the shape is the same everywhere: point a client at a server, over stdio for a local process or HTTP for a remote one, and the host takes care of the discovery handshake.
from agents import Agent
from agents.mcp import MCPServerStdio
search = MCPServerStdio(
params={"command": "npx", "args": ["-y", "some-search-server"]}
)
agent = Agent(
name="researcher",
instructions="Look things up before answering.",
mcp_servers=[search],
)
That's genuinely most of it for a read-only server. LangChain does the equivalent through langchain-mcp-adapters, CrewAI through crewai-tools' MCPServerAdapter, and the framework integration pages walk through each one. The interesting decisions start once a tool in that list can do something rather than just tell you something.
Where the default trust runs out
"A tool description is text that goes into the model's context the same way a user's message does. Most developers spend weeks thinking about prompt injection from a hostile web page and none thinking about the server they installed with
npx -ylast Tuesday, which can say anything it wants."the Spend7 engineering team
That's the sharpest version of the problem: connecting to one loads its tool names and descriptions into the model's context, and the model treats them as trustworthy the way it treats its own instructions. A malicious or compromised server doesn't need to trick the model at runtime — it can plant the instruction directly in a docstring, a technique known as tool poisoning, and it arrives the moment you add the server, not when anyone fetches a hostile page.
That's manageable for a server that only reads a filesystem or searches documentation, where the worst outcome of a poisoned description is a wasted call or a leaked file. It is a materially different conversation for a server holding a payment credential or the ability to check and spend a budget. We've written the specific playbook for that case: keep the server to reporting and scoring, never to moving money directly, and put the actual enforcement inside a function the model cannot opt out of calling — because an MCP tool, by design, is always something the model can choose not to use, which makes it a poor place to put your only control. The same reasoning applies to any prompt injection aimed at a payment-capable agent: the fix is architectural, not "trust the model more."
Do you need to build your own?
Almost certainly not from scratch, for the general case. Thousands of servers are already published for the obvious categories — filesystems, databases, search, common SaaS tools — and reusing an actively maintained one beats maintaining a bespoke integration nobody else is testing. The official specification and SDK list is the place to start looking, and the 2026-07-28 update to the protocol is worth reading before you pin a version, since authorisation handling changed meaningfully in that release.
Where building your own earns its cost is the case a generic server was never going to cover: something that reasons about your money against your rules. That's the gap our own risk-scoring tools fill for agent spend specifically — one whose only job is answering "is this safe to pay, and how much headroom is left," never executing the payment itself.
Common pitfalls
Assuming every server is read-only. Check the tool list before assuming an mcp server is safe to add. A transfer or delete tool changes the entire risk calculus of connecting to it.
Auto-updating third-party servers. One that updates itself is an auto-updating block of text sitting in your model's context. Pin the version.
Treating the tool call as the control. Nothing stops a model from declining to call a tool it was supposed to call. If a check has to happen, it belongs in code the model cannot route around, not in an optional tool.
Skipping the discovery step in review. The tool descriptions a server returns are exactly as reviewable as any other dependency's source. Most teams read neither the first time.
Next
The MCP server documentation covers Spend7's own tool surface if you're specifically after payment risk checks, and the official protocol specification is the source of truth for everything general covered above. If your agent already holds a payment credential and you're deciding what it should and shouldn't be allowed to do with that access, wiring a payment MCP server in without handing over the keys is the practical next read.
Frequently asked questions
- What is an MCP server in simple terms?
- A small program that speaks the Model Context Protocol and offers an AI agent a defined set of tools, data resources or prompt templates. Instead of writing custom integration code for every API an agent might need, the agent's host application connects to any MCP server that speaks the same protocol and gets the same three things: a list of what's on offer, a way to call it, and a structured result back.
- How does an MCP server differ from a normal API?
- A REST API is built to be called by code that already knows its shape: fixed endpoints, a contract read once at build time. An MCP server is built to be discovered by a model at runtime: it advertises its own tools, their names, their arguments and what they're for, in a form the model reads as part of deciding what to do next. The wire format underneath is still JSON-RPC; what's different is who is deciding what to call and when.
- Is it safe to connect an agent to any MCP server?
- Not by default. Connecting a client to a server loads that server's tool names and descriptions into the model's context, which the model treats as trustworthy instructions. A malicious or compromised server can write hostile text into a tool description, a technique called tool poisoning. Pin versions, review anything you add, and treat an unfamiliar server the way you'd treat an unfamiliar dependency, not the way you'd treat a trusted library.
- Do I need to build a custom MCP server for my product?
- Usually only if you're exposing something proprietary, like your own product's data or actions. For anything general (a database, a filesystem, a search engine) there is very likely a published server already, and reusing one that's actively maintained beats writing and patching your own. Where a custom server earns its cost is exactly the case a general-purpose one won't touch: something that reasons about your own money, like a payment risk check.
Score a payment before it settles
Spend7 returns allow, flag or deny in one call, with the signals that produced it. The free tier covers a single agent, its spend caps and its full decision log.
