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

Adds substantial context beyond the annotations: attempts are consumed even on failed evaluation, retrying a successful call burns another attempt, human review is required, no authorization or clearance is granted, and source content must be treated as data rather than instructions (prompt-injection guidance). Annotations (readOnlyHint=false, openWorldHint=true) do not contradict any of this; they are consistent with a scored, non-idempotent evaluation call.

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?

Dense but front-loaded: purpose first, then execution mode, then quota rules, then security caveat. Nearly every sentence carries operational information, though the quota sentences are somewhat compressed and could be tighter.

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 need not be described, and the description covers call mode, quota consumption, review requirements, and safety. It is slightly thin on how the trial differs in fidelity from the paid ruling tool and on what an exhausted quota produces.

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 description coverage is only 33% across 6 parameters with nested objects, so the description must compensate. It only gestures at field semantics ('agreed hashes, supported schemas, deadlines and SLO records'), leaving escrow_id, dispute_claim, arbitration_policy, and the delivery_submission structure unexplained.

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 uses a specific verb and resource ('Compare escrow delivery evidence with agreed hashes...') and clarifies that this runs m2m_escrow_arbitration_ruling on caller-supplied input without payment or an HTTP adapter. It is distinguishable from its sibling arbitration tool, though the opening sentence leads with the domain rather than the trial nature of the tool.

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?

Explicitly instructs 'Check free_trial_status first' and names the alternative execution path (the HTTP trial vs. this in-process run). It states the quota context (2-attempt allowance, shared daily capacity), but does not say when an agent should skip the trial entirely in favor of the paid sibling.

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