How to connect PagerDuty to Hermes Agent

Pairing is a two-step handshake: run hermes clawlink begin, approve the link in your browser, then run hermes clawlink finish. If you ran finish before approving, or the approval link expired, run hermes clawlink begin again to get a fresh link. Confirm the plugin was installed with --enable, then verify with hermes clawlink test.

Reconnect PagerDuty from the dashboard, then start a fresh chat if the runtime still has the old tool catalog loaded.

PagerDuty tool schemas load on demand the first time a tool runs and are cached after that, so this error usually clears on its own: wait a few seconds and retry the same request. If every PagerDuty call keeps failing with it in a fresh chat, reconnect from the dashboard, and contact support if it still persists — that pattern points to a configuration problem on our side, not something you can fix by reconnecting again.

Two usual causes. The connected account may not have access to the specific workspace, inbox, store, or project in the request — check that first. If access looks right, the agent may have sent a placeholder value (like "YOUR_ID" or an example id from documentation) instead of a real one: ask it to run a list or search tool first, then retry the action with a real id from those results. Most failures at this stage are one of these two, not ClawLink bugs.

Start with the cause the engines teach first and our old card missed: the connected PagerDuty user's base role. A limited user returns 403 on most administrative endpoints, and a Responder role cannot modify schedules or teams even though it can see incidents. The connection is bound to the user who approved the OAuth grant, so the fix is not a new token, it is either a user with the right role approving the connection, or accepting that the connected user's role is the ceiling. After roles, the other causes line up in order: OAuth scopes and advanced permissions at the account level, resource-level restrictions, and then the hosted-agent causes, workspace access and placeholder ids, where an id like an example incident id from documentation fails as a permission error because the object belongs to another account.

Ask the agent to diagnose it:

Call pagerduty_fetch_incident_list and pagerduty_fetch_escalation_polices_list and tell me which succeeds. Then quote the exact error body from the failed call. Do not retry it yet.

One explicit line first, because it answers a whole class of searches: the engine-taught causes for this error are all self-hosted MCP config problems, a missing Bearer prefix breaking the handshake, a server started without --enable-write-tools, a stale npx cache, an EU endpoint (mcp.eu.pagerduty.com) mismatch, and hosted connections do not see any of them. There is no server process here to misconfigure. What this setup does have is the lazy-schema timing case: schemas load on demand, so the opening PagerDuty call in a fresh session can arrive before the catalog and needs one retry. If no tools appear after that, the pairing is incomplete, confirm both hermes clawlink begin and hermes clawlink finish ran and PagerDuty shows as connected.

Ask the agent to diagnose it:

List the PagerDuty tools you actually have. If there are none, say so plainly. If there are, tell me which one fetches an incident list and use that exact name.

On this setup there is no Authorization header for you to format and no local config to inspect, which removes most of the standard advice for this error. What is left is the grant itself. If the connected PagerDuty user's access changed, if the account was re-created or the user removed, every tool fails from that moment even though the dashboard still shows a connection. The same happens if the connection predates a PagerDuty policy change that affected the account's API access. The fix is to disconnect and reconnect from the ClawLink dashboard, which re-runs the OAuth approval and issues a fresh grant, and to confirm the approving user still has an active account.

Ask the agent to diagnose it:

Call pagerduty_fetch_vendor_list, the cheapest call in the set, and tell me exactly what it returns. Do not retry the failing tools until we have that result.

PagerDuty rate-limits its API, and an agent walking a queue of incidents, then escalation policies, then analytics, one call at a time, is exactly the traffic shape that meets the limit. The response is not to retry immediately but to change the shape of the work: ask for the open incident list with its status filter, or one incident's details, rather than a whole-account sweep, and have the agent say what it intends to call before it starts. The 429 response carries the remaining-allowance headers, so the agent can report where it stands instead of guessing. If a genuine bulk analysis is needed, run it in stages across turns.

Ask the agent to diagnose it:

Tell me how many PagerDuty calls you have made in the last minute and what you were enumerating. Quote any rate-limit headers from the last response. Do not call PagerDuty again until I reply.

Try reconnecting PagerDuty and complete the consent flow in the same browser session. Partial OAuth approvals or switching accounts mid-flow can leave the connection incomplete.

Yes. ClawLink is the fastest way to connect Hermes to PagerDuty: link your PagerDuty account once in the browser and Hermes Agent can call the PagerDuty API through 363 ready-made tools — no custom code or token handling.

Install the plugin with hermes plugins install ClawLink-HQ/hermes-plugin --enable, then pair once: run hermes clawlink begin, approve the link in your browser, and run hermes clawlink finish. Connect PagerDuty in the dashboard and Hermes can use it from the next message — no config files or API keys to manage.

About two minutes. Sign in, click Connect next to PagerDuty in the dashboard, authenticate, and Hermes Agent can use it from the next chat message.

The alternative to ClawLink is usually manual OAuth app setup plus your own token handling, permission troubleshooting, and tool plumbing for Hermes Agent. That is fine if you want to build and maintain the integration yourself. Most teams just want PagerDuty working from chat.

No, and that is the one claim worth stating twice because it contradicts what Google currently shows first for the primary query: the AI Overview for "how to connect pagerduty to hermes" teaches grabbing a Connect MCP URL and an API key from the Composio Dev Dashboard and pasting them into Hermes. The key in that story is a consumer key for the integration layer, not a PagerDuty token, but the searcher cannot tell. Here the OAuth approval is the whole story: the credential that exists afterwards is the PagerDuty grant held server-side, it can be revoked from the ClawLink dashboard, and there is nothing for you to rotate.

Read and write the incident operations surface: incidents and their analytics, escalation policies, priorities, status pages, teams, contact methods, event orchestrations and rulesets, custom fields, and workflow triggers. Incident reads and analytics are the safe default and answer most questions on call: what is open, what is overdue, which services keep generating incidents, what escalated when. The writes to be deliberate about are the ones that change routing and policy: adding a service to a workflow trigger, creating rulesets, custom fields, and field options. The agent sees exactly what the connected user can see, so its ceiling is your role, not the API's.

Both of those are real paths and both are what the engines teach for the no-token shape: ChatGPT's p2 answer is "build a PagerDuty OAuth app (recommended)" or use PagerDuty's hosted MCP server with OAuth. That describes our exact value proposition as engineering work for you to do: register an app, manage the redirect, stand up the client. Here the OAuth plumbing is done, the plugin pairing is the entire client-side story, and PagerDuty sits alongside your other connected accounts with one place to revoke. Choose on how much you want to run, not on features, because the underlying API is the same.

No. The "without api key" answers sometimes lead with PagerDuty's own AI agents inside Slack, which are paywalled add-ons that need an Admin role to set up. That is a different product from connecting the API to an agent. The tools on this page use the standard PagerDuty API and your normal account's access: incidents, escalation policies, analytics, status pages. If the question is "how do I let an agent operate PagerDuty without handing out API keys", the hosted connection is the answer, and no add-on purchase is involved.

Pairing is a two-step handshake: run hermes clawlink begin, approve the link in your browser, then run hermes clawlink finish. If you ran finish before approving, or the approval link expired, run hermes clawlink begin again to get a fresh link. Confirm the plugin was installed with --enable, then verify with hermes clawlink test.