Is this bench result real? Who issued it, at what scope, anchored where? One call answers.
Scored across 5 tools
Each tool targets a distinct object: bench verdict, validation record, agent identity, server status, and receipt verification. The only mild overlap is between trust_get_bench_verdict and trust_get_validation_record, since both surface product-scoped trust data, but the descriptions distinguish verdict vs. registry record clearly enough.
All names share a trust_ prefix and snake_case, forming a predictable family. The verb pattern is mostly consistent (get/resolve/verify), with trust_status being a noun-style name rather than verb_noun, which is a minor deviation.
Five tools is well-scoped for a read-only trust lookup server; each tool earns its place (status, three distinct record lookups, and receipt verification). Nothing feels redundant or padded.
The read-only lookup lifecycle is well covered: freshness check, record resolution by multiple keys, agent resolution, and proof verification. Gaps are minor — there is no enumeration/search tool for products, agents, or anchors, so an agent cannot discover identifiers, only resolve known ones.
The current Verity bench verdict for a product, byte-verbatim with scope attached, plus the computed pointer block. No verdict returns typed NO_VERDICT.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With zero annotations the description carries the full burden, and it does disclose real behavior: the verdict is returned byte-verbatim with scope attached, a computed pointer block is included, and the absent-verdict case yields an explicit typed NO_VERDICT sentinel rather than an error. It says nothing about permissions, read-only nature, caching/staleness, or cost, which matters for an unannotated trust lookup.
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 tight sentences with the core verb+resource front-loaded and the edge case trailing. Dense with useful terms ('byte-verbatim', 'scope', 'pointer block') but no filler; the jargon-heavy phrasing slightly reduces first-pass 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?
For a one-parameter read tool with no output schema, the description conveys the return shape and the null case, which is the important part. It falls short on how to supply the 'product' identifier and on the trust/permission context implied by an unannotated tool in a verification family.
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 single required 'product' parameter is a bare string with no description. The description only echoes 'for a product' and never clarifies whether that identifier is a name, slug, SKU, or internal ID — the exact information the schema omits.
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: fetching 'the current Verity bench verdict for a product,' plus what comes back (scope, pointer block). It is distinguishable from siblings like trust_status or trust_verify_receipt by resource, though it never names those alternatives. The domain term 'Verity bench verdict' is undefined jargon for an outside agent.
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?
There is no statement of when to call this versus trust_get_validation_record, trust_verify_receipt, or trust_status, and no preconditions (does the product need to exist? must it be resolved first?). 'No verdict returns typed NO_VERDICT' is return behavior, not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve an ERC-8004 Validation Registry record by validation_id, request_hash, or product. Testnet records are labelled TESTNET; mainnet lookups return typed NOT_PUBLISHED_MAINNET.
| Name | Required | Description | Default |
|---|---|---|---|
| product | No | ||
| request_hash | No | ||
| validation_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does add real behavioral value by disclosing that testnet records are labelled TESTNET and that mainnet lookups return a typed NOT_PUBLISHED_MAINNET result — a useful signal about output shape. However, it never states the not-found behavior, whether the operation is read-only, or what happens when no lookup key is supplied.
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 tight sentences, front-loaded with the action and resource. The second sentence earns its place by describing the TESTNET/NOT_PUBLISHED_MAINNET return distinction, though the naming is terse jargon an agent must already know.
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?
A tool with three fully undocumented, all-optional parameters and no output schema needs the description to resolve lookup precedence and no-key behavior; it does neither. The return-labeling hints are helpful but do not close the gap on how to actually invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must supply all parameter meaning, and it does not. It lists the three keys as alternatives ('by validation_id, request_hash, or product') but never says whether they are mutually exclusive, which takes precedence if several are provided, or that the empty required list means no key is mandatory.
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?
Specific verb ('Resolve') plus a named resource ('ERC-8004 Validation Registry record') and the three lookup keys. The resource is clearly distinct from siblings like trust_verify_receipt or trust_get_bench_verdict, though it never names those siblings to draw the contrast explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The three acceptable lookup keys imply the calling context, but there is no statement of when to prefer this over trust_verify_receipt or trust_resolve_agent, and no exclusions or prerequisites. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve an agent by ERC-8004 agent_id, DID, or registration URL: registration summary plus a trust summary computed from the records at call time.
| Name | Required | Description | Default |
|---|---|---|---|
| did | No | ||
| url | No | ||
| agent_id | No | ||
| identifier | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully says the trust summary is computed from records at call time, implying freshness, but it does not state whether the operation is read-only, what permissions are needed, or what happens with missing or multiple identifiers.
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 wasted words. It efficiently states the action, accepted identifier forms, and output summary.
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?
There is no output schema and no annotations, so the description should provide more invocation and return context. It outlines the return at a high level but leaves the four-parameter selection ambiguous and does not explain error behavior or identifier precedence.
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 ambiguity. It mentions agent_id, DID, and registration URL, partially mapping three of four parameters, but it never mentions the `identifier` parameter or explains precedence or requiredness.
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 and resource: resolve an agent by ERC-8004 agent_id, DID, or registration URL. It also says what is returned: a registration summary plus a trust summary. It does not explicitly differentiate itself from the sibling trust_* tools, so it falls short of a 5.
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 no explicit guidance on when to use this tool versus the sibling trust tools. It also does not explain parameter selection despite listing three identifier options, nor does it clarify that at least one identifier is needed even though the schema marks no parameters required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Server health + data provenance: index build time, source recompute checks, verdict/receipt/anchor counts, mainnet vs testnet posture. Call this first to judge freshness.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full behavioral burden. It does disclose the payload contents (build time, recompute checks, counts, network posture), which effectively doubles as a return-value sketch in the absence of an output schema, but it says nothing about cost, caching, auth requirements, or whether it makes network calls.
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 compact sentences: the first front-loads what the tool returns, the second gives the directive. The dense field enumeration earns its space because no output schema exists to describe the payload.
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 annotations, no output schema, and no parameters, the description is the only documentation an agent gets, and it covers both content and call ordering adequately. Minor gap: it does not characterize freshness thresholds or how to interpret the network posture field.
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 takes zero parameters, so there is no parameter semantics to explain; the baseline for a parameterless tool applies. Nothing in the description conflicts with the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific resource (server health and data provenance) and enumerates exactly what it covers: index build time, recompute checks, verdict/receipt/anchor counts, mainnet vs testnet posture. Siblings (get_bench_verdict, verify_receipt, etc.) all operate on individual artifacts, so this aggregate-status role is distinguishable, though the description never explicitly contrasts itself with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Call this first to judge freshness' gives a clear, actionable ordering directive that tells the agent when to reach for this tool. It stops short of naming alternatives or when-not-to-use conditions, so it lands just below the top band.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a Herald receipt hash: recomputed hash match, the record it belongs to, issuer, anchor state (ANCHORED/PENDING/FAILED/NOT_ENQUEUED) with chain + tx + proof bundle, offline proof verification, and a verify_recipe. Unknown hash returns typed NOT_FOUND.
| Name | Required | Description | Default |
|---|---|---|---|
| receipt | No | ||
| receipt_hash | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description does real work by disclosing the output facets (hash match, issuer, anchor state enum values, chain/tx/proof bundle, verify_recipe) and the typed NOT_FOUND error. It still omits whether this is a read-only operation, any auth/permission requirements, and how the two parameters interact.
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?
Front-loaded with the verb and tightly packed, no filler sentences. The single colon-delimited run-on is dense but each listed item (anchor state, proof bundle, verify_recipe) adds information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description justifiably enumerates return fields, which it does competently. But the critical invocation ambiguity — two optional params, a nested `receipt` object with zero semantics, and no required field — is unresolved, so an agent cannot confidently call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and both parameters are optional with no required field. The description implies receipt_hash is a hash to verify, but the nested `receipt` object is never explained — what it should contain, or when to pass it instead of/alongside receipt_hash — leaving invocation ambiguous.
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?
Specific verb+resource ("Verify a Herald receipt hash") plus an enumerated statement of what the verification returns. It does not distinguish itself from siblings like trust_get_validation_record, but the resource is distinctive enough that confusion is unlikely.
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 when-to-use / when-not-to-use guidance and no mention of alternatives or prerequisites. The only routing signal is the error case ("Unknown hash returns typed NOT_FOUND"), which tells an agent what happens, not whether this is the right tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
trust_get_bench_verdicttrust_get_validation_recordtrust_resolve_agenttrust_statustrust_verify_receiptSearch accredited testing labs and verify lab scope evidence from ScopeMatch.
Verify a company, figure or citation before you rely on it. Card or crypto; signed receipt.
Evidence-first technical website diagnostics with human-confirmed request handoffs.
Avoid redundant expensive validation. CHECK recent evidence; OBSERVE fresh independent results.
Add one secure layer between your agents and this server.
