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

With annotations already declaring readOnlyHint, idempotentHint, and destructiveHint=false, the description adds meaningful context beyond structured fields: data is processed transiently and not stored or logged, compute may run server-side or delegate to the browser depending on compute mode and gpu status, and the tool exports an AP2 artifact with execution_hash. It also identifies upstream and downstream chain dependencies. It stops short of describing error behavior or return timing, but the behavioral disclosure is substantial.

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 not front-loaded: it opens with a title restatement and generic 'OpenChainGraph compute node' boilerplate, repeats the compute-node phrase, and only reaches the actual scoring purpose near the end. It also includes a full URL and a long FV-status hash that do not help an agent select or invoke the tool. Some sentences earn their place, but several do not.

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?

There is no output schema, but the description compensates by listing the returned fields: component_scores, component_weights, composite_pct, improvement_priorities, note, program_grade, reference_version, and wolfsberg_note. It also covers compute behavior, privacy, chain provenance, and upstream/downstream artifacts. For a complex compute node this is fairly complete, though the nested policy_parameters payload remains opaque beyond the schema.

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 all four parameters are already documented in the input schema. The description repeats the compute-mode semantics but adds no new meaning for parent_hashes, parent_tool_ids, or the nested policy_parameters object. Baseline 3 is appropriate when the schema carries the parameter documentation.

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 eventually states a specific purpose: a Wolfsberg-aligned screening-program quality scorecard combining list coverage, match calibration, alert tuning, escalation workflow, and model validation into a composite grade. It also differentiates itself by naming the upstream coverage and calibration artifacts it consumes. However, the actionable purpose is buried after generic compute-node boilerplate, so the agent must read to the end to understand what is being scored.

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 implies usage by specifying upstream artifacts it consumes and the downstream audit-trail aggregator it feeds, which helps situate the tool in a chain. It also warns to use synthetic or anonymised inputs only. But it never explicitly says when to choose this composite scorer over siblings like check_screening_list_coverage, score_fuzzy_match_calibration, or run_sanctions_screening_fit, nor does it state exclusions.

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