Atlas reads triggered PagerDuty incidents, their services, and log entries through PagerDuty's official MCP server, then traces the page back to a commit and drafts the postmortem timeline. Register it over stdio with atlas mcp add pagerduty --env PAGERDUTY_USER_API_KEY=$PAGERDUTY_USER_API_KEY -- uvx pagerduty-mcp, and leave --enable-write-tools off to keep the server read-only.
What Atlas does during a PagerDuty incident
Atlas reads triggered PagerDuty incidents, their services, and log entries through PagerDuty's official MCP server, then traces the page back to a commit and drafts the postmortem timeline. In 2026 an on-call engineer can ask which service is paging without opening a browser.
On-call work is mostly correlation under time pressure. PagerDuty knows what fired and when. Git knows what changed and when. The person in the middle is the one doing the joining, usually at an hour when joining things is hard. The PagerDuty MCP server hands that correlation to Atlas: it reads the triggered incident, its service, and its log entries, then looks for the commit that lines up. What comes back is a suspect, a proposed fix, and a timeline you can argue with.
Adding PagerDuty's MCP server over stdio
Add PagerDuty's official MCP server over stdio with atlas mcp add pagerduty --env PAGERDUTY_USER_API_KEY=$PAGERDUTY_USER_API_KEY -- uvx pagerduty-mcp. That 1 command is the whole install in 2026, because the uvx runner fetches pagerduty-mcp on demand and nothing has to be installed globally first.
The credential is a PagerDuty user API key, exported as PAGERDUTY_USER_API_KEY and passed through with --env. Because the server runs as a local stdio process launched by uvx pagerduty-mcp, no PagerDuty data leaves through a third party endpoint and the key stays on your machine. Register it once and the entry persists in atlas.json, which is also where you will edit the command array later if you decide to enable write tools.
Read-only by default, write tools by choice
Leave the --enable-write-tools flag off and PagerDuty's MCP server stays read-only, which is the correct default for most teams in 2026. Add that 1 flag to the pagerduty command array in atlas.json only when you want Atlas to acknowledge or resolve incidents.
Acknowledging and resolving a PagerDuty incident are consequential actions: they change who else gets woken up. The default in this setup is read-only, and that default is correct for most teams. If you do want Atlas to acknowledge or resolve, the change is explicit and reviewable: add --enable-write-tools to the pagerduty entry's command array in atlas.json. Keeping the flag out of the initial registration means nobody enables incident writes by accident.
EU accounts and PAGERDUTY_API_HOST
EU accounts set PAGERDUTY_API_HOST to https://api.eu.pagerduty.com when registering the pagerduty-mcp server with Atlas. Skip that 1 environment variable and an EU account's triggered incidents will not show up, which looks like a quiet on-call queue rather than a misconfiguration.
PAGERDUTY_API_HOST is easy to forget because everything else about the setup succeeds without it. The server starts, atlas mcp list reports the entry, and the only symptom is that Atlas cannot see incidents you know are firing. If your PagerDuty account is in the EU, set PAGERDUTY_API_HOST to https://api.eu.pagerduty.com alongside PAGERDUTY_USER_API_KEY, and verify before an incident rather than during one.
The on-call loop: what is paging, and why
Ask Atlas which service is currently paging, then have it pull the triggered incident's log entries and recent changes. Those 2 questions are the opening move of an on-call session in 2026, and PagerDuty's MCP server answers both without a dashboard.
Start broad, then narrow. The first question, which service is currently paging, tells Atlas where to look. The second, pull the triggered incident's log entries and recent changes, gives it the evidence. Log entries carry the sequence of what PagerDuty observed. Recent changes carry what your team shipped. Together they are usually enough for Atlas to say which deploy is the likely cause, and to say it before you have finished reading the alert yourself.
From suspect commit to incident timeline
Let Atlas name the suspect commit, write the fix, and produce the incident timeline as a diff you review. Both artifacts come out of 1 session in 2026, assembled from PagerDuty log entries and recent changes rather than from memory days later.
Postmortems are usually reconstructed days later from Slack scrollback and half remembered timestamps. Having Atlas produce the incident timeline from PagerDuty log entries while the incident is still live inverts that. You review the timeline as a diff, correct the parts it got wrong, and keep the parts it got right. The fix and the writeup come out of the same session, which is the only time anyone actually remembers what happened.
Check the connection before you go on call
Check with atlas mcp list that the pagerduty entry shows connected before an on-call session starts. Discovering a broken PagerDuty MCP connection during a live incident costs minutes nobody has, and the pre-flight check takes exactly 1 command.
atlas mcp list prints the registered servers and their status. Run it at the start of a shift, not at the start of an incident. If the pagerduty entry is not connected, the usual causes are an expired PAGERDUTY_USER_API_KEY or a missing PAGERDUTY_API_HOST on an EU account, and both take a minute to fix when nothing is on fire. Treat the check as part of the handoff ritual.
Setup
- 01Add PagerDuty's official MCP server over stdio with atlas mcp add pagerduty --env PAGERDUTY_USER_API_KEY=$PAGERDUTY_USER_API_KEY -- uvx pagerduty-mcp
- 02Leave the --enable-write-tools flag off for a read-only server, and add it to the command array in atlas.json only when you want Atlas to acknowledge or resolve incidents.
- 03EU accounts set PAGERDUTY_API_HOST to https://api.eu.pagerduty.com
- 04Ask Atlas which service is currently paging, then have it pull the triggered incident's log entries and recent changes.
- 05Let Atlas name the suspect commit, write the fix, and produce the incident timeline as a diff you review.
- 06Check with atlas mcp list that the pagerduty entry shows connected before an on-call session starts.
Frequently asked questions
- how to connect Atlas to PagerDuty
- Run atlas mcp add pagerduty --env PAGERDUTY_USER_API_KEY=$PAGERDUTY_USER_API_KEY -- uvx pagerduty-mcp to register PagerDuty's official MCP server over stdio, then verify it with atlas mcp list.
- how do I keep the PagerDuty MCP server read-only
- Leave the --enable-write-tools flag off. The server is read-only without it. Add the flag to the command array in atlas.json only when you want Atlas to acknowledge or resolve incidents.
- PagerDuty MCP server EU region setup
- EU accounts set PAGERDUTY_API_HOST to https://api.eu.pagerduty.com alongside PAGERDUTY_USER_API_KEY. Without it, an EU account's triggered incidents will not appear.
- can an AI agent trace a PagerDuty page back to a commit
- Yes. Atlas pulls the triggered incident's log entries and recent changes through PagerDuty's MCP server, names the suspect commit, and proposes the fix as a diff.
- can Atlas write a postmortem timeline from PagerDuty
- Yes. Atlas produces the incident timeline as a diff you review, built from PagerDuty log entries and recent changes rather than from memory.
- how do I check the PagerDuty MCP connection in Atlas
- Run atlas mcp list and confirm the pagerduty entry shows connected. Do it before an on-call session starts, not during an incident.
- can Atlas acknowledge or resolve a PagerDuty incident
- Only if you opt in. Add --enable-write-tools to the pagerduty command array in atlas.json. Without that flag the server is read-only.
Try Atlas in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install AtlasRelated guides
Atlas with GPT-5.6: OpenAI's 2026 Flagship in the Terminal
GPT-5.6 gives Atlas a 1,050,000 token context at $5 / $30 per Mtok. Atlas routes OpenAI through the Responses API so reasoning persists across tool calls in 2026.
Atlas for FastAPI in 2026
Atlas is a terminal-native AI coding agent for FastAPI in 2026. It reads Pydantic v2 models and Depends(), then runs pytest behind a permission prompt.
Atlas with DeepSeek V3 (open weights): The Frozen 671B Baseline in 2026
Run Atlas on DeepSeek V3 (open weights) in 2026. DeepInfra hosts the MIT-licensed 671B MoE at $0.32 per Mtok input, $0.89 per Mtok output, 128K context.
Atlas with GPT-5.4: The Balanced 2026 Default
GPT-5.4 brings a 1,050,000 token window to Atlas at $2.50 / $15 per Mtok, half the input cost of GPT-5.6. The balanced day-to-day default for 2026 sessions.
Atlas for Quarkus in 2026
Atlas is a terminal-native AI coding agent for Quarkus in 2026. It reads CDI beans and JAX-RS resources, then runs ./mvnw test behind a permission prompt.
Atlas with GPT-5.5: The 1.05M Token Jump, Reviewed for 2026
GPT-5.5 took the GPT-5 line to a 1,050,000 token context at $5 per Mtok input, $30 per Mtok output. Atlas setup, the price rise from $1.75, and when GPT-5.6 wins.
Atlas with Magistral Small: Open Reasoning for the Plan Agent in 2026
Magistral Small is Mistral's first open reasoning model: 128,000 tokens at $0.50 / 1M input tokens and $1.50 / 1M output tokens. Atlas setup, costs, and tradeoffs.
Atlas with Qwen3-Coder 30B-A3B Instruct: The Default Open Agentic Coder in 2026
Qwen3-Coder 30B-A3B Instruct in Atlas: 256K tokens (262,144), $0.45 per Mtok input, $2.25 per Mtok output, and 3.3B active parameters out of 30B total.