Skip to main content
Glama
deenesjakoruzh
dylancaponi

exhibit402-mcp

by dylancaponi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

exhibit402-mcp

exhibit402 用のMCPサーバー。これは、x402で支払いを行うライブWeb証拠サービスであり、エージェントがBase上のUSDCを支払って、公開URLが現在提供している内容を恒久的に証明し、既存の証明書を再検証できるようにします。

キャプチャの仕組み: 2つの独立したオブザーバーが異なるネットワーク上で、同じ凍結された瞬間にURLをキャプチャします。バイト単位で同一のキャプチャはCERTIFIEDティアになります。異なるキャプチャはWITNESSEDティアになり、ピクセル一致率と差分マップが含まれます。どちらの場合も、証拠（スクリーンショットと署名付きマニフェスト）はArweaveに恒久的に保存され、RFC 3161タイムスタンプトークンが含まれ、支払ったウォレットにBase上でERC-721証明書が発行されます。

機械可読なサービスドキュメント: /llms.txt と /openapi.json。

ツール

ツール

機能

価格 (Base上のUSDC)

certify_url(url, mode)

キャプチャの料金を支払い、証明書が確定するまで（最大約6分）クレームチケットをポーリングします。証明書のJSON（ティア、トークンID、ar://リンク、ハッシュ）を返します。

$1.00 (fullpage、デフォルト) または $0.50 (viewport、最初の1280x800画面)

verify_certificate(id)

exhibit402証明書を再検証します: サービスは保存されたバイトを再ダウンロードし、すべてのSHA-256を再計算し、オンチェーンレコードを確認します。機械可読な判定を返します。id はトークンID、ArweaveトランザクションID、またはジョブIDです。

$0.02

certify_url がポーリングタイムアウトに達した場合でも、claim_url を返します。クレームチケットは永続的で、読み取りは無料です。後でプレーンなGETでクレームURLを取得して、完了した証明書を収集できます。二重に課金されることはありません。

返金ポリシー（サービスによって開示）: 拒否されたキャプチャ（サイズ超過、到達不能なページ、コンテンツスクリーン）は、$0.10の手数料を差し引いて自動的に返金されます。サービス障害は全額返金されます。WITNESSEDは成果物であり、失敗ではなく、返金されません。

Related MCP server: 1cent

セットアップ

環境変数が1つ必要です:

  • EXHIBIT402_WALLET_KEY: Base（チェーンID 8453）でUSDCを保持するウォレットのEVM秘密鍵（16進数）。ウォレットに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（Base上のUSDC、eip155:8453）です。支払いはキャプチャ開始前に決済されます。クレームチケットのポーリングは無料です。

オペレーター向けの注意事項

  • EXHIBIT402_URL はサービスのベースURLを上書きします（デフォルト https://exhibit402.dylan-caponi.workers.dev）。通常は必要ありません。

  • フルフィルメントは通常30〜120秒で、コールドオブザーバーや再試行ラウンドがある場合は最大約5分かかります。

  • verify_certificate からの verified: false 判定は配信された結果であり、課金されます。不正なID、不明なID、ゲートウェイの停止は課金されません。

  • サービスは支払い前にプライベートおよび内部アドレスを拒否します。

ライセンス

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