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

Beyond the readOnly/idempotent annotations, it discloses that the file is generated to run against a stub with TODO markers, and that each case carries an exhibit id usable with edge_case_get. That is real behavioral context an agent could not get from the annotations. It does not say what happens with unsupported languages or whether the file is returned inline or written out.

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 artifact name and format variants, with the stub/TODO mechanics and the edge_case_get handoff packed into one follow-up sentence. The 'Edge Case Museum:' prefix is branding but does orient the reader quickly.

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 two-parameter, non-destructive generator with no output schema, the description covers what is produced, how it runs, and how to diagnose a failing case. Adequate; only the delivery mechanism (inline text vs. file) is unstated.

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%, with both parameters and the language enum documented in the schema, so the baseline is 3. The description adds only the framing that the context string drives which exhibits are bundled and that the output form differs per language, which the schema already conveys.

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 and artifact: it produces a runnable test file (pytest or node:test) containing parametrized edge cases drawn from the exhibits relevant to the caller's implementation. This is clearly distinguishable from edge_cases_find (searching exhibits) and edge_case_get (explaining a single exhibit), both of which are named or implied.

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 makes the trigger condition explicit ('inputs from the exhibits relevant to what you are implementing') and routes the agent to edge_case_get when a generated case fails. It doesn't state when to prefer edge_cases_find/browse first, but the selection criterion for this tool is clear.

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