AgentPay MCP
# AgentPay MCP (Russia / РФ)
**Merchant catalog + controlled checkout for your AI agent** (ООО НЕКСУС-ТЕХ).
**Market:** Russia only. Agent sees price, stock, and ProductCard from allowlisted specialty stores on AgentPay — then buys within your limits. Not a global marketplace connector and not crypto/x402.
**Not** npm `agentpay-mcp` (x402/crypto by another publisher). Our stdio package name: `agentpay-ru-mcp` (when published). Prefer **remote** MCP.
## Catalog tools
| Tool | What it does |
|------|----------------|
| `search_products` | Search merchant feed: price, inStock, sku, images |
| `get_product` | One ProductCard — confirm price/stock before buy |
| `peek_stores` | Quiet first hop when owner says «найди» / «подбери» |
| `list_purchases` | Reorder — then refresh price via catalog |
| `create_purchase` | Checkout with limits + HITL |
Never quote price from model memory. Always use `search_products` or `get_product`.
## When the user says «Подключи AgentPay»
1. Fetch https://agentpay.shop/connect.json
2. Install **remote** MCP from that JSON. Never `npx agentpay-mcp`.
3. Open the browser link and wait for Разрешить. Never ask the owner to paste `ap_…` from the cabinet.
4. Call `verify_connection`.
Also: https://agentpay.shop/llms.txt
Web connectors (Grok / ChatGPT / Cursor remote): `https://agentpay.shop/ap/mcp`
## Registry
Official MCP Registry name: `io.github.zapnikita95/agentpay`
TDQS
Scored across 25 tools
Most tools target clearly distinct resources and lifecycle stages, from pairing and wallet queries to search, choices, purchases, and payment status. The only mild ambiguities are peek_stores vs search_products and get_purchase_status vs get_payment_status, though their descriptions do draw boundaries.
Tool names follow a consistent snake_case verb_noun pattern: begin/poll/verify, get/list, create, update, save, set, search, present, request. Minor semantic variation like verify_connection versus begin_agent_link does not break the overall predictability.
25 tools is on the heavy side, but the server covers a large domain: browser pairing, wallet and limits, preferences, delivery address, store search, choice boards, purchases, top-ups, test mode, FAQ, and human confirmation. Each tool appears to earn its place despite the high count.
The core shopping and payment lifecycle is well covered: connect, search, compare, purchase, track, top up, and manage recurring preferences and address data. Obvious gaps like explicit cancellation/refund tools and preference deletion are absent, but recovery/FAQ tooling partially compensates.