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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral context beyond them: it returns exact big-number results and covers repetition cases plus factorial, which tells the agent about precision and scope. It stops short of describing the actual return shape, keeping it below 5.

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 tight sentences plus a reference URL; the concrete example is front-loaded and every clause conveys either an output or a capability. Nothing is wasted.

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?

With no output schema, the description must convey return content, and it does: both nPr and nCr, repetition variants, and factorial, with exact precision. It does not specify field names or result structure, which leaves a small gap for a calculator whose output format is otherwise undocumented.

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% (n and r are both documented with type, bounds, and defaults), so the schema carries the parameter semantics. The worked example (3 from 10) illustrates the n/r roles but adds little syntax or constraint detail beyond 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 states a specific resource and its outputs: ordered arrangements (nPr), combinations (nCr), repetition cases, and n factorial. The worked example (3 from 10 -> 720 / 120) makes the function unmistakable. However, it does not differentiate itself from nearby siblings such as scientific_calculator or lcm_gcd_calculator, so it falls short of the 5-level bar for sibling routing.

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?

Usage is implied by the example rather than stated: an agent infers it should call this when it needs permutation/combination/factorial results. There is no explicit when-to-use, when-not, or named alternative, so it stays at the minimum-viable level.

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