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

Beyond the annotations (readOnly, idempotent, non-destructive), the description adds meaningful behavior: it is pure arithmetic over the venue table, produces the same refusals as the mandate form, and refuses plans that would widen authority—unproven venues, empty allowlists, and overcommitting caps. This gives an agent concrete expectations about determinism and failure cases.

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 dense sentences, front-loaded with what the tool does and followed by the key safety distinction: it grants nothing. Every clause earns its place, and the refusal conditions are compactly listed without bloat.

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 rich annotations, complete schema coverage, and the description's explanation of both output shape (four seat sessions with allowlist, spend cap, expiry) and refusal behavior, the definition is fully sufficient for an agent to select and invoke the tool correctly—even without an output schema.

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 input schema already fully documents all three parameters with descriptions, types, and bounds. The tool description mentions capital amount and duration but adds no new parameter-level meaning; the baseline of 3 is appropriate since the schema carries the semantics.

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 names a specific operation: turning a capital amount and duration into four bounded sessions without granting anything. It also clarifies the scope of each session (contract allowlist, spend cap, expiry), which distinguishes this planning/preview tool from any actual granting action.

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 makes clear this is the tool to use when you want the exact plan the mandate form would show, including refusals, without making any grant. It does not name alternative sibling tools or provide explicit when-not-to-use guidance, but the context is clear enough for an agent to route correctly.

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