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

With no annotations, the description carries the full burden. It usefully discloses the output form ('Returns Markdown ready to file with the EU AI Office'), but says nothing about validation behavior, what happens with insufficient or out-of-window receipts, failure modes, or whether the report is deterministic.

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?

Three tight sentences: what it builds, why it is required, and what it returns. Front-loaded with the action and artifact, zero filler.

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 tool with nested objects, no output schema, and no annotations, the description covers purpose, legal basis, and return format. It stops short of describing report completeness requirements or error behavior, which matters for a compliance artifact intended for filing.

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%, including the nested SystemDescription shape and the 90-day PMM window hint, so the schema does the heavy lifting. The description adds only the general notion of a 'set of VAOS receipts' and no additional meaning for nextReportDue or operatorActions.

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?

States a specific verb and artifact ('Build an EU AI Act Annex IV technical-documentation report') plus the input source ('from a set of VAOS receipts'). The regulatory framing distinguishes it cleanly from sibling build_* tools covering ISO 42001, NIST AI RMF, SOC2, GDPR DPIA, etc.

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?

Gives clear triggering context: 'Article 11 of Regulation (EU) 2024/1689 requires this for every high-risk AI system', so an agent knows this applies to high-risk systems under the EU AI Act. However, it never explicitly contrasts with the other framework-report builders or states when-not to use it, leaving sibling selection partly to inference.

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

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

With no annotations, the description carries the full burden and does reasonably well: it explains that the constitution is a content-addressed SHA-256 document, that receipts commit to its hash, and that the output is a severity-ranked list of violations. It does not state whether the operation is read-only, what happens to receipts lacking the hash, or error behavior, which are meaningful gaps for an audit tool.

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?

Three sentences, each doing distinct work: what it does, what the inputs mean, and when to reach for it. The verb-and-resource statement is front-loaded with no filler.

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?

No output schema exists, and the description does compensate by describing the return as violations ranked by severity. For a two-parameter tool with nested objects, the remaining gap is edge-case behavior (unhashed receipts, empty results, mismatch handling), which keeps it short of a 5.

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 coverage is 100%, so the baseline would be 3. The description earns an extra point by explaining the semantic relationship between the two parameters — receipts commit to the constitution's hash — which is not obvious from the schema alone and clarifies why both are required together.

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?

States a specific verb and resource: 'Audit a VAOS receipt set against a signed AI constitution.' The follow-up sentences sharpen what the audit produces (receipts violating constitutional articles, ranked by severity), which clearly separates it from sibling builders like build_annex_iv or build_soc2_evidence that produce evidence rather than evaluate it.

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?

'Use it when you want to prove (or disprove) an autonomous agent followed its policy' gives a clear motivating context for invocation. It does not name an explicit alternative or a when-not condition, though the prerequisite (needing a signed constitution) is only surfaced in the schema, not the description.

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

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

With no annotations, the description carries the full burden and does disclose meaningful behavior: it maps requirements to evidence and explicitly surfaces open findings rather than silently passing. However, it never says whether the report is merely computed and returned or persisted, whether missing receipts degrade the result, or what an 'open finding' looks like.

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?

Three short sentences, front-loaded with the action and regulation, then the mapping behavior, then the findings output. No filler or repetition.

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 four-parameter tool with nested objects and no annotations or output schema, the description covers purpose and evidence-mapping but omits the report's return shape and ignores two of the four parameters. An agent knows what it gets conceptually but not structurally.

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 scope, receipts, residualRisks, and implementationStatus. The description reinforces the receipt-to-evidence relationship but adds no format or constraint detail for residualRisks or implementationStatus, so baseline 3 applies.

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?

States a specific verb and resource ('Build an EU Cyber Resilience Act compliance report') and names the exact regulation (EU 2024/2847), which cleanly separates it from the other build_* compliance siblings. The follow-up sentences define the report's content (Annex I requirements, Article 13/14 obligations, receipt-derived evidence, open findings).

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 phrase 'from a VAOS receipt set' implies the precondition (you must already hold receipts) but never states when to choose this over build_annex_iv, build_gdpr_dpia, or other build_* siblings, nor any exclusions. Usage is inferable from the named regulation rather than explicitly guided.

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

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

With no annotations, the description carries the full burden. It does disclose two non-obvious behaviors: the output is Markdown aimed at a DPO/supervisory authority, and high-residual-risk activities are automatically escalated to Article 36 prior consultation. It says nothing about whether anything is persisted or written to disk, or what happens on malformed receipts, which matters for a tool with no 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?

Three sentences, each earning its place: verb+artifact first, output format second, escalation behavior third. No filler and the most decision-relevant information is front-loaded.

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 four-parameter nested-input tool with no output schema, the description adequately covers what is produced (Markdown DPIA + RoPA) and one key output behavior (Article 36 flagging). It is slightly short on whether output is returned only or also persisted, but the schema carries the input contract fully.

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 (including the nested risks map and its auto-flag semantics) are already documented. The description only restates the input sources at a high level and adds no syntax, format, or ID-matching detail beyond the schema.

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?

States a specific verb (Build) and two precisely named artifacts (GDPR Article 35 DPIA + Article 30 RoPA report), plus the inputs it derives them from. Among siblings that all follow a build_*_compliance pattern, the Article numbers make it immediately distinguishable from build_annex_iv, build_iso_42001, and the rest.

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 input context ('operator-declared processing activities + a VAOS receipt set') implies when the tool applies, but there is no explicit when-to-use, no exclusions, and no routing guidance versus the many sibling compliance-report builders. An agent must infer that a GDPR DPIA (not Annex IV or ISO 42001) is the right artifact.

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

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

With no annotations, the description carries the burden and does disclose real behavior: every implementation specification is mapped to receipt-derived evidence, missing REQUIRED specs become surfaced findings rather than silent gaps, and ADDRESSABLE specs accept an operator note. It stops short of saying whether an artifact is written to disk, what permissions are needed, or what the returned binder looks like.

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?

Three dense sentences, front-loaded with the artifact and regulation, then behavior, then edge-case handling. No restatement of the tool name and no filler.

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 no output schema and a nested scope object, the description covers the main thing an agent needs to know: the output is a spec-to-evidence binder with findings for unevidenced REQUIRED controls. The one real gap is the return shape of that binder, which the description gestures at but never characterizes.

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 coverage is 100%, so baseline is 3; the description adds value by tying 'receipts' to receipt-derived evidence and by explaining the semantics of the optional implementationStatus map (ADDRESSABLE specs can be marked alternative-implemented, which is the only status branch with special meaning). It doesn't explain the required HipaaScope subfields.

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?

States a specific verb and artifact: 'Build a HIPAA Security Rule (45 CFR § 164.308-318) evidence binder' from VAOS receipts. The named regulation and control family make it unambiguously distinct from siblings like build_gdpr_dpia or build_soc2_evidence without opening any schema.

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 input context is clear ('from a set of VAOS receipts'), which implies when the tool applies, but there is no explicit when-to-use / when-not-to-use guidance and no routing statement toward the sibling framework builders. An agent must infer that HIPAA scope selects this over build_iso_42001 or build_gdpr_dpia.

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

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

Since there are no annotations, the description carries the full behavioral burden. It is highly transparent by explaining that it uses a 5x5 likelihood x impact matrix and attenuates risk based on evidence count, disclosing the exact computational logic involved.

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 extremely concise, packing the required inputs, the core calculation method, and the final output format into a single, highly effective paragraph. Every word contributes necessary value to the agent's understanding.

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 of generating an AI risk-management report, the description provides a complete picture. It identifies the inputs, the proprietary risk calculation methodology, and the final delivery format (Markdown), leaving no functional gaps.

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?

Even with 100% schema coverage, the description adds critical semantic meaning. It explains how the `receipt` input is used to modify the risk calculation (attenuated by receipt evidence count), connecting the variables in a functional way that the schema alone does not convey.

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 states the purpose: building an ISO/IEC 23894:2023 AI risk-management report. The tool name itself, coupled with the list of sibling tools (e.g., build_iso_42001), ensures perfect differentiation between compliance standards.

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?

While it does not explicitly use 'when to use,' the description explains that the tool processes operator-declared scenarios and VAOS receipts. This sets a very clear context for its required inputs, suggesting use in comprehensive risk assessment workflows.

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

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

With no annotations, the description carries the full burden. It usefully discloses the return format (Markdown ready for an auditor), which is the key behavioral trait here, but is silent on whether anything is persisted, whether retentionDays affects stored artifacts, and whether receipts must be pre-verified via verify_manifest.

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?

Three short sentences, front-loaded with the action and resource, followed by coverage and output format. No redundancy.

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?

No output schema exists, and the description compensates by naming the return format and the standard's clause coverage. It is nearly complete for a generation tool, with the only gap being side effects or prerequisites for the required receipts input.

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 coverage is 100%, so scope, receipts, retentionDays, and operatorActions are already documented in the schema. The description adds no parameter-level meaning (e.g., what constitutes a valid receipt or what operatorActions contribute), so the baseline 3 applies.

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?

States a specific verb (build) and a precisely scoped resource (an ISO/IEC 42001:2023 AIMS report from VAOS receipts), and quantifies the coverage (clauses 4-10 plus the 38-control Annex A matrix). This distinguishes it clearly from sibling builders for other standards such as build_nist_ai_rmf or build_iso_23894.

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 mention of a certification body (BSI, TÜV SÜD) implies the tool's use context, but the description never states when to choose it over neighbors like build_annex_iv or build_iso_23894, nor what prerequisites the receipts must satisfy. Usage is inferable but not guided.

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

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

No annotations exist, so the description carries the whole burden. It does disclose the output shape (Markdown with per-subcategory evidence counts and trustworthy-AI characteristic coverage), which is genuinely useful, but says nothing about side effects — whether artifacts are persisted, whether this requires VAOS receipts to be complete, or what happens with partial evidence.

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?

Three compact sentences: what it builds, why it matters, and what comes back. The output contract is placed last where it belongs and nothing is padded.

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 four-parameter report generator with no annotations and no output schema, the description covers identity, input source, standard context, and return format. It does not cover prerequisites (e.g., what minimum receipt coverage is needed) or failure behavior, which is the remaining gap.

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 nested scope, maturityOverrides scale, and functionNarratives keys are already documented. The description adds only the provenance of the receipts parameter, not extra meaning for the three optional/nested parameters, so the baseline 3 applies.

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?

States a specific verb (build) and a specific named artifact (NIST AI RMF 1.0 profile covering GOVERN/MAP/MEASURE/MANAGE), plus its input source (VAOS receipts). The framework naming cleanly separates it from the sibling builders (ISO 42001, SOC 2, GDPR DPIA, HIPAA, ISO 23894, EU CRA, Annex IV), which an agent can distinguish at a glance.

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 line 'The de-facto US federal AI risk-management standard' effectively tells the agent the situation that selects this tool over the other framework builders. There is no explicit when-not guidance or a direct comparison to ISO 23894 (the closest sibling), so the routing is clear but not fully fenced.

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

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

No annotations are present, so the description carries the full burden. It usefully discloses the output form ('Returns Markdown') and that metrics are 'receipt-derived', suggesting a pure computation rather than a persisted artifact, but it never states whether anything is written anywhere, what happens when receipts are sparse, or any prerequisite validation — meaningful gaps for a four-param builder.

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?

Two dense sentences, front-loaded with the resource and framework version, then the per-criterion output contract, then the intended use. No filler or restated title.

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 complex tool with nested objects (Soc2Scope, receipts) and no output schema, the description adequately conveys structure and return format. A gap remains around required input shape for 'receipts' and behavior when coverage data is missing, but the essentials for correct invocation are present.

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 including the 30-day default on coverageThresholdDays. The description adds conceptual color ('receipt-derived evidence count', 'days-of-coverage metric') but does not explain controlOwners or how scope.inScope interacts with the criterion set, so it adds little beyond the schema.

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?

States a specific verb+resource ('Build a SOC 2 evidence binder') and pins the exact mapping target (AICPA Trust Service Criteria 2017, with CC1-CC9, A1, PI1, C1, P-series enumerated). This clearly separates it from framework siblings like build_iso_42001, build_nist_ai_rmf, and build_gdpr_dpia without needing to name them.

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 closing phrase 'walk into the audit kickoff with' implies the audit-preparation scenario, but there is no explicit when-to-use/when-not guidance and no routing to sibling builders (e.g., use build_gdpr_dpia for privacy-rule audits). Usage is only implied.

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

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

With no annotations, the description does real work: it discloses the return type, the content-addressed id semantics, and the byte-deterministic invariant allowing re-derivation of the hash from articles+name+signedBy. It stops short of stating idempotency (re-signing the same content), immutability, or auth requirements, which matter for a mutation tool.

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?

Three sentences, front-loaded with the action, then the return value, then the determinism invariant. No filler or restatement of the tool name.

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?

No output schema exists, so the description correctly explains the meaningful return value (`hash`). Combined with full schema coverage this is nearly complete; the remaining gap is downstream/ordering context relative to the build_* and verify_manifest siblings.

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 coverage is 100%, so the baseline is 3. The description only adds that hash derivation depends on articles + name + signedBy (omitting preamble), which is a minor bit of semantics beyond the schema and does not require further elaboration.

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?

Opens with a specific verb+resource ("Sign a new AI constitution") and clarifies the return artifact (SignedConstitution with a content-addressed `hash`). It reads as clearly distinct from the build_*/verify_manifest siblings, though it never names or contrasts them explicitly.

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?

Usage is only implied: "Every receipt produced under this constitution should commit to this hash" signals that this is the root step preceding the build_* tools, but there's no explicit when-to-use, when-not-to-use, or named alternative.

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

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

With no annotations, the description carries the burden well: it discloses the internal mechanism (recompute manifest hash, then check signature) and a genuine coverage limit for v3 signatures. It does not say what failure looks like (exception vs. falsy result) or whether partial trust is signaled, which keeps it below a 5.

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?

Four short sentences, each doing distinct work: purpose, mechanism, usage trigger, and a scope caveat. The verb and resource are front-loaded with zero filler.

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 nested-object input with no output schema, the description should indicate the return shape (boolean vs. a result object with failure reasons). It covers inputs, mechanism, and scope but leaves the outcome contract unstated.

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 coverage is 100%, so both parameters are already documented as an object and a PEM SPKI Ed25519 key; baseline is 3. The description reinforces that the key must be Ed25519 and that the manifest is a signed envelope, but adds no format or constraint detail beyond the schema.

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?

Names a specific verb and resource ('Verify a signed receipt bundle manifest'), pins the exact artifact (MANIFEST.signed.json) and the algorithm (Ed25519). It is unmistakably different from the build_* sibling tools, which all generate reports rather than validate inputs.

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?

'Use before building a report from a receipt set you did not produce yourself' gives a concrete triggering condition and ties it to the downstream build_* workflow. It also states a negative scope ('Does not check the ML-DSA-65 half'), though it names no explicit alternative tool for that case.

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