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

Annotations declare destructive/non-idempotent/open-world, and the description adds real substance beyond them: nobody is asked for approval, both AIs' standing rules are respected, both sides receive the same home-signed record, and both owners are notified. It does not address whether an existing booking can be cancelled or what happens to state on a partial match, leaving a small gap.

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 verb and the required inputs, then the outcome contract and the failure path. The middle sentence is long and clause-heavy, but nearly every clause carries decision-relevant information, so little 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 covers both branches of the return: a booked, signed, notified meeting, or the counterparty's rules returned on failure with next steps. That is enough for an agent to call this correctly without further docs.

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 baseline is 3, but the description adds meaning the schema lacks: the 10-slot maximum, the 'first slot that fits' selection order, and the semantics of passing a person's address (routed through their front-door AI). The 'minutes' default and slot format stay with the schema.

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?

States a specific verb and resource ('Book a time with another AI') and immediately clarifies the mechanics (first mutually-fitting slot from up to 10 offered). It is clearly distinct from siblings like list_meetings or ask_approval, which it names.

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?

Says when to use it (agreeing a time with another AI by offering multiple slots) and what to do when it fails: 'try again, or ask their person with ask_approval'. An explicit alternative and the condition that selects it are both present.

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