Provides tools for accessing and managing SnappySnag bug reports from Flutter apps, including visual pin annotations, screenshots, widget tree/device diagnostics, and feedback ticket status updates.
The official Model Context Protocol (MCP) integration for SnappySnag — seamlessly bridge Flutter in-app bug reports, pin annotations, screen diagnostics, and device logs directly into Cursor, Windsurf, Claude Desktop, and other AI coding assistants.
When testing Flutter applications, QA testers and end-users pinpoint visual bugs or unexpected behaviors directly on the mobile screen. SnappySnag captures:
Exact visual pin coordinates and feedback comments
Annotated high-resolution screenshot
Active screen class & widget tree hierarchy
Real-time device logs (OS, platform, version, device metadata)
AI-generated root-cause insights and resolution prompts
With the SnappySnag MCP Server, your AI coding agent (in Cursor, Windsurf, Claude, etc.) can inspect these bug reports directly, jump straight to the relevant Flutter widget code, implement fixes, and mark tickets as resolved without ever switching context away from your editor.
Related MCP server: MCP Server Example
Tool | Description | Key Parameters |
| Fetches the most recent bug report or user feedback with full details (active pins, screenshot, metadata, device info). |
|
| Searches and lists feedback tickets matching filter criteria (status, severity, keyword). Returns lightweight summaries. |
|
| Retrieves complete details for a specific feedback ID, including screenshot image, active pins, and discussion notes. |
|
| Updates ticket status ( |
|
SnappySnag supports two connection options:
Option A (Command / stdio with Demo Mode): Runs locally via standard MCP stdio. If no key is provided, an interactive Demo Mode with mock Flutter bug tickets is activated!
Option B (Remote SSE / Streamable HTTP): Connects directly to SnappySnag's hosted endpoint without any local dependencies.
Sign in to your SnappySnag Dashboard.
Open Project Settings (gear icon) -> Integrations or MCP tab.
Click Generate MCP Secret Key and copy your key (snag_mcp_...).
npx or local build).cursor/mcp.json){
"mcpServers": {
"snappysnag": {
"command": "node",
"args": ["path/to/snappy-snag-mcp/dist/index.js", "--key=YOUR_MCP_SECRET_KEY"]
}
}
}(Tip: Omit --key or set --key=demo to test with demo data!)
claude_desktop_config.json){
"mcpServers": {
"snappysnag": {
"command": "node",
"args": ["path/to/snappy-snag-mcp/dist/index.js", "--key=YOUR_MCP_SECRET_KEY"]
}
}
}.cursor/mcp.json){
"mcpServers": {
"snappysnag": {
"url": "https://snappysnag.com/api/mcp",
"headers": {
"Authorization": "Bearer YOUR_MCP_SECRET_KEY"
}
}
}
}~/.codeium/windsurf/mcp_config.json){
"mcpServers": {
"snappysnag": {
"serverUrl": "https://snappysnag.com/api/mcp",
"headers": {
"Authorization": "Bearer YOUR_MCP_SECRET_KEY"
}
}
}
}Once connected, you can instruct your AI assistant naturally:
"Check the latest open bug report from SnappySnag and fix the issue."
The AI agent will:
Call get_latest_feedback(status: "open") to inspect the reported screen, pin position, and device specs.
Read the referenced Flutter widget file in your repository.
Apply the necessary code fix or layout adjustment.
Call update_feedback_status(feedback_id: "...", status: "resolved", comment: "Fixed overflow in ProductCard layout").
Per-Project Scoped Keys: Each MCP Secret Key is strictly scoped to its designated project.
Instant Revocation: If compromised, keys can be regenerated or revoked with a single click in the dashboard.
Encrypted Transmission: All data and screenshot assets are delivered via HTTPS with short-lived signed URLs.
SnappySnag Official Site: https://snappysnag.com
Flutter SDK (snappy_snag): pub.dev/packages/snappy_snag
Model Context Protocol (Anthropic): modelcontextprotocol.io
This repository is licensed under the MIT License.
Fetch the full details of a specific feedback item by its ID, including active pin annotations, Flutter widget hierarchy, developer notes, AI fix prompt, and screenshot image.
| Name | Required | Description | Default |
|---|---|---|---|
| feedback_id | Yes | The UUID of the feedback item to retrieve. | |
| include_screenshot | No | Whether to include the screenshot image in the response. Defaults to true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden; it does disclose the payload contents (annotations, widget hierarchy, notes, AI prompt, screenshot), which is meaningful behavioral context. It stops short of stating that this is a read-only, side-effect-free operation, how errors are surfaced for unknown IDs, or that responses can be large when a screenshot is included.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with the action first and the returned fields after; every listed item is informative rather than padding. No redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description adequately compensates by naming the returned data, so an agent knows what it will get. Missing only error/invalid-ID behavior and an explicit read-only assurance for a two-parameter retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both feedback_id (UUID) and include_screenshot (default true, included in response) are already fully documented. The description only reinforces that lookup is by ID and that the screenshot is part of the payload, adding little beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb ("Fetch") plus resource ("full details of a specific feedback item") and an enumeration of what comes back (pin annotations, widget hierarchy, notes, AI fix prompt, screenshot). This clearly separates it from list_feedbacks and get_latest_feedback by signaling an ID-addressed single-item lookup, though no sibling is named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the phrase "by its ID" suggests it is called after obtaining an ID from list_feedbacks or get_latest_feedback. There is no explicit statement of when to prefer this over get_latest_feedback, nor any note about what happens with an invalid or stale ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the most recent in-app bug report or user feedback from SnappySnag, including screenshot, visual pin annotations, screen name, device metadata, and AI fix prompts.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Filter by status before picking the latest item. Defaults to 'open'. | |
| include_screenshot | No | Whether to include the screenshot image in the response. Defaults to true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full disclosure burden. 'Fetch' signals a read operation and the enumeration of returned artifacts (screenshot, pin annotations, metadata, AI fix prompts) is useful, but it does not state permissions, rate limits, empty-result behavior, or explicitly confirm read-only semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is a single front-loaded sentence with no filler. The field list is dense but directly supports the return-content expectation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description helpfully enumerates the key returned fields, which compensates for the missing output schema. It still omits response structure and edge cases, but for a simple two-parameter retrieval tool it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the two parameters are already documented in the input schema. The description does not add syntax or default details for status/include_screenshot beyond noting that screenshot may be included; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Fetch' and resource 'most recent in-app bug report or user feedback,' and the inclusion list further clarifies scope. It does not explicitly name sibling tools like list_feedbacks or get_feedback_detail, so sibling differentiation is implied by 'most recent' rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when/when-not guidance or named alternative. The word 'latest' implies the use case (retrieve the newest item rather than a list or a specific detail), but the description leaves comparison with list_feedbacks and get_feedback_detail to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List and search feedback / bug reports in the SnappySnag project. Returns lightweight summaries (ID, title, status, severity, active pin count, screen category, created_at).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of items to return (1 to 30). Defaults to 10. | |
| source | No | Filter by submission mode ('user' for live end-users, 'dev' for internal QA). Defaults to 'all'. | |
| status | No | Filter by feedback status. Defaults to 'open'. | |
| keyword | No | Optional search keyword to match against pin comments or user memo. | |
| severity | No | Filter by severity level. Defaults to 'all'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden; it does assert this is a project-scoped read returning lightweight summaries with named fields, which is genuinely useful. It omits ordering/sort behavior, pagination or truncation semantics beyond the limit param, and any mention of what 'search' matches at a summary level.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the verb and scope, followed immediately by the return shape. Zero filler and no repetition of schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a five-parameter list tool with no output schema, listing the summary fields is the key compensating detail and it is present. Remaining gaps are ordering behavior and whether results are paginated beyond the limit cap, which leave it just short of fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and all five parameters carry enum values and defaults, so the schema already does the heavy lifting. The description adds no filtering syntax or interaction details (e.g., how keyword combines with status/severity filters), so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb pair ('List and search') and resource ('feedback / bug reports') scoped to the SnappySnag project, and enumerates the returned fields, which clearly separates it from detail-fetching siblings. It never explicitly names those siblings as alternatives, but the singular/plural read distinction is obvious from the phrasing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: 'list and search' plus 'lightweight summaries' suggests a browse/scan step before calling get_feedback_detail. There is no explicit statement of when to prefer this over get_latest_feedback or get_feedback_detail, and no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update the status of a feedback ticket (e.g., mark as 'resolved' after fixing the bug in your codebase, or 'ignored'), and optionally attach an internal developer resolution note.
| Name | Required | Description | Default |
|---|---|---|---|
| status | Yes | The new status to set ('resolved', 'ignored', or 'open'). | |
| comment | No | Optional summary of what was fixed or investigated (e.g., 'Fixed bottom overflow in CartCheckoutScreen'). | |
| feedback_id | Yes | The UUID of the feedback item to update. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It identifies the operation as a status update and mentions an internal developer resolution note, but it omits permissions/auth needs, allowed status-transition rules, side effects, reversibility, and error/response behavior for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with zero wasted text. The examples and optional-note detail are embedded efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter update tool with full schema coverage, the description makes the operation and optional note clear enough to call correctly. However, because annotations and an output schema are absent, the lack of permissions, transition rules, and response/error context leaves meaningful behavioral gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents feedback_id, status enum values, and the optional comment parameter. The description adds some useful context by framing the comment as an optional internal developer resolution note, but it mostly repeats what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: update the status of a feedback ticket. It is immediately distinguishable from the retrieval-oriented siblings (get_latest_feedback, list_feedbacks, get_feedback_detail) because it clearly performs a mutation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear usage context with examples such as marking a ticket resolved after fixing a bug or ignored. It does not include explicit exclusions or prerequisite conditions, but the when-to-use guidance is concrete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0get_feedback_detailget_latest_feedbacklist_feedbacksupdate_feedback_statusScored across 4 tools
Each tool targets a distinct retrieval/update mode: latest item, searchable list, ID-based detail, and status update. There is slight overlap because get_latest_feedback returns rich detail similar to get_feedback_detail, but the lack of an ID requirement makes the latest tool's purpose clear.
All names follow a readable verb_noun snake_case pattern (get/list/update + feedback noun). Minor pluralization inconsistency appears between 'feedbacks' and 'feedback', but the pattern remains predictable.
Four tools is well-scoped for a focused feedback triage server. Each tool covers a meaningful part of the read/update workflow without redundant operations.
The surface covers listing/searching, retrieving latest and detailed feedback, and updating status with notes, which supports the core bug-report triage lifecycle. Minor gaps like bulk status updates, assignment, or editing severity/title are not present but can be worked around.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Enable secure connectivity between Sentry issues and debugging data, and LLM clients, using a Model Context Protocol (MCP) server.
A Model Context Protocol server for Wix AI tools
MCP server for Sentry - error monitoring, issue tracking, and debugging for AI assistants
