MCP server

Everframe runs a hosted MCP server. Point a coding agent at it and the agent can look up a bug report, a crash’s error group, or a ticket on its own — read the evidence, follow the links between them, and answer “what is actually going on with this bug” without you copy-pasting anything.

Connections are read-only by default. With your explicit approval for ticket-write access, the agent can create and edit tickets, manage comments, and link reports. File uploads are not supported yet; to attach files, use the everframe CLI (@everframe/cli 1.7.0 or later).

Your endpoint

Use this MCP endpoint in your coding agent:

https://everframe.dev/mcp

This URL is the same for every Everframe account. Sign in to authorize the agent; your account permissions determine which projects it can access.

Connect your agent

Every client below does the same two things: registers itself with Everframe and opens your browser so you can approve it. You never paste a token.

claude mcp add --transport http everframe https://everframe.dev/mcp

codex mcp add everframe --url https://everframe.dev/mcp
codex mcp login everframe --scopes mcp:read,tickets:write

{
  "mcpServers": {
    "everframe": {
      "url": "https://everframe.dev/mcp"
    }
  }
}

{
  "servers": {
    "everframe": {
      "type": "http",
      "url": "https://everframe.dev/mcp"
    }
  }
}

{
  "context_servers": {
    "everframe": {
      "url": "https://everframe.dev/mcp"
    }
  }
}

Any other client

Anything that speaks MCP over Streamable HTTP and supports OAuth works without special handling. Add a remote server at https://everframe.dev/mcp; the client discovers everything else (RFC 9728 protected-resource metadata, dynamic client registration, authorization code + PKCE) by itself.

What happens when you connect

1. The client discovers that /mcp needs authorization, and where to get it.
2. Your browser opens — first to sign in, if you are not already, then to a consent screen: Connect <client name> to Everframe? It names the org the agent currently has access to and explains the requested permissions. Ticket writes appear only when the client requests them.
3. Click Allow. The client gets a one-hour access token and a refresh token it renews with on its own, so you are not asked again.

The grant acts as you. It reaches exactly the projects you are a member of and nothing else, and that is re-checked on every call — not frozen at the moment you clicked Allow. Lose access to a project and the agent loses it in the same instant.

What the agent can see

Read tools, scoped to the projects you can access:

resolve_link is the one to reach for first. Paste any dashboard link — a report, an error group, a ticket, with either a card number or a uuid — and the agent gets back exactly what the matching tool would return, without having to know any ids.

Every tool that names an id also names the tool that opens it, so an agent can walk search → get_error_group → get_report without being told how.

Reports default to a compact timeline and numeric summaries. Pass view: "full" to get_report or a report’s resolve_link call for original samples, expanded metadata, generated analysis details and artifact URLs. Both tools return the same report view. Captured content and generated analysis are labelled as untrusted; the server’s investigation prompt is separate.

Images are fetched on demand, never dumped into the conversation. get_report and get_ticket list what is attached; the agent calls get_screenshot or get_ticket_attachment only when it actually needs to look.

Create and edit tickets

Authorize your client with the OAuth scopes mcp:read tickets:write and approve the consent screen showing ticket-write access. Existing connections stay read-only: reconnect with the additional scope to enable writes. API tokens with tickets:write can also write within their allowed projects.

The agent can use:

These operations follow the same rules as the dashboard. Moving a ticket can send configured reporter messages; assignment or repository changes can start an assigned agent. Deleting a ticket comment also removes its attached files; error comments have no attachments.

Error comments are internal team notes on an error group, and use the same tickets:write permission. A note explains one status change (resolved, ignored, snoozed and so on) and only the person who made that change can add it, so an agent connected as you can annotate your own changes, while an API token can post free comments only. get_error_group lists the newest status changes and comments with their ids and a noteable flag, and pages older ones with activityCursor; long bodies are cut at 1,000 characters there and get_error_comment returns the full text. Comment bodies are labelled as untrusted content.

Every write uses a UUID requestId to make identical retries safe. Ticket and comment edits (ticket and error comments alike) also include the updatedAt value read beforehand as expectedUpdatedAt, so a stale edit is rejected instead of overwriting newer work. The agent should read again and reconcile when it receives a conflict.

get_ticket returns editable fields and comment IDs, with pagination for long text and discussions. get_ticket_options supplies the valid IDs for boards, columns, human/managed-agent assignees and repositories. Uploads and ticket deletion are not available through MCP; to attach files, use the everframe CLI (@everframe/cli 1.7.0 or later).

Disconnect

Settings → Agents lists every agent you have connected, when it connected, and when it last called. Disconnect ends the whole grant — every access and refresh token issued from it dies at once, so the agent’s very next call fails rather than quietly working until an hour-old token runs out. It can reconnect later by going through Allow again.

If your client cannot do OAuth

A CI job or a client that only supports a static header can skip the browser flow and send an API token instead:

Authorization: Bearer evf_api_...

/mcp recognizes an API token by its evf_api_ prefix and accepts it alongside OAuth tokens — no separate endpoint, no flag. Unlike a grant, an API token acts as whatever project access it was created with rather than as a person, and it does not expire on its own. Revoke it from Settings → API tokens.

Security

Report descriptions, console output, network URLs, ticket text and crash messages are user-submitted content, not Everframe’s own words. Anyone who can press the bug-report button in your production app — or trigger a crash — controls that text, and these tools hand it straight to a developer’s coding agent. Prompt injection through report content is the expected case here, not a hypothetical.

The server applies these controls:

• Write access is explicit. The server checks ticket-write scope and project permissions for each mutation. Use your client’s approval settings to review consequential actions when writes are enabled.
• Untrusted content is marked. Every response carrying user-submitted text wraps it in an explicit boundary telling the agent that what is inside is data, never instructions. The boundary is hardened against forgery: content that contains something resembling a closing marker is neutralized before wrapping, so it cannot fake its own boundary.

Treat what an agent quotes back to you from a report the same way you would treat any other anonymous internet input, because that is what it is.

Limits

• 120 requests/minute per credential — double the plain API’s limit, because an agent session is chattier than a script.
• Inline images are capped at 2 MiB. Anything larger comes back as a signed URL rather than a truncated image.
• Text responses are capped, with an explicit note when something was cut. Never a silent truncation.
• Refresh tokens are sliding, not absolute: each use issues another good for 30 days. Access ends when you disconnect it, when replay is detected, or when it simply goes unused for 30 days.
• No file uploads, ticket deletion, or session-replay tool yet — resolve_link recognizes a replay URL and tells you to open the dashboard. To attach files to a ticket, use the everframe CLI (@everframe/cli 1.7.0 or later).