Skip to main content
Glama
deenesjakoruzh
dylancaponi

exhibit402-mcp

by dylancaponi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

exhibit402-mcp

MCP server for exhibit402, a live x402-paid web-evidence service. It lets an agent pay USDC on Base to permanently certify what a public URL serves right now, and to re-verify existing certificates.

How a capture works: two independent observers on different networks capture the URL at the same frozen instant. Byte-identical captures get tier CERTIFIED. Differing captures get tier WITNESSED, with a pixel agreement percentage and a diff map. Either way the evidence (screenshot plus a signed manifest) is stored permanently on Arweave, an RFC 3161 timestamp token is included, and an ERC-721 certificate is minted on Base to the wallet that paid.

Machine-readable service docs: /llms.txt and /openapi.json.

Tools

Tool

What it does

Price (USDC on Base)

certify_url(url, mode)

Pays for a capture, then polls the claim ticket until the certificate is final (up to about 6 minutes). Returns the certificate JSON: tier, token id, ar:// links, hashes.

$1.00 (fullpage, default) or $0.50 (viewport, first 1280x800 screen)

verify_certificate(id)

Re-verifies any exhibit402 certificate: the service re-downloads the stored bytes, recomputes every SHA-256, and checks the on-chain record. Returns a machine-readable verdict. id is a token id, an Arweave tx id, or a job id.

$0.02

If certify_url hits its polling timeout, it still returns the claim_url. Claim tickets are durable and free to read: fetch the claim URL later with a plain GET to collect the finished certificate. You are not charged twice.

Refund policy (disclosed by the service): rejected captures (oversize, unreachable page, content screen) refund automatically minus a $0.10 fee; service faults refund in full. WITNESSED is a deliverable, not a failure, and is not refunded.

Related MCP server: 1cent

Setup

You need one environment variable:

  • EXHIBIT402_WALLET_KEY: an EVM private key (hex) for a wallet that holds USDC on Base (chain id 8453). The wallet needs no ETH; x402 settles via EIP-3009 and the facilitator pays gas. The key stays in your process environment and is never logged.

Without the key the server still starts and lists its tools, and every call returns a clear setup error instead of failing silently.

Claude Code (one line)

claude mcp add exhibit402 --env EXHIBIT402_WALLET_KEY=0xYOUR_KEY -- npx -y exhibit402-mcp

Claude Desktop

Add to claude_desktop_config.json:

{
  "mcpServers": {
    "exhibit402": {
      "command": "npx",
      "args": ["-y", "exhibit402-mcp"],
      "env": { "EXHIBIT402_WALLET_KEY": "0xYOUR_KEY" }
    }
  }
}

Cursor

Add to .cursor/mcp.json:

{
  "mcpServers": {
    "exhibit402": {
      "command": "npx",
      "args": ["-y", "exhibit402-mcp"],
      "env": { "EXHIBIT402_WALLET_KEY": "0xYOUR_KEY" }
    }
  }
}

Pricing summary

Action

Price

Full-page capture

$1.00

Viewport capture (1280x800)

$0.50

Verify a certificate

$0.02

Rejected capture refund fee

$0.10 kept, rest refunded

All payments are x402 (USDC on Base, eip155:8453). Payment settles before the capture starts; polling the claim ticket is free.

Notes for operators

  • EXHIBIT402_URL overrides the service base URL (default https://exhibit402.dylan-caponi.workers.dev). You will not normally need it.

  • Fulfillment is normally 30 to 120 seconds, up to about 5 minutes with a cold observer or a retry round.

  • A verified: false verdict from verify_certificate is a delivered result and is charged. Malformed ids, unknown ids, and gateway outages are not charged.

  • The service refuses private and internal addresses before payment.

License

MIT

Available Tools

2 tools
certify_urlCertify a URL (paid capture)A

Permanently certify what a public web page serves right now. Pays with x402 (USDC on Base): $1.00 for mode 'fullpage' (default, whole page) or $0.50 for mode 'viewport' (first 1280x800 screen). Two independent observers capture the URL at one frozen timestamp; matching captures are tier CERTIFIED, differing ones are WITNESSED (with pixel agreement percent and diff map). Evidence is stored permanently on Arweave and an ERC-721 certificate is minted on Base to the paying wallet. This tool polls the claim ticket for up to about 6 minutes (fulfillment is normally 30-120 seconds). If it times out, the returned claim_url is durable: fetch it later with a plain GET to collect the result. Rejected captures refund automatically minus a $0.10 fee; service faults refund in full.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesPublic http(s) URL to capture. Private and internal addresses are refused before payment.
modeNofullpage ($1.00, default) or viewport ($0.50, first 1280x800 screen)

TDQS

A4.2/5.0
Behavior5/5

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

With no annotations provided, the description fully discloses behavioral traits: payment amount and basis, dual-observer mechanism, tier outcomes (CERTIFIED vs WITNESSED), permanent storage on Arweave, NFT minting, polling duration, timeout behavior, durable claim_url, and refund policy. This is exemplary transparency for a state-changing, paid operation.

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

Conciseness4/5

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

The description is long but every sentence adds essential information (purpose, cost, verification process, outcomes, storage, polling, failure handling). It fronts the core purpose and then covers operational details in a logical sequence. Slight compactness could be achieved, but nothing is redundant, justifying a strong score.

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

Completeness5/5

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

For a paid, asynchronous tool with no output schema, the description is remarkably complete. It explains what will be returned (claim_url, tiers, agreement percent, diff map), how to handle timeouts, refund conditions, and the durability of the claim URL. An agent can call this tool and handle every possible outcome without additional documentation.

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

Parameters3/5

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

Schema coverage is 100% — both `url` and `mode` have detailed descriptions in the schema (including the refusal of private addresses and the exact pricing for modes). The tool description repeats these details without adding new semantic info, so it adds no value beyond the schema, meeting the baseline of 3.

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

Purpose5/5

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

The first sentence states a specific action — 'Permanently certify what a public web page serves right now' — with a clear resource (URL) and a concrete outcome (certification). It immediately distinguishes this from verification by describing the capture process and resulting certificate tiers, making the tool's role unambiguous.

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

Usage Guidelines3/5

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

The description gives detailed execution context (payment, modes, polling, timeout) but never explicitly states when to use this tool versus the sibling `verify_certificate`. Usage is implied by the capture-and-certify purpose, yet no direct comparison or exclusion is provided, leaving the agent to infer the boundary.

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

verify_certificateVerify a certificate (paid, $0.02)A

Re-verify any exhibit402 certificate for $0.02 (x402, USDC on Base). Pass the certificate's ERC-721 token id (digits), its Arweave manifest tx id (43 chars), or the exhibit402 job id (uuid). The service re-downloads the permanently stored screenshot and signed manifest, recomputes every SHA-256 from the actual bytes, and compares against the manifest and the on-chain record. Returns a machine-readable verdict: verified true/false plus per-check results (manifest_resolves, screenshot_hash, observer_agreement, onchain_sha256, rfc3161_timestamp). A false verdict is a delivered result and is charged; malformed ids, unknown ids, and gateway outages are not charged.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesERC-721 token id, Arweave tx id, or exhibit402 job id

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It excels: it explains the internal process (re-downloading, recomputing SHA-256, comparing against manifest and on-chain record), the output format (verdict with per-check results), and, critically, the cost implications—specifically that a false verdict is still charged while malformed/unknown IDs and gateway outages are not. This comprehensive disclosure leaves no ambiguity about side effects or 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.

Conciseness5/5

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

The description is well-structured and front-loaded with the core purpose and cost. Every sentence contributes—parameter formats, process steps, output verdict, and billing nuances. There is no redundancy or fluff; it is information-dense yet clear. This is exemplary conciseness.

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

Completeness5/5

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

Given the tool has only one parameter and no output schema, the description fully compensates by explicitly describing the return value (the verdict and its sub-fields) and the charging rules. It also covers invalid-input handling, making the tool's behavior predictable. The description is complete for an agent to correctly invoke and interpret results.

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

Parameters4/5

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

The input schema already provides a high-level description of the 'id' parameter with 100% coverage. The description adds substantial value by detailing the exact formats expected: ERC-721 token id (digits), Arweave manifest tx id (43 chars), and exhibit402 job id (uuid). This goes beyond the schema, so the description meaningfully augments parameter understanding, warranting a 4.

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

Purpose5/5

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 (exhibit402 certificate), and specifies it is a re-verification. It distinguishes from the sibling 'certify_url' by focusing on verification rather than creation, though it does not name the sibling. The description also enumerates accepted identifier types, making the purpose unmistakable.

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

Usage Guidelines4/5

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

The description provides strong context: it tells the agent to use this tool to re-verify existing certificates and even lists accepted identifier formats. However, it does not explicitly state when *not* to use it or mention the alternative 'certify_url' for creation, leaving that inference to the agent. This earns a 4 rather than a 5.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv0.1.0
    • First observedcertify_url
    • First observedverify_certificate
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.4/5.0

Scored across 2 tools

Disambiguation5/5

The two tools, certify_url and verify_certificate, have completely distinct purposes: one creates a certification, the other validates an existing one. There is no overlap or ambiguity in their functionality.

Naming Consistency5/5

Both tool names follow a consistent verb_noun pattern (certify_url, verify_certificate), using clear, action-first naming that is predictable and readable.

Tool Count3/5

With only 2 tools, the server feels minimal but is appropriate for its narrow focus on certification and verification. It falls into the borderline 'thin' range, yet the tools are purposeful and not redundant.

Completeness4/5

The core lifecycle of certification—creating and verifying—is covered. Minor gaps exist (e.g., no ability to list certificates or revoke them), but these are not essential for the primary workflow of certifying and checking authenticity.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers