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

Beyond the annotations, the description discloses that inputs are processed transiently and not stored or logged, explains compute mode behavior for server versus browser execution, and notes that an AP2 artifact with execution_hash is exported for provenance. These are meaningful behavioral details for an idempotent read-only checker.

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 definition is bloated with repeated OpenChainGraph platform boilerplate, a long external URL, and an FV-status receipt URL that do not help an agent decide how to invoke the tool. The domain purpose is not front-loaded; platform mechanics dominate the opening and body.

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?

For a compliance checker, the description should explain what DPA Article 28 completeness means, what policy_parameters are expected, and what the AP2 artifact result represents. It instead focuses on compute execution and provenance, leaving the domain semantics and actionable input guidance incomplete.

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 input schema already documents compute, parent_hashes, parent_tool_ids, and policy_parameters in detail. The description reinforces compute-mode and provenance concepts but does not add parameter-specific meaning beyond the schema, which is the baseline for high schema coverage.

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 essentially restates the title, calling it a "DPA Article 28 Completeness Checker" and an "OpenChainGraph compute node (compliance_mandate)," but never explains what completeness dimensions are checked or what a check result means. It does not add a specific verb-and-resource explanation beyond the tool name/title.

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 only usage constraint is "Use synthetic or anonymised inputs only," which is a data-safety instruction rather than guidance on when to select this tool. There is no comparison to sibling compliance checkers or indication of when not to use it.

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