MCP servers are how AI agents reach your data and systems. When a tool on one of those servers breaks, status checks stay green and agents carry on without it. Here’s how MCP monitoring catches it first.
Your support agent looks up an order, checks a refund policy and updates a ticket. Each of those steps is a tool call to an MCP server. The agent is only as reliable as the tools behind it.
Now the database behind the order-lookup tool goes down. The MCP server still answers, the HTTP status is still 200, and your uptime dashboard stays green. The agent retries, or worse, answers without the data. The first alert is a customer complaint.
This post covers why MCP servers fail quietly, what a useful MCP check looks like, and how Apica’s MCP Server Check finds a broken tool hours before your users do.
Why MCP servers fail quietly
An MCP server can be up and still be broken. The failures that hurt agents happen inside the protocol, where an uptime check never looks.
Errors hide inside successful responses. The MCP specification reports a tool’s own failures, such as an API or database error, inside a normal result marked isError: true. The HTTP status is still 200, so a status check stays green:
{
"jsonrpc": "2.0",
"id": 4,
"result": {
"content": [
{ "type": "text", "text": "Order lookup failed: database connection timed out" }
],
"isError": true
}
}Tools disappear after an update. A deploy renames or drops a tool your agents rely on. The server is healthy, but the tool your agents call is gone.
Backend credentials expire. The server answers, but every call that touches the expired backend fails.
Tools slow down. A tool that responds too slowly stalls every agent workflow waiting on it.
In each case the agent pays the price. It retries, or it answers without the data, and your users notice before your monitoring does.
How the MCP Server Check works
Apica’s MCP Server Check tests your MCP server the way an agent would, on a schedule. There’s no agent or LLM in the loop, nothing to install on the server, and no code changes. Each run answers three questions:
- Can agents connect? The check connects to the server. It confirms the server is reachable and secure, sign-in works, and the protocol version is the one your agents expect.
- Are the tools there? It reads the tool list and confirms every critical tool is still published. A missing tool fails the check.
- Do the tools work? It makes one safe, read-only call per critical backend. Errors hidden inside successful responses are caught, and tools slower than your response-time limit are flagged.
If any step fails, the alert names the broken tool, so on-call knows exactly where to look.
The 2 a.m. failure, found in five minutes
Here’s an illustrative example. At 2:07 a.m., the database behind one of your MCP tools fails. The server keeps answering, so status checks stay green.
The MCP Server Check’s next run calls that tool, sees the failure inside the response, and alerts at 2:12 a.m. with the tool’s name. With status checks alone, the first sign is a user complaint at 8:40 a.m.
That’s more than six hours in which your agents retried, stalled or answered without the data, and nobody on your team knew.
What good MCP server monitoring covers
Whatever tool you use, an MCP check earns its place when it tests what your agents actually depend on. Use this list to judge yours:
- Speak MCP, without an agent. Talk to the server over the protocol directly, with no LLM in the loop. Results stay predictable, and the check is cheap enough to run every few minutes.
- Pin the tools that matter. List the tools your agents rely on, and fail the check the moment one is missing from tools/list.
- Call one read-only tool per critical backend. A safe test call proves the whole path to each database or API works, without changing any data.
- Read the result, not the status code. Treat isError: true as a failure, even when the HTTP status is 200.
- Set a response-time limit. An answer that arrives too slowly is a failure for the agent waiting on it.
- Alert on the tool, not just the server. An alert that names the broken tool tells on-call exactly where to look.
- Run it around the clock. A scheduled check finds the failure at 2 a.m., when no one is using your agents to notice.
Where to start
Start with the MCP servers behind your customer-facing agents, and the handful of tools those agents can’t work without. The MCP Server Check needs no agent, no LLM, no code changes and nothing installed on your server, so it’s the fastest way to see what your agents are really getting back.
MCP monitoring is one part of Apica’s AI monitoring. Agentic Workflow Monitoring checks that the agent itself gives the right answer, LLM Observability tracks model performance and cost, and Apica Flow keeps the telemetry from MCP servers and agents affordable to store.
You shouldn’t hear about a broken tool from a customer. Book a 30-minute Apica demo and we’ll walk through the MCP servers your agents depend on and show you what a check would catch.
