How to Monitor MCP Servers for Agent Discovery

August 13, 20265 min read

Agents are hard to inventory because they enter your environment from every direction and rarely announce themselves. One of the most reliable places to catch them is the Model Context Protocol layer. When an agent exposes or consumes capabilities, it usually does so through an MCP server, and that server is something you can find, watch, and govern.

This is an operational guide for the security and platform engineers who have to wire that up. It assumes you already know what MCP is and why it matters, and focuses on how to actually monitor MCP servers to discover the agents behind them.

Why MCP is a discovery signal worth instrumenting

MCP servers expose tools and resources that agents call. A new server appearing in your environment usually means a new or changed agent is running somewhere, often before any instrumented trace has been emitted. That timing is what makes MCP monitoring valuable as a discovery technique: a server can be reachable and serving capabilities while its agent is still invisible to telemetry-based discovery.

Watching the MCP layer catches agents that other methods miss, and it gives you a structured view of what an agent can do rather than just raw traffic. You see the capability surface directly.

What you're actually looking for

Two events matter operationally. A new server appearing, which signals a potentially unknown agent. And an existing server changing, which signals that a known agent's capability or risk surface has shifted.

For each server you find, capture enough metadata to triage it later:

Exposed tools and resources — what the server lets an agent do, and what data those tools can reach.
Transport type — stdio, HTTP, or SSE, which determines how you monitor it going forward.
Auth model — whether the server is authenticated, and how.
Host and location — which environment, host, or process the server runs in.
Owner — the accountable team, if one can be resolved.

That metadata is the difference between "we found a server" and "we know what this server is and whether it's a problem."

Local vs. remote servers change the monitoring approach

MCP servers come in two shapes, and they demand different detection paths. Miss one and you miss half the surface.

Remote servers communicate over the network, typically over HTTP or SSE. They're reachable by network scanning, discoverable through gateway and proxy logs, and generally the easier of the two to find because they leave network-visible traces.

Local servers communicate over stdio and are bound to a specific host and process. They never touch the network, so network scans and gateway logs won't see them. Finding local servers requires host-level or process-level inspection: looking at what's running on a machine, not what's crossing the wire.

A monitoring strategy that only scans the network will build a clean inventory of remote servers and stay blind to every local one. You need both paths.

How to find MCP servers in your environment

No single method is complete, so combine several. This mirrors the multilayer logic of agent discovery overall.

Network and endpoint scanning. Scan for MCP-signature traffic and listening servers across your environment. This catches remote HTTP and SSE servers as they come online.

MCP gateways and proxies. Routing MCP traffic through a gateway turns discovery into a chokepoint problem. Every server that passes through registers itself by definition, which gives you a near-complete view of remote MCP activity from one vantage point. If you can standardize on a gateway, this becomes your strongest single signal.

Registry-based discovery. Where an MCP registry or catalog exists, use it as a source of declared servers, then reconcile it against what you actually observe. The gap between declared and observed is often where shadow agents hide.

Host and process inspection. For local stdio servers, inspect hosts and running processes directly. This is the only path that surfaces servers with no network footprint.

Detecting change on servers you already know

Discovery isn't a one-time scan. A server you cataloged last month can quietly become a bigger risk without a new server ever appearing. Watch known servers for:

New tools or resources exposed. Capability expansion changes the agent's risk surface. A server that gains write access to a database is a different risk than the one you originally triaged.
Auth, transport, or endpoint changes. A server that drops authentication or moves endpoints is worth an immediate signal.
A server going dark. Disappearance can mean a decommissioned agent, or an agent that moved somewhere you're not watching.

Each of these deserves an alert, because each represents a change to what an agent can do or where it lives.

Turning a discovered server into a governed one

Finding a server is the start. The point is to move it from unknown to governed. For each discovered server, run the same triage:

What tools and resources does it expose, and what data can those tools reach?
Is it third-party or internally built?
Who owns it?
What's its risk classification?

Once a server is triaged, you can organize it into a governed application, assign an accountable owner, and apply the right guardrails and access controls. This is the same discovery-to-governance handoff that the best practices for agent discovery and governance work through in more depth: an unowned server with unclear data access is exactly what a compliance review will flag.

Where MCP monitoring fits with the other three techniques

MCP monitoring is one of four discovery techniques, and you run them in parallel because each catches what the others miss.

Telemetry-based discovery listens to OpenTelemetry streams for new agents, tools, and config changes. MCP monitoring complements it by catching servers that are present but not yet emitting traces.
Network-layer analysis inspects traffic for LLM API-call signatures. MCP monitoring adds a structured capability view rather than raw traffic, and reaches local servers that never hit the network.
API-driven discovery queries cloud platforms like AWS Bedrock and Google Vertex AI for what they're running. MCP monitoring covers the servers those APIs don't advertise.

No single technique is complete. MCP monitoring's specific contribution is the documented capability surface: what an agent can do, seen directly at the protocol layer.

How Arthur fits

Arthur monitors MCP servers as one of four parallel discovery techniques in its agent security and governance (ASG) platform, alongside telemetry, network-layer, and API-driven discovery. New and changed servers are surfaced automatically, then routed into governed applications where they get an owner, a risk classification, and the right guardrails.

The control plane coordinates discovery and governance across your environment, while the data plane runs inside your VPC, so telemetry and agent data never leave it. You get one view of every agent and its MCP surface without moving data outside your cloud.

TL;DR

MCP servers are a strong discovery signal because a new or changed server usually means a new or changed agent, often before telemetry sees it.
Capture per-server metadata: exposed tools and resources, transport, auth model, host, and owner.
Local (stdio) and remote (HTTP/SSE) servers need different detection paths. Network scanning finds remote servers; host and process inspection finds local ones.
Find servers through network scanning, MCP gateways and proxies, registries, and host inspection. No single method is complete.
Watch known servers for new capabilities, auth or transport changes, and disappearance.
Triage each discovered server, assign an owner, classify risk, and apply guardrails to move it from unknown to governed.
Run MCP monitoring in parallel with telemetry, network-layer, and API-driven discovery.

Ready to bring every MCP server and agent in your environment under one governance framework? Book a demo with an AI expert or explore the Agent Development Toolkit.

‍