39633c2217
Connector catalog, setup guides, and shared access documentation, followed by a final code-accuracy repair pass. This PR does not change application behavior. ## Final accuracy pass Checked against shipped Paperclip `v2026.916.0`, commit `dffc2b3ca1b9e88fa21cb17493083e682dffd1ca`, rather than the dirty local checkout or the earlier canary baseline. - Corrects connector/method-specific identity choices, human audiences, and managed GitHub versus PAT scope and verification. - Explains that **Always allow** covers different arguments for the same agent/action/connection, with project scope when present; uses actual button labels and removes the test-panel control from review instructions. - Qualifies new-action quarantine, including safe-default read exceptions. Removes unconditional approval guarantees. - Separates provider channel/repository reach from Paperclip sender authorization. - Completes sandbox sign-in and model credential-selection instructions from the current UI implementation. - Repairs Notion's hub summary, removes incomplete optional Notion/Sentry client-registration procedures, and corrects Linear's provider-versus-Paperclip attribution. - Removes unsupported Postman tier claims, contradictory Cloudinary/Mem0 verification assertions, API-equivalence claims, and overbroad successful-test assurances. - Retains Supabase's required project reference: both released method definitions explicitly require it. An earlier review suggested otherwise; release code is authoritative here. - Updates the release baseline and removes draft commit chronology from the public introduction. ## Availability and remaining runtime gates - **Google:** Verification is pending. Per the product-owner clarification, authorization can continue where Google offers an Advanced option; this is not available for every account and does not override Workspace policy or other Google prerequisites. Notices on the hub and all Google guides now distinguish an unverified-app warning from blocked authorization. - **Slack is available but not yet fully functional; follow-up fixes are planned.** For agent tools, the released OAuth endpoint/scope defaults differ from Slack's documented MCP contract. The page now warns against treating that route as production-ready and removes the misleading bot-scope walkthrough. Chat-channel bot setup remains separate. Engineering must reconcile the integration and run OAuth plus one read before removing this warning. Source: https://docs.slack.dev/ai/slack-mcp-server/ - No credentialed connector run was performed in this pass. Code consistency, provider documentation, UI rendering, and successful live execution are separate evidence levels. No claim of runtime certification for all connectors. ## Validation - Root build: 253 crawlable documentation pages. - Full `docs:test`: all eight suites passed locally, including root/subpath routes, sitemap history, fingerprints, navigation, skill source blocks, crawlable links, doc-link resolution, and SEO metadata. - Internal-link lint: 258 Markdown files; no broken internal links. - Latest cleanup: full build, all eight docs:test suites, internal-link lint and diff whitespace checks passed; 1,878 link-resolution checks. - Fixed the Calendar MCP reference URL; browser-checked the five inconclusive external destinations (Miro article loads; Asana, Google Cloud, OpenAI and xAI reach sign-in/console screens). Authenticated destinations were not tested beyond those screens. - Replaced the Sandbox providers editorial TODO with a scope note and removed the CLI overview's unfinished-guide announcement. - Browser client navigation: 687 checks passed using installed Chrome. Initial launch lacked the downloaded Playwright browser; rerun used `DOCS_CHROMIUM_PATH` without changing the tests. - Nine representative connector/shared pages at 1440px and 390px: HTTP 200, one article H1, no page-level horizontal overflow. Mobile screenshot inspected; approval page opened in the Codex browser. - Navigation audit reports three existing non-connector orphan files; this patch does not alter those files or their navigation. The previous revision's provider-page expansion, Google shared setup guide, navigation additions, and accidental node_modules-symlink cleanup remain in this PR. Internal review ledgers remain outside the publication branch. No merge or production deployment authorized. --------- Co-authored-by: DevRel Gemini <[email protected]> Co-authored-by: Paperclip <[email protected]> Co-authored-by: Claude Opus 5 (1M context) <[email protected]> Co-authored-by: Michael Nguyen <[email protected]>
5.1 KiB
seo_title, seo_description
| seo_title | seo_description |
|---|---|
| PagerDuty Connector | Let agents read PagerDuty incidents, services, and schedules. Choosing the right service region, token scope, a safe read test, and troubleshooting. |
PagerDuty
Agents can work with PagerDuty incidents, services, schedules, and on-call information — useful for letting an agent summarize an incident or check who is on call.
Choose your region first
PagerDuty hosts accounts in separate service regions, and they are different endpoints with no cross-region access. Pick the one that hosts your account:
| Option | Use it when |
|---|---|
| US service region | The PagerDuty account is hosted in the US |
| EU service region | The PagerDuty account is hosted in the EU |
Choosing the wrong region is the most common setup failure, and it does not look like a region problem: authentication simply fails, or the account appears empty. If you are unsure, check the domain you use to sign in to PagerDuty.
Before you connect
- A PagerDuty account, and a user API token from it.
- Confirmation of which region hosts the account.
The token carries that user's permissions. If an agent should only read, issue the token from an account whose role is read-only — that is a stronger boundary than action settings alone.
Connect PagerDuty
- Open Connectors and select PagerDuty.
- On the Access step, choose the identity and which agents may use the connection.
- Choose US service region or EU service region.
- Paste the PagerDuty API key. Paperclip stores it as a secret.
Which PagerDuty token to create
Paperclip's field asks for a user API token, not a general REST API key. The two are different credentials in PagerDuty:
- A user API token acts as one person, and inherits that user's own PagerDuty role and team access. Create one under your PagerDuty user settings.
- A general REST API key is account-wide and is not what this field expects.
Because a user token inherits its user's permissions, the account you create it under is the access decision. A token made by a user with read-only PagerDuty permissions gives an agent read-only PagerDuty access, which is the cleanest way to bound this connector. Creating it under an account with broad permissions hands those to the agent.
PagerDuty's own reference is the PagerDuty MCP server documentation.
Choose access
Reach is the token's: the services, teams, and incidents the issuing user can see, subject to PagerDuty's own roles and team membership. There is no service or team picker in Paperclip.
Incident operations are consequential in a way that is easy to underestimate. Acknowledging or resolving an incident changes who gets paged and stops escalation — during a real outage that has immediate human consequences.
Warning: Keep incident mutations — acknowledge, resolve, reassign, and anything that creates or triggers an incident — on Ask first or Off. An agent resolving an incident it did not understand silently ends an escalation.
Reads are safe to leave Allowed. See Set action permissions.
Try it
Show me the most recent PagerDuty incident and tell me its status, service, and who it is assigned to. Do not acknowledge or resolve anything.
Compare against PagerDuty. Reading an existing incident confirms the token, the region, and the agent's permission without paging anyone or interfering with an escalation.
Do not verify by creating a test incident — that pages whoever is on call.
Note: Illustrative task, not a recorded test result.
Troubleshooting and limitations
| Problem | Likely cause | Fix |
|---|---|---|
| Authentication fails with a token you believe is valid | Often the wrong service region; also possible that a general REST API key was used instead of a user API token | Confirm the token is a user API token, then try the other region |
| It connects but no incidents or services appear | Wrong region, or the token's user has no team access | Sign in to PagerDuty as that user and check they can see the incidents themselves. If they can, try the other region |
| Some services are invisible | PagerDuty team membership and role restrict the token's user | Adjust the user's teams or role in PagerDuty |
| A write action is refused | The token's user role is read-only | Expected if you configured it that way |
| An incident was resolved unexpectedly | A mutation was set to Allowed | Re-open it in PagerDuty and tighten the action settings |
| Needs attention | The token was revoked | Issue a new token and reconnect |
Limitations: one account and one region per connection. No service or team filter inside Paperclip. PagerDuty's API rate limits apply.
Related guides
- Sentry — error tracking, often used alongside incident response.
- Set action permissions
- Answer a connector review request
- PagerDuty MCP server documentation