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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states that the tool exposes the assumptions and tables behind the calculator, which is useful transparency about what the returned description will contain. It does not explicitly declare 'read-only' or list side effects, but for a describe-style tool with zero parameters this is reasonably clear.

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 compact sentence covers all core aspects of the tool: inputs, outputs, assumptions, and tables. It is front-loaded and contains no filler, while the title adds complementary context without redundancy.

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?

There is no output schema and no parameter schema, so the description must stand alone. It adequately enumerates the categories of information returned by the tool. It could be strengthened by explicitly mentioning the relationship to 'calculate,' but for a zero-parameter documentation tool, the description is largely 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?

The tool takes zero parameters, and the schema already fully reflects that. The description adds meaningful context by noting that the calculator's own inputs are presented with units, ranges, and defaults, which helps an agent understand the kind of information the describe output will contain.

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 enumerates what the tool covers — the calculator's inputs with units/ranges/defaults, outputs, assumptions, and tables — and the title/name make it obvious this is a describe/reference tool rather than the calculation tool itself. It lacks an explicit standalone verb like 'returns,' but the scope is unmistakable and distinguishes it from the sibling 'calculate'.

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 implies this is the documentation/reference tool for the New Zealand notice period calculator, but it never explicitly states when to use it instead of 'calculate' or whether it should be consulted before performing a calculation. No exclusions or alternatives are named, leaving the agent to infer usage from the sibling tool names.

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