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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds non-trivial behavioral details: compute routing logic (browser delegation URL), transient processing with no storage/logging/retention, requirement for synthetic/anonymized inputs, AP2 artifact export with execution_hash, and FV-status snapshot semantics. These go beyond annotations and inform agent behavior. No contradiction with annotations.

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 quite long and dense with many pieces of information (compute logic, transient storage disclaimer, artifact exports, upstream/downstream artifacts, URL, FV-status). While it's front-loaded with the core purpose, it packs too many disparate details, making it harder to parse. Every sentence serves a purpose but the structure could be cleaner.

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 tool's complexity (compute routing, gpu modes, chaining, artifact export) and the absence of an output schema, the description covers the key behaviors an agent needs: what inputs are transient, what's exported, what upstream artifacts to consume, and how to verify provenance via FV-status. The only gap is what the returned response looks like beyond the browser delegation URL and AP2 artifact reference, but no output schema exists so the description compensates reasonably.

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 100%, so the schema already documents all 4 parameters. The description adds some semantic value for policy_parameters (mentions decision function) and parent_hashes/parent_tool_ids (chaining), plus compute modes are elaborated. But much of this repeats schema descriptions. Baseline 3 is appropriate since the schema carries detail; description's extra context is marginal.

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 clearly identifies this as a compute node for building a Mastercard agentic token scope, with specific function names (compliance_control, OpenChainGraph compute node). However, the name already conveys this, and the description bundles multiple purposes (compute routing, artifact export, chain provenance) without a single crisp verb-resource statement. It does distinguish from siblings by naming upstream/downstream artifacts.

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 explains when compute:'auto' vs 'browser' modes apply (gpu:false with registered kernel versus gpu:true always delegating), which is useful usage context. However, it doesn't explicitly say when to choose this tool over siblings like compare_agentic_payment_protocols or build_google_ap2_mandate; it only mentions upstream/output chains implicitly. No explicit exclusions or alternatives.

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