GENESIS ProofRelay MCP Verifier

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

Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that it maps to a 'hash-only PREP-3 input' and accepts identity as evidence without issuing identity, which provides relevant behavioral context 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?

Two succinct sentences with no wasted words. The first sentence states the action and output, the second clarifies the scope. Action is front-loaded, making it easy for an agent to quickly grasp.

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 has output schema (true) and detailed property descriptions in the schema, the tool description provides sufficient high-level context. It mentions input types and output format but could briefly explain the mapping process or constraints. Still, it is fairly complete for a mapping 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 tool description does not describe the single parameter 'identity', but the input schema itself provides detailed descriptions for each property of AgentIdentityEvidenceInput. Since schema coverage is 0%, the description does not add parameter meaning, but the schema compensates fully. A baseline 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 the verb 'map' and the resource 'identity references' (Concordium, ERC-8004, etc.) into a 'hash-only PREP-3 input', distinguishing it from identity issuance. The name 'adapt_agent_identity_evidence' aligns well, and the purpose is unambiguous even among diverse 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 explains what the tool does and what it does not do ('does not issue identity or certify people'), giving implicit guidance. However, it does not explicitly contrast with sibling mapping tools like 'map_lender_condition_evidence' or 'map_openapi_operation_evidence', so an agent might not know when to choose this one over 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=true, idempotentHint=true, destructiveHint=false. The description adds that it 'maps' data, which is consistent with read-only behavior, but does not provide additional behavioral details beyond what annotations convey.

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?

Description is a single sentence that front-loads the key action and scope. It is concise with no filler, though it could be restructured slightly for 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?

Given the complexity of x402 payment proof and the availability of a full input schema and output schema, the description provides enough context about what the tool does. It does not need to explain return values since an output schema exists.

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% because the tool description does not describe parameters. The schema itself has detailed descriptions for each property, but the description fails to compensate for the low coverage by adding meaning 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?

Description clearly states the tool maps x402 lifecycle hashes into ProofRelay's payment_context evidence profile. It specifies the verb 'map' and the resource 'hashes', and is distinct from siblings like 'normalize_payment_proof' by focusing on x402-specific inputs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. While the purpose is clear, the description does not mention when not to use it or suggest any alternative tools from the sibling list.

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 value by disclosing that the tool does not upload private files or logs, and that it is hash-only, providing 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?

The description is a single clear sentence that is front-loaded with the core purpose. Every word adds value, with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description explains the key constraint (hash-only, no uploads) and purpose well. An output schema exists, so return values are not needed. Could mention that the result is a manifest object, but overall it is sufficiently complete for a read-only, idempotent 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%, so the description must compensate. However, it only summarizes the parameter categories (bundle, verifier, policy, evidence hashes) without adding detail or explaining how to use parameters like pack_id or control_refs. This is insufficient for a parameter-rich input 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 'portable hash-only audit pack manifest'. It distinguishes this tool from siblings by specifying it uses only hashes and does not upload private files or logs, which is a unique differentiator.

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 cases where only hashes are needed and no upload is desired, but it does not explicitly state when to use this tool versus alternatives like 'build_bundle_draft' or 'build_closing_proof_pack'. There is no direct comparison to 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, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds that the server does not sign or certify facts, which is a useful behavioral note. However, it does not disclose other potential traits like auth requirements or rate limits, so the additional value is limited.

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 with two sentences, no fluff, and the key purpose is front-loaded. Every word adds value and avoids 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?

Despite having an output schema and many siblings, the description is minimal. It does not explain what a bundle draft is, how it relates to other tools, or constraints beyond being unsigned. For a complex tool with rich input, more context is needed for an agent to use it effectively.

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 describe any parameters; it has 0% schema description coverage. Although the input schema itself contains detailed descriptions for each property, the tool description fails to add meaning beyond what the schema already provides. Given the low coverage, the description should have compensated, 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 builds a canonical, unsigned, non-attesting ProofRelay bundle draft from public-safe event hashes. The verb 'Build' and the resource 'unsigned ProofRelay bundle draft' are specific, and the non-attesting aspect differentiates it from siblings that involve signing or attestation.

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 is for creating bundles without signatures, but it does not mention when to choose it over sibling tools like verify_bundle or build_audit_pack_manifest. The agent must infer usage context without direct comparison.

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, destructiveHint=false, and idempotentHint=true, so the tool is safe and idempotent. The description adds context that it builds a manifest (hash-only) and does not authorize, which aligns with annotations and adds some behavioral clarity.

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 focused sentences: the first defines the core action, the second clarifies a critical limitation. No redundant words, and every sentence adds value.

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 multiple optional parameters and an output schema (indicated by context). The description, together with annotations and schema, is mostly complete. It provides the key detail about not authorizing, which is relevant for a closing process. Slightly lacks explanation of default behavior when optional hashes are omitted.

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?

Despite schema description coverage being reported as 0%, the actual input schema includes detailed descriptions for each parameter (e.g., 'Optional notary event hash.'). The tool description lists the types of hashes accepted but does not add significant meaning beyond the schema's own descriptions. 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?

The description clearly states the tool's purpose: building a hash-only closing proof pack manifest from specific types of hashes (settlement, title, lender, etc.). This is a specific verb+resource combination that distinguishes it from sibling tools like 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 only includes a negative usage hint ('does not authorize closing or disbursement') but lacks explicit guidance on when to use this tool versus alternatives or prerequisites. No context for appropriate invocation.

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 indicate read-only, idempotent, and non-destructive behavior. The description adds critical context by clarifying that the tool does not create approval authority or certify identity, which aligns with readOnlyHint and prevents misinterpretation. It could further detail output structure, but output schema exists to cover that.

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, each adding value. It front-loads the core purpose and immediately clarifies limitations. No redundant or 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?

Given the complexity of the input schema and the availability of an output schema, the description omits usage guidelines and parameter semantics. It does not fully equip the agent to confidently select and invoke the tool without additional lookup. For a tool with 10 sub-parameters, more contextual hints are expected.

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 zero parameter-level information despite having a complex input object with 10 sub-parameters. Schema description coverage is 0%, so the description fails to add any meaning beyond the input schema. The agent must rely solely on the schema's property descriptions, which are present but not reinforced by the tool description.

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 an unsigned, hash-only human approval receipt draft for authority, policy, and subject evidence. It uses a specific verb 'build', a distinct resource, and adds differentiating context (draft, no certification of identity), making its purpose unambiguous among 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 does not specify when to use this tool versus alternatives like build_bundle_draft or build_registry_entry. It lacks explicit guidance on conditions, prerequisites, or exclusion criteria, leaving the agent without direction on appropriate usage.

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 and destructiveHint=false. The description adds that it is 'public-safe' and uses only hashes and profile markers, providing some behavioral context. However, it does not elaborate on input validation or output behavior beyond schema.

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 (25 words) that front-loads the key action and subject. Every word contributes to clarity with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complex input schema with many optional fields and the presence of an output schema (which likely describes the return), the description provides sufficient high-level context. However, it could briefly explain what a 'registry entry draft' represents to aid agent understanding.

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 detailed descriptions for all properties (high coverage). The description adds the insight that parameters are hashes and profile markers, which is already inferred from schema. Hence, description adds marginal 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 verb 'Build' and resource 'ProofRelay Registry entry draft', specifying the subject categories (agent, API, MCP server, workflow, adapter) and the nature of content (hashes and profile markers). This distinguishes it from siblings like build_bundle_draft which target 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 for creating a registry entry draft but does not provide explicit guidance on when to use this tool versus alternatives (e.g., build_bundle_draft). No when-not-to-use or prerequisite 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 mark the tool as read-only and idempotent. The description adds useful behavioral context by stating it does not certify title status or legal sufficiency, and emphasizes the hash-only nature, going 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 two sentences, front-loaded with the core action and inputs, followed by a clarifying limitation. No unnecessary words, every sentence adds value.

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 existence of an output schema and the tool's relatively straightforward purpose, the description covers the essential inputs and behavioral caveats completely. No gaps remain.

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 fully describes each parameter with individual descriptions. The tool description only lists general sources but does not add new meaning beyond the schema. Schema coverage is complete, 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?

The description clearly states the tool builds a hash-only title production evidence profile from specific hashes (order, property, etc.) and explicitly distinguishes what it does NOT do (certify title status or legal sufficiency), differentiating 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 implies usage for building hash-only profiles but provides no explicit guidance on when to use this tool versus alternatives (e.g., other build tools) 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 context by stating the tool is 'public-safe' and explicitly does not certify readiness, which aligns with annotations and adds value beyond them.

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 concise sentences, front-loaded with the tool's purpose and a key constraint. No unnecessary words, every sentence adds value.

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 output schema and annotations, the description is fairly complete for a read-only computation. It specifies inputs and what it does not do. However, it lacks details on output format or when to prefer this tool over siblings, given the complexity of multiple hash inputs.

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 parameter descriptions in the schema are minimal (e.g., 'Wire review hash.'). The tool description lists some field types (title, closing, wire, etc.) but does not explain their semantics, usage, or how they map to the input object. Description fails to compensate for the low schema coverage.

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

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

Description clearly states it computes a readiness signal from hashes/counts, and explicitly notes it does not certify readiness to close or fund, which distinguishes it from potential certification tools. However, it doesn't fully differentiate from siblings like 'proofrelay.recommend_checkpoint' that may also compute signals.

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 given, but the description implies it's for computing a public-safe signal without certification. Sibling tool names suggest others handle proofs and verifications, so usage is somewhat implied but not clearly stated.

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. The description adds context about being public-safe and not requiring package installation, but this is modest additional 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 one concise sentence that front-loads the purpose with no wasted words or 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?

For a read-only informational tool with an output schema, the description covers the key aspects (setup guidance, no secrets) though it could explain the structure of the returned guidance slightly more.

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 elaborate on the single 'helper' parameter beyond what the schema already provides (client enum, endpoint default). Schema descriptions already exist, so the description adds no extra meaning.

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 and preparing hash-only evidence inputs, which is specific and distinct from sibling tools focused on building evidence or verification.

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 safe initial setup ('public-safe', 'without exposing secrets') but does not explicitly state when not to use or name alternative tools for other 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, destructiveHint=false, and the description adds no new behavioral traits beyond stating what is returned. It doesn't describe side effects or limitations, but annotations cover safety. Bar is lowered for 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?

Single sentence, front-loaded with the core action and resource, no wasted words. Appropriate for a simple read-only query.

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 zero parameters and an output schema (not shown), the description is complete: it explains the purpose and what is included. The output schema likely defines the structure, so no further details needed.

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, so schema coverage is trivially 100%. Description adds meaning by detailing the content of the returned workflow (token, status, etc.), compensating for lack of parameters.

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 returns a specific workflow (Stripe checkout entitlement) for ProofRelay paid verification, listing included elements (token, status, redemption, replay). This is specific and distinguishes from sibling tools like describe_cli_sdk_helper.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied: use when you need to understand the Stripe entitlement flow. No explicit when-to-use or alternatives are provided, but the context of sibling tools suggests uniqueness. Lacks explicit guidance on when not to use.

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 critical context: the receipt is unsigned, hash-only, and the tool does not charge, redeem, settle, or attest to external facts. This goes beyond annotations to clarify operational boundaries.

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-loading the core action and then clarifying exclusions. Every word serves a purpose with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description provides the tool's purpose, its role in a bundle, and constraints. An output schema exists, so explaining return values is unnecessary. However, it could offer more detail on when exactly to use this receipt draft versus other receipt types, though the sibling list and annotations partially 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?

The description does not address the single 'receipt' parameter or its sub-fields. While the schema provides descriptions for each property, the tool description adds no additional meaning or usage guidance for inputs, which is a gap given the 0% parameter description 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 'generate', the resource 'paid MCP/API tool receipt draft', and adds specificity with 'unsigned, hash-only' and what it does not do (charge, redeem, settle, attest). This distinguishes it from sibling tools like build_bundle_draft or verify_signed_attestation.

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 receipt draft is meant to be included in a signed ProofRelay bundle, providing context for its use. It also explicitly states what the tool does not do, which helps avoid misuse. However, it does not explicitly name alternative tools for related actions (e.g., charging or attesting), leaving room for improvement.

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, fully covering safety and idempotency. The description adds context about the specific data returned (status, bundle shape, trust boundary), which is useful but not beyond what annotations already provide. Score 3 reflects adequate transparency with minor added 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 that are front-loaded with the action. The first sentence states what the tool does, 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?

An output schema exists (not shown but indicated), so the description need not explain return values. The description fully covers purpose and usage timing. With no parameters and output schema provided, it is 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?

The input schema has no parameters (0 required, 0 optional), so parameter semantics are not applicable. Baseline for 0 parameters is 4. The description does not need to add parameter information.

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 explicitly states the tool reads the ProofRelay verifier status, accepted bundle shape, and trust boundary. The verb 'Read' clearly indicates a retrieval action, and the resource is specifically the verifier status, distinguishing it from sibling tools that focus on building 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 advises using this tool as a first step before submitting evidence to understand what ProofRelay verifies. This provides clear context for when to use it. However, it does not explicitly mention when not to use it or list alternatives, so a 4 is appropriate.

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, indicating a safe, non-destructive, idempotent operation. The description adds that the badge is unsigned and a draft, and clarifies it is not a certification. This adds 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, consisting of two well-structured sentences. The first sentence delivers the core action and examples, and the second sentence adds clarifying limitations. 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?

While the description covers the purpose and some limitations, it is incomplete for operational context. It does not mention the return value (draft badge object), workflow steps (e.g., use before signing), or how to interpret the output. Given the tool's moderate complexity (many optional parameters), more contextual information would help an agent use 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?

The tool description does not describe any of the parameters. With 0% schema description coverage in the description, it fails to add meaning beyond the input schema. The input schema itself has descriptions, but the description does not help the agent understand parameter usage, constraints, or relationships, which is a significant 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 the tool's purpose: to build an unsigned ProofRelay evidence-conformance badge draft, listing example badge types (PREP-compatible, Verified Bundle, Verified MCP, Replay Tested). It also explicitly states what it is not (not legal, security, model-safety, or platform certification), which further clarifies its scope and distinguishes it from sibling tools like verify_bundle 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 provides some implicit context (building an unsigned draft vs. other operations), but it does not explicitly state when to use this tool versus alternatives like verify_bundle or build_registry_entry. There is no mention of prerequisites, typical workflow steps, or exclusionary conditions, leaving the agent without clear guidance on appropriate usage.

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 clear. The description adds value by explicitly stating the tool does not satisfy lender conditions, which is critical behavioral context beyond what annotations provide. 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, well-structured sentence that conveys the core operation efficiently. Every word serves a purpose, with no fluff or repetition. It is concise yet informative.

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 (single parameter, clear annotations, and existence of an output schema), the description covers the essential behavior. It could elaborate on what a 'portable condition profile' entails, but the overall completeness is high for a mapping tool with rich schema and annotation support.

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 provides detailed descriptions for each property (e.g., 'condition_id', 'condition_hash') with clear labels and notes. The tool description mentions the items being mapped (text, evidence, reviewer, waiver hashes) but does not add further semantic detail beyond what the schema already conveys. With high schema coverage, a baseline 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 uses a specific verb ("map") and identifies the resource ("lender condition evidence") clearly. It distinguishes itself from siblings like 'map_openapi_operation_evidence' by specifying it handles lender condition text, evidence, reviewer, and waiver hashes, and explicitly states it operates 'without satisfying lender conditions,' adding a unique behavioral trait.

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 lacks any guidance on when to use this tool versus alternatives. It does not provide context, prerequisites, or exclusions. The agent must infer usage solely from the name and purpose, which is minimal.

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 safe read, idempotent, non-destructive behavior. The description adds value by describing the transformation (mapping into event plan) but does not elaborate on side effects or constraints beyond what annotations imply.

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?

A single, front-loaded sentence that efficiently conveys the tool's purpose without extraneous words. Every part of the sentence contributes to understanding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with a single complex input and an output schema, the description adequately explains the output (event plan with recommendations) and the target operations. It could be more comprehensive, but given annotations and schema, it is 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 description does not mention the input parameter 'operation' or its properties. Although the schema has detailed descriptions, the tool description fails to add meaning beyond the schema, and given 0% schema description coverage, it should compensate.

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 maps OpenAPI operation metadata into a ProofRelay event plan with checkpoint recommendations, specifying the target operations (paid, mutating, relied-upon). This distinguishes it from siblings that handle other aspects like identity evidence, payment proofs, or risk scans.

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?

Description explicitly states the tool is for 'paid, mutating, or relied-upon API operations,' providing clear context on when to use it. It does not mention when not to use or suggest alternatives, but the scope 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds important context by confirming it only validates and returns a profile, and explicitly denies any destructive or financial actions. 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 sentences, each serving a distinct purpose: first states what the tool does, second clarifies what it doesn't do. No redundancy or 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?

Despite having an output schema (which mitigates the need to describe return values), the tool has a complex input parameter with many fields, and the description fails to provide guidance on how to construct the input. The context signals indicate high complexity, yet the description remains minimal, leaving significant gaps 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?

With 0% schema description coverage, the description should compensate by explaining the input parameter's structure. It only mentions 'payment or entitlement proof hashes' at a high level, but does not describe the individual fields within the complex 'payment_proof' object, leaving the agent without necessary detail to correctly populate the 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?

Description states 'validate rail-agnostic payment or entitlement proof hashes and return the ProofRelay payment_context evidence profile', which clearly identifies the verb (validate, return) and resource (hashes, evidence profile). The name 'normalize_payment_proof' and sibling names like 'adapt_x402_payment_proof' indicate distinct operations, with this tool focusing on validation and normalization.

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?

Description explicitly states what the tool does not do: 'does not charge, settle, custody funds, or verify external payment finality'. This clarifies its role as a validation step, not a payment execution tool. However, it does not explicitly mention when to use this tool over siblings like 'adapt_x402_payment_proof' or 'build_bundle_draft', 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=true and destructiveHint=false. The description adds that it does not redeem tokens or call paid endpoints, which reinforces safety but does not significantly extend 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: first defines purpose, second adds a critical behavioral note. No redundancy, front-loaded, and 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 the presence of an output schema and annotations, the description covers the core functionality and safety. It lacks details on output format but that is provided by the output schema.

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

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

Schema description coverage is 0% at the top level; the description provides no additional meaning for the single 'replay_test' parameter, relying entirely on the nested schema definitions which have descriptions.

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, which directly aligns with the tool name and distinguishes 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?

No guidance on when to use this tool versus siblings; it only mentions what the tool does not do (redeem tokens or call paid endpoints), but no explicit when-to-use or when-not-to-use 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 provide readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds value by stating the tool does not expose internal routing and returns reason codes, and that input must be normalized. This adds 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: first establishes purpose, second adds usage constraint and return value. No unnecessary words. Front-loaded with key information. Highly concise and structured.

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 purpose, input requirement (normalized context), and output (reason codes). An output schema exists (not shown but referenced), which helps completeness. It does not detail error cases, but for a simple recommendation tool, this is 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 single parameter 'workflow_context' is a nested object with property descriptions in the schema, providing rich semantics. The description adds the requirement that context be 'normalized', which is meaningful for correct use. Though schema coverage is reported 0% (likely an error in context signals), the property-level descriptions in the schema are substantial.

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: 'Choose the next public-safe GENESIS checkpoint for a paid, material, or relied-upon agent workflow.' It specifies the verb (recommend), resource (checkpoint), and context (public-safe, workflow type), and is distinct from sibling tools focused on adaptation, building, or verification.

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 guides submission ('Submit normalized context only') and clarifies return behavior ('returns reason codes without protected routing internals'). It implies usage for workflows needing a checkpoint recommendation, but lacks explicit when-not-to-use or alternatives. Still clear enough for an agent.

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, indicating a safe, read-only operation. The description adds that the tool uses hashes and declared boundaries, which aligns with annotations. No contradictions, but the description does not add substantial behavioral context 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 consists of two concise sentences. The first states the core purpose, and the second clarifies a boundary (what it is not). Every word earns its place, and it is front-loaded with the key 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 presence of an output schema and comprehensive annotations, the description does not need to explain return values or side effects. However, for a tool with many parameters and a complex input schema, the description is too minimal—it does not explain what governance signals are or how to interpret the results. Adequate but incomplete.

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

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

The schema descriptions for parameters (e.g., vendor_name, data_boundary) are present and clear, providing baseline meaning. The tool description adds context about 'hashes and declared boundaries', hinting at the importance of hash parameters and the data_boundary field. However, with 0% schema description coverage in the tool description, the added value is marginal, leading to a middle score.

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 reviews vendor/MCP server risk metadata using hashes and declared boundaries, and explicitly distinguishes itself from legal/security/procurement certification. However, it does not differentiate from the sibling tool 'scan_mcp_risk', which likely has a similar purpose.

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 over alternatives. It only states what it is not (certification), but does not provide conditions, prerequisites, or comparisons to siblings like 'scan_mcp_risk'.

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 context that the tool reviews 'hash-only' data and does not approve funds movement, which is consistent and adds value 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 sentence of 15 words, front-loaded with the action, and contains no extraneous information. Every word is necessary.

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 input schema and the presence of an output schema (which description need not explain), the description covers the essential context: what is reviewed and the limitation (no approval). Some details like 'required controls' are implied but 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 describe parameters, but the input schema provides thorough descriptions for each field. With schema coverage effectively high (via nested object), a baseline of 3 is appropriate; the description adds no additional meaning.

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 (review), the resource (hash-only wire/payoff/disbursement change metadata), and the purpose (for red flags and controls). It also differentiates by explicitly stating 'without approving funds movement', which distinguishes it from similar 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 for reviewing without approving, but does not provide explicit when-to-use or when-not-to-use guidance compared to sibling tools. It lacks exclusions or 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 reinforces these and adds context that the tool does not fetch network data, require authentication, mutate systems, inspect source code, or certify vulnerabilities. This goes beyond the annotations by clarifying the scope of analysis.

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 immediately states the core functionality, followed by concise exclusions. No redundant information; every word adds value.

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 low-complexity tool with one nested parameter and an output schema, the description is complete. It explains the input source, the nature of the output (risk score), and boundaries. The output schema further clarifies return 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 tool description does not explain the parameters; only the schema provides descriptions for each field. With 0% schema description coverage (the tool description lacks parameter details), the description should compensate, but the schema itself is clear. The parameter names and schema descriptions are self-explanatory, so the tool remains usable.

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 title and description clearly state the tool returns a read-only MCP risk score from tool descriptors, schemas, and registry claims. It specifies the exact action (scan risk) and the resource (MCP metadata), distinguishing it from sibling tools that focus on adaptation, payment, or evidence building.

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 recommends using the tool 'before listing, integrating, or wrapping another MCP server.' It also lists exclusions (does not fetch network data, require auth, mutate systems, inspect source code, or certify vulnerability status), providing clear guidance on when to use this tool 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=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context beyond that: it explains that the tool operates on hashes and counts rather than raw logs, and that it produces a 'governance review profile.' This clarifies the tool's execution model and security posture (public-safe). No contradictions with annotations exist.

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 immediately states the core action and outcome. It is front-loaded and contains no extraneous words. Every part of the sentence adds value: verb, resource, scope, and a clarifying constraint. It is efficiently structured for quick comprehension.

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 (single object input with many fields) and the presence of an output schema, the description provides a high-level purpose but does not explain how to construct the input object or when a 'governance review profile' is needed. An agent might need more context about the expected usage flow. The schema and output schema likely carry part of the burden, but the description itself is minimal.

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 property-level descriptions (e.g., 'SHA-256 hash of the action log'), providing good parameter semantics independently. The tool description adds no additional parameter meaning beyond the high-level mention of 'counts and hashes.' With schema description coverage effectively high (despite the 0% signal, the schema itself is well-described), a baseline 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 the tool's purpose: 'Summarize public-safe agent action log counts and hashes into a governance review profile.' It uses a specific verb 'summarize' and identifies the resource 'agent action log' with a clear outcome. The caveat 'without ingesting raw logs or traces' further refines the scope. While sibling tools are not directly differentiated, the unique focus on summarization and governance review sets it apart from the myriad build/verify/scan 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 no guidance on when to use this tool versus alternatives. It does not state prerequisites, contexts where it is appropriate, or when to avoid it. There is no mention of sibling tools or exclusion criteria. The single sentence only defines what it does, leaving agents without decision support for selection.

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 the tool as read-only, idempotent, and non-destructive. The description adds valuable behavioral context beyond annotations by stating it does not charge, settle, mutate storage, or certify external facts, which clarifies side effects 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 extremely concise, consisting of only two sentences. The first sentence front-loads the core action and resource, and the second sentence clarifies behavioral aspects. No unnecessary words or 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 tool's complexity (nested objects, output schema present, annotations provided), the description covers key aspects: what is verified, non-confidential nature, and side-effect guarantees. It lacks explicit error handling or preconditions, but is largely complete for a verification tool with good schema and annotations.

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 describe any parameters. Although the input schema itself has rich descriptions for properties, the description fails to compensate for the low coverage, providing no additional meaning about the bundle, require_chain, or require_signature parameters 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 action 'Verify' and the specific resource 'non-confidential ProofRelay evidence bundle', listing the aspects verified (hash integrity, receipt ordering, signatures, chain continuity). This distinguishes it from sibling tools that build, adapt, or issue, providing a clear purpose.

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 specify when to use this tool versus alternatives. While the purpose is clear, there is no guidance on when not to use it or comparison with similar sibling tools like proofrelay.verify_signed_attestation. Usage context is implied but not stated.

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), and destructiveHint (false). The description adds valuable behavioral context: 'never accepts private keys and does not sign caller claims,' which is not covered by annotations and is crucial for security. 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 two sentences: first defines the core action and scope, second clarifies what the tool does not do. Front-loaded, no 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?

Given the presence of an output schema and annotations, the description covers the main purpose, verification method, and key behavioral constraints. It does not detail error conditions or preconditions, but for a verification tool with good structured data, it is sufficiently 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?

The input schema provides descriptions for each parameter (e.g., public_key_hex, expected_issuer), so schema_description_coverage is high. The tool description mentions 'using a public key and optional issuer/purpose pins,' which summarizes key parameters but adds no new meaning beyond the schema. 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?

The description clearly states the verb 'verify' and the resource 'signed ProofRelay artifact' (e.g., badge or proof envelope). It specifies the use of a public key and optional issuer/purpose pins, and explicitly distinguishes what it does not do (never accepts private keys, does not sign claims). Among sibling tools, this is unique to verification of 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 implies usage for verifying signed attestations with public keys and optional pins, but does not explicitly state when to use this tool versus alternatives like verify_bundle. It provides no exclusion criteria or comparison with 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. The description adds the key behavioral trait that no raw prompts, outputs, credentials, or logs are ingested, which is a valuable privacy guarantee not captured by annotations. It does not contradict 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 of 30 words that efficiently conveys the tool's core purpose and key constraint. Every element is meaningful, with no redundancy or filler. It is well front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (one top-level parameter but ten nested properties) and the existence of an output schema, the description adequately covers the essential purpose and privacy aspect. It could mention the output format or that it creates a wrapper, but the output schema handles return values. The description is sufficiently complete for an experienced user.

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 no information about the parameters themselves. Although the input schema includes detailed descriptions for each property, the tool description has 0% coverage of parameters and does not add meaning beyond what the schema provides. Given the low coverage, the description should compensate but fails to do so.

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 specifies the action ('Convert'), the resource ('hash-only MCP tool request, response, schema, authority, and payment context references'), and the result ('portable ProofRelay evidence wrapper'). It also distinguishes from siblings by emphasizing that no raw data is ingested, uniquely positioning this tool among the many evidence-related 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 you have hashes and want to wrap them), but it lacks explicit guidance on when not to use it or how it compares to alternatives like proofrelay.build_bundle_draft or proofrelay.build_title_production_evidence. The 'without ingesting raw' clause hints at a constraint but not at exclusion conditions.

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