Skip to main content
Glama
kensaurus

Mushi-Mushi

by kensaurus
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Bug report evidence

get_report_evidence
Read-onlyIdempotent

Retrieve the complete evidence package for a bug report—logs, traces, metrics, screenshots, and browser environment—to diagnose root cause in a single call.

Instructions

Return the full evidence package for a single bug report covering all three observability pillars: (1) LOGS — console_logs (error/warn/info/debug entries with timestamps), breadcrumbs (SDK ring buffer: navigation, clicks, network, lifecycle events with category/level), repro_timeline (merged SDK event stream: route/click/request/log/screen), and the reporter's own comments thread; (2) TRACES — network_requests (SDK-captured fetch/XHR with method/status/duration/traceId), backend_spans (server-side spans joined by W3C trace_id: name/duration_ms/parentSpanId/status), and Sentry trace correlation IDs (sentry_trace_id, sentry_event_id) for deeplinks; (3) METRICS — performance_metrics (Web Vitals snapshot: LCP/CLS/INP/TTFB/FCP + INP attribution + page timing + connection info), anomalies (statistical provenance when auto-filed by CI metric regression: baseline_mean/std, score in σ, threshold); plus screenshot_url, browser environment (user agent, URL, viewport, SDK version), and tags. Reporter identifiers (session id, end-user id) are never returned. This is the same data an engineer would collect for a root-cause investigation. Faster than calling get_report_detail + report timeline separately.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
reportIdYesReport UUID. (`report_id` is accepted too.)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.1.12
    • addedInput schema / properties / reportId
      Added value: +{
+  "description": "Report UUID. (`report_id` is accepted too.)",
+  "type": "string"
+}
    • removedInput schema / properties / report_id
      Removed value: -{
-  "description": "Report UUID.",
-  "type": "string"
-}
    • changedInput schema / required
      Previous value: -[
-  "report_id"
-]New value: +[
+  "reportId"
+]
  2. Changed1 schema field changedv0.1.10
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  3. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds valuable behavioral disclosure beyond those hints: reporter identifiers (session id, end-user id) are never returned, and the evidence package is explicitly scoped to a single bug report. This is meaningful context about what the tool will and will not surface.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long, but every sentence earns its place: it needs the detail because there is no output schema and the return payload spans many categories. The content is front-loaded with the core purpose, then organized by pillar with numbered subsections, making it easy for an agent to scan. The final comparison to get_report_detail plus report timeline is a useful, non-redundant closing note.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the full burden of explaining the return value, and it does so thoroughly: it lists logs, traces, metrics, screenshot, browser environment, tags, and explicitly states what is excluded. It also gives the relationship to sibling tools and the efficiency benefit. An agent has enough information to call the tool correctly and interpret the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%: the reportId parameter is documented as 'Report UUID. (`report_id` is accepted too.)'. The description does not add much beyond this, though it reinforces that the parameter selects a single bug report. Since the schema already carries the parameter meaning, a baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Return the full evidence package for a single bug report.' It enumerates exactly which data is included across logs, traces, and metrics, and explicitly distinguishes itself from get_report_detail and get_report_timeline. This makes it immediately clear what this tool does and how it relates to siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context for when to use the tool: it returns the data an engineer would collect for root-cause investigation, and it is faster than calling get_report_detail and report timeline separately. It names alternatives and positions this tool as their combined, faster replacement, but it does not explicitly state when-not-to-use it or compare it with more decision-oriented siblings like get_fix_context or suggest_fix.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools