Verifies Bernstein run receipts and hash chains; lists the shipped presets and adapters. Read-only.
Scored across 7 tools
All tools target distinct resources or actions, but verify_chain and verify_receipt share a similar verification purpose, and explain_receipt also performs verification while adding narration. The descriptions are detailed enough to avoid misselection, though a slight overlap exists.
All tool names follow a consistent verb_noun pattern with snake_case (e.g., explain_receipt, verify_chain, list_presets). No deviations or mixed conventions.
Seven tools is well within the ideal 3-15 range. Each tool serves a distinct purpose (explanation, listing, verification, metadata) and none feel redundant or extraneous.
The server is focused on reading and verifying bernstein compliance data, and the surface covers all core operations: listing presets and adapters, fetching a preset, verifying chains and receipts, explaining receipts, and server info. No obvious gaps for the stated domain.
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.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It accurately signals a read-only introspection operation by naming the informational fields returned, and 'request limits' adds useful context about server constraints that the agent should be aware of.
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, compact sentence that names all key output categories in order. Every word adds value, and there is no unnecessary repetition or padding.
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?
This is a very simple, zero-parameter tool with an output schema available. The description covers the essential information an agent needs to decide when to call it and what to expect, so nothing meaningful 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?
The tool has zero parameters, so no parameter documentation is needed. The input schema is empty, and the description sufficiently communicates what the tool reports without needing to explain any parameter semantics.
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's purpose: returning identity, version, and request limits for the MCP server. This distinguishes it from the receipt, preset, and verification tools listed as siblings, and is far more specific than a mere restatement 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?
The phrase 'for this MCP server' establishes the context: call this when the agent needs server-level metadata. While no explicit alternatives or exclusions are mentioned, none of the sibling tools serve the same purpose, so the guidance is adequate.
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.
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 burden, and it does so well: it discloses that no secret is required, that nothing but the receipt is read, and that the verifier signs the verdict with its own Ed25519 key. This gives agents a clear safety and side-effect profile even without structured 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 information-dense but every sentence earns its place: the first explains the verification algorithm, the second states the safety model, and the third explains the signed output. It is front-loaded with the action verb and contains no filler or marketing 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 cryptographic complexity, a single well-documented parameter, and the presence of an output schema, the description is complete enough for correct invocation. It covers inputs, algorithm, safety, and return behavior without requiring the agent to guess about secrets, external reads, or output format.
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 100% and the schema already explains the receipt parameter, including the important byte-exact string vs parsed object distinction. The description does not add significant parameter-level detail beyond that, so it meets the baseline but does not exceed it.
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 ('bernstein run receipt'), and a precise mechanism: recompute hash chains, rebuild the signed subject, and check Ed25519. It is clearly distinguishable from siblings like explain_receipt or verify_chain by focusing on full receipt verification rather than explanation or a single 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 useful context: it needs no secret, reads nothing but the receipt, and returns an offline-recheckable DSSE-signed verdict. However, it never explicitly says when to choose this tool over siblings such as explain_receipt or verify_chain, nor does it state any exclusion conditions, so usage guidance is mostly implied rather than explicit.
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.
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.
