MCP
MCP (the Model Context Protocol) lets AI tools talk to BugPort directly. Instead of copy-pasting bug details into a chat, you connect your AI client to BugPort with a scoped token and it can list bugs, read their full context, generate fix prompts, comment, and update status — all from inside your editor or assistant, and all restricted to exactly the workspaces and projects you allow.
This page explains what MCP does in BugPort, why you'd connect an AI tool to your bugs, the scoped-token model, the actions available, the security guarantees, and — honestly — what is shipped today versus still being wired up.
What MCP is, in the BugPort context
BugPort already holds the rich context an AI assistant needs to be useful on a bug: feedback text, screenshots and annotations, console logs, network requests with response bodies, page context, and the activity timeline. MCP exposes that context to an AI client through a small, well-defined set of tools the model can call. The model never gets raw database access — it gets a curated toolbelt scoped by a token you control.
Why connect AI tools to BugPort
Ask your assistant to list open bugs, pull a bug's full context, and summarize what's likely going wrong — without leaving your editor.
Turn a bug's captured logs, network calls, and repro context into a ready-to-use prompt for fixing the issue in your codebase.
Comment on a bug or move its status to reflect the fix you just made, so the dashboard stays in sync with your work.
The point is to close the loop between where the bug is reported (BugPort) and where it gets fixed (your editor and AI assistant), without manual context shuttling.
Supported and target clients
MCP is a client-agnostic protocol, so any tool that speaks it can connect. The clients BugPort targets are:
- Claude
- Cursor
- VS Code
- Codex
Copyable setup configs for each will live on the dashboard's MCP Connections page so you don't have to hand-assemble them.
Scoped tokens
MCP access is gated by a scoped token, not your dashboard session. This is what makes giving an AI tool access safe.
project_ids. A token without a project restriction sees all projects in its workspace; with one, it sees only those projects.bugs:read and bugs:write. Read-only tokens can list and inspect bugs but cannot comment or change status.last_used_at so you can spot stale or unexpected tokens.bugs:read token. Add bugs:write only when you want it commenting or changing status.Connection flow
The token is the gate: the AI tool connects through MCP, presents its scoped token as a bearer credential over Streamable HTTP, and BugPort resolves that token to a specific workspace, optional project set, and scope before any tool runs.
What MCP lets you do — the tools
MCP exposes 11 tools, grouped by what they do. Read tools require bugs:read; write tools require bugs:write.
| Tool | Group | What it does |
|---|---|---|
list_workspaces | Read | List workspaces the token can reach. |
list_projects | Read | List projects in scope. |
list_bugs | Read | List bugs in scope. |
list_open_bugs | Read | List bugs that are still open. |
list_closed_bugs | Read | List bugs that are closed. |
get_bug_details | Read | Fetch a bug's full detail record. |
get_bug_context | Read | Fetch the captured context (logs, network, page context) for a bug. |
get_bug_media | Read | Fetch references to a bug's media (screenshots, attachments). |
create_bug_comment | Write | Add a comment to a bug. Requires bugs:write. |
update_bug_status | Write | Change a bug's status. Requires bugs:write. |
generate_fix_prompt | Helper | Assemble a bug's context into a ready-to-use fix prompt. |
The Read tools cover discovery and inspection, the two Write tools cover acting on a bug, and the Helper tool packages a bug's context for downstream fixing.
Security expectations
- Treat MCP tokens like passwords — they grant API access. Store them in your client's secret config, not in shared docs.
- Scope tokens to the minimum workspace, projects, and permissions needed.
- Revoke tokens you no longer use; check
last_used_atfor stragglers.
- Don't expect MCP to reach across workspaces — it never does.
- Don't expect MCP to expose public-share data; share links are a separate, read-only public surface.
- Don't assume calls are invisible — every MCP call writes an audit log.
By design, MCP never crosses a workspace boundary, never serves public-share data, and audit-logs every call. Combined with scoped, revocable tokens, that gives you a tight, accountable surface for AI access. See Security & Privacy for the broader model.
Rollout status
Here is the honest state of MCP today.
Implemented Done
- Scoped token authentication.
- All 11 tools (Read, Write, Helper).
- Token CRUD and the dashboard token UI for creating, viewing prefixes, and revoking tokens.
These are exposed through a token-authed REST bridge — GET /v1/mcp/tools lists the available tools, and POST /v1/mcp/tools/invoke runs one. Supporting helpers GET /v1/mcp/config, /v1/mcp/bugs/{bug_id}/context, and /v1/mcp/bugs/{bug_id}/prompt back the connection and the fix-prompt flow.
In progress In progress
- Wrapping the bridge in the official MCP SDK Streamable HTTP server at
https://api.bugport.dev/mcp, so off-the-shelf clients (Claude, Cursor, VS Code, Codex) speak the MCP wire protocol natively rather than calling the REST bridge.
In other words: the tools and tokens are real and working today via the REST bridge; the final step is presenting them over the standard MCP transport so any compliant client connects without custom glue. Transport is Streamable HTTP — a URL plus a bearer token. When it lands, setup config snippets for each client will live on the dashboard's MCP Connections page.