roll_pool

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

Annotations are all false (e.g., readOnlyHint false), suggesting the tool may have side effects such as recording history or hidden rolls. The description does not mention these behaviors, nor does it explain output format or whether multiple rolls are supported (times parameter). However, it does add context about glitch/critical mechanics (ones_glitch, tens_crit) which enriches the behavioral understanding beyond the 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?

The description is extremely concise and structured: a one-line purpose followed by three clear example configurations. Every sentence adds value, and the examples are well-formatted for quick reference. No wasted words.

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?

Despite the complexity of the tool (15 parameters, no output schema), the description does not explain the return value format, the meaning of hidden, times, explode_on, explode_limit, double_success_on, or locale. It also omits any mention of edge-case behaviors, leaving significant gaps for an agent to understand full functionality.

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 low (33%). The description compensates with concrete examples for Shadowrun, WoD, and Year Zero, showing how to set key parameters like count, sides, target, success_condition, ones_glitch, ones_cancel, and tens_crit. While not all 15 parameters are explained, the examples clarify the most important ones and illustrate the intended usage patterns.

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: '骰池检定（Shadowrun / WoD / Year Zero 等）' and '统计满足条件的成功骰数', which translates to 'dice pool check' and 'count successful dice meeting conditions'. It specifies the resource (dice pool check) and differentiates from siblings like roll_dice or roll_check by focusing on pool-based systems and success counting.

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 clear context for when to use the tool, listing specific game systems (Shadowrun, WoD, Year Zero) and example parameter configurations for each. It implicitly guides the agent to use this tool for dice pool mechanics, though it does not explicitly state exclusions or mention alternative tools.

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