GENESIS ProofRelay MCP Verifier

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

Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds context that the tool transforms rather than creates or certifies, which is consistent and adds marginal 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?

Two sentences, no wasted words. First sentence front-loads the action and scope, second sentence clarifies a boundary condition. Extremely efficient.

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 rich annotations and an output schema, the description provides enough context about the tool's role. It could mention validation or required fields, but overall complete for a read-only transformation 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?

Schema_description_coverage is 0% (parameter-level description missing), but the schema itself describes each field. The description explains the high-level purpose of the identity parameter, but does not detail individual fields. Adds some meaning beyond 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 maps identity references from multiple sources (Concordium, DID, etc.) into a hash-only PREP-3 input. It distinguishes from siblings by clarifying that ProofRelay does not issue or certify identity, which is a unique scope among 25 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 (when mapping identity references for PREP-3 input) and what it does not do (issue/certify), but does not explicitly name alternatives or provide exclusion criteria for when not to use it.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds context about the specific input hashes but does not disclose additional behavioral traits such as output format or constraints beyond what annotations provide.

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 that directly states the tool's function. While concise, it could be slightly more structured (e.g., listing components), but it effectively communicates the core 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 complexity of the input (multiple hashes) and the presence of annotations and output schema, the description provides adequate context but lacks details on lifecycle prerequisites or business logic. It is minimally sufficient.

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 input schema has detailed descriptions for each property, achieving high coverage. The tool description does not add new parameter semantics, maintaining the baseline without improvement.

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' and clearly identifies the resource (x402 lifecycle hashes) and target (ProofRelay's payment_context evidence profile). It distinguishes from siblings like 'adapt_agent_identity_evidence' by focusing on x402 payment proof specific hashes.

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 explicit guidance on when to use this tool versus alternatives. The description implies usage when x402 lifecycle hashes are available but does not provide exclusions or compare with sibling 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 mark readOnlyHint=true and idempotentHint=true. The description adds value by noting 'hash-only' and 'without uploading private files or logs', which is helpful privacy context. However, it doesn't describe behavior beyond these points, so it's adequate but not exceptional given annotation support.

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?

Single sentence that front-loads the action and key constraint. Every word serves a purpose, no repetition or fluff. Excellent conciseness for the information conveyed.

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 schema providing safety/profile details, the description covers the main use case. Presence of an output schema reduces need to describe returns. Slight gap: could mention that the manifest is built locally and only hashes are used, which is implied but not explicit.

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 main description, but the input schema itself contains detailed descriptions for each property (e.g., 'SHA-256 hash of audit subject', 'Optional audit pack id.'). The description adds nothing beyond the schema, so baseline 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?

Description clearly states 'Build a portable hash-only audit pack manifest from bundle, verifier, policy, and evidence hashes' with the specific constraint 'without uploading private files or logs'. This precisely identifies the tool's purpose and distinguishes it from siblings that may involve uploading or different artifacts.

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 (creating a manifest without uploading private data) but does not explicitly state when to use this tool over siblings like 'build_bundle_draft' or 'build_closing_proof_pack'. No when-not-to-use or alternative recommendations are provided.

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 readOnlyHint=true, but the description adds critical behavioral context: 'The public MCP server does not sign or certify caller-provided facts.' This discloses an important limitation beyond what annotations provide, though it does not cover all behavioral aspects.

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, clear, and front-loaded with the core action. Every word adds value with no redundancy or irrelevant details.

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?

Despite the presence of an output schema, the description fails to cover the input requirements. The tool is complex with nested parameter objects, yet the description provides no explanation of how to structure the `draft` input. This leaves a significant gap in completeness.

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?

With 0% schema description coverage, the description provides no information about parameters. The input schema has a complex nested object (`BundleDraftInput`), yet the description offers no guidance on its fields or structure, forcing reliance solely on 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 builds a 'canonical, unsigned, non-attesting ProofRelay bundle draft' from public-safe event hashes. It distinguishes from sibling tools like verify_bundle or build_closing_proof_pack by emphasizing the draft is unsigned and non-attesting, making the purpose 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 implies usage for building unsigned drafts from public-safe inputs, but it does not explicitly state when to use this tool over alternatives (e.g., for signed bundles). No 'when-not' or exclusions are provided, leaving some ambiguity.

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, destructiveHint. The description adds context that it operates on hashes only and does not authorize, which is valuable beyond annotations. 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?

Two sentences, front-loaded with the main action, no wasted words. Efficient and clear.

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, the description need not explain return values. It covers the tool's purpose and its non-authorization nature, but lacks guidance on when to prefer this over sibling tools like build_audit_pack_manifest.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description lists the types of hashes used, but the input schema already provides descriptions for each parameter. The tool description adds minimal additional meaning beyond summarizing that these are 'hash-only'.

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 builds a hash-only closing proof pack manifest from seven types of hashes, and explicitly clarifies it does not authorize closing or disbursement. This distinguishes it from authorization-related tools among 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 when to use (to build a manifest) and when not (for authorization), but does not explicitly name alternative tools for authorization or other manifest building.

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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, indicating safe, non-mutating behavior. The description adds that the receipt is 'unsigned' and 'hash-only', and explicitly states it does not create approval authority or certify the approver's identity. This provides useful behavioral context beyond the annotations without 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 extremely concise: two sentences that immediately convey the tool's purpose and a key limitation. Every sentence adds value, and the structure front-loads the core function. No unnecessary words 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?

Given the tool has a complex nested input schema with many parameters, the description is somewhat minimal. It does not mention the output format or that the tool returns a receipt draft object, but since an output schema exists, the burden is lower. Still, for an agent to fully understand the tool's role in the workflow, additional context (e.g., 'returns a document that can later be signed') would be helpful. Score 3 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?

Schema description coverage is 0% in the description text, but the input schema itself contains detailed descriptions for all parameters (e.g., 'SHA-256 hash of approver identity'). According to guidelines, when schema coverage is high, baseline is 3. The description adds no additional parameter information, so a score 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 it builds an unsigned, hash-only human approval receipt draft for authority, policy, and subject evidence. It uses a specific verb ('build') and resource ('human approval receipt draft'), and the qualifiers 'unsigned, hash-only' distinguish it from similar tools like proofrelay.build_bundle_draft or proofrelay.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 does not provide guidance on when to use this tool versus alternatives. It only states what it does and what it does not do (e.g., does not create approval authority), but lacks explicit context for usage, prerequisites, or exclusions. No sibling tools or conditions are mentioned.

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 tool is clearly non-mutating. The description adds minor context ('public-safe', 'using only hashes') but does not clarify whether the draft is returned directly, stored, or if it verifies any constraints. With annotations covering the safety profile, the description is adequate but not improved.

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-loads the core purpose, and contains no filler. Every word adds essential meaning—verb, resource, constraints, and the types of subjects. It is optimally concise for an AI agent.

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 has an output schema (avoiding need to describe return values) and the description covers the key functional intent, it is mostly complete. Missing is a note that the draft is generated in-memory and not persisted, but this is partially covered by annotations. The sibling tool set is large but the description is specific enough to avoid confusion.

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 input schema has rich property descriptions for all fields. The description adds high-level semantic context ('using only hashes and profile markers') that helps the agent understand permissible data types and intent. Since schema coverage is effectively high (descriptions on each field), the description's added value is moderate but useful.

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 ('ProofRelay Registry entry draft'), with explicit constraints: 'public-safe', 'using only hashes and profile markers'. It clearly distinguishes the tool from siblings like build_bundle_draft or build_audit_pack_manifest by specifying the exact type of draft and its allowed content.

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 prerequisites, exclusions, or preferred contexts. With over 20 sibling tools, explicit usage direction is missing, leaving the agent to infer from the tool name and purpose alone.

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 non-destructive. The description adds valuable context by stating it does not certify title status or legal sufficiency, which are important behavioral traits beyond what annotations cover.

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 followed by a clarifying sentence, with no redundant information. Every part adds value: the main action and a key 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?

With an output schema present, the description doesn't need to explain return values. However, given the tool's complexity (one parameter with many subfields) and numerous sibling tools, the description lacks guidance on when to use this tool and what output to expect. It is minimally complete but could be more helpful.

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 only lists the types of hashes (order, property, title-search, etc.) but does not add meaning beyond the input schema's field descriptions. With 0% schema description coverage, the description should compensate but fails to explain parameter roles, formats, or constraints.

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 builds a hash-only title production evidence profile from specified hashes, and explicitly clarifies what it does not do (certify title status or legal sufficiency). This distinguishes it from sibling tools like build_audit_pack_manifest or build_bundle_draft.

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 does not explicitly provide when to use this tool versus alternatives. It only implies usage through the scope (hash-only, no certification). Given 26 sibling tools, more explicit guidance would be beneficial.

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, so the description adds useful context like 'public-safe' and non-certification. However, it does not detail further behavior such as error handling or response format.

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 sentences: the first states the action and inputs, the second clarifies a limitation. No unnecessary words, front-loaded with core purpose.

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 tool has an output schema, so return values need not be described. The description adequately covers the tool's purpose and boundaries, making it complete for agent 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?

With 0% schema description coverage, the description lists the input categories (title, closing, wire, etc.), which maps to the schema fields. But it does not explain each parameter's meaning or constraints beyond the field names, leaving some ambiguity.

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 computes a readiness signal from specified input categories, and explicitly states what it does not do (certify readiness), distinguishing it from any potential certification 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 on when to use the tool (for computing a public-safe signal) and what it should not be used for (certification). No explicit alternatives are named, but the boundary is well-defined.

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 provide readOnlyHint, idempotentHint, destructiveHint. The description adds context that the output is 'public-safe' and 'without exposing secrets or requiring package installation,' which goes beyond annotations. No contradictions.

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 conveys the core purpose without unnecessary words. It is appropriately sized for the tool's simplicity.

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 output schema exists and annotations cover safety, the description is mostly complete for a simple read-only tool. However, it lacks any mention of the input parameter structure (client family and endpoint), which is essential for correct usage.

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 tool description does not explain the 'helper' parameter or its sub-properties ('client', 'endpoint'). The description fails to add meaning beyond the input schema, leaving agents unaware of how to configure the output.

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 returns 'public-safe setup guidance for connecting MCP clients to ProofRelay and preparing hash-only evidence inputs,' which is a specific verb and resource. It distinguishes from siblings focused on building proofs or adapting 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 for obtaining setup guidance, but does not explicitly state when to use this tool versus alternatives like build_bundle_draft or adapt_agent_identity_evidence. No exclusion criteria or alternative tool references are given.

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, destructiveHint. Description adds value by detailing the content of the return (workflow with token, status, etc.). No contradictions.

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?

Single, clear sentence with no unnecessary words. Front-loaded with action and outcome.

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?

Has output schema (not shown) so description need not detail return structure, but it still gives a useful summary. For a simple describe tool with no parameters, this is fully 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?

No parameters exist, and schema coverage is 100%. Description adds no parameter info, which is acceptable as there is nothing to add. Baseline score for zero params.

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?

Description clearly states the tool returns the agent-native Stripe checkout entitlement workflow, specifying included elements (token, status, redemption, replay). This is a specific verb+resource that distinguishes it from sibling tools like verify_bundle or scan_mcp_risk.

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 explicit when-to-use or alternatives are mentioned. Usage is implied by the tool's nature as a describe/read operation, but an agent would benefit from knowing when to call this before 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 indicate readOnly, idempotent, and non-destructive behavior. The description adds value by clarifying it is unsigned, hash-only, and does not charge or attest, enhancing the agent's understanding beyond 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 sentences front-loading key information; every sentence adds value with 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?

An output schema exists, so return values are covered, but the description lacks context on the receipt draft's role in the bundling process and does not mention prerequisites.

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 0%, so the description should compensate, but it offers no details on the input parameters (e.g., tool_name, hashes). The single parameter 'receipt' is a nested object with many fields left unexplained.

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 generates an unsigned, hash-only receipt draft for paid tool calls, specifying the resource and action. However, it does not explicitly differentiate from sibling tools, which is acceptable given the variety.

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 explains that the draft is for inclusion in a signed ProofRelay bundle and lists what the tool does not do (charge, redeem, etc.), providing context but no explicit when-to-use versus alternatives.

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 value by naming the specific data read (status, bundle shape, trust boundary), providing more context than the annotations alone.

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 concise with two sentences. The first sentence states the action and the second provides usage guidance. No unnecessary 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 there are no parameters, an output schema exists, and annotations cover safety, the description is complete. It explains what the tool does, what it reads, and when 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?

There are no parameters, so the baseline is 4. The description does not need to add parameter semantics, and it correctly focuses on the tool's purpose.

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 reads the ProofRelay verifier status, accepted bundle shape, and trust boundary. It specifies the verb 'Read' and the resource, and distinguishes itself from siblings by noting it should be used before submitting 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 explicitly says 'Use this first when an agent needs to understand what ProofRelay verifies and what it does not.' This provides a clear usage context, but does not explicitly list alternatives or when not to use it.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds 'build unsigned badge draft', which could imply a side effect, but annotations clarify it is read-only. No contradiction, but description adds no additional behavioral context beyond 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 sentences, concise and front-loaded with purpose. However, the disclaimer about what it is not could be better integrated. Overall efficient with 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 complexity of the nested badge object and the presence of an output schema, the description is minimal but adequate. It covers the core purpose but could benefit from more detail on the badge structure or return value. Output schema presumably fills the 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 0%, meaning the tool description does not explain any parameters. The single 'badge' parameter is a complex object with many properties, but the description provides no guidance on how to populate it. Schema property descriptions exist, but the tool description fails to compensate for 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 verb 'Build' and the resource 'unsigned ProofRelay evidence-conformance badge draft', provides examples of badge types, and distinguishes what it is not (legal, security, etc.). This makes the purpose specific and differentiates 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 offers no explicit guidance on when to use this tool versus alternatives. While it lists badge types, it does not discuss context, prerequisites, or exclusions. The disclaimer about what it is not is minimal 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, non-destructive behavior. The description adds the key behavioral trait 'without satisfying lender conditions', clarifying the operation's scope. No contradictions with annotations. Additional context (e.g., auth needs, rate limits) is not required for this simple 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 a single, concise sentence (20 words) that front-loads the core purpose. It is appropriately sized with no redundant words, though a structured format (e.g., listing inputs/outputs) could enhance readability without much added length.

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 simplicity (1 parameter, read-only) and presence of an output schema, the description is adequate but minimal. It does not explain the mapping process or the contents of the condition profile. More context about the transformation could improve completeness.

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 explain or add meaning to the single 'condition' parameter. Despite the schema having property descriptions, the tool description fails to compensate for the lack of parameter descriptions at the top level.

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 action ('Map'), the input components ('lender condition text, evidence, reviewer, and waiver hashes'), and the output ('portable condition profile'). It also specifies 'without satisfying lender conditions', distinguishing it from tools that would satisfy conditions. This contrasts with sibling tool 'map_openapi_operation_evidence', which targets OpenAPI operations.

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 (mapping without satisfying) but does not explicitly state when not to use or name alternative tools for satisfying conditions. It provides clear context but lacks exclusions or explicit guidance on selection among 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows it's safe. The description adds that the tool produces an event plan with checkpoint recommendations, which is useful context. However, it does not disclose any potential limitations, side effects, or authorization needs beyond what annotations provide. With annotations carrying the safety profile, a score of 3 is appropriate.

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 that front-loads the action and resource. It is concise with no wasted words, but it could be slightly more structured (e.g., listing key details). It adequately conveys the purpose without being verbose.

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 complexity (one complex object parameter with many fields) and the existence of an output schema, the description provides enough context: the input is OpenAPI operation metadata, the output is an event plan with checkpoint recommendations. It does not mention prerequisites like requiring a valid OpenAPI spec, but the annotations and schema fill most gaps. Slightly more context on the input format would improve completeness.

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%, meaning the description does not explain parameters. However, the input schema itself has detailed descriptions for each property of the 'operation' object (e.g., method, operation_id, path_template). The description implies the parameter contains OpenAPI operation metadata but adds little beyond the schema's own documentation. Baseline 3 is appropriate since the schema carries the burden.

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 action 'Map', the resource 'public OpenAPI operation metadata and schema hashes', and the outcome 'into a ProofRelay event plan with checkpoint recommendations'. It also specifies the target operations ('paid, mutating, or relied-upon API operations'), which distinguishes it from sibling tools like proofrelay.map_lender_condition_evidence or proofrelay.wrap_mcp_tool_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 provides no explicit guidance on when to use this tool versus its siblings or alternatives. There is no mention of prerequisites, context, or exclusions. The agent would have to infer usage from the name and description alone without comparative 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 and idempotent behavior. The description adds valuable context about what the tool does not do, but doesn't detail error handling or validation failure outcomes.

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 consists of two concise sentences that front-load the primary action and follow with key caveats, with no extraneous 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?

The description covers core behavior and negative constraints. With an output schema available, return value explanation is unnecessary. However, it omits prerequisites or error scenarios, leaving minor 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 description provides a high-level purpose for the 'payment_proof' parameter but doesn't elaborate on its nested fields. With 0% schema coverage for the main parameter, the description partially compensates but could add more context about the expected 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 states 'Validate rail-agnostic payment or entitlement proof hashes and return the ProofRelay payment_context evidence profile,' specifying a distinct verb and resource. It also differentiates from siblings by clarifying it does not perform payment actions.

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 explicit negative guidance ('This does not charge, settle, custody funds, or verify external payment finality'), helping agents know when not to use it. However, it lacks explicit alternatives or conditions for when to use this tool over others.

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, destructiveHint=false. The description adds the important behavioral note that the tool does not redeem tokens or call paid endpoints, which goes beyond annotations by specifying the scope of operations.

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 very concise with two sentences. The first sentence front-loads the primary purpose, and the second adds a key behavioral constraint. No unnecessary words, making it efficient for an 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?

Given the tool's complexity (nested input schema for replay test classification) and the presence of an output schema, the description is adequate but leaves gaps. It doesn't explain what a 'replay rejection test plan' entails or how classification is performed, which could be clarified.

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 provides no additional meaning about the parameters beyond what is in the input schema. With schema description coverage at 0%, the description should compensate but does not. The schema itself has descriptions, but the tool description adds no value for parameter understanding.

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 responses. It distinguishes itself from sibling tools by explicitly noting it does not redeem tokens or call paid endpoints, which is relevant given the sibling tools that involve payment or redemption.

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 testing replay rejection but does not provide explicit guidance on when to use this tool versus alternatives. It mentions the tool does not redeem tokens, which hints at a use case where redemption is not needed, but no specific when/ when-not context is given.

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 the tool is read-only, idempotent, and non-destructive. The description adds value by stating that it returns reason codes without protected routing internals and that input must be normalized context, which aligns with and extends the behavioral 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 concise with two clear sentences. The first sentence states the core purpose, and the second provides a usage guideline. No extraneous information is included.

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 complexity (one parameter with many boolean fields) and the presence of an output schema, the description covers the essential context: purpose, input requirement (normalized context), and output (reason codes). It does not need to explain the input structure since the schema provides 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?

With 0% schema description coverage, the description only mentions 'Submit normalized context only,' which provides a high-level hint but does not explain the structure or fields of the workflow_context parameter. The schema itself contains detailed descriptions, but the tool description does not compensate for the lack of parameter documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: to recommend the next public-safe GENESIS checkpoint for paid, material, or relied-upon agent workflows. It uses a specific verb ('choose') and resource ('checkpoint'), and distinguishes it from sibling tools by focusing on recommendation rather than building, verifying, or adapting.

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 on when to use the tool (for paid, material, or relied-upon workflows) and a guideline to submit normalized context only. However, it does not explicitly mention when not to use this tool or suggest alternatives among the many sibling 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 and idempotentHint true, and destructiveHint false. The description adds that it uses hashes and declared boundaries and is not a certification, which are consistent and provide additional, non-contradictory context.

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 concise at three sentences and front-loaded with the main purpose. However, it could be more structured (e.g., separate lines for key info). No wasted sentences.

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 input schema with many optional fields, the description is minimal. It does not explain which parameters are expected or how they relate. Output schema existence reduces the need to explain return values. Annotations provide safety guarantees but not usage completeness.

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 mentions 'hashes and declared boundaries' which conceptually groups some parameters (e.g., vendor_profile_hash, data_boundary) but does not detail each parameter. The input schema already provides property descriptions, so the tool description adds minimal new semantics. 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?

The description clearly states the tool reviews vendor risk metadata using hashes and declared boundaries. It identifies the resource and action but does not explicitly distinguish from sibling tools like scan_mcp_risk.

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 alternatives. The only usage note is a disclaimer that it is not certification, but there is no context about prerequisites or appropriate scenarios.

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 that the tool does not approve funds movement, reinforcing the read-only nature and clarifying a key behavioral aspect beyond 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, front-loaded sentence of 18 words with no redundant information. Every part serves a purpose, and the structure makes the tool's action and constraints immediately clear.

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 complexity (one parameter as a nested object with many fields), the description adequately covers the main purpose and constraints. The presence of an output schema and detailed property descriptions in the schema ensure completeness, though the description does not detail output expectations.

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%, but the input schema includes detailed property descriptions (e.g., 'SHA-256 change request hash') that largely compensate. The tool description provides a high-level overview of the input category but does not enumerate or explain the specific parameters, adding limited 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 reviews hash-only wire, payoff, or disbursement change metadata for red flags and required controls without approving funds movement. It uses a specific verb and resource, and the phrase 'without approving funds movement' distinguishes it from approval 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 the tool should be used for review rather than approval, providing clear context for when to use it. However, it does not explicitly mention alternatives or when not to use it, so it lacks explicit exclusionary 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?

Adds context beyond annotations: clarifies it only uses public metadata, does not fetch network data, require auth, mutate systems, inspect source code, or certify vulnerability status. No contradiction with annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false).

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 core action, and each sentence adds value. No redundant or extraneous text.

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 (readOnly, idempotent), presence of an output schema, and the tool's narrow scope, the description is complete. It covers purpose, usage, and limitations sufficiently for an agent to use this 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?

Schema description coverage is 0%, so the description should compensate but does not. The single parameter 'risk_scan' is a complex object with 5 properties, all described in the schema, but the tool description only mentions input sources generically. It adds minimal 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 returns a read-only MCP risk score from tool descriptors, schemas, and registry claims. It specifies the purpose and distinguishes from siblings by stating what it does not do (fetch network data, require auth, mutate systems, inspect source code, certify vulnerabilities).

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 'Use before listing, integrating, or wrapping another MCP server' and lists actions it does not perform, providing clear when-to-use and when-not-to-use guidance. Though not naming specific sibling alternatives, the context implies other proofrelay tools for deeper analysis.

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, making the tool's safety profile clear. The description adds context that it processes only hashes and counts, not raw logs or traces, which is beyond the annotations. No contradictions.

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 with no redundancy. Every word adds value: 'public-safe', 'counts and hashes', 'governance review profile', and the important qualifier 'without ingesting raw logs or traces'.

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 complex input schema (nested object with many fields) and lack of parameter descriptions in the schema, the description is insufficient. It does not explain what a 'governance review profile' is, how the input fields should be used, or what the output contains. While an output schema exists, it is not described.

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%, but the description does not explain any parameters. It mentions 'action log counts and hashes' but does not describe the input object structure or required fields (e.g., log_hash, action_count). The agent has no guidance on how to populate the action_log parameter.

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. It specifies the input type (counts and hashes) and the output (governance review profile), and distinguishes itself by noting it does not ingest raw logs or traces. This is specific and actionable, but lacks explicit differentiation 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 usage when you have hashes and counts rather than raw logs, but it does not explicitly state when to use this tool versus alternatives. No alternative tools are named or compared, and there is no guidance on when not to use it.

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

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

The description adds value beyond annotations by confirming the tool does not charge, settle, mutate storage, or certify external facts. Annotations already mark it as read-only, idempotent, and non-destructive; the description reinforces and extends this with specific behavioral traits. 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 two sentences long with no wasted words. The first sentence states the core purpose and scope, and the second clarifies limitations. Every sentence adds essential 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 complex schema with nested objects and three parameters, the description provides a high-level understanding but omits details about optional parameters like require_chain and require_signature. Since an output schema exists, the description is minimally complete for selecting the tool, but additional context on optional parameters would improve usability.

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%, meaning the tool description does not explain the parameters (bundle, require_chain, require_signature) or their semantics. While the schema itself has descriptions, the tool description should compensate for low coverage but fails to do so, leaving the agent to infer param usage solely 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 the tool's purpose: verifying a non-confidential ProofRelay evidence bundle for hash integrity, receipt ordering, signatures, and chain continuity. It uses a specific verb-resource structure and distinguishes itself from siblings by explicitly stating it does not charge, settle, or certify, which separates it from other ProofRelay 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 on what the tool does and does not do, helping the agent decide when to use it (for verification without charging or storage mutation). However, it does not explicitly mention when not to use it or contrast with sibling tools like proofrelay.verify_signed_attestation.

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, non-destructive. Description adds valuable security context: it never accepts private keys and does not sign caller claims, which is critical for trust.

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 sentences, front-loaded with the main action, no extraneous text. 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?

Given the presence of an output schema (context says yes), the description covers the tool's purpose, constraints, and verification scope sufficiently for an agent to understand and invoke it 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?

Input schema properties have descriptions (100% coverage), so the description does not add substantially beyond noting 'public key and optional issuer/purpose pins'. Baseline 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?

Description clearly states it verifies an Ed25519 signed ProofRelay artifact, such as a badge or proof envelope. The verb 'Verify' and resource 'signed artifact' are specific, and the tool distinguishes from siblings like proofrelay.verify_bundle by focusing on 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?

No explicit guidance on when to use this tool versus alternatives. The description implies it's for verification of signed artifacts with optional pins, but does not mention when not to use it or refer to sibling 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. The description adds that the tool does not ingest raw prompts, outputs, credentials, or logs, which is consistent and clarifies its safe, read-only nature. This adds value beyond 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 with no redundancy. It front-loads the action ('Convert') and concisely lists inputs and constraints.

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 single parameter with many optional fields and an existing output schema, the description provides a high-level summary but omits mention of required fields (tool_name, request_hash, response_hash) or the output format. This is adequate but could be more 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?

With schema description coverage at 0% for the top-level parameter, the description should compensate. It lists core inputs (hashes) but does not explicitly map them to the tool_evidence parameter or explain its structure. The sub-property schema descriptions exist, so understanding is possible but not optimal.

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 specific action: convert hash-only MCP tool references into a portable evidence wrapper. It identifies the key inputs (request, response, schema, authority, payment context hashes) and explicitly states what it does NOT do (ingest raw data), distinguishing it from potential alternatives.

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 hash-only references exist but does not explicitly state when to use this tool versus siblings like normalize_payment_proof or adapt_agent_identity_evidence. No 'when not to use' guidance is provided.

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