MCPサーバー

mcp

market.mtok/mcp
AI・エージェント 暗号資産・Web3 公開・接続可能 MCP 2026-07-28

このMCPでできること

Provides a peer-to-peer marketplace for buying and selling AI inference capacity with chunk-level USDC settlement on Base.

buying_guide
Turnkey, executable steps to get a human cheap AI tokens and run their prompts on mtok.market: bid (read routes[]) or read the book for a tier:direct offer, then draw paid chunks from the seller's relay (pay each draw on-chain through MtokDripLedger, POST <relayEndpoint>/chunk, the relay verifies DrawPaid and serves). You need a funded wallet on Base.
入力スキーマ
{'type': 'object', 'properties': {}}
cancel_order
Cancel one of your open orders. side: offer|bid.
入力スキーマ
{'type': 'object', 'required': ['side', 'id'], 'properties': {'id': {'type': 'string'}, 'side': {'enum': ['offer', 'bid'], 'type': 'string'}}}
get_book
Open offers (asks) and bids for a model. sort=input|output ranks by that dimension.
入力スキーマ
{'type': 'object', 'properties': {'sort': {'enum': ['input', 'output'], 'type': 'string'}, 'model': {'type': 'string'}}}
get_config
Chain config a SELLER-HOSTED buyer needs to build the on-chain draw payment: { feeAddress, feeBps, dustThresholdUsd, chainId, usdcAddress, dripContractAddress }. Pay each draw through the MtokDripLedger contract at dripContractAddress (payDraw), then affirmDraw/disputeDraw on-chain; the seller relay verifies the DrawPaid event before delivery.
入力スキーマ
{'type': 'object', 'properties': {}}
get_draws
The chain-derived draw tape: contract-paid draws indexed from MtokDripLedger events on Base. status=inProcess (DrawPaid with no terminal yet) | settled (closed by DrawAffirmed or DrawDisputed). This is the canonical delivered/receipt surface; the platform records nothing off-chain.
入力スキーマ
{'type': 'object', 'properties': {'limit': {'type': 'integer'}, 'status': {'enum': ['inProcess', 'settled'], 'type': 'string'}}}
get_me
Your agent state: open orders (offers + bids). Non-custodial — there is no platform wallet, grant, or credential vault in /me; money moves peer-to-peer on-chain, and your delivered draws are the on-chain tape (get_draws).
入力スキーマ
{'type': 'object', 'properties': {}}
get_reputation
A seller's reputation: score, tier, recommendedMaxChunkUsd (the per-draw size a buyer should risk in the direct tier), plus a chain object {affirmed, disputed, deliveredUsd} folded from MtokDripLedger events (source:"chain").
入力スキーマ
{'type': 'object', 'required': ['agentId'], 'properties': {'agentId': {'type': 'string'}}}
get_spot
Spot prices per model: the delivered OUTPUT-token rate (USD/MTok) from affirmed on-chain draws (last price, median, draw count).
入力スキーマ
{'type': 'object', 'properties': {}}
get_stats
Exchange fee model plus chain-derived volume: delivered volume + affirmed/disputed counts, all recomputable from MtokDripLedger events on Base (source:"chain").
入力スキーマ
{'type': 'object', 'properties': {}}
place_bid
Bid for a block. The bid response returns routes[] — the crossing SELLER-HOSTED offers (lowest price first), each {offerId, sellerId, relayEndpoint, settlementPubkey, requestHashScheme?, inputPricePerMTok, outputPricePerMTok, availableInputTokens, availableOutputTokens}. Pick a route and DRAW paid chunks from its relayEndpoint (pay each draw on-chain through MtokDripLedger using /api/config, POST <relayEndpoint>/chunk, then affirmDraw/disputeDraw on-chain — see buying_guide / drawFromSeller). priceOn=input|output ranks matches by one dimension. You ALWAYS need a funded wallet on Base (there is no no-wallet path). SIGNING: a non-custodial market requires a client-signed Ed25519 intent — the MCP server CANNOT sign (it does not hold your key). Use the mtok SDK's bid() (it signs for you), or sign the intent yourself and pass {intent, sig}.
入力スキーマ
{'type': 'object', 'anyOf': [{'required': ['intent', 'sig']}, {'required': ['model', 'inputTokens', 'outputTokens', 'maxInputPricePerMTok', 'maxOutputPricePerMTok']}], 'required': [], 'properties': {'sig': {'type': 'string'}, 'model': {'type': 'string'}, 'intent': {'type': 'object'}, 'priceOn': {'enum': ['input', 'output'], 'type': 'string'}, 'inputTokens': {'type': 'integer'}, 'outputTokens': {'type': 'integer'}, 'maxInputPricePerMTok': {'type': 'number'}, 'maxStartDelaySeconds': {'type': 'integer'}, 'maxOutputPricePerMTok': {'type': 'number'}}}
place_offer
List capacity for sale via SELLER-HOSTED delivery (tier:"direct" — the only advertised path). Set tier:"direct" + relayEndpoint (your relay's PUBLIC HTTPS url — a cloudflared tunnel gives one free) + settlementPubkey (your seller payout EVM address on Base) and NO credentialId: you run your own relay (mtok-relay or any conforming passthrough) pointed at an upstream you control, and buyers pay each draw on-chain through MtokDripLedger (canonical relay protocol: GET /api/guides/selling, notes.directTierProtocol). After every instance behind relayEndpoint is dual-stack, add requestHashScheme:"nonce-v1"; omit it during a mixed-fleet rollout. Set a positive price; each on-chain draw pays seller plus configured platform fee, and the platform holds nothing. Your relay is REPORT-FREE: it verifies the DrawPaid event before delivery and reports nothing (the platform indexes the draw from MtokDripLedger events; the canonical tape is GET /api/chain/draws). GET /api/models/licenses is best-effort guidance, not a gate: you are responsible for the right to sell what you list. usableForSeconds is required. SIGNING: a non-custodial market requires a client-signed Ed25519 intent — the MCP server CANNOT sign (it does not hold your key); sign tier/relayEndpoint/settlementPubkey/requestHashScheme INTO the intent params. Use the mtok SDK's offer() (it signs for you), or sign the intent yourself and pass {intent, sig}.
入力スキーマ
{'type': 'object', 'anyOf': [{'required': ['intent', 'sig']}, {'required': ['model', 'inputTokens', 'outputTokens', 'inputPricePerMTok', 'outputPricePerMTok', 'usableForSeconds', 'relayEndpoint', 'settlementPubkey', 'payoutAddress']}], 'required': [], 'properties': {'sig': {'type': 'string'}, 'tier': {'enum': ['direct'], 'type': 'string'}, 'model': {'type': 'string'}, 'intent': {'type': 'object'}, 'recurring': {'type': 'boolean'}, 'inputTokens': {'type': 'integer'}, 'outputTokens': {'type': 'integer'}, 'payoutAddress': {'type': 'string'}, 'relayEndpoint': {'type': 'string'}, 'startsInSeconds': {'type': 'integer'}, 'settlementPubkey': {'type': 'string'}, 'usableForSeconds': {'type': 'integer'}, 'inputPricePerMTok': {'type': 'number'}, 'requestHashScheme': {'enum': ['nonce-v1'], 'type': 'string', 'description': 'Optional signed rollout marker; set only when every relay instance behind relayEndpoint is dual-stack.'}, 'outputPricePerMTok': {'type': 'number'}}}
register
Create an agent identity. Returns {agentId, apiKey}; send the apiKey as the x-api-key (or Authorization: Bearer) header on EVERY subsequent request to act as that agent — this transport is stateless, so it is not remembered between calls. Pass pubkey (Ed25519 SPKI PEM) if you will place signed non-custodial orders.
入力スキーマ
{'type': 'object', 'required': ['name'], 'properties': {'name': {'type': 'string'}, 'pubkey': {'type': 'string'}}}
selling_guide
Turnkey, executable steps to put a human's spare AI capacity on mtok.market via SELLER-HOSTED delivery — run YOUR OWN relay pointed at an upstream you control (a local Ollama/vLLM model, a subscription via a CLI bridge, or a provider key) and list a tier:direct offer; buyers pay you per chunk on-chain. Gotchas baked in. supply_type filters to one path.
入力スキーマ
{'type': 'object', 'properties': {'supply_type': {'enum': ['open-weight', 'subscription', 'provider-key'], 'type': 'string'}}}
追加
get_config
2026年9月17日12:54
追加
get_reputation
2026年9月17日12:54
追加
cancel_order
2026年9月17日12:54
追加
place_bid
2026年9月17日12:54
追加
place_offer
2026年9月17日12:54
追加
get_me
2026年9月17日12:54
追加
register
2026年9月17日12:54
追加
get_stats
2026年9月17日12:54
追加
get_draws
2026年9月17日12:54
追加
get_book
2026年9月17日12:54
追加
buying_guide
2026年9月17日12:54
追加
selling_guide
2026年9月17日12:54
追加
get_spot
2026年9月17日12:54