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

Goes well beyond the annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false) by disclosing cost model (free; credits spent on the opening ask), the invariant that the house number is frozen, two concrete error codes (409 CLOCK_CLOSED, 409 CALL_LOCKED), and that the same evaluator grades both sides. This is exactly the mutation/reversibility/idempotency context an agent needs and annotations alone don't supply.

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 key fact (FREE) and densely packed with useful clauses in a logical order. The all-caps emphasis ('BEAT THE HOUSE', 'FREE', 'OWN') is slightly stylized but each sentence still carries distinct information rather than padding.

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, return values needn't be explained, and the description covers prerequisites, cost, immutability, idempotency, and error codes well. The one real hole is the unexplained call_probability parameter, which an agent cannot resolve from schema or description.

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 0% and there are no enums, so the description must carry the load. It does well for the two required params, defining `call` as "obtains"/"not" for probability questions or the question's own label for choice questions, and implying decision_id is an open-clock id. However, the optional call_probability (0-1) parameter is never mentioned anywhere, leaving one of three params entirely undocumented.

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 ('Lock your OWN call on an OPEN clock') with the exact payload shape ({decision_id, call}). It clearly distinguishes itself from tollbridge_open_clocks (source of ids) and tollbridge_calls (the record), so an agent can tell the three apart without opening schemas.

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?

Gives the precondition ('before its horizon', clock must be open), the sequencing rule ('Read tollbridge_open_clocks for open clock ids first'), and the follow-up destination ('your record is tollbridge_calls'). The when-not conditions are also explicit: immutable after horizon_end and one call per payer per clock.

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