MAP Maraventano Agent Protocol

MAP Maraventano Agent Protocol

MAP (Maraventano Agent Protocol). One MCP server with three subtractive parts — Merchant Key (read any product URL into one CleanRead), Atlas (publish your own catalog by reading yourself), Provisions (wallet curriculum), Teacher, not butler: never signs, pays, or holds keys.

Category
访问服务器

README

MAP — Maraventano Agent Protocol

Navigate agent commerce. Find any merchant. Pay any merchant. Be found.

MAP lets any agent read products across the open web in one shape, decide whether it can pay autonomously, and publish its own catalog.

Provisions · Merchant Key · Atlas — three minimal parts under one MCP server.

MAP is one MCP server with three parts. Each does one thing and shuts up; together they remove the gatekeeper between an agent and the open commercial web.

Part Name What it does
read Merchant Key Find any merchant. Decode any product URL into one clean shape (CleanRead).
pay Provisions Pay any merchant. Lessons that teach an agent to use the wallet it already has.
publish Atlas Be found. Point the decoder inward; serve your own catalog to other agents.

Teacher, not butler — every part. MAP reads, explains, persists, and serves. It never signs, pays, holds keys, transacts, or stores cards.

It publishes to npm as @maraventano/map. The standalone firstdollar package stays MIT and separate; the copy of its curriculum bundled here (Provisions) is relicensed dual — see LICENSE.


Merchant Key — find any merchant (read)

It reads any URL on the open web — not just a walled garden. That's the difference from Perplexity / Google Shopping / Amazon, who only see merchants inside their own programs. MAP never assumes the merchant is registered anywhere.

decode-merchant

Input a product url. Returns ONE shape (CleanRead):

{
  "schemaVersion": "map/v1",
  "sourceUrl": "https://…",
  "what":   "Void Latte — Meditation on emptiness and meaning…",  // name + identity, one string
  "who":    "underground.substratesymposium.com",                 // seller
  "price":  { "total": 1.99, "currency": "USDC" },                // total if knowable, else null
  "available": "in_stock",                                        // in_stock | out_of_stock | unknown
  "payable": {                                                    // can an agent pay this itself?
    "rail": "x402",                                               // schema (rail-agnostic): x402 | ap2 | acp | coinbase | stripe | http-json | walletconnect | human_checkout | unknown.  v1 DETECTS x402 only; the rest are reserved.
    "payTo": { "kind": "evm-address", "value": "0x…", "chain": "eip155:8453" },
    "instruction": "Agent-payable via x402 … see this kit's wallet lessons (read-this-challenge, how-do-i-pay)."
  },
  "outcome": "autonomous",                                        // autonomous | human_checkout | unreadable
  "reason":  null,
  "cuts":    []                                                   // 1-line actionable gaps
}

Five things and a verdict. No sixth field. Same shape every read, so four reads sort against each other. Unknown is null / "unknown" — never omitted.

The three outcomes:

  • autonomous — a machine-payable rail (x402) exists, the price is known, and it's not out of stock. The agent can buy it itself.
  • human_checkout — readable, but no agent-payable rail. Returns the clean card anyway. The common case, and a success — the agent-payable web is nearly empty today.
  • unreadable — couldn't get a usable price/product. Says why in reason. Doesn't guess.

How it reads (v1): JSON-LD (schema.org Product/Offer) → OpenGraph product tags → x402 402 challenge → else unreadable. Read-only GET. It follows one same-origin redirect (noted in cuts as "followed 1 same-origin redirect") so canonical→slug URLs resolve; it refuses cross-origin redirects and chains (those become a cuts note, not a silent follow) — you can't be silently bounced off the merchant's own host.

MAP is payment-rail agnostic by design. The payable.rail schema can describe any agent-payable rail — x402, ap2, acp, coinbase, stripe, http-json, walletconnect, human_checkout, unknown — but v1 only detects x402 reliably. The other rails are reserved schema values until they expose stable, machine-readable signals MAP can verify. MAP never infers a rail from branding, checkout buttons, script tags, marketing copy, or platform names; if no verifiable machine-readable rail is detected, the outcome is human_checkout. So a normal Shopify/Stripe page reads as human_checkout, correctly.

False human_checkout is acceptable in v1. False autonomous is dangerous and unacceptable — which is why detection stays conservative. The protocol is rail-agnostic in schema and roadmap; x402 is not baked into its identity, only into v1's detectors.

Known v1 limits (future enhancements, not bugs): no headless browser (JS-only pages with no JSON-LD/OG read as unreadable); stock is usually unknowable from outside (available: "unknown" is correct); no secondary endpoint probing.


Provisions — pay any merchant (pay)

When decode-merchant returns autonomous and you want to buy, Provisions teaches you how — with your own wallet. It is a relicensed copy of the First Dollar curriculum: short lessons from "what is a wallet" through reading a live x402 challenge, signing a USDC payment, and verifying the receipt.

Start with what-is-x402, then read-this-challenge, then how-do-i-pay. It explains what to run; it never signs for you. Mandate/delegation (AP2), receipt verification, and "what went wrong" diagnostics are all in here.


Atlas — be found (publish)

The decoder pointed inward. A merchant publishes by reading itself with the exact same decode-merchant a buyer uses — no new parsing, no per-platform adapters.

  • publish-catalog — decode your own product URLs → collect the CleanReads → write ./catalog.json and a ./.well-known/map.json discovery manifest for registries to crawl.
  • get-catalog / get-product — the tool surface other agents read.

Agents discover via tool surfaces and well-known manifests — not via scraping or HTTP headers. Atlas emits documents, validates shape, persists, and serves. It never deploys merchant infrastructure, holds keys, transacts, or stores cards.

Trust boundary (v1, named not built): MAP trusts the reads a merchant produces with its own decoder. Independent re-read/diff, merchant-signed manifests, and periodic re-audit are known future work — not implemented in v1. One safety property already holds: the payment rail enforces the real price at settlement, so a mistaken manifest can't overcharge — it can only misstate soft fields like stock.


Charlie's afternoon

Bob: "Charlie, find me kick-ass headphones under $300." Charlie walks the open web, hits four ad-bloated product pages, runs decode-merchant on each, gets back four clean cards — what it is, who sells it, what it costs, can I buy it myself. Three are human-checkout; he takes the shortlist back to Bob. One takes x402; Charlie buys it himself. On the way home, with his own wallet, Charlie buys himself a void latte. Nobody asked him to.


Install / run

npx @maraventano/map    # run the MAP MCP server on stdio (23 tools: read · pay · publish)
npm run smoke           # Merchant Key DoD — the four decode cases (hits the live Underground x402 item)
npm run smoke:publish   # Atlas DoD — publish-catalog → catalog.json → get-product → .well-known

Node ≥ 18. One dependency: @modelcontextprotocol/sdk.

License & trademarks

Dual-licensed: free for individuals and agents; commercial license required for companies. See LICENSE. Not MIT. For a commercial license, contact Lisa Maraventano at lisamaraventano@gmail.com.

All trademarks belong to their respective owners. MAP is not affiliated with or endorsed by Coinbase, Stripe, Google, Shopify, or any other company named in its documentation or lessons.


By Lisa Maraventano, with Claude · Clarksdale, Mississippi

推荐服务器

Baidu Map

Baidu Map

百度地图核心API现已全面兼容MCP协议,是国内首家兼容MCP协议的地图服务商。

官方
精选
JavaScript
Playwright MCP Server

Playwright MCP Server

一个模型上下文协议服务器,它使大型语言模型能够通过结构化的可访问性快照与网页进行交互,而无需视觉模型或屏幕截图。

官方
精选
TypeScript
Magic Component Platform (MCP)

Magic Component Platform (MCP)

一个由人工智能驱动的工具,可以从自然语言描述生成现代化的用户界面组件,并与流行的集成开发环境(IDE)集成,从而简化用户界面开发流程。

官方
精选
本地
TypeScript
Audiense Insights MCP Server

Audiense Insights MCP Server

通过模型上下文协议启用与 Audiense Insights 账户的交互,从而促进营销洞察和受众数据的提取和分析,包括人口统计信息、行为和影响者互动。

官方
精选
本地
TypeScript
VeyraX

VeyraX

一个单一的 MCP 工具,连接你所有喜爱的工具:Gmail、日历以及其他 40 多个工具。

官方
精选
本地
graphlit-mcp-server

graphlit-mcp-server

模型上下文协议 (MCP) 服务器实现了 MCP 客户端与 Graphlit 服务之间的集成。 除了网络爬取之外,还可以将任何内容(从 Slack 到 Gmail 再到播客订阅源)导入到 Graphlit 项目中,然后从 MCP 客户端检索相关内容。

官方
精选
TypeScript
Kagi MCP Server

Kagi MCP Server

一个 MCP 服务器,集成了 Kagi 搜索功能和 Claude AI,使 Claude 能够在回答需要最新信息的问题时执行实时网络搜索。

官方
精选
Python
e2b-mcp-server

e2b-mcp-server

使用 MCP 通过 e2b 运行代码。

官方
精选
Neon MCP Server

Neon MCP Server

用于与 Neon 管理 API 和数据库交互的 MCP 服务器

官方
精选
Exa MCP Server

Exa MCP Server

模型上下文协议(MCP)服务器允许像 Claude 这样的 AI 助手使用 Exa AI 搜索 API 进行网络搜索。这种设置允许 AI 模型以安全和受控的方式获取实时的网络信息。

官方
精选