mcpField
O
openai-sentry

openai-sentry

github.com/trailofbitsCloud & DevOps52272 installsUpdated 15w ago
Repository

About openai-sentry

A read-only Sentry observability skill for retrieving project issues and event details through the Sentry API. It formats issue and event data while redacting personal information and avoiding raw stack traces.

Key features

  1. 01List and filter issues
  2. 02Retrieve issue and event details
  3. 03Paginated API requests
  4. 04Redact personal information
  5. 05Format issue summaries

Use cases

  1. 01Review recent production issues
  2. 02Inspect events for an issue
  3. 03Find issues matching a query

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/trailofbits/skills-curated --skill openai-sentry

After installing, type/openai-sentryin Claude Code to confirm it loaded.

Bundled filesscripts/sentry_api.py

Details

From the project README

Sentry (Read-only Observability)

Quick start

  • If not already authenticated, ask the user to provide a valid SENTRY_AUTH_TOKEN (read-only scopes such as project:read, event:read) or to log in and create one before running commands.
  • Set SENTRY_AUTH_TOKEN as an env var.
  • Optional defaults: SENTRY_ORG, SENTRY_PROJECT, SENTRY_BASE_URL.
  • Defaults: org/project {your-org}/{your-project}, time range 24h, environment prod, limit 20 (max 50).
  • Always call the Sentry API (no heuristics, no caching).

If the token is missing, give the user these steps:

  1. Create a Sentry auth token: https://sentry.io/settings/account/api/auth-tokens/
  2. Create a token with read-only scopes such as project:read, event:read, and org:read.
  3. Set SENTRY_AUTH_TOKEN as an environment variable in their system.
  4. Offer to guide them through setting the environment variable for their OS/shell if needed.
  • Never ask the user to paste the full token in chat. Ask them to set it locally and confirm when ready.

Core tasks (use bundled script)

Use scripts/sentry_api.py for deterministic API calls. It handles pagination and retries once on transient errors.

Scripts and references are located under {baseDir}/.

API requirements

Always use these endpoints (GET only):

  • List issues: /api/0/projects/{org_slug}/{project_slug}/issues/
  • Issue detail: /api/0/issues/{issue_id}/
  • Events for issue: /api/0/issues/{issue_id}/events/
  • Event detail: /api/0/projects/{org_slug}/{project_slug}/events/{event_id}/

Inputs and defaults

  • org_slug, project_slug: default to {your-org}/{your-project} (avoid non-prod orgs).
  • time_range: default 24h (pass as statsPeriod).
  • environment: default prod.
  • limit: default 20, max 50 (paginate until limit reached).
  • search_query: optional query parameter.
  • issue_short_id: resolve via list-issues query first.

Output formatting rules

  • Issue list: show title, short_id, status, first_seen, last_seen, count, environments, top_tags; order by most recent.
  • Event detail: include culprit, timestamp, environment, release, url.
  • If no results, state explicitly.
  • Redact PII in output (emails, IPs). Do not print raw stack traces.
  • Never echo auth tokens.

Golden test inputs

  • Org: {your-org}
  • Project: {your-project}
  • Issue short ID: {ABC-123}

Example prompt: “List the top 10 open issues for prod in the last 24h.” Expected: ordered list with titles, short IDs, counts, last seen.

When to Use

When NOT to Use

Comments

Markdown supported