MCP server
LaraBug speaks MCP, so an assistant that supports it can read your issues while you are working on them. Ask what is failing, and it can list the issues, open one, read the latest occurrence with its stack trace and request, and hand it back.
Connecting
The endpoint is streamable HTTP:
https://www.larabug.com/mcp
Point your client at it and complete the OAuth flow it offers. Claude Code, for example:
claude mcp add --transport http larabug https://www.larabug.com/mcp
Then run /mcp in Claude Code, pick LaraBug, and authenticate. That opens the OAuth flow in your browser, you approve the scopes, and the connection is remembered.
The connection is scoped to your account and sees exactly the applications you see.
What it can read
| Tool | What it answers |
|---|---|
list_projects |
Which applications you have. |
get_project_summary |
How one of them is doing. |
list_issues |
What is open, filtered the way the panel filters. |
get_issue |
One issue, with its status and history. |
get_latest_occurrence |
The last time it happened, with the stack trace and the request. |
list_vulnerabilities |
The CVE findings for an application. |
What it can change
| Tool | What it does |
|---|---|
update_issue_status |
Mark an issue read, fixed or open. |
add_issue_comment |
Leave a comment on the thread. |
assign_issue |
Assign it to somebody on the application. |
set_issue_priority |
Set the priority. |
snooze_issue |
Snooze it, with a reason. |
Reading needs the read scope, and the five above need the write scope. Nothing here deletes anything, and nothing reaches your application: the server reads the reports LaraBug already holds.
Using it well
The thing it is good at is the loop where you are fixing something. Paste a failing test, ask for the issue behind it, and let the assistant read the occurrence rather than describing it to it: the stack trace, the request, the twelve lines of code around the failure and the user it happened to are all already stored.