Can either server both detect a problem and page the right person?

Each covers half of that. Grafana MCP can detect problems through Sift investigations (find_error_pattern_logs, find_slow_requests) and manage Grafana OnCall schedules to see who is on call, but it does not create PagerDuty incidents or trigger escalation policies. PagerDuty MCP can route and escalate incidents and check on-call coverage with list_oncalls, but has no telemetry query tools to find the underlying cause.

Is PagerDuty MCP read-only?

By default, yes. The server exposes only read-only tools when launched without additional flags. Write tools, including create_incident, manage_incidents, add_responders, and create_status_page_post, require launching the local server with the --enable-write-tools flag. Grafana MCP enables most write-capable tools (update_dashboard, create_incident, alerting_manage_rules) by default, with a smaller subset of admin and advanced query tools disabled.

Grafana vs PagerDuty

Grafana MCP and PagerDuty MCP sit at different points in the incident-response chain. Grafana's server is a deep observability platform: an agent can run PromQL queries with query_prometheus, LogQL queries with query_loki_logs, and pull Pyroscope profiles; search and render dashboards; create and update incidents in Grafana Incident; check who is on call with get_current_oncall_users; run Sift investigations (list_sift_investigations, get_sift_analysis) for automated root-cause analysis; manage alert rules and routing with alerting_manage_rules and alerting_manage_routing; and annotate the timeline. PagerDuty's server is an incident-routing and on-call management platform: an agent can list and manage incidents, add notes and responders, start incident workflows, inspect escalation policies and on-call schedules, read change events, list related and past incidents, inspect event orchestrations, and post to status pages. Grafana is where telemetry lives; PagerDuty is where the alert becomes a managed incident. Here is a balanced look.

How they compare

Dimension	Grafana	PagerDuty
Primary focus	Observability data and dashboards: PromQL, LogQL, Pyroscope profiles, panel rendering, and Loki log patterns feed investigation from the signal layer.	Incident routing and on-call operations: incidents, escalation policies, schedules, workflows, and status pages manage the human response once an alert fires.
Querying telemetry	query_prometheus and query_prometheus_histogram for metrics; query_loki_logs, query_loki_stats, and query_loki_patterns for logs; fetch_pyroscope_profile for profiling data.	No telemetry query tools; the server reads incident-level data (alerts from incidents via list_alerts_from_incident, change events via list_change_events) rather than raw metric or log streams.
Automated root-cause analysis	Sift investigations via list_sift_investigations, get_sift_investigation, and get_sift_analysis; find_error_pattern_logs and find_slow_requests surface elevated errors and slow traces automatically.	get_past_incidents and get_related_incidents surface similar historical incidents; get_outlier_incident identifies unusual incidents for a service. No automated signal analysis.
On-call and schedule management	list_oncall_schedules, get_oncall_shift, get_current_oncall_users, list_oncall_teams, and list_oncall_users are available through the Grafana OnCall integration.	list_schedules, get_schedule, list_schedule_users, create_schedule, update_schedule, and create_schedule_override give full schedule CRUD; list_oncalls shows current on-call entries across all policies.
Incident lifecycle	create_incident, add_activity_to_incident, and list_incidents for Grafana Incident; create_annotation and update_annotation mark the timeline. No workflow, status-page, or escalation-policy tools.	Full lifecycle: create_incident, manage_incidents (acknowledge/resolve/reassign/escalate), add_responders, add_note_to_incident, start_incident_workflow, list_escalation_policies, and create_status_page_post.

Verdict

Choose by where you need the agent to act. Reach for Grafana MCP when investigation is the job: running PromQL and LogQL queries, rendering dashboard panels, pulling Pyroscope profiles, and using Sift to surface error patterns and slow requests before or during an incident. Reach for PagerDuty MCP when response coordination is the job: routing the incident to the right responders, managing escalation policies and on-call schedules, tracking past and related incidents, running incident workflows, and posting status page updates. In practice, both tools serve the same incident but at different layers; Grafana owns the signal layer, PagerDuty owns the response layer.

FAQ

Can either server both detect a problem and page the right person?: Each covers half of that. Grafana MCP can detect problems through Sift investigations (find_error_pattern_logs, find_slow_requests) and manage Grafana OnCall schedules to see who is on call, but it does not create PagerDuty incidents or trigger escalation policies. PagerDuty MCP can route and escalate incidents and check on-call coverage with list_oncalls, but has no telemetry query tools to find the underlying cause.
Is PagerDuty MCP read-only?: By default, yes. The server exposes only read-only tools when launched without additional flags. Write tools, including create_incident, manage_incidents, add_responders, and create_status_page_post, require launching the local server with the --enable-write-tools flag. Grafana MCP enables most write-capable tools (update_dashboard, create_incident, alerting_manage_rules) by default, with a smaller subset of admin and advanced query tools disabled.