Monitor your MCP servers — the new microservices

MCP servers are the microservices of agentic AI

The Model Context Protocol (MCP) is Anthropic's open standard for connecting AI models to external tools and data sources. An MCP server is a lightweight process that exposes tools — read a database, call an API, search a codebase, manage files — over a standardized transport layer. Claude, Cursor, Windsurf, and dozens of other AI clients speak MCP natively.

As of March 2026, there are over 1,600 publicly listed MCP servers. They cover everything from GitHub and Slack integrations to Postgres queries, Stripe billing, and Kubernetes management. Organizations are building internal MCP servers for proprietary systems. The ecosystem is growing faster than npm packages did in 2014.

If this sounds like microservices, that is because it is. MCP servers are small, single-purpose, independently deployed services that larger systems depend on. And just like microservices, they introduce a distributed systems problem: any one of them can go down, and the system that depends on them degrades or breaks.

When your MCP server goes down, agents lose their hands

An AI agent without its MCP tools is like a developer without a terminal. It can still think, but it cannot act. If your MCP server that provides database access goes offline, the agent cannot query data. If the one that connects to your deployment pipeline crashes, the agent cannot ship code. The conversation continues, but the agent is suddenly helpless.

The failure is often silent. Most MCP clients handle tool failures gracefully from the user's perspective — the agent says "I was unable to access that tool" and moves on. No alarm fires. No page goes out. The user might not even realize the tool was supposed to work. They just get a less useful response.

Six ways MCP servers fail in production

MCP servers have their own category of failure modes. Some are inherited from the services they connect to, and some are unique to the protocol itself:

How to monitor MCP servers with HTTP health checks

MCP's Streamable HTTP transport means remote MCP servers are just HTTP endpoints. You can monitor them the same way you monitor any API — with standard HTTP requests. The key is knowing what to send and what to check in the response.

MCP servers speak JSON-RPC 2.0 over HTTP POST. To check if a server is alive and responding correctly, send a JSON-RPC ping:

# JSON-RPC ping to an MCP server
$ curl -X POST https://your-mcp-server.example.com/mcp \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc": "2.0", "method": "ping", "id": 1}'

# Healthy response
→ {"jsonrpc": "2.0", "result": {}, "id": 1}

# Server is down or misconfigured
→ Connection refused / 502 / timeout

A valid JSON-RPC response with a matching id confirms three things: the HTTP layer is working, the MCP server process is running, and the JSON-RPC handler is functional. That covers the majority of failure modes.

For deeper checks, you can call tools/list and verify specific tools are still registered. If your MCP server should expose 8 tools and suddenly returns 3, something broke during initialization.

Monitor the MCP server AND the services behind it

An MCP server is a proxy. It translates tool calls into API requests, database queries, or file system operations. The server itself can be perfectly healthy while the service behind it is down. You need to monitor both layers.

Consider a typical enterprise setup: a Slack MCP server, a Postgres MCP server, a GitHub MCP server, and a Jira MCP server. That is four MCP server processes, plus four upstream services, each with independent failure modes. You need eight monitors minimum — four for the MCP server processes and four for the upstream APIs.

This is exactly why MCP servers are the new microservices. The operational overhead scales linearly with the number of tools your agents depend on. The good news is that monitoring them is straightforward — they are HTTP endpoints like any other.

1,600 servers and counting — the MCP ecosystem is accelerating

The MCP server ecosystem crossed 1,600 publicly listed servers in March 2026, up from roughly 400 in late 2025. Every major SaaS vendor is shipping an MCP server alongside their REST API. Stripe, Linear, Notion, Datadog, PagerDuty — the list grows weekly.

This means your agent's dependency tree is expanding. A year ago, an AI coding assistant depended on one or two tool servers. Today, a well-configured Claude Code setup might have eight MCP servers providing access to GitHub, a database, a deployment pipeline, monitoring, documentation search, a browser, and internal APIs. Each one is a potential point of failure.

Teams that treat MCP servers as production infrastructure now — with monitoring, alerting, and incident response — will avoid the same painful lessons that the microservices wave taught us between 2015 and 2020. The failure modes are predictable. The monitoring tooling already exists. The only question is whether you set it up before or after your first silent outage.

We eat our own dogfood: monitoring our own MCP server

Uptrack itself has an MCP server at api.uptrack.app/mcp. It lets AI agents create monitors, check uptime status, and manage alerts — all through tool calls. If our MCP server goes down, agents using Uptrack lose the ability to manage their monitoring infrastructure. That is not acceptable.

So we monitor it with Uptrack. An HTTP monitor sends a JSON-RPC ping to our MCP endpoint every 30 seconds from multiple regions. We keyword-match on jsonrpc in the response body to confirm the JSON-RPC handler is responding, not just the HTTP layer. If the check fails from 3+ regions, we get alerted on Slack within 90 seconds.

This is the same setup any team can replicate for their own MCP servers. If you expose tools over Streamable HTTP, you can monitor them with an HTTP endpoint check. No special MCP-aware monitoring tool needed — just a POST request with the right payload.

Setting up MCP monitoring in Uptrack

Here is the quick setup for monitoring any remote MCP server: