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

Beyond annotations that already declare read-only, idempotent, and non-destructive, the description adds a key behavioral trait: on invalid, missing, or malformed input this tool never raises a protocol error, returning an error object instead. It also states the practical consequence that after correcting input it is always safe to retry. This is valuable context the annotations do not provide.

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 front-loaded with the core purpose and packs a lot of useful detail into a compact space, including an example and error behavior. It loses a point for the stray 'FREE.' and for repeating the read-only/idempotent facts already present in annotations, but overall the length is justified.

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 an output schema present, the description doesn't need to define return fields, yet it still gives a realistic example. It covers all three parameters, typical and degenerate input, error mode, and retry safety, and it disambiguates from compute_deadlines. Nothing an agent needs to invoke it correctly is missing.

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 goes beyond schema by explaining the meaning of empty values ('Leave obligation empty to get every obligation of the event type; leave event_type empty on single-event regimes') and providing a worked example with valid values. That elevates it above the baseline.

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 opens with a specific verb and resource: 'Quote the time limit, citation and required content for an obligation.' It also names the sibling it is not ('Not for computing dates: use compute_deadlines'), so an agent can distinguish it from the nearest alternative. The typical input/output example reinforces the function with concrete fields.

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?

'Use when a caller needs the rule's own words next to a computed date' gives a positive context, and 'Not for computing dates: use compute_deadlines' gives an explicit exclusion. It also explains parameter-level usage: leaving obligation empty returns all obligations, and event_type can be empty on single-event regimes. This is complete routing guidance.

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