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

The description significantly enriches the annotations: it discloses that inputs are processed transiently and are not stored, logged, or retained, that the node is deterministic, how browser/server delegation works on gpu:false and gpu:true nodes, and that an AP2 artifact with execution_hash is exported for on-chain provenance. These behaviors align with readOnlyHint, idempotentHint, and no destructionHint, so there is no annotation contradiction.

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?

Most behavioral details are useful and directly relevant to invoking the tool. But the description repeats the tool title and `OpenGraph compute node` nearly verbatim in the first two sentences, and the FV-status/provenance block is long and marginally relevant to selection or invocation.

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 that there is no output schema, the description is very useful in saying what the tool emits, what it feeds, and how it handles privacy and execution. The main gap is the opaque `policy_parameters` payload: the calling agent cannot determine how to structure the actual ISO 20022 input without retrieving the referenced manifest.

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 four parameters. The description adds some runtime semantics around compute, but does not add field-level detail. In particular, `policy_parameters` is still only a pointer to an external manifest, so the description does not clarify its actual contents.

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 tool name and opening line clearly identify the resource and transformation: ISO 20022 to EVM calldata. The description adds that it is a deterministic, compliance-related OpenChainGraph compute node whose output feeds an on-ledger transfer batch artifact, so an agent can infer what it produces. However, it does not explicitly state an active user-facing description and does not differentiate itself from other map_* sibling tools.

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?

There is no guidance on when to select this tool instead of an alternative mapper, and no mention of when to avoid it. The compute-mode explanation describes execution routing, not invocation context. The input-safety rule `Use synthetic or anonymised inputs only` is operational guidance, but it does not tell an agent when or why to use this tool against a sibling tool.

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