Skip to main content
Glama
Sign In
Mushi-Mushi

Mushi-Mushi

by kensaurus
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Run the hole checks now

run_radar

Start an on-demand project check now instead of waiting for the daily run: verify store names, listings, domains, certificates, headers, privacy links, and connector health.

Instructions

Start the hole checks (radar) for one project now instead of waiting for the daily run: store names, listing languages, domain and certificate expiry, security headers, the privacy link, and the connector-backed checks. The checks run in the background; poll get_radar until checkedAt changes. At most one run per project every 10 minutes (429 RATE_LIMITED with Retry-After otherwise). Optional projectId (defaults to the server-configured project). Returns { started, projectId, startedAt }. Write: it records a new gate run; nothing in your app or repo changes.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "run_radar"
  }
}

Input Schema

NameRequiredDescriptionDefault
projectIdNoProject UUID — defaults to the server-configured project when omitted (`project_id` is accepted too.)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.14

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations: the run is asynchronous/background, the rate-limit contract and error shape are spelled out, and 'Write: it records a new gate run; nothing in your app or repo changes' reconciles non-read-only with non-destructive. It even discloses the return payload, which no output schema provides.

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 the action, then constraints, then return shape and write semantics — a sensible ordering. The mid-sentence enumerations of check types and response fields are dense but each item carries information an agent would otherwise have to guess.

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?

Despite having no output schema, the description supplies the return shape ({ started, projectId, startedAt }), the async completion signal, and the write scope. Nothing needed to invoke or follow up on this tool is missing.

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% and the schema already documents the default and the project_id alias, so the description's mention of 'optional projectId (defaults to the server-configured project)' largely repeats structured data. Baseline 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?

Specific verb ('start the hole checks/radar') plus resource ('one project'), and it enumerates the check categories so the agent knows the scope. It explicitly distinguishes itself from the get_radar sibling by casting itself as the trigger and get_radar as the poll target.

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?

Explicit 'now instead of waiting for the daily run', plus the follow-up procedure (poll get_radar until checkedAt changes) and the hard constraint (max one run per project every 10 minutes, 429 RATE_LIMITED with Retry-After). Both when-to-call and when-not-to-call are covered.

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