DottaandClaude Opus 5.5
34f2bb78ee
## Thinking Path
> - Paperclip is the open source app people use to manage AI agents for
work
> - Agents use app connections to call provider tools, such as the
Sentry MCP server
> - The Sentry connection has only one method: browser sign-in through
the hosted MCP OAuth server
> - That grant expires. An unattended triage agent loses Sentry access
until a person signs in again
> - During that time, a scheduled triage routine completes each run but
reads no Sentry data
> - This pull request adds a second Sentry method that uses a user auth
token
> - The benefit is a Sentry connection that stays valid until a person
revokes the token
## Linked Issues or Issue Description
**Subsystem affected**
App connections: the Sentry entry in the connection catalog.
**Problem or motivation**
A Sentry connection that was created with browser sign-in on 2026-10-11
changed to "OAuth authorization expired. Reconnect this app to
continue." at 04:01 UTC on 2026-11-10. The agent that used it had no
Sentry tools after that time. Each hourly triage run reported the
blocker but could not continue. Unattended agents need a Sentry
connection that does not need a person to sign in again each month.
**Proposed solution**
The hosted Sentry MCP server accepts a Sentry user auth token in the
`Authorization: Sentry-Bearer <token>` header. It reserves `Bearer` for
its own OAuth tokens. Paperclip API-key methods already support a custom
header prefix. Add a Sentry API-key method that uses this header.
**Alternatives considered**
Reconnect with browser sign-in again. That restores access only until
the next grant expiry.
## What Changed
- Add the `mcp-user-token` method ("Use a user auth token") to Sentry in
`scripts/ingest-app-definitions.mjs`. It uses the same server URL and
sends the token as `Authorization: Sentry-Bearer <token>`.
- Regenerate `packages/shared/src/app-definitions/sentry.json`. I did
not include unrelated output that the content corpus drift caused for
other providers.
- Add a permission review entry for the new method in
`doc/connections/tool-method-permission-reviews.json`.
- Add a test for the new method and its header prefix.
- Document the token method, its required scopes, and its ownership risk
in `doc/connections/SENTRY.md`.
## Verification
- `pnpm exec vitest run packages/shared/src/app-definitions.test.ts`: 40
passed. The new assertion fails on `master` because Sentry has only one
method there.
- `pnpm exec vitest run src/__tests__/tool-access-service.test.ts -t
Sentry` (server): 2 passed.
- `pnpm exec vitest run ui/src/pages/apps/app-connect-policy.test.ts
server/src/__tests__/satisfied-connection-intents.test.ts`: 64 passed.
- `pnpm verify` returned exit 2 (a doc is a global CI input). Required
CI supplies the broad coverage.
- Live probe of `https://mcp.sentry.dev/mcp` with an `initialize`
request: `Authorization: Sentry-Bearer <invalid token>` starts an MCP
session (the token is checked on tool calls). `Authorization: Bearer
<same token>` returns `401 invalid_token`. This confirms the server
accepts the header scheme.
- Not done yet: a real agent tool call with a real token after
deployment.
## Risks
- Low risk. This adds a method. The existing OAuth method and saved
connections do not change.
- A user auth token acts as its creator and lasts until revoked. The
method guidance and docs say this. Rotate the token when that person
leaves.
- If Sentry changes the `Sentry-Bearer` scheme, connections that use
this method fail on tool calls. The OAuth method still works.
> For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and
discuss it in `#dev` before opening the PR. Feature PRs that overlap
with planned core work may need to be redirected — check the roadmap
first. See `CONTRIBUTING.md`.
## Model Used
- Claude Opus 5.5 (`claude-opus-5-5`) in Claude Code, with tool use
(shell, browser, web search).
## Checklist
- [x] I have included a thinking path that traces from project context
to this change
- [x] I have specified the model used (with version and capability
details)
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [x] I have searched GitHub for duplicate or related PRs and linked
them above
- [x] I have either (a) linked existing issues with `Fixes: #` / `Closes
#` / `Refs #` OR (b) described the issue in-PR following the relevant
issue template
- [x] I have not referenced internal/instance-local Paperclip issues or
links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip`
URLs)
- [x] My branch name describes the change (e.g. `docs/...`, `fix/...`)
and contains no internal Paperclip ticket id or instance-derived details
- [x] I have run tests locally and they pass
- [x] I have added or updated tests where applicable
- [x] I have updated relevant documentation to reflect my changes
- [x] I have considered and documented any risks above
- [ ] All Paperclip CI gates are green
- [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups
- [x] I will address all Greptile and reviewer comments before
requesting merge
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
3.1 KiB
Sentry
Paperclip connects to Sentry's official MCP server
at https://mcp.sentry.dev/mcp. Browser sign-in uses the MCP authorization
server. A normal connection does not require a customer-created OAuth app.
User auth token
Browser sign-in grants expire. A staging company connected on 2026-10-11 needed reauthorization at 04:01 UTC on 2026-11-10, and its agents lost Sentry access until a person signed in again. For unattended agents such as a triage routine, use Use a user auth token instead.
Create a user auth token
with org:read, project:read, project:write, team:read, team:write and
event:write. Paperclip sends it to the same hosted server as
Authorization: Sentry-Bearer <token>. The hosted server reserves Bearer for
its own OAuth tokens and forwards a Sentry-Bearer token to Sentry without
storing or refreshing it. See the
Sentry MCP README.
The token acts as the person who created it and is limited by that person's organization role. It lasts until revoked, so rotate it if that person leaves the organization.
Discovery
The method pins the MCP protected-resource metadata.
That document names https://mcp.sentry.dev as its authorization server.
Its authorization-server metadata
advertises automatic client registration, PKCE S256, refresh tokens, and
client ID metadata documents. Paperclip retains its normal client selection
and binding checks.
Do not use https://sentry.io/.well-known/oauth-authorization-server for this
method. That server describes the web/API OAuth service. It does not advertise
MCP client registration. Both metadata URLs return valid JSON, so checking
only HTTP status or the presence of authorization/token endpoints misses this
failure.
Repair an existing connection
After deploying the corrected catalog, resume or reconnect the existing Sentry connection. Keep its connection identity and access policies. Complete browser consent if required. Confirm the intended organization and projects through a read-only tool call from the assigned agent.
The catalog repair fixes setup and reconnect discovery. It cannot restore an expired or revoked grant without the owner's consent. If the saved connection changes to Finish setup, inspect its health error, refresh outcome, and transition timestamp separately. A setup error alone does not prove why the previous grant stopped working.
Verification
The service regression uses separate, realistic metadata for both Sentry hosts. It checks new registration and reuse of an existing MCP registration, the authorization URL, resource, requested scopes, and PKCE. These fixtures prove Paperclip's endpoint selection; they do not prove live account consent.
Before claiming restoration, verify browser consent, catalog discovery, and a real agent read. Record token refresh separately. Do not publish credentials or unredacted authorization URLs in evidence.