Skip to main content
Glama
deenesjakoruzh
dylancaponi

exhibit402-mcp

by dylancaponi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

exhibit402-mcp

MCP-Server für exhibit402, einen Live-Web-Beweisdienst, der per x402 bezahlt wird. Er ermöglicht einem Agenten, USDC auf Base zu zahlen, um dauerhaft zu zertifizieren, was eine öffentliche URL gerade ausliefert, und bestehende Zertifikate erneut zu verifizieren.

So funktioniert eine Erfassung: Zwei unabhängige Beobachter in verschiedenen Netzwerken erfassen die URL im selben eingefrorenen Augenblick. Byte-identische Erfassungen erhalten die Stufe CERTIFIED. Abweichende Erfassungen erhalten die Stufe WITNESSED, mit einem Prozentsatz der Pixelübereinstimmung und einer Diff-Map. In beiden Fällen wird der Beweis (Screenshot plus signiertes Manifest) dauerhaft auf Arweave gespeichert, ein RFC-3161-Zeitstempeltoken ist enthalten, und ein ERC-721-Zertifikat wird auf Base an die Wallet geprägt, die bezahlt hat.

Maschinenlesbare Dienstdokumentation: /llms.txt und /openapi.json.

Tools

Tool

Funktion

Preis (USDC auf Base)

certify_url(url, mode)

Bezahlt für eine Erfassung und fragt dann das Claim-Ticket ab, bis das Zertifikat endgültig ist (bis zu etwa 6 Minuten). Gibt das Zertifikat-JSON zurück: Stufe, Token-ID, ar://-Links, Hashes.

$1.00 (fullpage, Standard) oder $0.50 (viewport, erster 1280x800-Bildschirm)

verify_certificate(id)

Verifiziert jedes exhibit402-Zertifikat erneut: Der Dienst lädt die gespeicherten Bytes erneut herunter, berechnet jede SHA-256-Prüfsumme neu und prüft den On-Chain-Datensatz. Gibt ein maschinenlesbares Urteil zurück. id ist eine Token-ID, eine Arweave-Transaktions-ID oder eine Job-ID.

$0.02

Wenn certify_url sein Abfrage-Zeitlimit erreicht, gibt es trotzdem die claim_url zurück. Claim-Tickets sind dauerhaft und kostenlos lesbar: Rufen Sie die Claim-URL später mit einem einfachen GET ab, um das fertige Zertifikat abzuholen. Es wird Ihnen nicht zweimal berechnet.

Erstattungsrichtlinie (vom Dienst offengelegt): Abgelehnte Erfassungen (zu groß, Seite nicht erreichbar, Inhaltsbildschirm) werden automatisch erstattet, abzüglich einer Gebühr von 0,10 $; Dienstfehler werden vollständig erstattet. WITNESSED ist ein lieferbares Ergebnis, kein Fehler, und wird nicht erstattet.

Related MCP server: 1cent

Einrichtung

Sie benötigen eine Umgebungsvariable:

  • EXHIBIT402_WALLET_KEY: ein privater EVM-Schlüssel (hex) für eine Wallet, die USDC auf Base (Chain-ID 8453) hält. Die Wallet benötigt kein ETH; x402 wickelt die Abrechnung über EIP-3009 ab, und der Facilitator bezahlt das Gas. Der Schlüssel verbleibt in Ihrer Prozessumgebung und wird nie protokolliert.

Ohne den Schlüssel startet der Server weiterhin und listet seine Tools auf, und jeder Aufruf gibt einen klaren Einrichtungsfehler zurück, anstatt still zu scheitern.

Claude Code (eine Zeile)

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

Claude Desktop

Fügen Sie zu claude_desktop_config.json hinzu:

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

Cursor

Fügen Sie zu .cursor/mcp.json hinzu:

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

Preisübersicht

Aktion

Preis

Ganzseiten-Erfassung

$1.00

Viewport-Erfassung (1280x800)

$0.50

Zertifikat verifizieren

$0.02

Erstattungsgebühr für abgelehnte Erfassung

$0.10 einbehalten, Rest erstattet

Alle Zahlungen erfolgen über x402 (USDC auf Base, eip155:8453). Die Zahlung wird abgewickelt, bevor die Erfassung beginnt; das Abfragen des Claim-Tickets ist kostenlos.

Hinweise für Betreiber

  • EXHIBIT402_URL überschreibt die Basis-URL des Dienstes (Standard: https://exhibit402.dylan-caponi.workers.dev). Sie werden sie normalerweise nicht benötigen.

  • Die Ausführung dauert normalerweise 30 bis 120 Sekunden, bei einem kalten Beobachter oder einer Wiederholungsrunde bis zu etwa 5 Minuten.

  • Ein verified: false-Urteil von verify_certificate ist ein geliefertes Ergebnis und wird berechnet. Fehlerhafte IDs, unbekannte IDs und Gateway-Ausfälle werden nicht berechnet.

  • Der Dienst lehnt private und interne Adressen vor der Zahlung ab.

Lizenz

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

ActivitySlowing
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers