MCP server for offline verification of ScopeBlind and Veritas Acta artifacts.
It is deliberately narrow:
verify a single signed receipt or artifact
verify an audit bundle offline
explain a signed artifact in normalized form
run a packaged self-test so clients can prove the verifier works
This is the registry-worthy MCP surface for the verification lane. It is not a gateway, not a builder, and not a hosted verification service.
npm install -g @scopeblind/verify-mcpRelated MCP server: protect-mcp
{
"mcpServers": {
"scopeblind-verify": {
"command": "npx",
"args": ["-y", "@scopeblind/verify-mcp"]
}
}
}self_testRuns packaged sample verification.
Returns:
sample receipt valid / invalid
sample bundle valid / invalid
total receipts in the sample bundle
verify_receiptInputs:
artifact_json or path
optional public_key_hex
Returns:
valid / invalid
type
format
issuer
kid
canonical hash
verify_bundleInputs:
bundle_json or path
Returns:
valid / invalid
total receipts
passed
failed
explain_artifactInputs:
artifact_json or path
Returns a normalized summary of:
type
format
issuer
kid
issued_at / timestamp
payload keys
No ScopeBlind servers are contacted.
This server verifies local JSON artifacts only.
protect-mcp remains the local policy gateway.
@scopeblind/passport remains the local pack builder.
@scopeblind/red-team remains the local benchmark runner.
Apache 2.0 (see LICENSE).
Inspect a signed artifact WITHOUT verifying it: reports what the artifact claims to be so you can choose the right verification tool and key. Requires no key; read-only and offline. Provide raw JSON (artifact_json) or a local file path (path). Returns JSON { type, format ('v1'|'v2'|'passport'), issuer, kid, issued_at, payload_keys (sorted, signature excluded) }. It performs no signature check, so a well-formed forgery will explain cleanly; use verify_receipt to check authenticity.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Path to a local JSON artifact file. | |
| artifact_json | No | Raw JSON artifact string. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable context: it is offline, requires no key, describes the return JSON structure in detail, and warns that forgeries will explain cleanly. This goes beyond annotations to inform the agent of important behaviors.
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 paragraph that is well-structured and front-loaded: it states the core purpose first, then usage hints, parameter choices, return format, and a warning. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description fully documents the return JSON structure including fields like type, format, issuer, kid, issued_at, and payload_keys. It also covers the two parameter alternatives and warns about forgeries. The tool is relatively simple, and the description is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% since both parameters are documented in the input schema. The description briefly restates the two input options (artifact_json or path) but adds no additional semantic meaning or constraints beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: inspecting a signed artifact without verifying it. It uses specific verbs ('inspect') and identifies the resource ('signed artifact'), and distinguishes from sibling tools like verify_receipt by emphasizing no verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool (before verification to choose the right tool/key) and what it does not do (no signature check). It mentions that verification is done by verify_receipt, providing a clear alternative. It also notes that no key is required and it is read-only and offline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run the packaged offline self-test: verifies a known-good sample receipt and sample audit bundle shipped with the server. Read-only and deterministic; no network calls and no ScopeBlind servers are contacted. Returns JSON { ok: boolean, receipt: { valid, type, format, kid, issuer, hash }, bundle: { valid, total, passed, failed }, note }. If the packaged samples cannot be read it returns { ok: false, error }. Call this first to prove the verifier works before verifying your own artifacts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses read-only, deterministic behavior, no network calls, and not contacting ScopeBlind servers, going beyond annotations (readOnlyHint, idempotentHint) with specific operational details and return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently convey purpose, constraints, and call order; front-loaded with action and directly useful for agent decision-making.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, rich annotations, and detailed description covering behavior, output shape, and recommended usage order, it is fully complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters present, so baseline 4 applies; description adds no extra parameter info as none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool runs a packaged offline self-test that verifies a known-good sample receipt and bundle, distinguishing from siblings like verify_receipt and verify_bundle by being a self-contained trust check.
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?
Explicitly advises 'Call this first to prove the verifier works before verifying your own artifacts', providing clear when-to-use guidance and implying it's a prerequisite for sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify every receipt in a ScopeBlind audit bundle offline, using the bundle's embedded verification keys (the JWK set at verification.signing_keys, matched to each receipt by kid). Read-only; no network calls. Provide the bundle as raw JSON (bundle_json) or a local file path (path). Returns JSON { valid: boolean (true only if every receipt verifies), total, passed, failed, receipts: [{ index, type, kid, valid, error }] }. A document without a receipts array returns { ok: false, error }. For a single artifact, or to supply an external key, use verify_receipt instead.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Path to a local JSON bundle file. | |
| bundle_json | No | Raw JSON bundle string. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds valuable behavioral details: 'Read-only; no network calls', specifies the use of embedded keys, describes the return JSON structure including error handling, and states it works offline. This fully informs the agent of what to expect.
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 three sentences that efficiently convey purpose, input options, output format, and alternative tool usage. Every sentence adds value, with no redundancy or filler. It is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, the description fully documents the return value structure and error case. Parameters are completely covered by schema. Annotations cover safety. Sibling tool context is provided. The description is comprehensive and leaves no ambiguity.
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 has 100% coverage with descriptions for both parameters (path and bundle_json). The description merely restates that the bundle can be provided as raw JSON or a file path, adding no new meaning beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'verify' and the resource 'every receipt in a ScopeBlind audit bundle'. It specifies offline verification using embedded keys, and it distinguishes itself from the sibling tool 'verify_receipt' by noting when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use this tool (for bundles with multiple receipts) and when to use the alternative 'verify_receipt' (for single artifacts or external keys). It also notes that no network calls are needed, guiding appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify the Ed25519 signature of a single signed artifact (decision receipt, restraint receipt, passport envelope, or other Veritas Acta artifact; v1, v2, and passport formats are auto-detected). Read-only and fully offline. Provide the artifact as raw JSON (artifact_json) or a local file path (path); artifact_json wins if both are given. Verification uses public_key_hex when provided, otherwise a key embedded in the artifact payload; if neither exists it returns valid: false with error 'no_public_key' rather than guessing. Returns JSON { valid: boolean, error: string|null (e.g. 'invalid_signature', 'no_public_key'), type, format ('v1'|'v2'|'passport'), kid, issuer, hash (SHA-256 over the canonical unsigned bytes) }. Unparseable input returns { ok: false, error }.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Path to a local JSON artifact file. | |
| artifact_json | No | Raw JSON artifact string. | |
| public_key_hex | No | Optional Ed25519 public key hex (64 bytes as hex). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include readOnlyHint, idempotentHint, destructiveHint. Description adds details: auto-detects formats, offline operation, specific error strings (invalid_signature, no_public_key), and key resolution logic. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is dense but each sentence adds value. Slightly verbose with full return JSON structure, but front-loaded with purpose. Could be slightly more concise without losing 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?
No output schema, but description fully specifies return JSON fields (valid, error, type, format, kid, issuer, hash) and error conditions. Covers edge cases like unparseable input. Complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds value by explaining precedence between artifact_json and path, and clarifying that public_key_hex is optional with fallback behavior. This goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Verify the Ed25519 signature of a single signed artifact' and lists specific artifact types. It clearly distinguishes from siblings like verify_bundle and explain_artifact.
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?
Provides guidance on when to use artifact_json vs path, explains optional public_key_hex, and describes behavior when no key is available. However, it does not explicitly mention when to use alternatives like verify_bundle for multiple artifacts.
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. Dates show when Glama detected each change.
v0.1.0explain_artifactself_testverify_bundleverify_receiptEach tool has a clearly distinct purpose: explain_artifact inspects without verifying, self_test runs a built-in test, verify_bundle checks multiple receipts, and verify_receipt checks a single artifact. No functional overlap.
Three tools follow a clear verb_noun pattern (explain_artifact, verify_bundle, verify_receipt), while self_test deviates as a noun-based name. This minor inconsistency is acceptable given the tool's special role.
With only 4 tools, the server is well-scoped for its verification purpose. Each tool serves a necessary function without redundancy, making the set efficient and focused.
The tool set covers core verification workflows: pre-verification inspection, self-test, single artifact verification, and bundle verification. A minor gap is the lack of a tool to verify multiple individual receipts without forming a bundle, but this is covered by verify_bundle assuming bundles are the primary use case.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Trust checks for MCP servers: trust scores, tool-drift detection, signed diligence receipts. Free.
Read-only verifier for 25 ProofRelay MCP tools and non-confidential evidence bundles.
Artifact store for AI agents. Hosted OAuth at mcp.artifacta.io/mcp; local stdio via npm/PyPI.
A paid remote MCP for CLI tool MCP, built to return verdicts, receipts, usage logs, and audit-ready
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ScopeBlind/verify-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
