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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description adds behavioral context such as 'reject irrelevant meanings', 'inspect product evidence', 'score...', and the precise output format (Minionese verdict first, English translation second, leaderboard third). This goes well beyond the annotations by explaining the step-by-step processing and rendering behavior.

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 two sentences long: the first sentence concisely lists the multi-step process (discover, reject, inspect, score, crown), and the second sentence specifies the required output format. Every part adds value, nothing is redundant. The description is front-loaded with the main purpose.

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?

Given the presence of an output schema (signal: 'Has output schema: true'), the description does not need to explain return values. It fully covers the high-level workflow and output formatting rules. The complexity of 6 parameters is handled by the schema descriptions, and the annotations provide safety context. The description is complete for a demo tool with these structured fields.

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%, with all 6 parameters having descriptions in the input schema. The tool description does not add parameter-specific semantics beyond what the schema already provides. It explains the overall workflow, but the individual parameter meanings are fully covered by the schema. 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 clearly states the tool's purpose: 'discover food buns sold online, reject irrelevant meanings... then crown a citation-backed winner.' It specifies the exact workflow and output format. The title 'Find the Juiciest Buns' reinforces the specific resource. Sibling tools (verify_app, research, roleplay) are clearly different, so there is no ambiguity.

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?

The description explains that this tool runs 'the gold Minion MCP demo' and details its internal steps, but it does not explicitly state when to use this tool versus alternatives. It implies a specific demo scenario (finding buns) but offers no guidance on when not to use it or when other siblings might be preferable. Usage is implied rather than clearly directed.

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

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

The description adds behavioral context beyond the annotations (readOnlyHint, openWorldHint, destructiveHint) by detailing what the tool returns: 'bounded page evidence, per-source verification status, citations, failures, and recovery'. This aligns with the annotations and provides useful transparency about the tool's output and safety profile.

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 three sentences long, with no wasted words. It front-loads the core action and purpose, then adds key differentiators and output details. Every sentence earns its place, making it highly concise and effective.

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?

Given the tool's complexity (7 parameters, 1 required, output schema available, annotations present), the description covers the essential aspects: what it does, when to use it, and what it returns. It could be more complete by explicitly mentioning the parameter limits (e.g., max 6 sources) or linking to the output schema, but the schema already provides that detail, so the description is sufficient.

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?

With 100% schema description coverage, the baseline is 3. The tool description does not add significant new information about the parameters beyond what the schema already provides. It mentions the preference for direct URLs, which is a usage guideline rather than parameter semantics, so no extra value is added to parameter understanding.

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 clearly states the tool's action: 'Search and open source pages in one call' for specific use cases like comparisons, recommendations, and factual lookups. It distinguishes itself from a basic search tool by noting it does not treat result titles as answers, and it enumerates the return types (evidence, verification, citations). This is specific and helpful for an agent.

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?

The description provides explicit guidance on when to use the tool, including preferring direct source URLs when known and contrasting with a basic search tool. However, it does not directly compare against sibling tools like minion_verify_app or minion_bun_hunt, leaving some ambiguity about when to choose this over alternatives.

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

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

The annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the tool is known to be safe and non-mutating. The description adds that the tool returns 'full-intensity Minionspeak by default,' which is a behavioral detail not captured by annotations. However, it doesn't clearly explain how the mood, intensity, and translation parameters interact with the roleplay output beyond a brief hint. Since annotations handle the safety profile, the description is adequate but not overly rich.

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 two sentences long and front-loads the primary use case. Every sentence adds value: first sentence defines scope and context, second sentence clarifies default behavior and sibling tool alternative. It is concise but could be slightly more structured, e.g., by separating the bans from the functional details. Still, it efficiently communicates the tool's purpose and boundaries.

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?

Given the presence of a rich output schema and full annotation coverage, the description does not need to document return values or safety. The tool has 4 parameters (1 required), simple enums, and no nested objects – moderate complexity. The description covers the roleplay domain, sibling differentiation, and default behavior. However, it doesn't mention that the output will be styled as Minionspeak regardless of mood or intensity, nor does it clarify if the mood parameter affects the translation. Minor gaps, but overall complete for the tool's purpose.

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 schema already documents all parameters including descriptions for 'message', 'mood', 'intensity', and 'include_translation'. The description adds that the tool is for roleplay and that the default output is Minionspeak, which provides context for how parameters like 'intensity' and 'include_translation' are used. However, it doesn't explain the relationship between mood and intensity, nor does it specify the expected tone of the message input. Baseline 3 is fair since schema coverage is complete.

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 clearly states the tool is for 'Evil Boss banter, greetings, celebrations, dramatic scheming, and roleplay about any topic that does not require app verification, source research, or a bun hunt.' It explicitly differentiates from sibling tools by listing what it's not for, and the title 'Scheme With Minion' reinforces the purpose. The verb 'returns full-intensity Minionspeak by default' specifies the output behavior.

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?

The description explicitly tells when to use this tool (banter, roleplay) and when not to use it (app verification, source research, bun hunt). It also explicitly recommends using a sibling tool ('use the specialized Minion tool instead') for operational work. This provides clear guidance on alternatives.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the agent knows this is a safe non-destructive audit. The description adds important behavioral context: the tool captures screenshots, saves a JSON dossier, and 'brutally roasts every failure in Minionspeak with exact evidence and evil repair orders'. This goes far beyond the annotations and tells the agent exactly what kind of output to expect. No contradictions with annotations.

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?

Three sentences: first sets the trigger scenario and lists what the tool does, second adds technical constraints, third provides a prerequisite. Every sentence earns its place. No filler. Front-loaded with the most critical information.

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?

The tool has 7 parameters, 100% schema coverage, and an output schema. For a complex audit tool, the description covers the usage scenario, the exact scope of the audit, the behavior (crawling, capturing, saving, roasting), and the prerequisite. The output schema handles return values. This is complete enough for an agent to select and invoke correctly.

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 baseline is 3. The description does not add additional semantic info beyond the schema's own descriptions (which are already quite clear). The description summarizes the overall purpose but does not explain how each parameter affects the tool's behavior. At 100% coverage, a 3 is appropriate – the schema carries the burden.

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 states a specific verb ('crawls') and resource ('same-origin routes'), and then enumerates exactly what it captures: runtime, console, network, broken-image, layout, content, and accessibility failures. It clearly distinguishes from siblings that are about research, bun hunting, or roleplay, so an agent can tell when to use this vs. alternatives.

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?

The description explicitly says when to use the tool ('when Evil Boss or another coding agent claims a vibe-coded web app is done') and gives a prerequisite ('requires a running absolute URL such as http://localhost:3000'). It does not mention when not to use it or list alternatives explicitly, but the context and siblings make it clear enough.

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