Skip to main content
Glama
deenesjakoruzh
dylancaponi

exhibit402-mcp

by dylancaponi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

exhibit402-mcp

Servidor MCP para exhibit402, un servicio de evidencia web en vivo pagado con x402. Permite que un agente pague USDC en Base para certificar de forma permanente lo que una URL pública está sirviendo en ese momento, y para volver a verificar certificados existentes.

Cómo funciona una captura: dos observadores independientes en redes distintas capturan la URL en el mismo instante congelado. Las capturas idénticas byte a byte obtienen el nivel CERTIFIED. Las capturas que difieren obtienen el nivel WITNESSED, con un porcentaje de coincidencia de píxeles y un mapa de diferencias. En cualquier caso, la evidencia (captura de pantalla más un manifiesto firmado) se almacena permanentemente en Arweave, incluye un token de sello de tiempo RFC 3161 y se acuña un certificado ERC-721 en Base para el monedero que realizó el pago.

Documentación del servicio legible por máquina: /llms.txt y /openapi.json.

Herramientas

Herramienta

Qué hace

Precio (USDC en Base)

certify_url(url, mode)

Paga la captura y consulta el ticket de reclamación hasta que el certificado quede finalizado (hasta unos 6 minutos). Devuelve el JSON del certificado: nivel, id de token, enlaces ar://, hashes.

$1.00 (fullpage, predeterminado) o $0.50 (viewport, primera pantalla de 1280x800)

verify_certificate(id)

Vuelve a verificar cualquier certificado de exhibit402: el servicio vuelve a descargar los bytes almacenados, recalcula todos los SHA-256 y comprueba el registro en cadena. Devuelve un veredicto legible por máquina. id es un id de token, un id de transacción de Arweave o un id de trabajo.

$0.02

Si certify_url agota el tiempo de espera de polling, aun así devuelve la claim_url. Los tickets de reclamación son persistentes y gratuitos de leer: obtén la claim_url más tarde con una simple petición GET para recoger el certificado finalizado. No se te cobra dos veces.

Política de reembolso (indicada por el servicio): las capturas rechazadas (exceso de tamaño, página inaccesible, pantalla de contenido) se reembolsan automáticamente menos $0.10 de comís; los fallos del servicio se reembolsan por completo. WITNESSED es un entregable, no un fallo, y no se reembolsa.

Related MCP server: 1cent

Configuración

Necesitas una variable de entorno:

  • EXHIBIT402_WALLET_KEY: una clave privada EVM (hex) para un monedero que tenga USDC en Base (id de cadena 8453). El monedero no necesita ETH; x402 se liquida mediante EIP-3009 y el facilitador paga el gas. La clave se queda en el entorno de tu proceso y nunca se registra en nada.

Sin la clave, el servidor se inicia igualmente y muestra sus herramientas, pero toda llamada devuelve un error claro de configuración en lugar de fallar silenciosamente.

Claude Code (una línea)

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

Claude Desktop

Añade a claude_desktop_config.json:

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

Cursor

Añade a .cursor/mcp.json:

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

Resumen de precios

Acción

Precio

Captura de página completa

$1.00

Captura de viewport (1280x800)

$0.50

Verificar un certificado

$0.02

Tarifa de reembolso de captura rechazada

$0.10 retenido, el resto reembolsado

Todos los pagos son x402 (USDC en Base, eip155:8453). El pago se liquida antes de que comience la captura; comprobar el ticket de reclamación es gratis.

Notas para operadores

  • EXHIBIT402_URL reemplaza la URL base del servicio (predeterminada: https://exhibit402.dylan-caponi.workers.dev). Normalmente no necesitarás cambiarla.

  • El procesamiento suele tardar entre 30 y 120 segundos, hasta unos 5 minutos con un observador en frío o con un reintento.

  • Un veredicto false de verify_certificate es un resultado entregado y se cobra. Los ids malformados, los ids desconocidos y las caídas de pasarela no se cobran.

  • El servicio rechaza las direcciones privadas e internas antes del pago.

Licencia

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