Skip to main content
Glama
kensaurus

Mushi-Mushi

by kensaurus
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Gate findings

list_gate_findings
Read-onlyIdempotent

Lists recent inventory gate runs and their findings for a project, filterable by gate or severity. Use this to see which CI gates failed.

Instructions

List recent inventory gate runs and their findings for a project, newest first. Returns { runs: [{ id, gate, status, findings_count, … }], findings: [{ severity, rule_id, message, file_path, node_id, … }] }. Filter by gate (dead_handler | mock_leak | api_contract | crawl | status_claim | spec_drift | orphan_endpoint | unknown_call | schema_drift | code_health | design_drift | ci_drift | deploy_drift | env_drift | radar | portfolio_radar | portfolio_radar_ci | store_review) or finding severity (info | warn | error). The *_drift gates are the App Recipe checks: design_drift is code that drifts off the design tokens, ci_drift / deploy_drift / env_drift are CI, deploy and env vars that drift from the recipe; radar is the Mushi setup checks (a rejected provider key, no spend cap or AI budget, a webhook that never delivered, a stale code index), each with a suggested_fix (a spend-cap fix is applied in the console by a signed-in project admin, not through an API key); portfolio_radar / portfolio_radar_ci / store_review are the app hole checks (prefer get_radar). Available on every plan. Read-only. Use to see which CI gates failed on the last crawl; use diff_inventory to compare two commits, or get_inventory for the full snapshot.

Input Schema

NameRequiredDescriptionDefault
gateNoOnly runs of this gate (and their findings).
severityNoOnly findings with exactly this severity.
projectIdNoProject UUID — defaults to configured project (`project_id` is accepted too.)

Output Schema

NameRequiredDescriptionDefault
runsYesRecent gate_runs rows, newest first
findingsYesgate_findings rows for those runs

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.14
    • changedInput schema / properties / gate / enum
      Previous value: -[
-  "dead_handler",
-  "mock_leak",
-  "api_contract",
-  "crawl",
-  "status_claim",
-  "spec_drift",
-  "orphan_endpoint",
-  "unknown_call",
-  "schema_drift",
-  "code_health"
-]New value: +[
+  "dead_handler",
+  "mock_leak",
+  "api_contract",
+  "crawl",
+  "status_claim",
+  "spec_drift",
+  "orphan_endpoint",
+  "unknown_call",
+  "schema_drift",
+  "code_health",
+  "design_drift",
+  "ci_drift",
+  "deploy_drift",
+  "env_drift",
+  "radar",
+  "portfolio_radar",
+  "portfolio_radar_ci",
+  "store_review"
+]
  2. Changed5 schema fields changedv0.1.12
    • changedInput schema / properties / gate / description
      Previous value: -"Filter to one gate id: dead-handler | mock-leak | crawl | status-claim"New value: +"Only runs of this gate (and their findings)."
    • addedInput schema / properties / gate / enum
      Added value: +[
+  "dead_handler",
+  "mock_leak",
+  "api_contract",
+  "crawl",
+  "status_claim",
+  "spec_drift",
+  "orphan_endpoint",
+  "unknown_call",
+  "schema_drift",
+  "code_health"
+]
    • changedInput schema / properties / projectId / description
      Previous value: -"Project UUID — defaults to configured project"New value: +"Project UUID — defaults to configured project (`project_id` is accepted too.)"
    • changedInput schema / properties / severity / description
      Previous value: -"Minimum severity to include: low | medium | high | critical"New value: +"Only findings with exactly this severity."
    • addedInput schema / properties / severity / enum
      Added value: +[
+  "info",
+  "warn",
+  "error"
+]
  3. Changed2 schema fields 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"
    • changedOutput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  4. Addedv0.1.2

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already cover readOnly/idempotent/openWorld, but the description adds real behavior: newest-first ordering, that radar findings carry a suggested_fix, and a non-obvious auth constraint (a spend-cap fix is applied in the console by a signed-in project admin, not through an API key). It doesn't mention pagination or result limits despite 'recent' runs, and 'Read-only' partially repeats readOnlyHint.

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

Conciseness4/5

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

Front-loaded with purpose, then return shape, filters, gate semantics, then usage. The bulk of the length comes from restating the 18-value gate enum already present in the schema, which is somewhat duplicative, but the surrounding explanation earns most of the space.

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?

An output schema exists, so the description need not explain returns, yet it covers filtering, plan availability, gate semantics, sibling routing and an auth caveat. Nothing an agent needs to invoke it correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning to the enum values — it explains that design_drift is code drifting off design tokens, ci_drift/deploy_drift/env_drift relate to recipe drift, and radar covers setup checks. That is semantic enrichment the bare enum does not provide.

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?

States a specific verb+resource+scope: 'List recent inventory gate runs and their findings for a project, newest first.' It also distinguishes itself from siblings by naming get_radar, diff_inventory and get_inventory, so an agent can route without opening schemas.

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

Usage Guidelines5/5

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

Gives an explicit use case ('see which CI gates failed on the last crawl') and names the alternatives with their selecting conditions ('use diff_inventory to compare two commits, or get_inventory for the full snapshot', 'prefer get_radar' for portfolio/store gates). Routing is unambiguous.

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