GENESIS ProofRelay MCP Verifier

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

Annotations already declare readOnlyHint=true, openWorldHint=false, idempotentHint=true, destructiveHint=false. The text adds useful context: it accepts evidence without issuing identity or certifying people, which is not encoded in annotations. It does not expose hashing internals, failure modes, or normalization behavior, so not a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences provide the core semantics with modest structure. Some jargon ('PREP-3', 'hash-only') adds density; no fluff.

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

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

Rich context: nested input schema with enums (provider variants), annotation hints, output schema true, and many sibling tools for comparison. However, no return-value explanation, error/gql edge cases, and does not clearly describe the trust-proof procedure or output hash format; the output schema exists but the narrative doesn't fully synthesize the overall result.

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% and parameter descriptions are absent. The specification only enumerates the location of identity parameter objects; provider enum values provide top-level content, but nested fields (e.g. issuer, timestamps, hashes, register hash) have no semantic description; the documentation's 'identity' does not explain those particular fields. A fairly deep parameter 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?

States a specific verb+resource: "Map ... identity references into a hash-only PREP-3 input." It also indicates a behavioral boundary ('accepts identity as evidence; does not issue identity or certify people'). Some domain jargon ('PREP-3', 'hash-only') is not defined, and it doesn't explicitly distinguish itself from sibling tools, but the core action is clear.

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?

Notes that the tool accepts evidence and does not issue identity, which implies a read/transform role; however, it does not state when to prefer this over sibling tools, provide alternative conditions, or explicitly specify prerequisites for input identity formats.

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, so safety is covered. The description adds that the tool maps hashes into an 'evidence profile', implying a transformation, but it doesn't specify whether it computes anything, validates, or stores. No contradiction with annotations; no additional behavioral traits (e.g., side effects, required credentials) are disclosed.

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, which is efficient. It front-loads the action and lists the components. No wasted words, but it could benefit from a brief parameter-level clarification. It is structured acceptably for a concise description.

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 processes a complex nested object with many hashes, and there is an output schema. The description explains the high-level intent but not the semantics of each hash field, nor does it clarify how the output profile is used. Given the complexity, the description is adequate but lacks detail on field meanings and potential transformations.

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 explain the 'x402' object and its fields. It only mentions 'request, 402 challenge, payment payload, facilitator response, and resource response hashes', which correspond to some fields, but doesn't explain the meaning of 'payment_required_hash' (402 challenge), 'facilitator_hash', or optional fields like amount, network, currency, replay_key. Most fields remain ambiguously named in the schema and are not elaborated in the 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 states a specific verb ('Map') and resource (x402 payment proof components into 'payment_context evidence profile'), which clearly indicates the tool's function. It distinguishes from siblings like 'normalize_payment_proof' by focusing on mapping hashes into a specific evidence profile, though it doesn't explicitly contrast with 'normalize_payment_proof' or other mapping 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 an x402 payment flow's hashes need to be structured into ProofRelay's payment_context profile. It provides no explicit when-to-use or when-not-to-use guidance, and no alternatives are mentioned. Sibling names like 'normalize_payment_proof' could be alternative, but no comparison is made.

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 that it does not upload private files, complementing the readOnly hint.

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 concise sentence with relevant extra context.

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?

Missing explanations for many parameters and no mention of output.

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?

Only mentions bundle, verifier, and policy hashes, leaving other schema fields like pack_id, control_refs, generated_at, evidence_hashes 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?

Clearly states it builds a hash-only audit pack manifest, distinguishing it from other 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?

Implies usage for creating manifests but does not explicitly compare to 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 indicate readOnly, idempotent, and non-destructive behavior. The description adds that it 'does not sign or certify caller-provided facts' and only accepts 'public-safe event hashes', providing extra transparency about limitations and data handling 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 concise, consisting of two sentences that deliver the essential purpose and key behavioral constraint without unnecessary detail or verbosity.

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, the tool's input is a highly nested object with multiple required fields (service, created_ts_ms, events) and a complex payment_context. The description omits critical guidance on constructing the 'draft' parameter, making it insufficient for an agent to use correctly in real scenarios.

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 describes a single complex 'draft' parameter with many required and optional fields, but schema coverage in the description is 0%. The description only hints at 'public-safe event hashes' without explaining the object structure, required fields, or semantics of nested objects. Given low coverage, the description does not compensate adequately.

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 (build) and the resource (canonical, unsigned, non-attesting ProofRelay bundle draft), and specifies that it operates on 'public-safe event hashes'. This distinguishes it from sibling tools that verify, attest, or produce signed bundles.

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 a draft bundle is needed without signing or attestation, and mentions 'public-safe' inputs, which guides context. However, it does not explicitly contrast with alternative build tools or state when not to use it, 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 readOnly and idempotent hints, which are consistent with the description's 'hash-only' and non-authorizing nature. The description adds valuable context by explicitly stating the tool does not authorize closing or disbursement, which is a behavioral constraint not conveyed by annotations alone. It also clarifies that the tool works only with hashes, not actual documents, providing extra transparency beyond structured fields.

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, tightly packed. The first sentence identifies the purpose and scope, and the second provides a critical caveat about what the tool does not do. Every word earns its place, and there is no redundant or filler language.

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 object with multiple optional fields) and the presence of an output schema (which likely describes the returned manifest), the description covers the essential inputs and the tool's non-authorizing behavior. It lists all hash categories and explicitly says it is hash-only. Minor omissions include the format of hash values and the meaning of non_secret_refs, but these are partially addressed by the schema and do not severely hinder correct 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?

Though the schema description coverage is 0%, the description compensates by enumerating all the hash categories (settlement, title, lender, funding, notary, disbursement, approval) that correspond to the nested closing_pack fields. This gives semantic meaning beyond the bare schema definitions, though it doesn't explain non_secret_refs or the structure of closing_pack itself. Since the schema is rich and nested, the description's enumeration of hash types adds significant value.

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 a hash-only closing proof pack manifest from a specific set of hash categories (settlement, title, lender, funding, notary, disbursement, approval). It also explicitly notes what it does not do (authorize closing or disbursement), distinguishing it from potential 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 implies the tool is used when you need to assemble a closing proof pack from hashes, and it clarifies it does not authorize actions. However, it does not explicitly state when to use this tool versus alternatives like build_audit_pack_manifest or other build_* siblings, nor does it mention any prerequisites or exclusions beyond the authorization caveat.

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 discloses that the receipt is unsigned and hash-only, and explicitly states it does not create authority or certify identity, adding behavioral context beyond the readOnlyHint and idempotentHint annotations. It doesn't contradict any 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 concise with two informative sentences, front-loading the purpose and adding a clarifying limitation without waste.

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 nested approval object and output schema, the description covers the purpose and limitations but does not explain how to structure the approval parameter or what the output contains. It is somewhat incomplete for a complex tool, but adequate given the 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?

The description gives a high-level hint that the approval object contains authority, policy, and subject evidence, but does not explain the specific fields or their semantics. With 0% schema coverage, it partially compensates but lacks detail on the approval object 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 the tool builds an unsigned, hash-only human approval receipt draft, specifying the resource and scope. It also distinguishes itself from sibling tools by emphasizing it does not create approval authority or certify identity.

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

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

The description gives clear context that this tool only drafts an unsigned receipt and does not create approval authority or certify identity, providing negative use cases. However, it doesn't explicitly mention alternative tools or positive when-to-use 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?

Annotation contradiction. The description says 'Build a registry entry draft,' implying a create/write operation, but readOnlyHint: true is set, which asserts no state modification. No other behavioral side effects are disclosed (e.g., persistence status, hashing process, approval controls).

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?

One long but readable sentence. No padding, clear phrasing, aligned with the tool name and title. Could be slightly smaller by removing the entity list, but acceptable.

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 is complex: a single deeply-nested entry parameter, ~22 optional or conditional fields, no parameter descriptions, and no output schema documentation. The description covers the type of target at a high level but never mentions return formats, behavior on validation failure, ordering constraints, or related chain interactions.

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 coverage is 0%, and the nested 'entry' object with many fields/options is not explained. The description only says it accepts hashes/profile markers, but does not explain the per-field meanings (entry_type, subject_hash, profile markers, status, hash references, etc.).

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

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

States a clear action ('build') and object ('registry entry draft'), and enumerates acceptable entity types (agent, API server, MCP server, workflow, adapter). Does not explicitly contrast with sibling tools, but the name 'build_registry_entry' is specific enough to distinguish registry creation from audit/bundle/verification 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?

Gives an implicit constraint ('using only hashes and profile markers'), but no explicit when-to-use vs alternatives, no exclusions/alternatives, and no prerequisites or postconditions for creating a registry draft.

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

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

The description adds the information that it does not certify title status or legal sufficiency, which complements the annotations indicating read-only and idempotent behavior, though it does not detail all side effects.

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, concise and well-structured with no unnecessary information, clearly articulating the tool's core functionality and boundary.

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 lacks details on the output format, optional fields, and the meaning of production_status, making it incomplete for complex usage despite having an 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?

The description mentions the types of hashes but does not explain individual fields such as non_secret_refs or production_status, leaving ambiguity for some 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?

The description clearly states the tool builds a hash-only title production evidence profile from specific hash types (order, property, title-search, commitment, exception, tax-cert), providing a specific verb and resource.

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, lacking explicit usage guidance or conditions for 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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds value beyond these by clarifying that the output is 'public-safe' and explicitly stating it does not certify readiness, which provides additional behavioral context about the tool's limitations and output nature.

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 purpose, and includes a succinct caveat. There is no fluff, and every word adds value. It is appropriately concise for the tool's complexity.

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

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

Given the tool's complexity (a nested object with 10 properties and an output schema), the description is minimal. It covers the purpose and input categories but does not explain the nature of the computed 'readiness signal' (e.g., what it represents, its format, or how to interpret it). While the output schema exists, the description does not add enough context to make the tool fully self-contained.

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. It does list high-level categories (title, closing, wire, etc.) that map to the nested object fields, but it does not explain individual parameter meanings or the structure of the required 'readiness' object. It provides some context but not enough detail to fully understand each field without relying on names and types.

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 'Compute' and the resource 'a public-safe readiness signal', and lists the specific input categories (title, closing, wire, etc.). It also includes a scope limitation ('does not certify readiness to close or fund'), which helps differentiate it from potential certification tools. This is specific and not tautological.

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

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

The description provides a clear negative usage guideline by stating the tool does not certify readiness, which tells the agent when not to use it for certification. However, it does not explicitly name alternative tools for certification or provide a positive 'use when' scenario, so it lacks full alternative guidance.

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

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

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds important context by mentioning 'public-safe', 'without exposing secrets', and 'without requiring package installation', which are not captured by the annotations. This provides additional behavioral transparency about the output's constraints and safety.

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 is front-loaded with the main action ('Return public-safe setup guidance') and quickly conveys the scope and constraints. 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 simplicity (one parameter, no complex behavior), the description covers the essential purpose and key constraints. The annotations provide safety guarantees, and the output schema (if present) would handle return format specifics. The description is complete for an informational tool, though it could mention the parameter structure explicitly.

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

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

Schema description coverage is 0%, meaning the schema provides no explanations for the 'helper' object or its properties. The description does not mention the parameter at all, nor does it explain what 'client' or 'endpoint' mean. While the purpose gives some implicit clues, the description fails to compensate for the lack of schema documentation, leaving parameter semantics underspecified.

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: it returns setup guidance for connecting MCP clients to ProofRelay and preparing hash-only evidence inputs. The verb 'Return' specifies the output, and the resource is well-defined. It distinguishes itself from siblings that focus on building, verifying, or adapting evidence, making it a unique informational tool.

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

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

The description implies its usage context—when an agent needs setup guidance for connecting clients or preparing evidence inputs—and contrasts with the mutating/adapting tools. However, it does not explicitly state when to use it over alternatives or provide exclusions, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is established. The description adds that the tool returns workflow expectations including token, status, redemption, and replay, which provides semantic context beyond annotations. However, it does not disclose output format details, error behavior, or what 'agent-native' means operationally—leaving some behavioral traits implicit. 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 front-loads the core action and resource, then lists the key coverage areas. Every phrase earns its place: 'agent-native', 'Stripe checkout entitlement workflow', 'ProofRelay paid verification', and the four expectations. No redundancy or filler.

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

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

With zero parameters, a strong output schema, and comprehensive annotations, the description needs relatively little to complete the picture. It communicates the tool's purpose and scope effectively. The only minor gap is that it doesn't explicitly state the return value shape beyond the schema, but the presence of an output schema reduces that burden. This is complete enough for its complexity.

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

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

The tool has zero parameters, so the schema is trivial and covers 100% of the parameter space. Per the rubric, a zero-parameter tool gets a baseline of 4. The description correctly does not attempt to explain non-existent parameters. There is no additional semantic burden for the description here.

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

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

The description uses a specific verb ('Return') and identifies a clear resource ('agent-native Stripe checkout entitlement workflow for ProofRelay paid verification'). It also lists key content areas (token, status, redemption, replay expectations), making the tool's focus understandable. However, it does not explicitly distinguish the tool from siblings like proofrelay.normalize_payment_proof or proofrelay.describe_cli_sdk_helper, though the named resource is fairly distinct.

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 this tool is relevant—when an agent needs the Stripe checkout entitlement workflow for ProofRelay paid verification. It does not explicitly state when not to use it or name alternative tools among the siblings. Given the descriptive intent, the usage context is clear but lacks exclusion criteria or direct sibling differentiation.

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 value by specifying 'unsigned, hash-only' and explicitly listing actions it does not perform (charge, redeem, settle, attest). This gives a clearer picture of side effects beyond safety hints. No contradiction with annotations observed.

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—and the main action is stated in the first sentence. The second sentence adds necessary boundary conditions without redundancy. Every word earns its place, and the structure is front-loaded.

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

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

Despite having an output schema, the tool has a complex nested input object that remains completely unexplained. The description does not mention the structure or required fields of the receipt parameter, nor any workflow context. Given the moderate complexity and the 0% parameter coverage, the description is insufficiently complete for an agent to use the tool correctly.

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

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

The description provides zero explanation of the single 'receipt' parameter and its nested structure. Schema description coverage is 0%, and the description does not compensate by describing required fields like tool_name, ts_ms, or hashes. The agent receives no guidance on how to construct the receipt object, making parameter usage unclear.

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 generate an unsigned, hash-only paid MCP/API tool receipt draft for inclusion in a signed ProofRelay bundle. The verb 'generate' and specific resource 'receipt draft' are unambiguous, and the 'does not charge, redeem, settle, or attest to external facts' line distinguishes it from other receipt or payment tools in the sibling set.

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 a caller needs a receipt draft for a paid tool call to include in a ProofRelay bundle. It also clarifies limitations ('does not charge, redeem, settle'), which implicitly warns against using it for those actions. However, it does not explicitly name alternative tools or provide when-not-to-use conditions, so it falls short of a full 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds the context of being a prerequisite ('before submitting evidence') but does not describe additional side effects or error behavior. Since annotations cover the safety profile, the description provides minimal extra transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences, directly stating what the tool does and when to use it. No redundant or extraneous information is present.

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 no parameters and an output schema present, the description covers the essential context: what is read, when to use it, and its purpose as a first step. It is complete for a simple getter 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 has zero parameters, so the schema fully covers the parameter space. The description does not need to explain any parameters, and it does not introduce ambiguity. Perfect score for a no-parameter tool.

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 verifier status, accepted bundle shape, and trust boundary. It also explicitly says 'Use this first' to understand what ProofRelay verifies, distinguishing it from sibling tools that perform other 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 a clear when-to-use instruction ('Use this first when an agent needs to understand what ProofRelay verifies and what it does not'), but does not explicitly contrast with alternatives or mention when not to use it. The guidance is implicit and sufficient for most cases.

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, so the description doesn't need to repeat safety. It adds value by clarifying the badge is 'unsigned' and not a certification, which is important behavioral context 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?

The description is two sentences, front-loaded with the main purpose. The second sentence adds a useful disclaimer. No wasted words, though it could be slightly more structured with explicit parameter guidance.

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 nested schema (1 param with 10 subfields) and no output schema details, the description is somewhat thin. It doesn't explain what the draft badge contains, how hashes are computed, or what the output looks like. The output schema exists, so return values are covered, but the input semantics are under-specified.

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 names the badge types and mentions 'unsigned' and 'draft', which adds some meaning. However, it doesn't explain the required fields (subject_hash, criteria_hash) or optional fields like profile, issued_at, expires_at. The nested object structure is complex, and the description doesn't 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 builds an unsigned ProofRelay evidence-conformance badge draft and lists specific badge types (PREP-compatible, Verified Bundle, Verified MCP, Replay Tested). It distinguishes from siblings by focusing on 'draft' and 'unsigned' badges, though it doesn't explicitly contrast with build_bundle_draft or build_registry_entry.

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

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

The description implies usage for creating badge drafts but doesn't provide explicit when-to-use vs alternatives. It mentions what it is not (legal, security, model-safety, platform certification), which adds some context, but no direct comparison to sibling tools like build_bundle_draft or verify_bundle.

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, but the description adds the explicit note 'without satisfying lender conditions.' This clarifies that the tool does not alter condition fulfillment, which is important behavioral context beyond the annotations. The description does not contradict any annotation, and it provides a valuable additional constraint.

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 is concise and front-loaded with the action verb. It includes the core purpose and a key caveat without extraneous information. Every part is relevant 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?

The tool has a nested input object and an output schema (not shown), but the description does not explain the output 'portable condition profile' or any transformations. It explains the main behavior but omits details about hashing, output structure, or prerequisites. Given the complexity of the input schema and the presence of an output schema, the description is adequate but not thorough.

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 for parameter meaning. It mentions 'lender condition text, evidence, reviewer, and waiver hashes' which map to some fields like condition, evidence_hashes, reviewer_hash, and waiver_hash, but it does not explain the required fields condition_id, condition_type, condition_hash, nor optional fields like status, non_secret_refs. The description offers a high-level concept but insufficient detail for the agent to understand each parameter's role.

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 lender condition text, evidence, reviewer, and waiver hashes into a portable condition profile. The verb 'Map' and the resource 'lender condition evidence' are specific, and the caveat 'without satisfying lender conditions' distinguishes it from tools that would modify condition status. This is a clear purpose that differentiates from siblings like build_bundle_draft or verify_bundle.

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 a portable representation of condition evidence is needed without changing condition status, but it does not explicitly state when to use or not use this tool compared to alternatives. No alternative tools are referenced, and no exclusions are mentioned, so guidance is only implicit.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful context by framing the tool as mapping metadata rather than invoking operations, and by highlighting paid, mutating, or relied-upon operations. It does not contradict annotations and provides enough behavioral context beyond the structured hints.

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 with no filler. It states the action, the input, and the output efficiently, making it easy for an agent to parse quickly.

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 one nested parameter, an output schema, and annotations covering the safety profile, the description provides sufficient context for a mapping tool. It would benefit from explicit when-to-use guidance and a bit more parameter detail, but overall it is adequately complete.

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

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

Schema description coverage is 0%, so the description must compensate. It adds high-level meaning by referencing 'schema hashes' and 'paid, mutating, or relied-upon' categories, which align with fields like payment_required, idempotency_required, and method. However, it does not explain individual nested fields such as operation_id, path_template, server_url_hash, or security_scheme_refs.

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

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

The description uses a specific verb ('Map') with a clear object ('public OpenAPI operation metadata and schema hashes') and a distinct output ('ProofRelay event plan with checkpoint recommendations'). It differentiates from siblings like wrap_mcp_tool_evidence by naming the OpenAPI source and the event-plan output.

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 public OpenAPI operation metadata is available and checkpoint recommendations are needed, but it does not explicitly state when to choose this over alternatives like map_lender_condition_evidence or wrap_mcp_tool_evidence. No exclusions or alternative tool references 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, lowering the burden. The description adds valuable context beyond annotations by noting the tool is rail-agnostic and by clarifying that it does not charge, settle, custody funds, or verify external payment finality. It does not describe error handling, but annotations cover the safety profile well.

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 exactly two sentences, each providing essential information. The first states the purpose and output; the second enumerates explicit non-goals. There is no redundancy, fluff, or irrelevant detail.

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 rich annotations and an output schema, the description covers the key context: purpose, non-goals, and the resulting evidence profile type. However, given the complex nested input and zero parameter-level descriptions, a brief note on the structure or validation expectations would make it fully complete. Still, it is strong overall.

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

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

Schema description coverage is 0%, and the description does not compensate for the complex nested payment_proof object. It only refers to 'payment or entitlement proof hashes' without explaining the meanings of required fields like challenge_or_session_hash or payment_proof_or_charge_hash. The property names are somewhat self-explanatory, but for constructing valid input, an agent would need more guidance.

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

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

The description clearly states the tool's function: 'Validate rail-agnostic payment or entitlement proof hashes and return the ProofRelay payment_context evidence profile.' It uses specific verbs, names the resource, and explicitly lists non-goals ('does not charge, settle, custody funds, or verify external payment finality') to distinguish it from payment-execution 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 gives clear context for when to use the tool (validating proof hashes and producing an evidence profile) and explicit exclusions (not for charging, settlement, custody, or finality verification). However, it does not name alternative sibling tools for protocol-specific adaptation, so it lacks explicit alternative guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so a safe read is established. The description adds genuine, agent-critical value by explicitly stating 'does not redeem tokens or call paid endpoints' — a payment-domain behavior not captured in annotations. It also discloses determinism. No contradiction. A slightly deeper disclosure on the optional classification branch would merit a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, roughly 25 words, front-loaded with the primary action and ending with the most important safety qualifier. Every clause earns its place with zero redundancy or filler.

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

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

Given the nested ReplayObservation schema, the payment-protocol enum, and the output schema, the description covers the two critical non-obvious aspects: the plan/classify dual modality and the absence of paid side effects. The presence of an output schema means return-value documentation is not the description's job. Only the thin framing of the tool's role in the broader payment-proof workflow keeps this from a 5.

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

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

With 0% schema description coverage, the description must compensate. It usefully clarifies that 'observed first/replay responses' maps to the nested ReplayObservation (first_status/second_status/error pairs) and clarifies the plan-vs-classify dual mode. However, it leaves the semantics of redeem_url, bundle_hash, entitlement_hash, and payment_protocol entirely unexplained — an agent cannot determine what these identifiers represent or when the enum values apply.

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+resource construct ('Return a deterministic replay rejection test plan') with a clear secondary behavior ('optionally classify observed first/replay responses') plus a key qualifier ('does not redeem tokens or call paid endpoints'). It cleanly distinguishes itself from its 26 build/verify/describe siblings, none of which cover replay rejection planning.

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 context is only implied through the word 'plan' and the qualifier 'deterministic.' The no-side-effects statement hints that this is the safe, no-cost planning alternative, but no explicit when-to-use, when-not-to-use, or sibling alternatives are named. The agent must infer when this non-redeeming planner takes precedence over actionable payment 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?

The annotations (readOnlyHint=true, idempotentHint=true) already establish this is a safe read operation. The description adds meaningful behavioral context beyond this: 'returns reason codes without protected routing internals' clarifies the privacy boundary of the output, and 'public-safe' sets expectations about what the tool will filter for. 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, zero waste. The first sentence front-loads the core action and scope; the second covers the privacy model. Every word earns its place, covering what, when, and output characteristics in breakneck efficiency.

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 an output schema exists, explaining returns would be redundant, and the annotations already provide safety context. However, with 26 sibling tools—several of which (e.g., build_bundle_draft, verify_bundle) overlap thematically with checkpoint/evidence concepts—the description should clarify where 'GENESIS checkpoint' fits relative to those alternatives. The undefined domain term and missing ecosystem positioning keep this from being complete for a nested, zero-coverage parameter.

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 coverage and a nested workflow_context object containing 12+ undocumented fields, the description must compensate—but 'Submit normalized context only' is the sole hint about parameter semantics. While field names are self-descriptive (e.g., payment_context_present), the description neither explains normalization requirements, field semantics, nor constraints, leaving a significant documentation gap for such a rich 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 uses a specific verb-resource pairing ('Choose the next... GENESIS checkpoint') with strong scope qualifiers ('public-safe,' 'paid, material, or relied-upon agent workflow') that clearly delimit the tool's domain. It distinguishes itself from siblings by implying a classification/eligibility role rather than an action tool, though the term 'GENESIS' remains an undefined domain term.

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

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

The phrase 'for a paid, material, or relied-upon agent workflow' provides clear context for when to invoke the tool. 'Submit normalized context only' gives input guidance. However, no sibling alternatives are named and there is no explicit when-not-to-use guidance, which would have made this a 5 given the large sibling ecosystem.

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 discloses the tool's scope (public metadata, hashes, declared boundaries) and its non-certification limitation, aligning with the read-only and non-destructive annotations. It could be more explicit about the exact output format, but it is transparent about its intent.

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 (two sentences) and well-structured, conveying essential information without unnecessary detail. It avoids fluff and directly communicates the tool's purpose and limitations.

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 gives the tool's purpose and boundaries but does not specify the output structure, expected results, or any preconditions. While the core intent is clear, the lack of output context may leave the agent uncertain about what the tool actually returns.

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 elaborate on the 'vendor' object parameters or their significance. The schema contains many fields (e.g., requires_payment, data_boundary) but the description adds no additional meaning, leaving the agent to infer usage from field names alone.

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 that the tool reviews public vendor or MCP server risk metadata for governance signals, with explicit constraints on using hashes and declared boundaries. It differentiates itself from certification tasks, making its purpose specific and distinct 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 provides context on when to use the tool (for governance signals) and explicitly notes what it is not (legal, security, or procurement certification). However, it does not directly mention alternative tools or specific scenarios beyond the core review purpose.

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 transparency by noting 'hash-only' (limiting to hashes) and 'without approving funds movement,' which aligns with readOnly and complements the annotations. It does not contradict annotations and provides extra context about the nature of the review.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that packs essential information without fluff. It is well-structured and directly states the action and scope.

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 tool (an object parameter and likely analysis output), the description provides sufficient context for a user to understand the review's purpose and constraints. It implies what the review covers (red flags, required controls) but does not elaborate on return format, which is acceptable as 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?

The description adds some semantic context by mentioning 'wire, payoff, or disbursement change metadata,' which maps to the change_type field, and 'hash-only' clarifies the data format. However, it does not explain individual properties within the wire_change object, so the schema remains the primary source for parameter details.

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: reviewing hash-only wire, payoff, or disbursement change metadata for red flags and required controls. It distinguishes itself from sibling tools by focusing on wire/payoff changes and explicitly stating it does not approve funds movement.

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

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

The description implicitly guides usage by indicating it reviews changes and explicitly states 'without approving funds movement,' providing a clear when-not scenario. However, it does not explicitly mention alternatives or compare with sibling review tools, 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, and destructiveHint=false, and the description adds valuable context beyond those flags: it only uses public metadata, makes no network calls, requires no auth, mutates nothing, does not inspect source code, and does not certify vulnerabilities. These are concrete behavioral 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 entire description is one well-front-loaded sentence that states the output, the data sources, the use case, and the key exclusions. Every clause adds information and there is no filler.

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

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

Given the rich annotations and the presence of an output schema, the description covers the tool's role and limitations thoroughly. The main gap is that the nested risk_scan input object is not semantically described, and no alternative sibling tool is named for comparison, but the tool remains usable enough for an agent with the schema.

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

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

Schema coverage is 0% and the description does not explain the risk_scan parameter or its nested properties such as server_name, declared_read_only, requires_authentication, or payment_or_entitlement_required. The phrase 'from tool descriptors, schemas, and registry claims' hints at inputs, but it does not compensate for the undocumented nested object 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 the tool returns a read-only, public-metadata MCP risk score from tool descriptors, schemas, and registry claims. It uses a specific verb plus resource and defines the scope ('Use before listing, integrating, or wrapping another MCP server'), which separates it from the sibling build/wrap evidence 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 gives an explicit trigger: 'Use before listing, integrating, or wrapping another MCP server.' It also supplies when-not guidance by stating the tool does not fetch network data, require auth, mutate systems, inspect source code, or certify vulnerability status, so the agent knows its limitations.

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 barrier is low. The description adds valuable transparency by emphasizing it does not ingest raw logs or traces, which reassures the agent about privacy and scope. It does not contradict annotations, and the addition of 'public-safe' clarifies the security posture.

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-formed sentence that is front-loaded with the primary action and includes a crucial negative ('without ingesting raw logs or traces'). No wasted words; every clause adds meaning.

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 is relatively simple with one parameter and an output schema, and annotations cover safety aspects. The description is sufficient for basic usage, but given the nested object schema and the governance context, a bit more detail on expected inputs or output format would be helpful. Yet the output schema may compensate.

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%, the description must compensate, and it partially does by conveying the 'action_log' parameter contains counts and hashes. However, it does not elaborate on individual nested fields like 'log_hash' or 'action_type_counts', relying on the schema for structure. This is acceptable given the single parameter and clear high-level intent.

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: summarizing 'public-safe agent action log counts and hashes' into a 'governance review profile' while explicitly noting it does not ingest raw logs or traces. This distinguishes it from sibling tools that build evidence or proofs, and uses specific verbs and resources.

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 governance review without needing to process raw logs, which provides clear context. However, it does not explicitly state when not to use this tool or mention alternatives, though the sibling list suggests related but distinct tools like 'build_audit_pack_manifest' or 'build_closing_proof_pack'.

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 explicitly states what the tool does NOT do (charge, settle, mutate storage, certify external facts), which goes beyond the readOnly and idempotent annotations. It also mentions the 'non-confidential' nature, providing additional context about data handling. However, it does not describe failure modes or return behavior.

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, consisting of two short sentences, with no redundant words. It efficiently conveys the core action and key exclusions.

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 schema (oneOf, nested objects, enums) and the lack of any parameter descriptions in the schema, the tool description is insufficient. It does not explain the required inputs, the meaning of 'require_chain' or 'require_signature', nor what the output contains. The description is too sparse to be complete for complex 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?

The schema provides no descriptions for parameters, and the tool description does not explain the meaning or usage of 'bundle', 'public_keys', 'require_chain', or 'require_signature'. The description only mentions the bundle implicitly, leaving all parameters under-specified for an AI agent.

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 evidence bundle for hash integrity, monotonic ordering, signatures, and chain integrity. It distinguishes from sibling tools (e.g., build_bundle_draft, verify_signed_attestation) by focusing on verification of bundle properties.

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. It lacks guidance on when verification is appropriate, what scenarios require it, or when other tools like verify_signed_attestation might be preferred. No prerequisites or contextual triggers 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=true, idempotentHint=true, and destructiveHint=false. The description adds valuable security context beyond annotations: 'never accepts private keys and does not sign caller claims.' This informs the agent about operational boundaries, which is meaningful added 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?

Two sentences, ~30 words, front-loaded with the primary action. Every phrase earns its place — no filler 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 verification tool with a single nested parameter, an output schema, and rich annotations, the description covers the essential context well. It could mention validation edge cases (e.g., which key format to prefer when both are present), but nothing critical is missing.

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 compensates by clarifying parameter groups: 'public key material' maps to public_jwk/public_key_hex, 'pins' maps to expected_issuer/expected_purpose, and 'artifact' maps to signed_artifact. The now/now_ms params remain unexplained, but the most important semantics are captured.

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+resource structure ('Verify a legacy Ed25519 or V2 ES256 ProofRelay artifact') and adds scoping ('using public key material and optional issuer/purpose pins') that differentiates it from siblings like verify_bundle. The version qualifiers ('legacy', 'V2') give concrete operational specificity.

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 through the 'Verify' verb and algorithm details, but there's no explicit when-to-use-versus-alternatives guidance (e.g., no comparison to verify_bundle). The second sentence hints at security-relevant non-behavior but doesn't direct tool 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 this as readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description meaningfully adds behavioral clarity: it explicitly states the tool only accepts hashes and does not ingest raw data—important context about privacy/safety boundaries beyond the annotations. It doesn't describe failure modes or error handling, but for a pure wrapping tool this is solid transparency.

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, dense sentence that packs in verb, resource, constraints, portability outcome, and privacy exclusions. No wasted words. Front-loads the action and specifies the security boundary at the end.

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 sensitive security context (hashing raw references, handling secrets), the description's note about 'non-secret refs' and the exclusion of 'raw... credentials' is well-placed. The annotations cover read-only/idempotency, the output schema exists, and the input schema is quite descriptive on its own. The description could theoretically mention what happens if invalid hashes are passed, but for a stateless wrapping operation this is near-complete.

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

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

Schema description coverage is 0%, and the single parameter is a nested object with a mix of required and optional fields. The description provides security context (mentions 'payment context references', 'authority', 'non-secret refs'), which adds mild meaning beyond the field names. However, it doesn't describe field-level semantics like expected hash formats (hex? base64?), which would meaningfully help agents construct valid input. The description's 'hash-only' framing is helpful but doesn't fully compensate for the lack of field 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 uses a specific verb (Convert) and identifies a precise resource (hash-only MCP tool request/response references into a ProofRelay evidence wrapper). It clearly distinguishes itself from sibling tools by naming the wrapping/conversion functionality and the input constraints (hash-only, no raw data).

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

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

The description clearly implies when to use this tool (when hash-only references are available and a portable wrapper is needed) and explicitly states what it does not do ('without ingesting raw prompts, outputs, credentials, or logs'). While alternatives are not named, the exclusion criteria is strong guidance for an agent deciding between this and related proof-construction tools.

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