Why This Matters Right Now

AI agents are reaching into your infrastructure faster than most founders realize. A single configuration line in Cursor, Claude Code, or VS Code can point an agent at a third-party MCP server that reads databases, queries logs, or fires off API calls — all without you reviewing each request.

Cloudflare recently published guidance on detecting shadow MCP traffic, and the core concern is the same one every solo founder faces: you don’t have a security team watching dashboards at 2 a.m. When an agent makes a plausible but incorrect decision, it can repeat that action thousands of times before you notice. That’s not a theoretical risk anymore.

This isn’t about buying an enterprise observability platform. It’s about knowing what MCP servers are running on your machines, what they’re allowed to access, and how to spot activity that doesn’t belong there.

What You Should Be Monitoring

You don’t need fifteen different tools. Focus on three things:

Which MCP servers are active. Every MCP client you use — Cursor, Claude Desktop, Copilot, Windsurf — maintains its own configuration file. These files list every server the client can connect to. Check them. If you see a server you don’t recognize, that’s your first signal.

What data those servers access. MCP tool calls carry arguments inside a JSON-RPC envelope. Those arguments can contain search queries, source code, customer data, or instructions for actions like creating records or changing infrastructure. The tool name tells you what the agent intends to call; the arguments tell you what data it will send. Both matter.

Unexpected patterns in the traffic. MCP doesn’t require a specific hostname or a /mcp path. A direct connection can look like any other HTTPS API call. That means you won’t always spot shadow traffic by URL alone. You need to look at volume, frequency, and whether the same tool is being called repeatedly in a short window.

Practical Steps for Your Own Infrastructure

Start with what you already have. Most MCP servers communicate over stdio or HTTP, and both leave traces if you know where to look.

Check Your Client Configurations

MCP clients store server configurations in well-known locations:

  • Cursor uses .cursor/mcp.json at the project level or a global config
  • Claude Desktop stores its config at ~/Library/Application Support/Claude/claude_desktop_config.json on Mac
  • VS Code with GitHub Copilot uses .vscode/mcp.json
  • Windsurf has its own MCP config file

Open each one. List every server. Ask yourself whether you intentionally added it and whether it still serves a purpose. Remove anything you don’t recognize.

Use a Local Logs MCP Server

If you want something that runs locally and gives you visibility without sending data to a third party, the Local Logs MCP Server is worth testing. It monitors local application logs with real-time tailing, error tracking, and log search — all read-only, all on your machine.

You install it with a single command, point it at your logs directory, and connect it to your MCP client. From there you can ask your AI assistant to list available log files, check for recent errors, tail the last few hundred lines, or search across logs for specific patterns. It streams data instead of loading entire files into memory, which matters when you’re working with large log suites.

The server only reads log files. It never writes or modifies them. That’s an important boundary — you’re gaining visibility, not introducing a write path that could accidentally change production state.

Connect to an Existing Monitoring Backend

If you already use Datadog, New Relic, Grafana, or Prometheus, several MCP servers exist to bridge those platforms into your AI workflow. The Datadog MCP server, for example, lets you query monitors, dashboards, metrics, events, logs, and incidents through a standardized interface — no custom API integration required.

This is useful when you want your AI assistant to help you investigate an incident or check system health as part of your normal workflow. But it also means every query your agent runs goes through your Datadog account. Make sure your API keys have appropriate permissions and aren’t granting broader access than you need.

Watch Your Browser Console

For front-end work, the Chrome Spy MCP server provides real-time monitoring of Chrome developer console logs via the Chrome DevTools Protocol. You can monitor specific tabs, filter logs by severity, and retrieve them incrementally. If your AI agent is interacting with browser-based tools or debugging client-side issues, this gives you visibility into what the agent sees in real time.

Run an MCP Health Monitor

Some MCP servers exist specifically to monitor other MCP servers. The MCP Health Monitor checks uptime, response times, and pipeline status for connected servers. The MCP Agent Trace Inspector gives you step-by-step observability into agent workflows. These are lighter-weight than full observability suites and run locally, which keeps your data where it belongs.

How to Spot Shadow Traffic

Shadow MCP traffic is traffic that reaches an MCP server outside your approved path. Cloudflare’s guidance focuses on this distinction: when an employee points an AI harness at a server without checking whether it’s approved, the resulting traffic has no obvious shape.

Here’s how you can catch it on your own setup:

Look for repeated calls to the same tool. An agent that makes the same tool call thousands of times in a short window is likely stuck in a loop or acting on a flawed assumption. The Local Logs MCP Server can help you detect this by surfacing error patterns and sudden spikes in log volume.

Check tool arguments for sensitive data. If an agent is calling a server and passing customer records, API keys, or internal URLs as arguments, that’s a red flag — especially if you didn’t expect that server to receive that data.

Audit your API keys and permissions. Every MCP server that connects to an external platform needs credentials. Review which keys are in use, what scope they have, and whether you can restrict them to read-only access where possible.

Test whether servers are responding. You can verify an MCP server is active by sending a basic initialization request. If a server you don’t recognize is responding, you’ve found a shadow connection.

Trade-offs to Consider

Adding MCP server monitoring means adding another tool to your stack. Every tool introduces a decision point: does this save me more time than it costs to maintain? Here’s where the balance usually falls:

Local logs servers cost nothing to run beyond your own machine and give you immediate visibility into application errors and patterns. The trade-off is that you’re only seeing logs your apps write locally — if you ship to a managed host, those logs may not be accessible.

Platform-specific MCP servers (Datadog, New Relic, Grafana) extend your existing monitoring into your AI workflow. The trade-off is that you’re sending queries through your existing account, which may already have usage-based pricing. A runaway agent could generate more billable requests than you expect.

Health monitors and trace inspectors are lightweight and local but only show you what happens inside the MCP layer — they won’t tell you what your application is doing downstream. Use them alongside, not instead of, your primary observability.

Read-only access is your friend. Any MCP server you add should read, not write, unless you have a specific reason to allow writes. The Local Logs MCP Server respects this boundary by design. Other servers may not. Check before you connect.

FAQ

Do I need an enterprise observability platform to monitor MCP traffic? No. You can start by checking your client configuration files and using a local logs server. Those two steps alone will surface most issues a solo founder encounters. Enterprise tools become worth considering only when your infrastructure grows beyond what you can reasonably manage yourself.

Can MCP traffic really look like normal API calls? Yes. The Model Context Protocol doesn’t require a guaranteed hostname or a specific path like /mcp. A direct connection can appear indistinguishable from any other HTTPS request to someone glancing at network logs. That’s why you need to look at tool names, method calls, and argument patterns — not just URLs.

Should I remove MCP servers I don’t remember adding? Yes. If you can’t explain why a server is configured in your MCP client, remove it. Unknown servers are the easiest way for shadow traffic to enter your workflow. It’s better to re-add a server you need later than to leave a potentially unnecessary connection active.

What’s the safest way to connect an MCP server to an external platform like Datadog? Use the narrowest API key scope possible. If the server only needs to read logs and metrics, don’t grant it write or delete permissions. Review the permissions regularly, not just at setup time.

How do I know if an agent is stuck in a loop? Watch for repeated calls to the same tool in rapid succession. Both the Local Logs MCP Server and MCP health monitors can surface this pattern. If your agent starts making hundreds of identical requests, stop it, review the prompt or workflow that triggered it, and adjust before reconnecting.

Sources