Production Monitoring MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_observability_statusA | Inspect the status of connected production monitoring providers (Sentry, GitHub, Vercel, Better Stack, Cloudflare) and list any missing credentials. |
| get_production_healthA | Single-call operational pulse across all connected services (Uptime, Sentry error spikes, latest Vercel deploy, Cloudflare 5xx). Returns lean status signals rather than verbose raw logs. |
| get_recent_errorsA | Fetch recent production errors from Sentry for a project or service, including frequency counts, first/last seen timestamps, and affected user counts. |
| get_error_detailsA | Fetch deep technical details for a specific Sentry issue including parsed in-app stack trace frames, code context, tags, and breadcrumbs. |
| find_regressionC | Find errors in Sentry that have regressed or were first introduced in a specific release or timeframe. |
| get_deploymentsB | Fetch recent deployments from Vercel (or GitHub) with deployment state, commit SHA, branch, and timestamp. |
| get_deployment_logsA | Fetch runtime and build logs for a specific Vercel deployment to diagnose deployment failures. |
| compare_deploymentsA | Compare two deployments or commit SHAs via GitHub to see all commits, authors, and exact files changed. |
| get_commit_detailsB | Inspect a specific GitHub commit's message, author, stats, and modified files with diff snippets. |
| check_uptimeB | Query Better Stack Uptime monitors to check availability, status (up/down), and recent downtime incidents. |
| analyze_logsB | Query structured application logs from Better Stack Logs to investigate log anomalies, errors, and traces. |
| analyze_api_latencyC | Analyze edge HTTP traffic, status codes (2xx, 4xx, 5xx), and error rates from Cloudflare Analytics. |
| correlate_incidentC | Run automated triage correlating deployment timestamps, git diffs, and Sentry stacktraces to find the root cause. |
| explain_incidentB | Generates a human-readable executive briefing of an incident with root cause, evidence chain, confidence, and recommended action. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 14 tools
Most tools target distinct resource+action pairs (Sentry errors vs deployments vs uptime vs latency), and descriptions clarify boundaries. Slight overlap between get_production_health and get_observability_status (a pulse vs provider/credential status), and correlate_incident/explain_incident form a related triage/briefing pair, but each remains differentiable.
All 14 tools use snake_case with a consistent verb_noun pattern (get_recent_errors, check_uptime, analyze_logs, compare_deployments, explain_incident). No mixing of camelCase or vague bare verbs.
14 tools is well within the ideal 3-15 range and each earns its place across distinct monitoring and incident-response stages. No redundant or filler tools.
The surface covers the full incident lifecycle: detection (health, errors, uptime, latency), investigation (error details, deployment logs, commit details, regressions), correlation (correlate_incident), and reporting (explain_incident). No obvious dead ends for the stated production monitoring purpose.