MCP is generating a lot of hype nowadays (but then again, almost anything that emerges in AI seems to attract hype). The anticipation around it is similar to the level of excitement that would break out if Apple were to finally introduce USB-C to iPhones. To be fair, though, some of that hype is warranted, considering the fact that MCP provides a standardized approach to connecting agents with third-party tools, which significantly simplifies this type of integration (hence the USB-C analogy).
But the hype has got me wondering: if my agent can access all my data, do I even need the monitoring tool anymore? Why not just pipe logs and metrics to Claude and call it a day?
TL;DR MCP is an interface layer, not a data layer. Think of the USB-C and what it could do for your iPhone; not any processing, that’s for sure. It would just provide a standardized way to transmit data. The same logic applies to MCP. It queries your monitoring data, but it doesn’t collect or store any of it. Nobody is watching your app overnight or alerting you if something goes wrong. Something still needs to do that job, and that something is your monitoring tool (AppSignal, perhaps? 😉)
What MCP Actually Does
Before we go any further, let’s quickly go over what MCP is all about.
Model Context Protocol (MCP) allows AI agents to connect to external tooling and data sources, removing the limitations of stale training data.
AppSignal, for example, provides an MCP server that exposes monitoring data, such as errors, performance metrics, anomaly alerts, and similar. Instead of opening its dashboard each time to investigate an incident, you can just ask your AI agent. The agent will query AppSignal autonomously on your behalf and return relevant information.
That is super duper useful, but it’s still an interface layer. The agent needs to query something, and that something has to exist, be running, and contain actual data.
In short, MCP is not a data layer. It has no collection mechanism, no storage, or continuous processing. It bridges an AI agent and systems that process those things, like AppSignal.
What Monitoring Tools Do
Prior to MCP getting a hold of any data, a monitoring tool (again, like AppSignal 😉) needs to do a lot of heavy lifting:
Function | What It Involves |
|---|---|
Collection | SDKs running in your app, tracking metrics, capturing errors, streaming logs at scale 24/7 | Storage | A lot of things: time-series databases, log aggregation, retention policies, compression, handling terabytes of telemetry | Processing | Anomaly detection, alerting rules, threshold evaluation, incident correlation, running continuously in the background | Visualization | Dashboards, trace waterfalls, error grouping, trend analysis | Alerting | Paging you at 3 a.m. when something breaks, before users notice (if they are “lucky” to be in that time zone) |
MCP does none of this processing itself. Instead, it queries the results of all that work, which is actually done by the underlying monitoring tool.
What "Replacing Your Monitoring Tool with MCP" Would Look Like
If you wanted to go MCP-only, it would likely end up being pretty nasty:
- You would have to pipe raw logs, metrics, and traces directly to an AI agent.
- The agent would need to process, store, and analyze this data in real-time (tokens go vroom vroom).
- EVERY event your app generates now has a token cost attached, not just the queries. Tokens go vroom vroom².
- There’s no persistence. If you do not ask the right question at the right moment, you lose data. Sure, you can make yourself a storage bucket, some RAG. But, is it worth it? 100% no.
- You will miss out on alerts. The AI is not watching your app while you’re sleeping. All it does is respond when prompted.
- There’s no historical baseline at all. The agent has no memory of what “normal” looks like unless you tell it every time, or chain together kilometer long system prompts. Yeah, I wouldn’t do it either.
Looking at the economic aspect alone, this makes zero sense. Teams operating heavy agentic workflows are already accustomed to $1,000+ token invoices for a few hours of prompt-maxxing.
Now, imagine routing your entire telemetry through an LLM continuously. The cost starts to look like a black hole with no event horizon in sight.
Another Analogy
With MCP, it’s more like outsourcing work to an assistant. This assistant can search, pull docs, and get a general understanding of stuff. But they will not build the underlying document systems or organize them.
So, if you fire the documentation clerk and expect the assistant to magically figure out everything, you’re in for a rude awakening.
What MCP Is Good For
Don’t get me wrong, none of the above is an argument against MCP. It’s an argument for using it properly.
The real value of MCP lies in:
Faster incident investigation: Instead of clicking through dashboards until you go gray, you can ask your agents in plain English, “What the frick is happening, m8?” and get your answer.No context-switching: Your agent can look at your code and monitoring data in parallel. Something that humans are notoriously bad at (multitasking) is now handled for you.Accessibility: Developers who are not in the domain of monitoring (both those who aren’t really familiar with it and those who simply have more important stuff to do) can get meaningful insights without fully mastering the tool. That said, we don’t really think you would have that kind of issue with AppSignal. It all comes down to speed and ease of use at this point. 🙂
MCP is just a faster interface for your monitoring data. The collecting infrastructure remains in place and is not replaced.
Where MCP Shines (and Where It Does Not)
So, let’s find out where MCP works best and where it's best avoided.
| Scenario | Is MCP Useful? | Notes |
|---|---|---|
| Investigating an active incident | Yes | Fast querying, correlation, natural language synthesis |
| Routine production health check | Yes | Quick status without opening dashboards |
| 3 a.m. alert that wakes you up | No | MCP does not guard your app while you sleep |
| Historical trend analysis | ⚠️ Partial | Needs the monitoring tool's stored data to be useful |
| Anomaly detection configuration | No | Configuration work, not querying |
| Compliance and audit trails | No | Requires persistent, structured storage |
| Processing high-volume telemetry | No | Economically impossible at LLM token rates (perhaps if you have an infinite money glitch) |
MCP and monitoring tools are complementary to each other and are definitely not competing.
Monitoring tool = the system of recordthat collects, stores, and processes. It runs whether you pay attention or not, as it should.
MCP = a neat, “smart” interfacethat lets you query the above-mentioned system in natural language using ✨AI assistance ✨.
Next Steps and Resources
MCP works great for increased productivity. Monitoring is brought directly into your editor, and the production data is made accessible to developers who do not have much time (or inclination) to learn about it inside and out.
But, keep in mind that MCP is still an interface, not a replacement for this kind of infra. If someone tells you AI will replace your monitoring stack, ask them who’s going to pay the token bill for a million events per hour.
Already on AppSignal? Set up the MCP server and see how they work together. If you’re not on AppSignal yet, you can start a free 30-day trial, then connect your AI agent.
Let us know if anything breaks on [Discord](https://discord.gg/sBWWGwYzfC).
Frequently Asked Questions (FAQ)
- So MCP is just a query interface. Why not simply use the AppSignal UI?
MCP allows you to combine context. In the AppSignal UI, you are looking at isolated pieces of monitoring data. With MCP, your agent can correlate the monitoring data with your source code and other chained tools.
- What if I already send logs to an LLM for analysis?
Sending a batch of truncated logs for a specific investigation is fine. The problem occurs when you try to replace continuous monitoring with continuous LLM ingestion.
- Does AppSignal’s MCP server give write access or is it read-only?
Both. You can update stuff, not just query. See the MCP Tool Reference for the full breakdown.
Published
Wondering what you can do next? #
Try out AppSignal with a 30-day free trial.Reach out to our support team with any feedback or questions.
- Share this article on social media
Dejan Lukić #
Our guest author Dejan is an electronics and backend engineer, who is pursuing entrepreneurship with SaaS and service-based agencies and is passionate about content creation.
All articles by Dejan Lukić Become our next author!
AppSignal monitors your apps #
AppSignal provides insights for Ruby, Rails, Elixir, Phoenix, Node.js, Express and many other frameworks and libraries. We are located in beautiful Amsterdam. We love stroopwafels. If you do too, let us know. We might send you some!