cr_calculate

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

With no annotations, the description carries the full burden of behavioral disclosure. It explains the calculation flow: defensive CR from HP/AC (with adjustments), offensive CR from DPR and attack bonus/save DC, then averaged. It stops short of covering rounding rules or edge cases, but the core behavior is clearly visible.

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 compact and front-loaded, starting with the primary action and then efficiently explaining the algorithm and input expectation. Every sentence earns its place; there is no filler or repetition of schema content.

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 algorithmic complexity, 8 parameters, no annotations, and no output schema, the description covers the main behavioral contract well: what is calculated, how, and what inputs are expected. It would be slightly stronger with rounding/edge-case notes, but as a calculator tool the description is reasonably complete.

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 and the description does not need to redefine parameters. It does add meaningful relationship guidance ('Provide at least one of attackBonus or saveDc'), but most parameter-level meaning is already present in the schema.

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 ('Calculate') and resource ('Challenge Rating for a custom monster'), and identifies the exact algorithm used (DMG Appendix B). It clearly differentiates itself from siblings like cr_scale or encounter_build by focusing on stat-to-CR conversion for custom monsters.

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: use this when you have a custom monster's defensive and offensive stats and want its CR. It also explicitly instructs that at least one of attackBonus or saveDc must be provided. It does not name alternative tools or direct when not to use it, but the usage context is unambiguous.

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