| FMRS | 64 / 100 · C | 79 / 100 · B |
|---|
| Reliability | 8 / 20 | 12 / 20 |
|---|
| Security and permissions | 14 / 20 | 18 / 20 |
|---|
| Maintenance | 11 / 20 | 16 / 20 |
|---|
| Documentation | 17 / 20 | 18 / 20 |
|---|
| Setup experience | 14 / 20 | 15 / 20 |
|---|
| Best for | - SREs / on-call engineers already using PagerDuty
- DevOps teams wanting AI-assisted incident triage without leaving their IDE
- Teams that want to query incident metrics or manage schedules conversationally
| - Engineering teams scaling AI coding agents while controlling spend
- Platform teams that need auditable, rollback-aware agent execution records
- Organizations using multiple agents (Claude, Codex, Gemini) under one governed flow
|
|---|
| Not for | - Teams that don't use PagerDuty
- Organizations requiring strict least-privilege, role-scoped tokens (this server uses a user-level API token with that user's full account privileges)
- Deployments that expose the HTTP endpoint directly on untrusted networks without an authenticating reverse proxy
| - Developers who just want a simple code-completion helper without run governance
- Teams unwilling to accept local JSONL run records with HMAC signing
- Environments without a supported adapter (Claude/Codex/Gemini CLIs, direct provider, or verifier-only)
|
|---|
| Required permissions | - Requires a PagerDuty User API Token (`PAGERDUTY_USER_API_KEY`) with that user's full privileges on the PagerDuty account
- Only read-only tools are exposed by default; `--enable-write-tools` must be explicitly set to create, update, or delete incidents, services, teams, schedules, escalation policies, webhooks, and status page content
- Optional `PAGERDUTY_API_HOST` to target the standard or EU regional API endpoint
| - Read/write access to the configured repo root (writable scope restrictable via --allow-path/--deny-path)
- Ability to invoke the chosen agent CLI (Claude/Codex/Gemini, etc.) and its underlying model account
- Local disk writes for run records, receipts, and share outputs (share/run-receipt., etc.)
- Execution of user-configured verifier commands (e.g. npm test)
|
|---|
| Risks and side effects | - The streamable-http and sse transports have no built-in authentication — any client able to reach the host/port can invoke tools, including write tools, using the single API key the server was started with; the README explicitly warns to keep the default loopback bind and only expose 0.0.0.0 behind an authenticating reverse proxy/gateway
- Write tools are powerful: they can delete teams, modify escalation policies and schedules, and create status page incident posts, so mistakes can disrupt real on-call routing or customer-visible status pages
- Creating a webhook subscription returns a signing secret that must be stored securely
- Claude Desktop's config file requires the API key to be stored in plaintext, so file permissions matter
| - Verifier commands are executed; poorly chosen verifier commands carry security risk despite preflight policy checks
- Cost and token figures may be estimates (labeled with provenance) and should not be treated as settled accounting
- Receipt integrity must be verified before use as trustworthy evidence; missing rollback evidence is flagged as EVIDENCE_BOUNDARY
- Policy defaults come from martin.config.yaml and can be overridden by CLI flags; misconfiguration can loosen safety boundaries
|
|---|
| Supported clients | Claude Desktop, Cursor, VS Code | Claude Code, Codex, Gemini CLI, Cursor, VS Code, GitHub Copilot, Continue |
|---|
| Tools | 82 | 0 |
|---|