List D&D 5e monsters and optionally filter by challenge rating to find creatures for encounters or reference their stats.
List D&D 5e monsters, optionally by challenge rating.
| Name | Required | Description | Default |
|---|---|---|---|
| challenge_rating | No | Filter by CR (e.g. '1', '0.25') |
Changes observed during successful MCP inspections.
v0.1.11Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and openWorld, so safety and determinism are covered. The description adds nothing beyond that: no note on result volume, pagination, or whether the list is exhaustive, which are the behaviors that actually matter for a bulk list tool.
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?
A single front-loaded sentence with no filler. It is appropriately sized for a one-parameter list tool, though the terseness leaves no room for the result-shape caveat an agent might want.
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 is simple and annotations cover its safety profile, but there is no output schema and the description says nothing about what a monster record contains or how large the unfiltered list is. For a bulk-listing tool with no return-value documentation anywhere else, that is a real gap.
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% and the single parameter documents CR formatting with examples. The description restates the same filter ('by challenge rating') without adding syntax, accepted values, or behavior for unmatched CRs, so it only matches the schema baseline.
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 resource ('List D&D 5e monsters') plus the optional filter, which is enough to tell it apart from dnd_get_monster in practice. It never names the sibling explicitly, so the listing-vs-single-record distinction is inferred rather than stated.
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?
'optionally by challenge rating' implies you can call it bare to get everything or filter by CR, which is useful usage shape. There is no explicit statement of when to use this versus dnd_get_monster, nor any note about breadth of results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.