four02-commerce-mcp
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| FOUR02_COMMERCE_REGISTRY | No | Four02ReputationRegistry on Ink | 0x33E2c56035C059553a37a3A56199B5b5b3DA3365 |
| FOUR02_COMMERCE_PAYER_KEY | No | Optional payer key: enables four02_invoice_pay broadcast mode | |
| FOUR02_COMMERCE_INK_RPC_URL | No | Ink RPC for reads | https://rpc-gel.inkonchain.com |
| FOUR02_COMMERCE_INVOICE_KEY | No | Optional issuer key: four02_invoice_create signs server-side when it matches the issuer | |
| FOUR02_COMMERCE_FACILITATOR_URL | No | 402 facilitator base URL | https://402-production.up.railway.app |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| four02_invoice_createA | Create a 402 EIP-712 invoice for native USDC on Ink (chain 57073). Returns the canonical invoice plus its content-addressed id. If FOUR02_COMMERCE_INVOICE_KEY is configured and matches the issuer, the invoice is signed; otherwise it is returned unsigned with instructions to sign client-side (domain "402 Invoice", version "1"). |
| four02_invoice_statusA | Verify a signed 402 invoice (pure cryptography, no trust needed) and heuristically check whether it looks paid by scanning Ink USDC Transfer events to the issuer. Payment detection is a heuristic — "likely paid", never certain. |
| four02_invoice_payA | Verify a signed 402 invoice and build the exact USDC payment plan for it. DRY RUN BY DEFAULT — returns the plan and client-side signing instructions, broadcasting nothing. Pass approveBroadcast:true ONLY after the human explicitly approved that exact payment in chat, and only when FOUR02_COMMERCE_PAYER_KEY is configured; then the server submits the USDC transfer itself. |
| four02_reputation_summaryA | One-shot commerce reputation snapshot for an ERC-8004 agentId from the Four02ReputationRegistry on Ink: reliability (0-100), dispute rate (bps), arbitration record, total events, last event time. Read-only. |
| four02_reputation_reliabilityA | Payment reliability score (0-100) and dispute rate (basis points) for an ERC-8004 agentId, from the Four02ReputationRegistry on Ink. Value-weighted with 365-day linear decay. Read-only. |
| four02_reputation_historyA | Raw commerce-event history for an ERC-8004 agentId from the Four02ReputationRegistry on Ink (append-only; newest last). Each entry shows the recording writer contract, the event type (e.g. invoice_paid_on_time), and the USDC value. Read-only. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
Invoice tools (create/status/pay) are clearly distinct by lifecycle stage. Reputation tools have slight overlap because reputation_summary already includes reliability and dispute rate, which are also the focus of reputation_reliability; however, the descriptions clarify that summary is broader and reliability is narrowly scored, so confusion is limited.
All tools follow the same four02_<resource>_<action> snake_case pattern: invoice_create, invoice_status, invoice_pay, reputation_summary, reputation_reliability, reputation_history. The convention is predictable and consistent throughout.
Six tools are well-scoped for a focused commerce server covering invoice creation, verification, payment planning, and reputation reads. Each tool has a clear role without an excessive or thin surface.
The invoice lifecycle is covered from creation through status verification to payment, and reputation read operations are present. Minor gaps exist around listing/searching invoices or writing reputation/dispute events, but the core stated workflows are supported.