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

Annotations already cover read-only/idempotent/non-destructive, and the description still adds substantive behavior: what the response contains (raw vs final deadline, skipped days, explanation trail, disclaimer), the data_confidence levels and what triggers medium confidence, estimated_items, sources and warnings. That is exactly the kind of context annotations cannot carry.

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?

Front-loaded with the purpose and the counting/rolling behavior, then calendar selection, then response shape; every block earns its place for a 14-parameter tool. It is dense and long-winded in places (the response sentence is a run-on), which keeps it from a 5.

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 14 parameters and an output schema, the description supplies the decision logic (which calendar source, how confidence is derived, what warnings mean) that structured fields do not. Slight redundancy in re-explaining return fields already covered by the output schema, and no negative guidance about sibling tools.

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 coverage is 100%, so the baseline is 3; the description still adds cross-field meaning — country OR market selects the calendar, subdivision codes come from list_calendars, weekend defaults to the country's legal weekend, extra_holidays are company/contract dates — plus a worked example. It stops short of explaining exclude_start_day or month_end_clamp, which only the schema covers.

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?

Names a specific verb and resource ('Compute the end of a period ... from a start date') and enumerates the counting, rolling and explanation behaviors, so the operation is unambiguous. It never names a sibling (add_working_days, roll_date, working_days_between) to draw the boundary, so it falls short of full differentiation.

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?

'Pass the rules the contract/law states; defaults are the common ones' gives a context for use, and the calendar-selection sentence hints at inputs. But there is no explicit when/when-not guidance and no routing to roll_date or add_working_days, so the agent must infer which sibling to call.

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