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

Annotations already declare readOnly, idempotent, and non-destructive. The description adds meaningful beyond-annotation context: inputs are transiently processed and not stored/logged/retained, the computation is deterministic, it exports an AP2 artifact with execution_hash for provenance, and it explains compute mode delegation (server vs browser). This materially improves agent understanding of side effects and data handling.

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 dense but well-structured: it opens with the core purpose, then explains compute behavior, privacy, artifact export, upstream dependency, URL, and FV-status. Each sentence adds distinct information, and the most critical operational details (compute modes, privacy) are front-loaded. It is a bit long but avoids fluff.

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 complexity (4 optional params, compute modes, artifact export, upstream chain dependency), the description covers most operational aspects: compute delegation, transient data handling, artifact provenance, upstream artifact ID, and verification URL. It does not describe the output format (no output schema) or the contents of policy_parameters beyond a manifest reference, which is a notable gap for an agent needing to construct a correct request.

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 parameters (compute, parent_hashes, parent_tool_ids, policy_parameters) are already documented. The description adds little beyond the schema: it repeats the compute mode logic and mentions that policy_parameters are for the decision function, but it points to an external manifest for field names rather than explaining them inline. Given full schema coverage, baseline 3 is appropriate; it doesn't compensate for the external manifest gap.

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 the tool as an OpenChainGraph compute node for the 'Arc Paymaster Economics Model' with a 'treasury_mandate', using a specific verb-resource pair. It distinguishes itself from generic compute tools by naming the specific domain (paymaster economics) and the node type (treasury_mandate). However, it doesn't explicitly contrast with sibling models like model_arc_cpn_economics or model_arc_stablefx_rfq, so it's not perfectly differentiated.

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 provides operational constraints ('Use synthetic or anonymised inputs only') and clarifies when compute:'browser' or server-side execution applies, but it doesn't tell an agent when to choose this tool over alternatives. No mention of specific use cases, prerequisites, or exclusions relative to sibling tools. The guidance is mostly about how to invoke rather than when to select.

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