GENESIS ProofRelay MCP Verifier

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds valuable context by emphasizing 'hash-only' behavior and clarifying that ProofRelay does not issue or certify identity, which goes beyond the annotations and helps set expectations.

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 two sentences, starts with the primary action, and includes a relevant clarifying statement. Every word adds value without 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?

Given complexity (nested object with many fields) and the existence of an output schema, the description provides sufficient context for tool selection and basic invocation. It communicates the tool's purpose and key constraints, though it could mention the required top-level shape more explicitly.

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?

The top-level parameter 'identity' lacks a description in the schema (0% coverage), so the description must compensate. The description names the provider types and hash-only nature, but it does not describe the internal structure or required fields (e.g., agent_id_hash, provider). The nested schema does provide field descriptions, so the description adds some context but not enough to fully fill the 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 states it maps various identity references into a hash-only PREP-3 input, with a specific verb ('Map') and a defined resource (identity evidence). It also distinguishes itself from identity issuance tools by clarifying what it does not do, which helps differentiate it from 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?

The description implies when to use the tool (to transform identity references for ProofRelay evidence) and provides a clear exclusion ('does not issue identity or certify people'). However, it does not explicitly name alternative sibling tools for different use cases, so it falls short of a perfect 5.

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?

The description adds the qualifier 'public-safe' and frames the action as a mapping operation, which aligns with the readOnlyHint, idempotentHint, and destructiveHint annotations. It does not disclose additional side effects or prerequisites, but the annotation set already covers safety traits, so no contradiction exists. The description contributes modest context about the evidence profile target.

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 a single, information-dense sentence that front-loads the action and enumerates key inputs without wasted wording. It earns its place despite being jargon-heavy.

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 the x402 object and the existence of a sibling normalize tool, the description could benefit from clarifying when to adapt vs normalize or what constitutes a valid input lifecycle. The output schema presumably handles return values, but the absence of usage guidance or contextual prerequisites leaves the description somewhat incomplete for a tool with a nested parameter structure.

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?

The schema has rich per-field descriptions, and the description provides a high-level summary listing five of the hash inputs (request, 402 challenge, payment payload, facilitator response, resource response). It does not mention the optional fields (amount, network, currency, replay_key, facilitator_hash), and the schema coverage is 0% by the strict metric, but the description does add conceptual meaning about the 'public-safe' nature and the evidence profile.

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's function: mapping specific x402 lifecycle hashes into ProofRelay's payment_context evidence profile. It names the constituent parts (request, 402 challenge, payment payload, facilitator response, resource response), making the scope unambiguous. However, it does not explicitly differentiate from the sibling normalize_payment_proof, so it stops short of a top score.

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?

No guidance is provided on when to use this tool versus the many sibling proof/evidence tools. The description only states what it does, not why or when to choose it, nor which scenarios it is inappropriate for.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral context beyond those: the output is 'portable' and 'hash-only', and the tool works 'without uploading private files or logs'. This clarifies privacy and data-handling behavior without contradicting 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?

The description is a single, well-structured sentence that front-loads the core action and output, then adds the safety qualifier. Every phrase earns its place, with no redundant filler or repetition of schema fields.

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?

The output schema exists, so return-value details are covered structurally. The tool has a nested input object with multiple hash-array fields, and the description sufficiently communicates the overall use case and privacy guarantee. It could be slightly more complete by hinting at the required subject_hash, but it remains adequate for selection and invocation.

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?

The description names 'bundle, verifier, policy, and evidence hashes', which maps directly to bundle_hashes, verifier_response_hashes, policy_hashes, and evidence_hashes in the schema. However, schema coverage in the description is 0% overall, and it does not mention the required subject_hash or optional pack_id/control_refs/generated_at. The schema's own property descriptions compensate partially, so the description adds some but not sufficient parameter-level guidance.

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 states a specific action ('Build'), a concrete resource ('portable hash-only audit pack manifest'), and the source inputs ('bundle, verifier, policy, and evidence hashes'). It clearly distinguishes this tool from sibling build tools by emphasizing 'hash-only' and 'without uploading private files or logs'.

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 gives clear context: use this tool when you need to assemble a portable manifest from hashes while avoiding upload of private files/logs. It does not explicitly name alternative tools or provide when-not-to-use exclusions, but the privacy and hash-only framing provides solid situational guidance.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context beyond annotations: it clarifies the tool produces a non-attesting bundle and that the server does not sign or certify facts. It also emphasizes 'public-safe' inputs, signaling that secrets should not be included. This adds meaningful behavioral transparency without contradicting 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?

The description is two sentences and entirely front-loaded. The first sentence states the core purpose and constraints; the second adds a critical limitation. There is no fluff or repetition, making it highly efficient for an AI agent to parse.

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?

The description, combined with the rich output schema and annotations, covers the core purpose, key constraints (unsigned, non-attesting, public-safe), and safety profile. It does not explain canonical ordering or how event ordering is handled, but the schema notes 'events in any order,' and the output schema covers return structure. Overall sufficiently complete for a tool of this complexity.

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 0% per the provided signal, and the description does not compensate. It does not explain the 'draft' parameter's structure, required fields, or how events/payment context should be supplied. While the nested $defs contain descriptions, the tool description itself adds no parameter-level guidance, leaving the AI agent under-informed about constructing valid input.

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 uses a specific verb ('Build') with a clear resource ('canonical, unsigned, non-attesting ProofRelay bundle draft') and a clear input source ('public-safe event hashes'). It distinguishes itself from sibling tools like build_closing_proof_pack or build_audit_pack_manifest by emphasizing the draft's unsigned, non-attesting nature.

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 implicitly communicates when to use this tool: when you need an unsigned, non-attesting draft (as opposed to signed attestation or verification, handled by siblings like verify_signed_attestation). It also warns that the server 'does not sign or certify caller-provided facts,' but does not explicitly name alternatives or provide exclusion criteria.

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?

Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds valuable context beyond this: 'hash-only' (no content processing) and the explicit caveat 'does not authorize closing or disbursement.' This clarifies behavioral expectations without repeating the 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?

The description is two sentences long, front-loaded with the main action and inputs. The second sentence adds an important caveat without fluff. Every word earns its place.

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 a rich input schema and an output schema, the description covers the essential aspects: purpose, input types, and a key limitation. It does not detail the return format, but the output schema handles that. The description could be slightly more explicit about the manifest's role, but overall it is adequate.

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?

The tool description has 0% schema coverage, but it does enumerate the hash categories (settlement, title, lender, funding, notary, disbursement, approval) which correspond to the schema properties. The schema itself provides detailed descriptions for each property, including requiredness, so the description adds a high-level summary but does not clarify which fields are optional or required. The single required field is only evident from 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?

The description clearly states a specific action: 'Build a hash-only closing proof pack manifest' from enumerated hash types. It also adds a critical limitation ('does not authorize closing or disbursement') that distinguishes it from authorization-related tools. This goes well beyond the 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 description provides a clear context for use (constructing a closing proof pack from hashes) and an explicit exclusion: 'The tool does not authorize closing or disbursement.' However, it does not name sibling tools or suggest alternatives, so it stops short of full when-to-use-vs-alternative guidance.

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?

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds beyond this by clarifying the receipt is 'unsigned' and 'hash-only,' and by explicitly stating that it does not create approval authority or certify identity. This is valuable behavioral context not found in the 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?

The description is two concise sentences. The first sentence states the primary action and purpose; the second clarifies boundaries. No fluff or redundant information, and it is front-loaded with the core function.

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 the nested approval object and the presence of an output schema, the description covers the essential context: what the tool produces (a draft receipt), its nature (unsigned, hash-only), and its limitations. It does not explain all sub-fields, but the input schema's own descriptions handle those details. The description is complete for an agent to understand when and why to use it.

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 0% for the top-level parameter, and the description does not compensate. It mentions 'authority, policy, and subject evidence' which loosely maps to some sub-fields (approver_role, policy_hash, subject_hash) but gives no guidance on required fields like 'decision', 'approver_hash', or optional parameters. The description adds minimal parameter semantics.

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 states a clear, specific action: 'Build an unsigned, hash-only human approval receipt draft' for 'authority, policy, and subject evidence.' It mentions the tool is for a draft and explicitly distinguishes it from creating actual authority or certifying identity, which differentiates it from sibling build_* 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?

The description provides clear context about the tool's purpose and explicitly states what it does NOT do ('does not create approval authority or certify the approver's identity'), giving useful exclusion criteria. However, it does not explicitly name when to use this tool over alternatives or reference sibling tools, so it stops short of full guidance.

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?

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds valuable context beyond annotations by noting the output is 'public-safe,' a 'draft,' and uses 'only hashes and profile markers,' clarifying that no secrets are exposed and no final entry is published. This does not contradict the 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?

The description is a single concise sentence that captures the core purpose and constraints. Every word contributes to understanding, and it is properly front-loaded with the verb 'Build.' There is no redundant or extraneous information.

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 the registry entry draft with numerous optional hash fields, the description provides sufficient high-level context about the safety and content requirements. It does not explain the return value, but an output schema exists, so the description need only orient the agent. It adequately conveys the tool's role among many build-related 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?

Although the description does not enumerate parameters, it adds a key semantic constraint: the entry must consist of 'only hashes and profile markers' and be 'public-safe,' which guides how to fill the nested 'entry' object. The schema itself provides detailed descriptions for each field, so the description supplements rather than duplicates 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?

The description clearly states the verb 'Build' and the resource 'ProofRelay Registry entry draft'. It specifies the acceptable subjects (agent, API, MCP server, workflow, adapter) and the key constraint of using only hashes and profile markers. This distinguishes it from sibling tools like build_bundle_draft and build_audit_pack_manifest.

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 no guidance on when to use this tool versus alternatives. It does not mention any exclusions or indicate situations where a sibling tool would be more appropriate. The only implied usage is for creating registry entry drafts, which is too generic to help an agent choose among the many 'build' tools.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds important behavioral context beyond these hints: it emphasizes that the tool operates only on hashes (no sensitive data) and explicitly states it does not certify title status or legal sufficiency. This clarifies the output's scope and limitations.

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 two sentences with no wasted words. The first sentence states the core function, and the second sentence adds an essential disclaimer. It is front-loaded and easy to parse.

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?

The description covers the tool's purpose and key limitations, and an output schema exists so return values are not required. It does not explicitly mention when to use it versus siblings, and it omits optional parameters like non_secret_refs or the production_status enum, but the schema handles those details. Overall, it is a complete enough description for the tool's complexity.

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?

The schema itself provides descriptions for all parameters, so the baseline is 3 even without parameter info in the description. The description lists the data sources but does not explain the structure of the nested title_evidence object or the semantics of individual parameters such as non_secret_refs or production_status beyond what the schema already covers.

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 a specific verb ('build'), a resource ('hash-only title production evidence profile'), and lists the input sources (order, property, title-search, commitment, exception, tax-cert hashes). It also immediately distinguishes itself from certification tools by explicitly disclaiming title status or legal sufficiency, which differentiates it from siblings.

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 its usage for building hash-only evidence profiles, and the caveat about not certifying title status or legal sufficiency provides an exclusion of scope. However, it does not explicitly state when to use this tool versus alternatives or name any sibling tool, so the guidance remains implicit.

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?

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds valuable context by specifying that the signal is 'public-safe' and explicitly not a certification of readiness to close or fund, which goes beyond the annotations and clarifies the output's nature. No contradiction with 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?

The description is two sentences, front-loaded with the action, and contains no redundant information. Every phrase earns its place: it lists the input types, states the output is public-safe, and clarifies the non-certification limitation.

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 tool's moderate complexity, a nested input schema, and the presence of an output schema, the description provides sufficient context. It explains the purpose and the key behavioral constraint (no certification). It could elaborate on the output signal's format, but the existing output schema is expected to cover that, so the description is adequately complete.

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 0% from the tool description, so the description must compensate. It enumerates the input categories (title, closing, wire, lender-condition, approval, exception, risk hashes/counts) which vaguely maps to the schema properties, but it does not explain the required workflow_hash and target_milestone fields. The schema's own property descriptions are minimal (e.g., 'Wire review hash.'), so the description adds only marginal semantic value 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?

The description clearly states the tool's function: computing a public-safe readiness signal from specified hash/count inputs. It uses the specific verb 'compute' and names the resource, and explicitly distinguishes itself from certification tools by stating it does not certify readiness to close or fund, which helps differentiate it from siblings.

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 use for a public-safe readiness assessment and explicitly lists a limitation (no certification), but it does not provide explicit when-to-use guidance or name alternative tools. The 'does not certify' statement gives a partial when-not signal, but the agent is left to infer the appropriate context.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, which cover the core safety profile. The description adds valuable context by emphasizing 'public-safe' and 'without exposing secrets or requiring package installation,' which goes beyond the annotations and clarifies behavioral constraints.

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 a single sentence with no wasted words, and it front-loads the main purpose. However, the sentence is somewhat dense, combining two distinct purposes (client connection and evidence preparation), which slightly reduces clarity.

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?

With strong annotations and an output schema, the description adds enough context about safety and constraints. However, it does not elaborate on what 'hash-only evidence inputs' means, which could be ambiguous for an agent without domain knowledge. Overall, it is adequate for a read-only helper.

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?

The schema has 0% description coverage for the top-level 'helper' parameter, and the description does not explain its structure or fields. It only mentions the overall purpose. The nested schema contains descriptions for client and endpoint, but the description itself fails to compensate for the missing parameter guidance.

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 tool 'returns public-safe setup guidance' for specific actions: connecting MCP clients to ProofRelay and preparing hash-only evidence inputs. It uses a specific verb and resource, and distinguishes itself from sibling tools like proofrelay.describe_stripe_entitlement_flow, though it could be more concise.

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 when setup guidance for MCP clients is needed, but it does not explicitly state when not to use it or mention alternative tools. There is no exclusion criteria or alternative recommendation, leaving the usage context 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds the content scope (token, status, redemption, replay) but does not go beyond annotations with behavioral details like authentication needs, rate limits, or side effects. No contradiction with 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?

The description is a single sentence (23 words) that front-loads the action ('Return the agent-native Stripe checkout entitlement workflow') and then lists specific content items. No wasted words and all information is relevant.

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 no-parameter, non-mutating descriptor tool with an output schema, the description captures the essential purpose and content coverage. It provides enough detail for an agent to decide to invoke it and know what to expect in broad terms, and the output schema handles detailed return values.

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?

The tool has zero parameters, so the schema coverage is 100% by definition. The baseline for 0 params is 4, and the description compensates by explaining what the tool returns, giving context that the schema cannot. Even though no parameter details are needed, the description is sufficient.

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 tool returns the Stripe checkout entitlement workflow for ProofRelay paid verification, with a specific verb ('Return') and a specific resource ('agent-native Stripe checkout entitlement workflow'). It lists key elements (token, status, redemption, replay expectations), making it distinct from sibling tools that adapt, build, or verify evidence.

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 when to use this tool (when you need to understand the Stripe entitlement flow for ProofRelay), but it does not explicitly state exclusions or alternatives. No mention of when not to use or what to use instead, so it falls short of strong usage guidance.

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?

Annotations already declare safety traits (read-only, idempotent, non-destructive), so the description adds valuable context beyond annotations: it specifies that the receipt is 'unsigned' and 'hash-only', and clarifies that it does not perform any financial settlement or attest to external facts. This helps the agent understand side effects and trust boundaries without contradicting 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?

The description is two sentences, front-loaded with the core action, and each sentence adds distinct value: the first defines the deliverable and purpose, the second clarifies non-behaviors. No wasted words.

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 tool's moderate complexity (a nested parameter with many fields) and the presence of a rich input schema, the description sufficiently covers the tool's purpose and constraints. The output schema is present, so the description need not explain return values. Some might argue it could mention prerequisites or when not to use it, but the existing text is adequate for a safe, read-only draft generator.

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?

The description does not explain the single 'receipt' parameter, but the input schema itself provides detailed field-level descriptions (e.g., 'SHA-256 hash of the tool result'). Since the schema does the heavy lifting, the description adds only the high-level context that the receipt is hash-only, which is already implied by the field names. The baseline of 3 is appropriate.

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 tool's action ('Generate') and the specific resource (an unsigned, hash-only paid MCP/API tool receipt draft). It also distinguishes the tool from related siblings by noting it produces a draft for inclusion in a signed bundle and explicitly contrasts with tools that charge, redeem, or attest.

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 context for when to use it ('callers can include in a signed ProofRelay bundle') and implicitly lists non-uses ('does not charge, redeem, settle, or attest to external facts'). It does not explicitly name alternative sibling tools, but the 'does not' phrasing provides clear exclusions, which is strong guidance.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context by specifying what the read operation reveals: 'accepted bundle shape' and 'trust boundary,' which go beyond a generic read operation. No contradiction with 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?

The description is a single sentence front-loaded with the action verb 'Read,' followed by a clear usage directive. Every word earns its place, with no redundancy or 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 simple no-parameter read tool with an output schema, the description thoroughly covers purpose and usage. It mentions key output concepts ('status, shape, trust boundary') and the broader workflow context, leaving no significant 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?

The tool has zero parameters, so baseline is 4. The description provides context about the scope of the read operation (status, shape, boundary) but no parameter details are needed since the schema is empty.

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 uses the specific verb 'Read' and identifies the resource as 'ProofRelay verifier status, accepted bundle shape, and trust boundary,' which clearly distinguishes it from sibling verification tools by positioning it as a pre-submission check. The scope is explicit and unambiguous.

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 explicitly states 'Use this first' and 'before submitting evidence,' providing a clear when-to-use directive. It does not explicitly name alternatives or exclusions, but the context strongly implies it is the preliminary step in the evidence submission workflow.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the low side-effect bar is met. The description adds transparency by emphasizing 'unsigned', 'draft', and the non-certification disclaimer, which clarifies the tool's output is a preliminary artifact, not a finalized credential. No contradiction with 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?

Two short sentences deliver the core purpose and an important disclaimer. Every word adds value, and the structure front-loads the main action.

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 rich input schema, output schema, and annotations, the description is reasonably complete for understanding what the tool does. It includes enough context about badge types and non-certification scope, though it could have added a pointer to alternative tools for stronger sibling differentiation.

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 0%, and the description does not compensate for this. It names badge types, which maps to the badge_type enum, but it does not explain required hashes (subject_hash, criteria_hash) or the single 'badge' parameter. The schema itself has property descriptions, but the dimension requires the tool description to compensate when coverage is low.

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 uses a specific verb ('Build') and resource ('unsigned ProofRelay evidence-conformance badge draft'), and lists concrete badge types (PREP-compatible, Verified Bundle, Verified MCP, Replay Tested). This clearly distinguishes it from sibling tools like build_bundle_draft or build_registry_entry.

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 gives clear context: this tool creates an evidence-conformance badge draft. It also notes what the badge is not (legal, security, model-safety, or platform certification), which is a useful exclusion. However, it does not explicitly mention when to use this tool over sibling build_* tools or provide alternative tool names.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the key behavioral nuance 'without satisfying lender conditions,' which is not captured by annotations and clarifies the tool's side-effect-free nature. This exceeds the baseline but could be richer.

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 a single, focused sentence that front-loads the main action and includes all essential elements without redundancy. It is appropriately concise for the tool's complexity.

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?

With annotations and an output schema present, the description sufficiently covers the tool's core transformation and explicitly states the non-goal. The phrase 'portable condition profile' is somewhat vague but acceptable given the schema's existence.

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 0% and the description only loosely references 'text, evidence, reviewer, and waiver hashes,' omitting the actual parameter name 'condition' and required fields like condition_id, condition_type, and condition_hash. The schema provides detailed per-property descriptions, but the description itself fails to compensate for the coverage 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 uses a specific verb 'Map' with clear inputs (lender condition text, evidence, reviewer, waiver hashes) and output (portable condition profile), distinguishing it from sibling mapping tools like map_openapi_operation_evidence. It precisely conveys the tool's scope and non-goal.

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 for creating a portable profile from lender condition hashes but provides no explicit when-to-use or alternatives. It does not contrast with sibling tools like adapt_agent_identity_evidence or wrap_mcp_tool_evidence, leaving the choice context-dependent.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context by mentioning the creation of an event plan with checkpoint recommendations, but does not go beyond annotations to describe side effects or output details. This aligns with the calibration where annotations carry the safety burden and the description adds moderate value.

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 a single, front-loaded sentence covering the key action and target operations without redundancy. It earns every word and is easy to scan.

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 presence of an output schema and comprehensive annotations, the description adequately covers the purpose and scope. It does not fully elaborate on when to use this versus sibling tools, but the complexity is moderate and the description is sufficient for a well-annotated tool.

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?

The top-level 'operation' parameter has no description (schema coverage 0%), but its nested object includes detailed descriptions for all fields. The tool description does not compensate for the missing parameter-level description, instead relying on the schema's field documentation. This meets the baseline for schemas with high effective coverage, but no additional semantic value is provided.

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 tool's function: it maps public OpenAPI operation metadata and schema hashes into a ProofRelay event plan with checkpoint recommendations. This is specific and distinguishes it from sibling tools like map_lender_condition_evidence, which handles lender-specific evidence.

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 context by specifying it operates on 'public OpenAPI operation metadata' and targets operations that are 'paid, mutating, or relied-upon.' It does not explicitly mention alternatives or exclusions, but the context is clear enough for selection among sibling mapping tools.

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?

Annotations already convey read-only, idempotent, and non-destructive behavior. The description adds valuable context beyond annotations by explicitly stating it does not charge, settle, custody funds, or verify external payment finality, clarifying its scope and non-interactions with payment systems. No contradictions with 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?

The description is two concise sentences, front-loaded with the main purpose and followed by a clear non-goals list. Every sentence adds value 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?

For a validation/normalization tool with a rich schema and output schema present, the description adequately covers the tool's purpose and non-behaviors, but does not explain the structure of the evidence profile or any prerequisites beyond the input. It is slightly sparse on what constitutes a valid proof envelope, though the schema fills that 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?

The description provides almost no parameter-level semantics, mentioning only that it validates proof hashes. With schema description coverage at 0%, the description fails to compensate, leaving the agent to rely entirely on the nested schema. It does not name any of the required hash fields or clarify the envelope structure.

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's function: validating rail-agnostic payment/entitlement proof hashes and returning a ProofRelay payment_context evidence profile. The verb 'validate' plus the specific resource distinguishes it from siblings like proofrelay.adapt_x402_payment_proof, which are rail-specific adapters.

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 gives some implicit usage guidance by describing the tool as 'rail-agnostic,' implying it is the generic normalization path compared to provider-specific adapters. It also states exclusions (does not charge, settle, custody funds, or verify finality), but does not explicitly name alternatives or conditions for when to use this tool over other ProofRelay tools.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description adds valuable context by explicitly noting no token redemption or paid endpoint calls. This goes beyond the annotations by clarifying the side-effect-free nature of the 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?

The description is two concise sentences with the main purpose front-loaded and the safety property added immediately. Every phrase earns its place with no 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 rich input schema (which documents all parameter fields), the output schema, and the clear annotations, the description is largely complete. It explains the core function and safety characteristics, though it could elaborate on what a 'replay rejection test plan' entails, but the schema and output schema likely cover that.

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 0%, and the description provides no direct information about parameters like redeem_url, bundle_hash, or payment_protocol. It only hints at the observed field through 'classify observed first/replay responses', which is insufficient compensation for the low 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 clearly states the tool returns a deterministic replay rejection test plan and optionally classifies observed responses. This is a specific verb+resource combination that distinguishes it from sibling tools like verify_bundle or generate_paid_tool_receipt.

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 for planning replay rejection tests without executing paid operations, stating 'does not redeem tokens or call paid endpoints'. This gives clear context that it is a safe planning tool, though it does not explicitly name alternatives or exclusion criteria.

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 annotations already declaring read-only, idempotent, and non-destructive behavior, the description adds value by disclosing that the tool returns 'reason codes without protected routing internals' and only considers 'public-safe' checkpoints. This gives the agent useful expectations about output and constraints.

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 two sentences long, front-loaded with the action, and contains no filler. Every clause adds either purpose, scope, or behavioral context, making it appropriately sized and easy to parse.

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?

While the description covers purpose, input constraint, and output nature, it lacks guidance on how to populate the complex workflow_context object (with many fields) and does not mention relationships to sibling tools like normalization or readiness checkers. The presence of an output schema reduces the burden for return-value explanation, but the input complexity is not adequately addressed.

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?

The schema coverage for the single parameter is 0%, and the description only says 'Submit normalized context only' without explaining what fields the workflow_context object needs or what 'normalized' means. Since there is only one parameter, the description should compensate for the schema's lack of a top-level description, but it does not.

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 tool's verb ('Choose') and resource ('next public-safe GENESIS checkpoint'), and specifies the workflow categories it applies to ('paid, material, or relied-upon'). This specificity distinguishes it from sibling tools like compute_readiness_signal or verify_bundle, which have different purposes.

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 clear context for when to use the tool: 'for a paid, material, or relied-upon agent workflow'. It also hints at prerequisite input ('Submit normalized context only'), but does not explicitly name alternatives or state when not to use it, so it lacks exclusion guidance.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context beyond annotations: it only uses hashes and declared boundaries, and it is not a certification. No contradiction with 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?

The description is two sentences with no filler. It front-loads the action and scope, then adds a necessary limitation. Every sentence earns its place.

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?

The description covers scope, method, and limitations, and the output schema exists, so return-value details are not required. A minor gap is that 'governance signals' is not defined, but overall the tool is sufficiently contextualized for an agent.

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?

The description adds a high-level semantic ('using hashes and declared boundaries only') that frames the parameters, but it does not map to individual nested fields. The input schema's property descriptions carry much of the parameter meaning, and the top-level schema coverage is 0%, so the description only partially compensates.

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 states a specific verb ('Review'), resource ('public vendor or MCP server risk metadata'), and method ('using hashes and declared boundaries only'). This distinguishes it from sibling tools like scan_mcp_risk by emphasizing a metadata-only, hash-based review rather than a live scan.

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 clearly indicates when to use the tool (for governance signals from public vendor risk metadata) and explicitly states what it is not for (legal, security, or procurement certification). However, it does not name alternative sibling tools for excluded use cases, so it stops short of full alternatives guidance.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable context by specifying 'hash-only' and 'without approving funds movement', which clarifies the non-mutating nature and scope. No contradiction with 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?

The description is a single, front-loaded sentence that efficiently conveys the tool's purpose and key constraint. No wasted words.

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?

The description, together with the annotations and output schema, provides sufficient context for an agent to understand the tool's role and safety profile. The main gap is parameter clarification, but the nested schema partially covers the fields. The description adequately positions the tool within its domain.

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?

The top-level parameter wire_change has no description in the schema (0% coverage). The tool description does not explain the parameter or its fields, merely mentioning the general subject matter (wire/payoff/disbursement metadata). The nested schema fields have descriptions, but the description does not compensate for the missing top-level parameter semantics.

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 tool reviews hash-only wire, payoff, or disbursement change metadata for red flags and controls, and explicitly distinguishes it by noting it does not approve funds movement. This differentiates it from potential 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?

The description implies use when reviewing change metadata for red flags, and explicitly excludes approval of funds movement. However, it does not name alternative tools or provide explicit when-to-use/when-not-to-use scenarios beyond the approval exclusion.

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?

Annotations already mark readOnlyHint and idempotentHint; the description adds meaningful constraints beyond that: no network fetching, no auth, no system mutation, no source code inspection, and no vulnerability certification. This gives the agent a clear behavioral profile beyond structured metadata.

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 tightly packed sentences front-load the purpose and immediately follow with usage boundaries. Every clause adds value, with no repetition of schema content or 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?

The description covers what the tool returns, the input sources, when to use it, and explicit non-behaviors. Combined with the output schema and read-only/idempotent annotations, no significant context is missing for a lightweight metadata scanner.

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 for the single parameter is 0%, but the description orients inputs as 'tool descriptors, schemas, and registry claims.' It does not enumerate or explain individual fields like declared_read_only or requires_authentication beyond what the nested schema already provides, so it only partially compensates for the coverage 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 uses a specific verb ('Return') and names the exact resource ('read-only, public-metadata MCP risk score') and data sources ('tool descriptors, schemas, and registry claims'). This clearly distinguishes it from sibling risk/review tools by scoping to MCP metadata scanning.

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?

Explicitly states when to use: 'Use before listing, integrating, or wrapping another MCP server.' It also provides exclusion boundaries ('does not fetch network data, require auth, mutate systems, inspect source code, or certify vulnerability status') that signal when this tool is insufficient, though it does not name a specific 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds 'without ingesting raw logs or traces', which clarifies that the tool operates purely on summary data rather than raw content. This is valuable behavior insight beyond the annotations, though no additional details on auth or side effects are provided.

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 a single, well-structured sentence that front-loads the core functionality and includes a key constraint ('without ingesting raw logs'). Every word earns its place, with no redundant or filler content.

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 annotations, output schema, and nested field descriptions, the description sufficiently covers the tool's purpose and key behavioral constraints. It omits explicit usage guidance and parameter details, but the overall context for a read-only, idempotent summarization tool is adequately complete.

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 0% for the top-level 'action_log' parameter, and the tool description does not compensate by explaining the parameter structure beyond generic 'counts and hashes'. While the nested schema fields have individual descriptions, the agent must infer that these fields correspond to the summary data. The description adds little semantic value for parameter usage.

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 tool summarizes 'public-safe agent action log counts and hashes' into a 'governance review profile', giving a specific verb, resource, and outcome. This distinguishes it from sibling tools like build/adapt/verify, none of which mention summarizing agent action logs in this manner.

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 'public-safe' and 'without ingesting raw logs or traces' provides clear context for when to use this tool (when you only have hashes/counts, not raw logs). While it doesn't explicitly name alternatives or exclusions, the context is specific enough to guide selection among the listed siblings.

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?

Even with readOnlyHint and idempotentHint annotations, the description adds valuable context by explicitly stating the tool does not charge, settle, mutate storage, or certify external facts. It also highlights that only non-confidential bundles are accepted, which is a meaningful behavioral constraint for an agent.

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 two sentences: the first states the core purpose and scope, the second clarifies non-effects. Every clause adds information, and it is front-loaded with the verb and resource. No wasted words.

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?

The description covers the main verification dimensions and non-effects but omits guidance on V2-specific behavior, such as when caller-supplied public_keys are needed or how require_chain/require_signature affect verification. With an output schema present and rich input schema, a 3 is appropriate – the tool is understandable but not fully complete for an agent to handle all invocation scenarios confidently.

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 0% for the four top-level parameters. The description mentions 'signatures' and 'chain continuity', which loosely map to require_signature and require_chain, but it does not explain how to use public_keys or what require_chain/require_signature actually control. For an agent to invoke the tool correctly, it would need to infer behavior from the bare parameter names.

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 uses a specific verb ('Verify'), identifies the resource ('ProofRelay V1 or V2 evidence bundle'), and enumerates the exact checks performed: hash integrity, monotonic ordering, signatures, and chain continuity. This clearly distinguishes it from siblings like 'verify_signed_attestation' and 'get_verifier_status'.

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 clearly implies when to use the tool: whenever a submitted evidence bundle requires verification. It does not explicitly name alternatives or exclusions, but the scope is unambiguous given the title and specific verification checks.

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?

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds that the tool 'never accepts private keys' and 'does not sign caller claims', which are meaningful behavioral disclosures beyond the annotations and directly relevant to safe invocation.

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 two sentences, front-loaded with the core action and resource, and every clause adds value. The second sentence adds an important safety constraint without 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?

Given the rich nested schema with field descriptions and the output schema, this description covers the essential purpose, version scope, key material, optional pins, and security constraints. It does not detail version-to-key mapping, but the schema's nested descriptions and the concise nature of the tool make this acceptable.

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?

The tool description does not name individual parameters, but it does mention 'public key material' and 'optional issuer/purpose pins', which map to the schema's public_jwk/public_key_hex and expected_issuer/expected_purpose fields. The top-level parameter has 0% schema description coverage, but the nested schema provides detailed descriptions. The description gives a high-level semantic map but does not clarify which key type maps to which artifact version.

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 uses the specific verb 'Verify' and identifies the exact resource: 'legacy Ed25519 or V2 ES256 ProofRelay artifact'. It clearly distinguishes this from signing/issuing tools and from the sibling 'verify_bundle' by focusing on individual signed attestations.

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 clearly states the verification context, the required public key material, and optional issuer/purpose pins. It also excludes private keys as inputs. While it does not explicitly mention an alternative tool like 'verify_bundle', it gives clear context for when this tool applies.

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?

The annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, and destructiveHint=false. The description adds valuable context by reaffirming that the tool does not ingest raw prompts, outputs, credentials, or logs, which reinforces the safe, side-effect-free nature. It is consistent with the annotations with no 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?

The description is a single, well-structured sentence that front-loads the core action and includes the key privacy constraint without unnecessary elaboration. It earns its place and is highly scannable.

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 detailed input schema and available output schema, the description does not need to explain return values. It sufficiently covers the purpose, privacy constraints, and the portable wrapper concept. It lacks explicit alternative guidance but is otherwise complete for an agent to select and invoke the tool correctly.

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?

The tool description bridges the gap left by 0% schema description coverage by explaining that inputs are hash-only references to request, response, schema, authority, and payment context. This maps directly to the schema fields (e.g., request_hash, response_hash) and clarifies that no raw data is passed, adding meaning beyond the property names.

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 tool's function with a specific verb ('Convert') and resource ('hash-only MCP tool request, response, schema, authority, and payment context references into a portable ProofRelay evidence wrapper'). It also differentiates by emphasizing it does not ingest raw prompts, outputs, credentials, or logs, distinguishing it from sibling tools that might handle raw data.

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 the tool is appropriate for hash-only evidence wrapping and explicitly notes it avoids raw data ingestion, providing clear usage context. However, it does not explicitly name alternative tools or provide when-not-to-use exclusions, so it falls just short of a perfect score.

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