Usage

Tools

The Bugsee MCP server exports three read-only tools.

list_applications

List all applications accessible to the current user. Takes no parameters. Returns an array where each entry has:

Field	Description
id	Internal application ID
key	Application key used in issue keys (e.g., MYAPP in MYAPP-123)
name	Display name
description	Free-form description (may be empty)
type	ios, android, or web
subtype	Wrapper / framework if any (e.g., react_native, flutter, unity)

Use this tool first when the agent doesn't yet know which application key to query.

list_issues

List issues for a given application. Returns a paginated response (50 issues per page).

Parameters:

Parameter	Type	Required	Description
application_id_or_key	string	Yes	The application ID or key (e.g., "MYAPP")
type	string	No	Filter by issue type: "bug", "error", or "crash"
status	string	No	Filter by issue status: "open" or "closed"
version	string	No	Filter by application version (e.g., "1.2.3")
reporter_email	string	No	Filter by reporter email address
sort	string	No	Sort order. One of: "date_desc" (default), "date_asc", "events_desc", "events_asc", "users_desc", "users_asc"
cursor	string	No	Pagination cursor from a previous response to fetch the next page

Response fields:

• issues — array of issues, each containing id, key, type, status, severity, summary, created_on, updated_on; plus events_count and users_count for crashes/errors, or description for bugs
• total — total number of matching issues
• nextCursor — present if more pages exist; pass it as cursor to fetch the next page

get_issue

Get a single issue by its key (e.g., "MYAPP-123"). Returns a plain-text report with markdown sections covering timing, environment, summary, exception details, and optionally per-thread stacks and logs.

Parameters:

Parameter	Type	Required	Description
issue_key	string	Yes	The issue key in "APPKEY-NUMBER" format (e.g., "MYAPP-123"). Use list_issues first to discover available keys.
include_all_threads	boolean	No	When true, include stack traces for all threads in the crash dump, not just the crashed/target thread. Useful for diagnosing deadlocks, thread-related crashes, or cases where the crashed thread alone does not explain the failure. Native iOS/Android dumps may contain dozens of threads, so response size grows accordingly. No effect on bug-type issues. Default: false.
include_logs	object	No	Log filter configuration. If omitted, logs are not included. See below.

Log filter options (include_logs):

Parameter	Type	Description
entries	string	Required. Which log entries to include: "all", "errors", or "range".
max_log_entries	number	Maximum number of log entries to return. For "all", keeps the last N entries (closest to crash). For "errors" and "range", keeps the first N. Recommended: start with 50–100 for initial triage.
deduplicate_errors	boolean	When true and entries="errors", groups identical error messages and returns a count summary.
errors_surrounding	object	Context around error entries (only with entries="errors"). Fields: entries_before, entries_after (number of entries), time_before, time_after (milliseconds).
range	object	Range specification (only with entries="range"). Fields: from_index, to_index (entry positions), from_time, to_time (timestamps in ms).

Recommended workflow

1. Call get_issue without include_logs to inspect the issue first.
2. If logs are needed, use entries="errors" with deduplicate_errors=true or max_log_entries to limit output.
3. Use entries="all" only when you specifically need the full session log.

Response sections:

• Issue timing — start/end timestamps
• Environment — device, OS, app version (YAML format)
• Runtime — React Native, Flutter, Unity, etc. (if applicable)
• Summary — issue title
• Description — bug reports only
• Exception — crash/error type, signal, reason, stack trace of the crashed/target thread
• All threads — only when include_all_threads=true; one subsection per thread with the crashed thread marked
• Logs — only when include_logs is provided

Prompts

Note: While most AI agents that support the MCP Protocol also support tools, prompts are less widely adopted and may not be available in your AI agent of choice.

• /bugsee_fix — when invoked from an agent that supports MCP prompts, pulls the supplied issue key and walks the agent through analyzing and proposing a fix.

Example prompts by workflow

The patterns below are what most users will write into their agent of choice. They map naturally onto the three tools above, so an MCP-aware model can handle them without any custom wiring on your side.

1. Triage overnight crashes

Start the day knowing which crashes spiked or are blocking the most users — without leaving the editor for the dashboard.

"Show me the open crashes in MyApp from the last 24 hours, sorted by affected users."

"List the top 5 crashes in MyApp version 1.2.3 by event count."

2. Root-cause a single crash report

Take a specific issue key (often from support or a webhook notification), pull the full crash dump, and let the agent map the stack trace onto your source files.

"Pull up MYAPP-1234 with the error log from the 5 seconds before the crash, then read the files in the stack trace and explain what's going wrong."

"Get MYAPP-4567 including all threads — I think we're deadlocking on the main thread."

The second example uses include_all_threads=true, which adds an "## All threads" section to the response — useful when the crashed thread alone doesn't explain the failure.

3. Regression hunting across releases

Diff issues between two versions of the app to spot what's new in the next build.

"What crash types appeared in MyApp 1.2.2 that didn't exist in 1.2.1? Show me counts."

"Compare the open issues in MyApp 1.2.2 vs 1.2.3 — which ones are new in 1.2.3?"

The agent issues two list_issues calls (one per version filter) and diffs the results. Follow up with "now pull the full crash for each new one and find the suspect commit" to chain get_issue calls.

4. Bug report to code change

Turn a user-submitted bug report into a proposed fix in the same conversation.

"Show me the latest 5 bug reports in MyApp from real users. For each, look at the relevant files and suggest a fix."

"Find bug reports in MyApp mentioning 'login' filed by jane@example.com — pull the most recent and explain how I'd fix it."

list_issues filtered by type="bug" plus reporter_email scopes down to user-submitted reports; get_issue returns the description and device context; the agent proposes the fix against your working tree.

Worked example

A crash was deliberately planted within a test iOS app that had Bugsee pre-configured. Once triggered, the crash was intercepted and symbolicated by Bugsee, and a new issue was created (IOS-1443):

Having a working folder open in Cursor, and the Bugsee MCP server configured, using it is as simple as asking the agent:

"Help analyze and fix IOS-1443 from Bugsee."

Cursor fetches the full context (stack traces, environment, optional logs) from the Bugsee MCP server, locates the relevant files and methods in the workspace, analyzes the issue, and proposes a fix: