Skip to main content
Glama
deenesjakoruzh
dylancaponi

exhibit402-mcp

by dylancaponi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

exhibit402-mcp

MCP-сервер для exhibit402 — живого сервиса веб-доказательств с оплатой через x402. Он позволяет агенту платить USDC в сети Base, чтобы навсегда засвидетельствовать, что публичный URL отдаёт прямо сейчас, и повторно проверять существующие сертификаты.

Как работает захват: два независимых наблюдателя в разных сетях захватывают URL в один и тот же замороженный момент. Байт-идентичные захваты получают уровень CERTIFIED. Различающиеся захваты получают уровень WITNESSED, с процентом совпадения пикселей и картой различий. В любом случае доказательство (скриншот плюс подписанный манифест) постоянно хранится на Arweave, включается токен временной метки RFC 3161, и на Base выпускается сертификат ERC-721 на кошелёк, который заплатил.

Машиночитаемая документация сервиса: /llms.txt и /openapi.json.

Инструменты

Инструмент

Что делает

Цена (USDC на Base)

certify_url(url, mode)

Оплачивает захват, затем опрашивает тикет заявки, пока сертификат не станет окончательным (до ~6 минут). Возвращает JSON сертификата: уровень, идентификатор токена, ссылки ar://, хэши.

$1.00 (fullpage, по умолчанию) или $0.50 (viewport, первый экран 1280x800)

verify_certificate(id)

Повторно проверяет любой сертификат exhibit402: сервис заново скачивает сохранённые байты, пересчитывает каждый SHA-256 и проверяет запись в блокчейне. Возвращает машиночитаемый вердикт. id — это идентификатор токена, идентификатор транзакции Arweave или идентификатор задания.

$0.02

Если certify_url достигает тайм-аута опроса, он всё равно возвращает claim_url. Тикеты заявок долговечны и бесплатны для чтения: позже можно получить URL заявки обычным GET-запросом, чтобы забрать готовый сертификат. С вас не взимается плата дважды.

Политика возврата (раскрыта сервисом): отклонённые захваты (слишком большой размер, недоступная страница, экран с контентом) возвращаются автоматически за вычетом комиссии $0.10; сбои сервиса возвращаются полностью. WITNESSED — это результат, а не сбой, и не подлежит возврату.

Related MCP server: 1cent

Настройка

Вам нужна одна переменная окружения:

  • EXHIBIT402_WALLET_KEY: приватный ключ EVM (hex) для кошелька, на котором есть USDC в сети Base (chain id 8453). Кошельку не нужен ETH; x402 рассчитывается через EIP-3009, а газ оплачивает фасилитатор. Ключ остаётся в окружении вашего процесса и никогда не логируется.

Без ключа сервер всё равно запускается и перечисляет свои инструменты, а каждый вызов возвращает понятную ошибку настройки вместо тихого сбоя.

Claude Code (одна строка)

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

Claude Desktop

Добавьте в claude_desktop_config.json:

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

Cursor

Добавьте в .cursor/mcp.json:

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

Сводка цен

Действие

Цена

Захват полной страницы

$1.00

Захват области просмотра (1280x800)

$0.50

Проверка сертификата

$0.02

Комиссия за возврат отклонённого захвата

$0.10 удерживается, остальное возвращается

Все платежи осуществляются через x402 (USDC на Base, eip155:8453). Оплата происходит до начала захвата; опрос тикета заявки бесплатен.

Примечания для операторов

  • EXHIBIT402_URL переопределяет базовый URL сервиса (по умолчанию https://exhibit402.dylan-caponi.workers.dev). Обычно он вам не понадобится.

  • Выполнение обычно занимает от 30 до 120 секунд, до ~5 минут при холодном наблюдателе или повторной попытке.

  • Вердикт verified: false от verify_certificate — это доставленный результат, и он оплачивается. Некорректные идентификаторы, неизвестные идентификаторы и сбои шлюза не оплачиваются.

  • Сервис отклоняет частные и внутренние адреса до оплаты.

Лицензия

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