How I Connected Claude to My Monitoring Dashboard with MCP (And Stopped Checking Dashboards Manually)

Last month I was triaging an incident at 1 AM. API latency on a client's payment service had spiked. I had the UptyBots dashboard open in one tab, Grafana in another, the deployment log in a third, and a terminal SSH'd into the production box. Standard drill. Four browser tabs, three terminal windows, eyes jumping between them trying to correlate timestamps.

Then I remembered: I had set up the UptyBots MCP server the week before as an experiment. I switched to my Claude terminal and typed: "Show me the incidents for the payment-api monitor in the last 6 hours." Three seconds later I had a formatted list of every incident with timestamps, status codes, and error messages. No tab-switching. No scrolling through dashboard history. No squinting at time pickers.

I typed: "What about the hourly stats for that same monitor? Is this a latency spike or a total outage?" Claude pulled the hourly performance data and told me response times had climbed from 180ms to 4,200ms starting at 12:47 AM, with intermittent 503 errors. Not a total outage. A degradation.

That was the moment I realized conversational monitoring is not a gimmick. It is a genuinely faster way to investigate incidents. I have been running this setup for a month now, and I am not going back.

What MCP Actually Is (Without the Marketing)

MCP stands for Model Context Protocol. Anthropic created it as an open standard. The idea is simple: give AI assistants a way to call functions on external systems.

Without MCP, an AI assistant can only work with text you paste into it. You copy monitoring data from a dashboard, paste it into Claude, and ask questions about it. That works, but it is slow and the data is stale the moment you paste it.

With MCP, the AI assistant has direct access to live tools. It can call list_monitors and get your current monitor statuses in real time. It can call get_incidents and pull your incident history. It can call create_http_monitor and actually set up a new monitor. It is not reading about your data. It is reading your actual data.

The important part for security-minded people (which should be all of us): the MCP server runs locally on your machine. Your AI client starts it as a subprocess. The server talks to the UptyBots API using your API key. No monitoring data passes through any additional third-party server. The only external communication is between the MCP server on your laptop and the UptyBots API, the same connection your browser makes when you open the dashboard.

The 15 Tools You Get

The UptyBots MCP server exposes 15 tools. Here is what they do:

That covers the full lifecycle: create monitors, check their status, investigate incidents, review performance trends, manage the configuration, and audit notifications. All from a conversation.

Setup: 10 Minutes, No Excuses

I have set this up on three machines now. It takes about 10 minutes. Here is the exact process.

Step 1: Get an API Key

Log into UptyBots. Go to Account > API Keys. Click "Create API Key." Give it a name like "mcp-laptop" so you know what it is for later. The key starts with upty_ and is shown once. Copy it. Store it somewhere safe. I keep mine in a password manager.

You can create read-only keys if you want the AI to only fetch data without being able to create or delete monitors. For my personal setup, I use a full-access key because I trust the workflow. For a team setup, read-only is the sensible default.

Step 2: Install the MCP Server

The server is a Node.js application. You need Node.js 18 or newer.

git clone https://github.com/uptybots/mcp-server.git
cd mcp-server
npm install

That is it. No build step. No configuration files to edit. The server reads its config from environment variables passed by the AI client.

Step 3: Configure Your AI Client

This is where you tell your AI client how to start the MCP server. The config format depends on which client you use.

Claude Desktop (edit claude_desktop_config.json):

{
  "mcpServers": {
    "uptybots": {
      "command": "node",
      "args": ["/path/to/mcp-server/index.js"],
      "env": {
        "UPTYBOTS_API_URL": "https://uptybots.com",
        "UPTYBOTS_API_KEY": "upty_your_key_here"
      }
    }
  }
}

Claude Code (add to .claude/settings.json or run the config command):

{
  "mcpServers": {
    "uptybots": {
      "command": "node",
      "args": ["/path/to/mcp-server/index.js"],
      "env": {
        "UPTYBOTS_API_URL": "https://uptybots.com",
        "UPTYBOTS_API_KEY": "upty_your_key_here"
      }
    }
  }
}

Cursor (add to MCP settings in the Cursor config):

{
  "mcpServers": {
    "uptybots": {
      "command": "node",
      "args": ["/path/to/mcp-server/index.js"],
      "env": {
        "UPTYBOTS_API_URL": "https://uptybots.com",
        "UPTYBOTS_API_KEY": "upty_your_key_here"
      }
    }
  }
}

Replace /path/to/mcp-server/index.js with the actual path where you cloned the repository. Replace upty_your_key_here with your real API key.

Restart your AI client. Done. You can now talk to your monitors.

My Actual Workflows: What I Use Daily

After a month of using this setup, here are the workflows that stuck. These are things I do repeatedly because they are genuinely faster through conversation than through the dashboard.

Morning Check-in

Every morning I start with: "Give me a status summary of all my monitors. Flag anything that is down or had incidents overnight."

Claude calls list_monitors, scans the results, and gives me a summary like: "42 monitors total. All up. 3 had incidents overnight: staging-api (down 4 minutes at 3:12 AM, recovered), blog-cdn (elevated latency between 1 AM and 2 AM), payment-service (brief 502 at 5:47 AM, single occurrence)."

On the dashboard, this same check involves: opening the browser, loading the dashboard, scanning the monitor list, sorting by recent incidents, clicking into each one to read the details. About 3-5 minutes. With MCP, it takes 10 seconds.

Incident Investigation

This is where MCP really earns its keep. During an incident, speed matters and context-switching between tools is expensive.

My typical investigation flow:

1. "Show me incidents for the checkout-api monitor in the last 24 hours." (Calls get_incidents)
2. "What were the hourly response times for that monitor over the last 48 hours?" (Calls get_stats_hourly)
3. "Were there any incidents on the database-port monitor during the same time window?" (Calls get_incidents on a different monitor)
4. "Compare the daily stats for checkout-api this week vs last week." (Calls get_stats_daily twice and correlates)

Claude runs these tool calls, correlates the data, and gives me an analysis: "The checkout-api incidents correlate with database port monitor showing elevated latency starting 2 hours earlier. This suggests a database performance issue is the root cause, not the API service itself."

That is pattern recognition across multiple monitors and time ranges. On a dashboard, I would be opening each monitor in separate tabs, mentally comparing timestamps, and writing notes on paper. Claude does it in seconds.

Bulk Monitor Setup

Last week I onboarded a new client with 8 services to monitor. On the dashboard, that is 8 rounds of: click "Add Monitor," fill in the form, set the frequency, choose notification channels, save. About 3 minutes per monitor if you are quick. 24 minutes total.

With MCP, I typed:

Create these HTTP monitors with 2-minute check intervals:
- "Client-X Main Site" at https://clientx.com
- "Client-X API" at https://api.clientx.com/health
- "Client-X Admin" at https://admin.clientx.com
- "Client-X Checkout" at https://clientx.com/checkout
- "Client-X CDN" at https://cdn.clientx.com/status

And these SSL monitors:
- "Client-X SSL Main" for clientx.com
- "Client-X SSL API" for api.clientx.com

And a port monitor:
- "Client-X DB" on db.clientx.com port 5432

Claude created all 8 monitors in about 15 seconds. Each one with the correct type, URL, and frequency. I verified by asking "List all monitors with 'Client-X' in the name" and confirmed they were all there and active.

Twenty-four minutes reduced to under a minute. That is not a marginal improvement. That is a different category of workflow.

Deploy-Time Monitor Management

Before a deployment, I pause monitors to avoid false alerts during the deploy window. After the deploy, I resume them and verify everything is green.

"Pause the staging-api, staging-web, and staging-worker monitors.
I'm deploying to staging."

Claude pauses all three. I deploy. Then:

"Resume all three staging monitors and tell me their status
in 2 minutes."

Claude resumes them, waits for the next check cycle, and reports back: "All three staging monitors are up. staging-api responded in 210ms, staging-web in 85ms, staging-worker port check passed."

On the dashboard, pausing and resuming three monitors involves 6 clicks and two page loads. Not hard, but when you are in the middle of a deploy with a terminal open, switching to a browser is a context break. Staying in the terminal and telling Claude to handle it keeps me in flow.

Weekly Infrastructure Review

Every Friday I run a quick infrastructure review. Used to take 30 minutes of clicking through dashboard charts. Now:

"Give me a reliability summary for the week. For each monitor,
show the total uptime percentage and the number of incidents.
Flag anything below 99.9%."

Claude pulls daily stats for every monitor, calculates uptime percentages, counts incidents, and presents a sorted report. Monitors below threshold are highlighted. Total time: about 20 seconds to ask, 10 seconds for Claude to process.

Things I Tried That Did Not Work Well

Being honest: not everything about conversational monitoring is better than the dashboard.

• Real-time visual monitoring. Watching a dashboard with live status indicators and auto-refreshing charts still beats conversation for "keep an eye on things" during a critical window. Conversation is pull-based. You have to ask. Dashboards push visual changes to you.
• Complex chart analysis. When I need to zoom into a specific time range on a response time graph and visually identify patterns, the dashboard's interactive charts are better. Claude can give me the numbers, but sometimes you need to see the shape of the curve.
• One-off quick checks. If I just need to glance at whether a specific monitor is up, and I already have the dashboard open, clicking is faster than typing a sentence. MCP wins when you need to check multiple things or correlate data.

The sweet spot is using both. Dashboard for visual monitoring and real-time awareness. MCP for investigations, bulk operations, and data analysis.

MCP vs. Writing Scripts Against the REST API

If you have used REST APIs before, you might wonder why MCP matters when UptyBots already has a full REST API. Fair question. I have written plenty of API scripts over the years.

The difference is the interface. With a REST API, you write a script for each task. You hard-code monitor IDs. You parse JSON responses. You maintain the scripts. When you need a slightly different query, you write a new script or add parameters to an existing one.

With MCP, you describe what you want in plain language. "Show me all monitors that had incidents this week, sorted by total downtime" is a sentence, not a script. The AI figures out which tool calls to make, chains them together, and formats the output. When you need a different analysis next time, you just ask differently. No code changes.

The practical comparison:

• Self-describing tools. MCP exposes available actions with descriptions the AI can understand. No reading API docs to figure out parameters.
• Natural language interface. You describe what you want. The AI translates to the right tool calls.
• Local execution. The MCP server runs on your machine. Your API key stays local.
• Composable. The AI can chain multiple tool calls to answer complex questions. "Compare this week's performance to last week" involves multiple API calls that the AI handles automatically.
• Zero maintenance. No scripts to update when the API changes or when you need a new query pattern.

I still use direct API calls for automated pipelines (CI/CD integration, automated reporting cron jobs). But for interactive work, MCP is faster.

Security: What You Should Know

I am particular about security, so I dug into this before deploying it.

• The MCP server runs locally. It is a Node.js process on your machine. It communicates with your AI client via stdio (standard input/output), not over a network.
• API key stays local. The key is passed as an environment variable to the MCP server process. It never leaves your machine except in API requests to UptyBots's servers.
• API keys support permission scoping. You can create a read-only key that allows listing monitors and viewing stats but cannot create, delete, or modify anything. Good default for exploration.
• Keys are hashed. UptyBots stores API keys as SHA-256 hashes. If their database were compromised, your key cannot be recovered from the hash.
• Per-account isolation. Each API key is scoped to your account. You can only see and manage your own monitors. There is no path to accessing another user's data.

For team environments, I recommend creating separate API keys for each person's MCP setup, with the minimum permissions needed. If someone leaves the team, you revoke their key without affecting anyone else.

Getting Started

Ready to connect your AI assistant to your monitors? Check out the full MCP documentation for detailed setup instructions, the complete tool reference, and configuration examples for Claude Desktop, Claude Code, and Cursor.

Don't have an API key yet? Read the API docs first, or sign up free to get started.

Frequently Asked Questions

What is MCP exactly?

The Model Context Protocol is an open standard for connecting AI assistants to external tools and data sources. Created by Anthropic, it has been adopted by Claude, Cursor, and other AI clients.

Is my data safe?

Yes. The MCP server runs locally on your machine. Your AI client starts it as a subprocess. No data passes through third-party servers beyond the AI service you are already using.

Which AI clients support MCP?

Claude Desktop, Claude Code, Cursor, and a growing number of other AI tools. The MCP standard is open, so any client can implement it.

Do I need a paid plan to use MCP?

The MCP server itself is free and open source. You need an API key from UptyBots, available with both free and paid accounts.

Can I limit what the AI can do?

API keys can be configured with specific permissions. You can create read-only keys for AI assistants that should only fetch data, not modify it.