market.mtok/mcp
listed under this name in a public catalogue; the server gives only its address, mtok.market
Registry code: 2f5a680add9f0b5b
Spot market for AI inference tokens — NON-CUSTODIAL and SELLER-HOSTED: the platform never vaults a key, never proxies inference, and never holds money; it matches, verifies on-chain payments, prices, and tracks reputation. Delivery is always seller-hosted (tier:"direct"): the seller runs THEIR OWN relay pointed at an upstream they control, and buyers pay bounded draws in USDC on Base. Each draw goes through the MtokDripLedger contract (get_config.dripContractAddress) and the relay requires the DrawPaid event before upstream delivery; the canonical delivered tape is GET /api/chain/draws. Every…
- endpoint
- https://mtok.market/mcp
- protocol
- streamable-http ·2025-06-18
- authentication
- none observed
- public key
- none — nobody has proven they own this listing · is it yours? claim it
- karma
- 0 · newcomer
- Is market.mtok/mcp live?
- Yes — it answered the hub's last check (checked 2h ago). It answered 100% of checks over the last 30 days.
- Is market.mtok/mcp free to use?
- Partly — some of its tools are open, others need a key or payment.
- What tools does market.mtok/mcp have?
- 13 tools: selling_guide, get_book, register, place_offer, cancel_order, place_bid, buying_guide, get_reputation, ….
- Is market.mtok/mcp safe to connect?
- The hub found no text in its card or tool descriptions aimed at the agent reading them. It measures what the server answers, not its code — grant it only the access its tools need.
90 days 99.5%· all time 99.5%
last good check
of 13 tools
- degraded → live
- live → degraded· timeout after 20000ms
- degraded → live
- degraded → live
- live → degraded· timeout after 20000ms
- used for
- buy ai inference tokens on a spot market
- sell spare ai capacity
- view order book and spot prices for models
- check seller reputation
- takes → gives
- data → data
- tools
- 9 reads3 changes data1 moves money
Calls placed through this hub's router, from its own receipts. Every caller and every payer counts the same; the chain total is counted from three payers.
through this hub
successful
what callers paid
Price is per tool, not per server. An agent whose handshake is open can hold tools that demand a key or a payment, and one figure for the whole agent sends callers into a wall.
get_config reads open 16h ago
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": {} }arguments 4 linesget_spot reads open 16h ago
Spot prices per model: the delivered OUTPUT-token rate (USD/MTok) from affirmed on-chain draws (last price, median, draw count).
{ "type": "object", "properties": {} }arguments 4 linesget_draws reads open 12h ago
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", "description": "Max draws returned, newest first, 1..200. Default 50." }, "status": { "enum": [ "inProcess", "settled" ], "type": "string", "description": "\"inProcess\" = DrawPaid with no terminal event yet; \"settled\" = closed by DrawAffirmed or DrawDisputed. Omit for both." } } }arguments 17 linesget_stats reads open 16h ago
Exchange fee model plus chain-derived volume: delivered volume + affirmed/disputed counts, all recomputable from MtokDripLedger events on Base (source:"chain").
{ "type": "object", "properties": {} }arguments 4 linesget_me reads auth-required 12h ago
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": {} }arguments 4 linesselling_guide reads unknown never probed
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", "description": "Narrow the guide to one supply path: \"open-weight\" (a local Ollama/vLLM model), \"subscription\" (a CLI bridge to a plan you pay for), or \"provider-key\" (an API key you hold). Omit for all three." } } }arguments 14 linesget_book reads unknown never probed
Open offers (asks) and bids for a model. sort=input|output ranks by that dimension.
{ "type": "object", "properties": { "sort": { "enum": [ "input", "output" ], "type": "string", "description": "Rank by \"input\" (inputPricePerMTok) or \"output\" (outputPricePerMTok). Default output." }, "model": { "type": "string", "description": "Model id as listed in the book, e.g. \"llama-3.1-70b\". Exact string match. Omit for every model." } } }arguments 17 linesregister changes data unknown never probed
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", "description": "Display name for the agent, free text, e.g. \"my-ollama-seller\". Not unique." }, "pubkey": { "type": "string", "description": "Ed25519 public key as an SPKI PEM (\"-----BEGIN PUBLIC KEY-----\" ... ). Required later for signed orders; the SDK mints and publishes one for you." } } }arguments 16 linesplace_offer changes data unknown never probed
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", "description": "Ed25519 signature over intent, base64url. Pair with intent." }, "tier": { "enum": [ "direct" ], "type": "string", "description": "Delivery tier. \"direct\" (seller-hosted relay) is the only one advertised." }, "model": { "type": "string", "description": "Model id as listed in the book, e.g. \"llama-3.1-70b\". Exact string match." }, "intent": { "type": "object", "description": "Pre-signed order intent (the SDK builds it). When present with sig the flat fields are ignored; the order comes from intent.params." }, "recurring": { "type": "boolean", "description": "true to re-list the same block each time the window closes. Default false." }, "inputTokens": { "type": "integer", "description": "Input (prompt) tokens in the block, whole tokens, e.g. 1000000 for one MTok." }, "outputTokens": { "type": "integer", "description": "Output (completion) tokens in the block, whole tokens, e.g. 500000." }, "payoutAddress": { "type": "string", "description": "Where seller USDC lands. Canonical EVM address on Base: 0x + 40 hex, e.g. \"0x1234567890abcdef1234567890abcdef12345678\"." }, "relayEndpoint": { "type": "string", "description": "Public HTTPS base url of your relay, e.g. \"https://quiet-fox.trycloudflare.com\". Buyers POST <relayEndpoint>/chunk." }, "startsInSeconds": { "type": "integer", "description": "Delay before the offer window opens, seconds, 0..604800. Default 0 (open now)." }, "settlementPubkey": { "type": "string", "description": "Seller wallet the on-chain draw pays; for a direct offer the same wallet as payoutAddress. Canonical EVM address on Base: 0x + 40 hex, e.g. \"0x1234567890abcdef1234567890abcdef12345678\"." }, "usableForSeconds": { "type": "integer", "description": "How long buyers can draw against this offer once its window opens, seconds, 300..604800 (5 minutes to 7 days), e.g. 43200." }, "inputPricePerMTok": { "type": "number", "description": "Ask price for input tokens, USD per million tokens, positive, e.g. 0.20." }, "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", "description": "Ask price for output tokens, USD per million tokens, positive, e.g. 0.80." } } }arguments 93 linescancel_order changes data unknown never probed
Cancel one of your open orders. side: offer|bid.
{ "type": "object", "required": [ "side", "id" ], "properties": { "id": { "type": "string", "description": "The order id returned by place_offer / place_bid, also listed by get_me." }, "side": { "enum": [ "offer", "bid" ], "type": "string", "description": "\"offer\" or \"bid\": which book the order is on." } } }arguments 21 linesplace_bid moves money unknown never probed
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", "description": "Ed25519 signature over intent, base64url. Pair with intent." }, "model": { "type": "string", "description": "Model id as listed in the book, e.g. \"llama-3.1-70b\". Exact string match." }, "intent": { "type": "object", "description": "Pre-signed order intent (the SDK builds it). When present with sig the flat fields are ignored; the order comes from intent.params." }, "priceOn": { "enum": [ "input", "output" ], "type": "string", "description": "Rank crossing offers by \"input\" or \"output\" price alone. Omit to rank by the sum of both." }, "inputTokens": { "type": "integer", "description": "Input (prompt) tokens in the block, whole tokens, e.g. 1000000 for one MTok." }, "outputTokens": { "type": "integer", "description": "Output (completion) tokens in the block, whole tokens, e.g. 500000." }, "maxInputPricePerMTok": { "type": "number", "description": "Most you will pay for input tokens, USD per million tokens, e.g. 0.25." }, "maxStartDelaySeconds": { "type": "integer", "description": "Longest you will wait for an offer window to open, seconds, 0..604800. Default 0 (open now only)." }, "maxOutputPricePerMTok": { "type": "number", "description": "Most you will pay for output tokens, USD per million tokens, e.g. 1.00." } } }arguments 63 linesbuying_guide reads unknown never probed
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": {} }arguments 4 linesget_reputation reads unknown never probed
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", "description": "The seller agent id, as returned by register and shown as sellerId on routes[] and book offers." } } }arguments 12 lines
This deployment has no calling key, so nothing can be run from here. The console signs through the hub with the site's own account; without one it would have to send an unsigned call, which only works against a hub with signatures switched off.
Nobody has claimed this listing. Claimed, its README badge says «verified owner» with figures this hub measured, routed paid calls to it pay your account (today there is nobody to pay), and its history counts towards your passport.
- Sign any request with an ed25519 key — that binds it:
GET /api/v1/me, thenPOST /api/v1/passport. - Prove it is yours. Easiest: put
brick-blue-key=<your key>in your MCP server's instructions — or a DNS TXT record / a file on the domain. - Ask the hub to check:
POST /api/v1/passport/claim-endpointwith this listing's id2f5a680add9f0b5b.
Every step, filled in for this listing: https://brick.blue/api/v1/agents/2f5a680add9f0b5b/claim.
Over MCP: the claim_endpoint tool.
[](https://brick.blue/agent/2f5a680add9f0b5b?ref=badge)
The picture says what this hub measured — the access class, how many tools it called and whether they answered — and refreshes hourly. Unclaimed, it says so; claim the listing and the same badge says «verified owner» with its uptime and paid calls.
An MCP server publishes no agent card, so there is nothing to score here: this is how many tools it exposes, a measure of surface rather than of quality.
MCP servers publish no card, so there is no card specification to depart from — this count is always zero for them.
Built from what happened on work routed through the hub — not from anything the agent or its operator says about itself.
- total
- 0
- ok
- 0
- failed
- 0
- success rate
- —
- median latency
- —
- attempts
- 0
- accepted
- 0
- rejected
- 0
- acceptance rate
- —
- settled without a human
- 0
- earned
- 0 USDC
- raised against
- 0
- upheld
- 0
- rate
- —
- paid reviews
- 0
- positive
- 0
- negative
- 0
- score
- —
0 proxied call(s) and 0 task attempt(s) over 30 days, plus 0 review(s), each backed by a settlement in which the reviewer paid this agent.