Verifies Bernstein run receipts and hash chains; lists the shipped presets and adapters. Read-only.
Scored across 11 tools
Each tool targets a distinct object and action: explain vs verify, receipt vs chain vs delegation chain vs trace record vs manifest, and list/get vs server_info. The purposes are clearly separated, with no overlapping functionality.
Most tools follow a verb_noun pattern (explain_receipt, verify_chain, list_presets), but server_info deviates as a noun phrase. This minor inconsistency does not impede readability.
With 11 tools, the server is well-scoped for its purpose of verifying and explaining bernstein compliance artifacts. Each tool earns its place, covering verification, explanation, and introspection without bloat.
The surface provides comprehensive coverage for the domain: verification of receipts, chains, delegation chains, trace records, and agent manifests, plus explanation and listing capabilities. No obvious gaps in the verification lifecycle.
Verify a run receipt and narrate the result in plain language: what the run recorded, which chains recomputed, where the first divergence is, and what an auditor can and cannot conclude without the producing install's keys.
| Name | Required | Description | Default |
|---|---|---|---|
| receipt | Yes | The run receipt: pass the file contents as a string for byte-exact verification, or the parsed object. |
| Name | Required | Description |
|---|---|---|
| verdict | Yes | |
| explanation | Yes | |
| receipt_sha256 | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It transparently explains the tool's verification action and the inherent limitation that conclusions depend on not having the producing install's keys, which is valuable context. However, it does not explicitly state whether the operation is read-only, whether it can fail or throw errors, or what happens if the receipt is invalid – though these may be partially covered by the output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core action ('Verify a run receipt and narrate the result') and then enumerates the key things the narration covers. It is dense but not bloated; every phrase adds relevant detail. The list format within the sentence makes it scannable, though it is slightly longer than necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameterley documented, an output schema, and a clear description of what the tool produces. The main gap is that, in the presence of sibling verify_receipt and verify_chain, the description does not clarify the decision between explanation and raw verification. For an agent, this missing routing guidance makes the definition adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers the single parameter with a detailed description, saying it can be a string for byte-exact verification or a parsed object. Since schema description coverage is 100%, the baseline of 3 applies. The tool description itself adds no extra parameter semantics, but the parameter is simple and well documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Verify') and resource ('a run receipt') and adds a distinctive outcome: narrating the result in plain language, including what the run recorded, which chains recomputed, and where the first divergence is. This clearly differentiates it from sibling verify_receipt, which likely only verifies without the narrative layer. It doesn't explicitly name any sibling, but the behavioral detail supplies enough distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you need a plain-language explanation of a run receipt, including auditor-relevant conclusions. However, it never explicitly states 'use verify_receipt for a structured/machine-readable result' or any exclusion criteria. The guidance is present but not explicit enough to fully prevent ambiguous tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How a bernstein run maps onto a TRACE v0.2 Trust Record: one row per claim with the journal field it is sourced from and the rule that derives it. Pass a run receipt to fill in the rows its embedded journal can answer (subject, iat, model, data_class, policy digest, tool transcript) alongside the receipt's own verdict.
| Name | Required | Description | Default |
|---|---|---|---|
| receipt | No | Optional run receipt: the file contents as a string, or the parsed object. |
| Name | Required | Description |
|---|---|---|
| mapping | Yes | |
| verdict | Yes | |
| markdown | Yes | |
| receipt_sha256 | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains how the tool behaves: it maps a bernstein run to a Trust Record, generates one row per claim, sources fields from the journal, and includes the receipt's own verdict. It also calls out the specific fields it can answer. It does not discuss behavior when no receipt is passed, but for an explanatory tool this is a minor gap.
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 dense sentences with no filler. The core concept is front-loaded, followed by a concise input-output explanation. Every phrase earns its place by clarifying the mapping, the row structure, or the receipt's role.
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 is complete for an explanation tool: it states the mapping being explained, the output granularity, the input, and the claimable fields. Since an output schema exists, return-value details are not required. The main missing piece is explicit guidance on receipt-optional behavior, but the overall context is sufficient for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only describes 'receipt' as optional string or parsed object. The description adds meaningful semantics: the receipt contains an embedded journal used to fill rows, and its own verdict is included alongside the derived claims. This goes beyond the schema's bare type information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: it explains how a bernstein run maps onto a TRACE v0.2 Trust Record, and even specifies the output shape (one row per claim with journal field and deriving rule). This clearly distinguishes it from siblings like verify_receipt or explain_receipt because the focus is on the mapping itself, not on verification or general receipt explanation.
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 usage context: pass a run receipt to fill in rows that the embedded journal can answer. However, it does not explicitly say when to choose this tool over explain_receipt or when not to use it, nor does it name alternatives. The guidance is functional rather than comparative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every field of one compliance preset as bernstein v3.19.2 resolves it.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| config | Yes | |
| bernstein_version | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It adds one meaningful behavioral trait: the result is based on bernstein v3.19.2 resolution semantics, implying version-specific output. However, it does not disclose side effects, error conditions, or what happens if an unknown preset name is requested, though the 'get' semantics make mutation unlikely.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, with no filler, and leads with the most important fact: 'Every field of one compliance preset.' The second phrase adds a version qualifier, but it is slightly awkwardly phrased, which prevents a perfect score.
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 simple, has only one enum-based parameter, and has an output schema, so the missing return-value documentation is acceptable. However, the description lacks guidance about how to use the name parameter and does not relate this tool to list_presets, leaving a small but real completeness gap for an agent selecting among siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention the name parameter or explain how to select the preset. The schema's property name and enum make the parameter somewhat self-explanatory, but the description does not add meaning beyond the schema and does not compensate for the missing per-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 identifies the resource: one compliance preset, and states the returned content is every field of that preset as resolved by a specific bernstein version. It distinguishes itself from a list-style sibling like list_presets by emphasizing a single preset's complete resolved view, though the sentence is grammatically a fragment and 'as bernstein v3.19.2 resolves it' is somewhat awkward.
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 explicit statement about when to use this tool versus alternatives such as list_presets or explain_receipt. The purpose implies use cases, but the description does not provide context, prerequisites, or exclusions, leaving the agent to infer routing entirely from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The agent adapters bundled with bernstein v3.19.2: adapter name, the binary it drives, the module that implements it.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| adapters | Yes | |
| bernstein_version | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It conveys that this is a static enumeration of bundled adapters and lists the output fields, which implies a read-only operation. However, it does not explicitly state side-effect-free behavior, determinism, environment assumptions, or any error/edge cases.
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 compact sentence, front-loaded with the core function and free of filler. The version pinning and output fields are conveyed efficiently without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list with an output schema present, the description covers the essentials: what is listed and what details are included. It is slightly incomplete because it does not signal when to prefer this over sibling tools or clarify whether 'bundled' means only a fixed built-in set.
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 zero parameters, the description has nothing to compensate for; the baseline of 4 applies. It introduces no parameter ambiguity and the absence of parameter documentation is not a gap 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 clearly identifies the resource ('agent adapters bundled with bernstein v3.19.2') and the fields returned (adapter name, binary, module). It is unambiguous about what the tool lists, though it does not explicitly differentiate itself from sibling tools like list_presets.
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 guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The intended usage is only implied by the name and content description; nothing tells an agent when list_adapters is the right choice over other listing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The compliance presets bernstein v3.19.2 ships, with the switches each one turns on.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| presets | Yes | |
| bernstein_version | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It clearly communicates a read-only listing operation and discloses the content scope: presets and their switches. It does not mention side effects, but the verb 'list' and the zero-parameter schema make non-read behavior highly unlikely.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the main purpose and includes only the most relevant additional detail: the exact version and the switches covered. 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 zero-parameter, read-only list tool with an output schema available, the description is fully sufficient. It states what is listed, the version scope, and what information about each preset is included, leaving no critical gap for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema already fully documents this with an empty properties object, so there is no parameter burden for the description to carry. The baseline of 4 applies because no parameter semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (list) and resource (compliance presets shipped with bernstein v3.19.2), and adds specificity by stating the switches each preset enables. This differentiates it from sibling tools like get_preset (single preset) and list_adapters (different resource type).
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 intended use is implied: call this when you need to know which compliance presets bernstein ships with and what switches they enable. However, it does not explicitly contrast it with get_preset or mention when not to use this tool, leaving some routing inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Identity, version, and request limits for this MCP server.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| limits | Yes | |
| version | Yes | |
| keys_url | Yes | |
| verdict_key | Yes | Public Ed25519 JWK this deployment signs verdicts with; also at keys_url. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must establish behavioral safety. It names the informational content and has zero parameters, strongly implying a read-only metadata call, but it never explicitly states that it has no side effects or how it behaves on failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no filler, and the most identifying content ('Identity, version, and request limits') is front-loaded. Every word adds signal.
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 zero-parameter, output-schema-backed metadata endpoint, the description covers the essential returned categories (identity, version, limits) and needs no further operational detail. It is complete enough for safe selection, though it could slightly expand on what 'identity' means.
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 and schema description coverage is 100%, so there is no parameter burden for the description to carry. A baseline of 4 is appropriate; no additional parameter meaning is needed.
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 specifies exactly what the tool exposes ('Identity, version, and request limits') and scopes it to 'this MCP server', clearly separating it from the sibling receipt/trace/verification tools. It lacks an explicit verb, but the noun-phrase description is specific and not a tautology of the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when/when-not guidance is given, but no sibling offers server-level identity and request limits, so the intended use is clear from context. The phrase 'for this MCP server' is sufficient for an agent deciding whether to call it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Agent Manifest v0.2 conformance checks on one manifest, stateless, no account: schema (vendored agent-manifest.schema.json), profile context, version, canonicalization, COSE envelope signature (Ed25519, key identified by kid in the protected header; ML-DSA-65 is reported unverifiable). Optionally checks that a TRACE Trust Record cites this manifest by digest. Nothing is fetched; resolvers are checked as URIs only. The manifest hash is sha256 over the COSE payload bytes (or RFC 8785 canonical JSON for object input).
| Name | Required | Description | Default |
|---|---|---|---|
| manifest | Yes | The agent manifest: COSE envelope as base64 string, or the parsed JSON object (payload). | |
| trustRecord | No | Optional TRACE v0.2 Trust Record to check if it cites this manifest (references[].rel == 'agent-manifest'). |
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| checks | Yes | |
| summary | Yes | |
| verdict | Yes | |
| failing_check | Yes | |
| manifest_sha256 | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations supplied, the description carries full behavioral burden and meets it: it discloses statelessness, no-account operation, no-fetch behavior, resolver URI-only checking, and the specific signature handling (Ed25519 with kid, ML-DSA-65 reported unverifiable). It even specifies the hash basis, leaving little room for surprise.
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 dense but efficiently packaged: three sentences cover scope, checks, optional behavior, constraints, and hashing. Every clause carries information, and the most identifying constraint (single manifest, stateless) 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?
For a complex verification tool, the description is complete: it specifies input forms, optional trustRecord behavior, hashing algorithm, signature algorithm/key identification, non-fetching behavior, and how unsupported algorithms are reported. With an output schema present, lack of return-value prose is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema already covers both parameters, the description adds materially: it distinguishes string input (COSE envelope base64) from object input (parsed JSON payload), defines the manifest hash as sha256 over COSE payload bytes or RFC 8785 canonical JSON, and clarifies that trustRecord is optional and checked by digest citation. This is meaningful semantic enrichment beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-plus-resource statement: 'Agent Manifest v0.2 conformance checks on one manifest', and goes on to enumerate the exact checks (schema, profile context, version, canonicalization, COSE signature). This is clearly distinct from siblings like verify_chain or verify_receipt, which target different artifacts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description establishes clear context: the tool validates a single manifest and is stateless with no account and no network fetches. It does not explicitly name an alternative to use when only a TRACE Trust Record must be verified, so it stops short of a full when-not list, but the context is enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Walk bernstein chain rows and recompute every link: journal rows (event_hash), lineage spine entries (entry_hash) or audit events (prev_hmac linkage). The row kind is detected from the fields, or pass kind explicitly. Reports the first divergent index. Pass entries as the file text (a JSON array or one row per line, as journal.jsonl is written) for byte-exact hashing; a parsed array also works, but then a float spelled 1.0 or -0.0 in the file cannot be told apart from an integer.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | ||
| entries | Yes | Rows in chain order, oldest first: a JSON array, or the raw text of the file. |
| Name | Required | Description |
|---|---|---|
| head | Yes | |
| kind | Yes | |
| detail | Yes | |
| intact | Yes | |
| entries | Yes | |
| divergent_index | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden itself. It discloses the recomputation behavior, the first-divergent-index report, field-based kind detection, and important byte-exactness and float-vs-integer caveats. It could say what happens when all links match, but the output schema likely covers return details.
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 front-loaded with the core algorithm and target rows, immediately followed by detection behavior, output, and the most important input nuance. Every sentence earns its place; nothing is redundant.
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 two parameters, one required, and an output schema available, the description covers purpose, row-kind selection, input format options, and a subtle fidelity caveat. No essential information for invoking the tool correctly 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?
Schema coverage is only 50%, and the description substantially compensates. It explains the three `kind` values, the detection behavior when omitted, and adds crucial semantics for `entries`: raw text enables byte-exact hashing while parsed arrays lose float formatting distinctions. This goes well beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific operation ('Walk bernstein chain rows and recompute every link') and enumerates the exact row kinds it applies to, making the tool's scope unambiguous. It is clearly distinct from the sibling verify_receipt despite the similar prefix.
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?
It explains when the row kind is auto-detected versus when to pass `kind` explicitly, and gives concrete guidance on choosing raw text vs a parsed array. It does not explicitly name alternative tools or exclusion conditions, but the operational context is clear enough for correct use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TRACE v0.2 delegation-chain conformance, stateless, no account: index every Trust Record by the RFC 8785 digest of its complete form, start at the leaf, follow delegation.parent_record_hash to the root, and check each hop's signature, the root key against trusted_root_keys, the depth bound, the link's digest algorithm, the credential (registered, issuer = parent subject, holder = record subject, window at the hop's own iat) and data_class narrowing under data_class_lattice. Classification: provenance-invalid outranks authorization-invalid; an unread link is unverifiable, not broken. Pass records as a JSON array or as file text (one record per line or a JSON array).
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | ||
| records | Yes | The record set in any order: a JSON array of records (objects or strings), or the raw text of a file. |
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| walk | Yes | |
| codes | Yes | |
| depth | Yes | |
| failures | Yes | |
| warnings | Yes | |
| classification | Yes | |
| first_broken_link | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full weight and delivers: it states statelessness, no account, the exact traversal and verification checks, classification precedence, and the special handling of unread links. This goes well beyond a generic 'verify' claim and tells the agent exactly what happens.
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 dense but efficient, front-loading the core purpose and statelessness before the detailed algorithm. Every clause adds operational information; the length is justified by the complexity of a delegation-chain conformance check.
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 complex tool, the description covers the full verification algorithm, the classification semantics, and the accepted input formats. Since an output schema is present, the absence of return-value explanation is not a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50%, but the description compensates by specifying the records input format (JSON array or file text, one per line) and by mapping each verification step to context parameters like trusted_root_keys, credentials, supported digest algorithms, and data_class_lattice. It adds meaning that is not apparent from the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a TRACE v0.2 delegation-chain conformance checker and enumerates the exact verification steps, so an agent can tell it verifies chains rather than single records. However, it never explicitly contrasts itself with sibling tools like verify_trace_record or verify_chain.
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 context is clear: this is a stateless, no-account conformance check for delegation chains, and the description gives explicit input-passing guidance. It does not mention when-not-to-use or name alternative tools, but the domain and behavior make the intended use unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recompute every hash chain a bernstein run receipt embeds (journal, lineage spine, optional audit range), rebuild the signed subject from the recomputed heads, and check the Ed25519 signature with the key the receipt carries. Needs no secret and reads nothing but the receipt. Returns the verdict, the first failing check, one line per check, and the same verdict as a DSSE envelope signed by this verifier's Ed25519 key (public key at keys_url) so the outcome can be kept and re-checked offline.
| Name | Required | Description | Default |
|---|---|---|---|
| receipt | Yes | The run receipt: pass the file contents as a string for byte-exact verification, or the parsed object. |
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| checks | Yes | |
| summary | Yes | |
| verdict | Yes | |
| keys_url | Yes | |
| verify_url | Yes | |
| failing_check | Yes | |
| divergent_step | Yes | |
| receipt_sha256 | Yes | |
| signed_verdict | Yes | DSSE envelope over the verdict statement (JCS JSON in payload), Ed25519 over the DSSE PAE. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden and does so thoroughly: it states the operation is read-only, requires no secret, returns the verdict plus first failing check and per-check lines, and wraps the verdict in a DSSE envelope. This gives the agent a complete behavioral model.
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 dense sentences front-load the verification mechanism, then the input/output behavior. Every clause contributes either a behavioral guarantee, a return-value detail, or a usage constraint, with 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 single-parameter tool with an output schema, the description covers the verification procedure, input formats, cryptographic behavior, output contents, and offline re-checking use case. Nothing material is missing for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers the 'receipt' parameter at 100%, but the description adds genuinely useful semantics: passing file contents as a string gives byte-exact verification, while passing the parsed object is also acceptable. This goes beyond the schema without needing to repeat basic type information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('verify'), a specific resource ('a run receipt'), and precisely what verification means: recomputing hash chains, rebuilding the signed subject, and checking the Ed25519 signature. This clearly distinguishes it from sibling tools like explain_receipt or verify_chain.
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 this tool: it needs no secret, reads nothing but the receipt, and produces an offline-recheckable signed verdict. However, it does not explicitly name alternatives or state when not to use it, so it stops 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.
TRACE v0.2 conformance checks on one Trust Record, stateless, no account: schema (vendored trace-claim.json), profile, subject URI, software-only runtime rule, policy digest, public-only confirmation key, the embedded signature (EdDSA, ES256 or ES384 with the key in cnf.jwk), appraisal, delegation link shape and references. Nothing is fetched: resolvers are checked as URIs only. record_sha256 is the RFC 8785 digest of the complete record, signature included — the value a child hop puts in delegation.parent_record_hash.
| Name | Required | Description | Default |
|---|---|---|---|
| record | Yes | A TRACE v0.2 Trust Record: the file contents as a string, or the parsed object. |
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| checks | Yes | |
| summary | Yes | |
| verdict | Yes | |
| failing_check | Yes | |
| record_sha256 | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so thoroughly. It discloses statelessness, no account, no network fetcing, URI-only resolver checks, software-only runtime rule, public-only confirmation key, accepted signature algorithms, and the exact meaning of record_sha256 as the RFC 8785 digest including the signature.
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?
Dense but every segment earns its place: scope is front-loaded, the conformance checklist is structured with a colon, and the digest clarification adds necessary precision without 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?
For a stateless single-record verification tool with a fully documented parameter and an output schema, this description covers all invocation-relevant behavior: what is checked, what algorithms are accepted, that nothing is fetched, and how the digest behaves. No important gap remains.
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 already documents the single record parameter at 100% coverage, giving a baseline of 3. The description adds meaning by explaining the expected record contents, accepted signature key formats, and the role of record_sha256 in delegation.parent_record_hash, which helps an agent construct a valid input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action (verify), a specific resource (one TRACE v0.2 Trust Record), and a detailed checklist of conformance aspects: schema, profile, subject URI, signature, appraisal, delegation shape, references. This clearly distinguishes it from sibling tools that verify chains or receipts.
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 scope is clear: it verifies a single Trust Record and is stateless with no account or fetching. This implies when to use it versus chain/receipt verification, but it does not explicitly name alternatives or say when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
verify_agent_manifestexplain_trace_mappingserver_info2 fields changedOutput schema / properties / limits / properties / max_trace_recordsAdded value: +{
+ "exclusiveMinimum": 0,
+ "maximum": 9007199254740991,
+ "type": "integer"
+}Output schema / properties / limits / requiredPrevious value: -[
- "max_body_bytes",
- "max_chain_entries"
-]New value: +[
+ "max_body_bytes",
+ "max_chain_entries",
+ "max_trace_records"
+]verify_delegation_chainverify_trace_recordverify_receipt1 field changedOutput schema / properties / summary / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "audit_events": {
- "anyOf": [
- {
- "maximum": 9007199254740991,
- "minimum": -9007199254740991,
- "type": "integer"
- },
- {
- "type": "null"
- }
- ]
- },
- "hash_profile": {
- "type": "string"
- },
- "journal_events": {
- "maximum": 9007199254740991,
- "minimum": -9007199254740991,
- "type": "integer"
- },
- "key_id": {
- "type": "string"
- },
- "run_id": {
- "type": "string"
- },
- "schema_version": {
- "type": "string"
- },
- "spine_entries": {
- "maximum": 9007199254740991,
- "minimum": -9007199254740991,
- "type": "integer"
- }
- },
- "required": [
- "run_id",
- "schema_version",
- "hash_profile",
- "journal_events",
- "spine_entries",
- "audit_events",
- "key_id"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "audit_events": {
+ "anyOf": [
+ {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "hash_profile": {
+ "type": "string"
+ },
+ "journal_events": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "key_id": {
+ "type": "string"
+ },
+ "producer": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "run_id": {
+ "type": "string"
+ },
+ "schema_version": {
+ "type": "string"
+ },
+ "spine_entries": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "tool_calls": {
+ "anyOf": [
+ {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "run_id",
+ "schema_version",
+ "hash_profile",
+ "journal_events",
+ "spine_entries",
+ "audit_events",
+ "key_id",
+ "producer",
+ "tool_calls"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]explain_receiptget_presetlist_adapterslist_presetsserver_infoverify_chainverify_receiptRead-only verifier for 25 ProofRelay MCP tools and non-confidential evidence bundles.
Find governed AI capabilities and verify signed receipts. Read-only, no account.
Issue & verify signed (ed25519), hash-chained, timestamped provenance receipts for agent actions.
Read-only gateway for durable agent identity, consent, recognized work, and signed receipts.
Add one secure layer between your agents and this server.
