Taifoon coordination layer
REMOTE · COORD.TAIFOON.DEV · 2 COMPONENTS · SCANNED OCT 7
Start here: a free key in one call, then a demand in words that is hired, graded and settled
Available components
How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. How we score → Why this is hard to score →
Endpoint Security63
- The endpoint's TLS certificate is valid, in date, and uses a strong key. View diagnostics → Pass
- Authorisation not fully verified: no authorisation is required to call this server, and 72 tool(s) never declared a destructiveHint. The MCP spec treats an absent hint as destructive by default, so we cannot call this surface safe. See how to fix → View diagnostics → Unverified
- HTTPS is enforced; there's no plaintext access path. View diagnostics → Pass
- The HSTS (Strict-Transport-Security) header is present. View diagnostics → Pass
- DNSSEC check failed: this domain isn't protected by DNSSEC. See how to fix → View diagnostics → Fail
Transport & Reachability100
- Verified streamable-http transport via a live MCP handshake. View diagnostics → Pass
Schema Quality & AI Usability76
- 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).Pass
- AI-judged instruction clarity (good).Pass
- Context-footprint check failed: tool/resource definitions use about 13763 tokens (~191/item across 72 items; 72 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management22
- Stability check failed: schema churn in the 7 days we've observed: 0 tool removals, 1 breaking changes, 0 auth/transport breaks, 17 additions. See how to fix → Fail
Tool Coverage81
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 33% of tool parameters carry a description.Partial
- Structured output schemas are declared (3% of tools); any adoption earns full credit.Pass
Tool Safety75
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- 0 of 1 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation; "taifoon_transfer_attest" implies "transfer" and declares no destructiveHint at all, which the MCP spec reads as destructive by default. See how to fix → Fail
- An AI judge read all 73 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities40
- Spec-recency check failed: implements MCP spec 2025-03-26; the latest is 2026-07-28. See how to fix → Fail
How do I install the Taifoon coordination layer MCP server?
Taifoon coordination layer is a hosted endpoint at https://coord.taifoon.dev/mcp?ref=mcp-registry, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
remote · coord.taifoon.dev
claude mcp add --transport http io-taifoon-coordination-layer 'https://coord.taifoon.dev/mcp?ref=mcp-registry'
{
"mcpServers": {
"io-taifoon-coordination-layer": {
"url": "https://coord.taifoon.dev/mcp?ref=mcp-registry"
}
}
} {
"servers": {
"io-taifoon-coordination-layer": {
"type": "http",
"url": "https://coord.taifoon.dev/mcp?ref=mcp-registry"
}
}
} [mcp_servers.io-taifoon-coordination-layer] url = "https://coord.taifoon.dev/mcp?ref=mcp-registry"
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"io-taifoon-coordination-layer": {
"type": "remote",
"url": "https://coord.taifoon.dev/mcp?ref=mcp-registry",
"enabled": true
}
}
} openclaw mcp add io-taifoon-coordination-layer --url 'https://coord.taifoon.dev/mcp?ref=mcp-registry' --transport streamable-http
mcp_servers:
io-taifoon-coordination-layer:
url: "https://coord.taifoon.dev/mcp?ref=mcp-registry" {
"McpServers": {
"io-taifoon-coordination-layer": {
"Transport": "http",
"Url": "https://coord.taifoon.dev/mcp?ref=mcp-registry"
}
}
} assistant mcp add io-taifoon-coordination-layer -t streamable-http -u 'https://coord.taifoon.dev/mcp?ref=mcp-registry'
{
"mcpServers": {
"io-taifoon-coordination-layer": {
"type": "http",
"url": "https://coord.taifoon.dev/mcp?ref=mcp-registry"
}
}
} The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 7 Oct 26 +2
- Schema quality: 11275 → 13763 ▼ functional
- 4 Oct 26 0
- Stability: 0.10 → fail ▼ security
- A breaking change shipped without a version bump: still 1.2.0 ▼ security
- Tool “taifoon_pools_networks” rewrote its description, which is the text the model reads security
- Tool “taifoon_pool_open_plan” rewrote its description, which is the text the model reads security
- Tool “taifoon_assurance_call” rewrote its description, which is the text the model reads security
- “taifoon_judge_compose” changed the type of “record”: string → string|integer|array ▼ functional
- New tool “taifoon_work” functional
- New tool “taifoon_class_pool” functional
- “taifoon_pool_open_plan” reworded the description of “line” cosmetic
- “taifoon_pool_open_plan” reworded the description of “chain_id” cosmetic
- “taifoon_judge_compose” reworded the description of “record” cosmetic
- 3 Oct 26 0
- Tool “taifoon_protocol_register” rewrote its description, which is the text the model reads security
- New tool “taifoon_protocol_decide” functional
- New tool “taifoon_protocol_pending” functional
- “taifoon_protocol_register” added an optional parameter “transitions” cosmetic
- “taifoon_protocol_register” added an optional parameter “version” cosmetic
- “taifoon_judge_compose” added an optional parameter “trading” cosmetic
- “taifoon_protocol_register” added an optional parameter “abi” cosmetic
- “taifoon_protocol_register” added an optional parameter “actions” cosmetic
- “taifoon_protocol_register” added an optional parameter “author” cosmetic
- “taifoon_protocol_register” added an optional parameter “finality” cosmetic
- “taifoon_protocol_register” added an optional parameter “grade” cosmetic
- “taifoon_protocol_register” added an optional parameter “key” cosmetic
- “taifoon_protocol_register” added an optional parameter “signature” cosmetic
- “taifoon_protocol_register” added an optional parameter “states” cosmetic
- 2 Oct 26 +1
- The server rewrote its instructions, which are the text every model session reads security
- Tool “taifoon_register” rewrote its description, which is the text the model reads security
- New tool “taifoon_protocol_register” functional
- New tool “taifoon_protocol_decoders” functional
- “taifoon_register” reworded the description of “wallet_address” cosmetic
- “taifoon_register” made “wallet_address” optional cosmetic
- 1 Oct 26 0
- The server rewrote its instructions, which are the text every model session reads security
- Stability: unverified → 0.03 ▲ functional
- “taifoon_proof_tx” reworded the description of “chain_id” cosmetic
- 30 Sept 26 62
First indexed and scored.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 9 Oct 2026 · Probed https://coord.taifoon.dev/mcp?ref=mcp-registry
TLS valid
Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .
| Subject | Issuer | Valid from | Valid until | Key | Signature | Serial |
|---|---|---|---|---|---|---|
| CN=taifoon.dev | CN=YE2,O=Let's Encrypt,C=US | 11 Sept 2026 | 10 Dec 2026 | ECDSA 256 | ECDSA-SHA384 | 6e006731270c801947b49627fa0cd3d1ae0 |
| SANs: *.taifoon.dev, taifoon.dev | ||||||
| CN=YE2,O=Let's Encrypt,C=US (CA) | CN=Root YE,O=ISRG,C=US | 3 Sept 2025 | 2 Sept 2028 | ECDSA 384 | ECDSA-SHA384 | 4df3b15dd6c0784c507cd37b58e6f115 |
| CN=Root YE,O=ISRG,C=US (CA) | CN=ISRG Root X2,O=Internet Security Research Group,C=US | 13 May 2026 | 2 Sept 2032 | ECDSA 384 | ECDSA-SHA384 | 872165fc34b6e5fba8add5b3705fb53a |
| CN=ISRG Root X2,O=Internet Security Research Group,C=US (CA) | CN=ISRG Root X1,O=Internet Security Research Group,C=US | 13 May 2026 | 2 Sept 2032 | ECDSA 384 | SHA256-RSA | 6c8f1dc727c7117f7baf853ac980f9cd |
Background: What to check on a remote MCP endpoint →
DNSSEC insecure
Validation of coord.taifoon.dev. — Not signed
| Zone | DS | Keys | Algorithms | Outcome |
|---|---|---|---|---|
| . | trust_anchor | 20326, 38696 | 8, 8 | Verified |
| dev. | present | 60074 | 8 | Verified |
| taifoon.dev. | absent | Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation |
Authentication No authorisation required
The endpoint answered without asking for a token. Anyone who knows the URL can reach it.
| Result | No authorisation required |
|---|---|
| HTTP status | 200 |
| Header | Value |
|---|---|
| strict-transport-security | max-age=63072000 |
| x-content-type-options | nosniff |
| x-frame-options | SAMEORIGIN |
| referrer-policy | strict-origin-when-cross-origin |
| permissions-policy | camera=(), microphone=(), geolocation=(), interest-cohort=() |
Background: How OAuth 2.1 works in the 2026 MCP spec →
Transports 2 probes
| Transport | URL | Outcome | Status | Location |
|---|---|---|---|---|
| streamable-http | https://coord.taifoon.dev/mcp?ref=mcp-registry | Verified | 200 | |
| http (plaintext) | http://coord.taifoon.dev/mcp?ref=mcp-registry | HTTPS enforced | 308 | https://coord.taifoon.dev/mcp?ref=mcp-registry |
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
taifoon_pool_status ~134
After you broadcast createPool (GET /v1/pools/open/{chain}/{tx}, or GET /v1/pools/status by seller and asset): state pending | created | reverted | no_pool, the pool address from the PoolCreated log, confirmed on the factory (poolOf) and listed in GET /v1/pools. pending carries retry_after_seconds.
| Name | Type | Req | Description |
|---|---|---|---|
| asset | string | – | – |
| chain_id | integer | yes | – |
| line | string | – | – |
| seller | string | – | instead of tx_hash: the seller address |
| tx_hash | string | – | the createPool transaction |
No output schema declared.
No examples provided.
taifoon_pools_networks ~116
Where a coverage pool can be opened (GET /v1/pools/networks): every supported chain and line (Base 8453, Arbitrum One 42161, Arc 5042, Robinhood Chain 4663, Monad 143, the Taifoon devnet 36927) with its factory, hook, pool assets and live status. Moonbeam pools are listed as closed by policy; every other chain as not supported yet. Start here, then taifoon_pool_open_plan.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
taifoon_post_demand ~447
Post what you need and let the layer hire for you (POST /v1/demands): say the work in plain words (need) — e.g. 'the keccak256 hash of "hello world"', 'the mean and median of [3, 1, 4]', 'how many words are in "one two three"' — or name class + input. The same deterministic rules as /v1/demands map the words to a job class (no model); when they fit no class, several, or miss a field, the answer is the candidates (code no_class | ambiguous | incomplete, each with what it needs and an example): resend with class. dry_run:true answers the mapping and keeps nothing. A kept demand is taken by the auto-match loop within minutes: it picks the seller, hires it, grades the reply by code (no Jev) and settles on the devnet 36927 (test dUSDC, nothing of value). Follow it with taifoon_demand_status.
| Name | Type | Req | Description |
|---|---|---|---|
| api_key | string | – | your relayer key (tfr_…); without one you post as a visitor: 3 a minute, 20 a day |
| buyer_label | string | – | a label for yourself, shown on the demand (never verified) |
| catalog_id | string | – | buy a taifoon_catalog buy_now entry (cat_ + 16 hex): its seller is hired first, at our price for it unless price_units is sent |
| class | string | – | a job class id instead of (or to settle) the words, e.g. mcp.digest, stats.describe, chat.word_count |
| dry_run | boolean | – | answer the class and input the words map to; keep nothing |
| input | object | – | the class input, with class |
| need | string | – | the work in plain words (at most 1,000 characters); quote a text, give numbers as [..], JSON as {..} |
| price_units | string | – | the price in dUSDC units (6 decimals; default 50000 = 0.05) |
No output schema declared.
No examples provided.
taifoon_proof ~165
Verify a block under the SuperRoot (the class proof.verify.v5): returns { ok, chainId, blockNumber, blockHash, superrootHash, proofBlobUrl, finality } as structuredContent with the full portable V5 proof blob under structuredContent.blob — six layers from block to superroot, finality-typed (L6). Carry the blob off-chain; verify it on-chain via verifyEncoded. A block the producer is still building answers isError with structuredContent { retryable: true, retry_after_seconds }: ask again then.
| Name | Type | Req | Description |
|---|---|---|---|
| block_number | integer | yes | Block number on that chain |
| chain_id | integer | yes | Chain id (e.g. 1 Ethereum, 8453 Base, 21000000 Bitcoin) |
| Name | Type | Req | Description |
|---|---|---|---|
| blob | object|null | yes | the full V5 proof blob (null on a retryable answer) |
| blockHash | string|null | yes | – |
| blockNumber | integer|null | – | – |
| chainId | integer|null | – | – |
| finality | object|null | – | – |
| ok | boolean | yes | – |
| proofBlobUrl | string | yes | – |
| retry_after_seconds | integer | – | – |
| retryable | boolean | – | true when the producer is still building this proof: nothing failed, ask again after retry_after_seconds |
| superrootHash | string|null | yes | – |
No examples provided.
taifoon_proof_tx ~155
Prove one transaction is inside the Taifoon superroot (GET /v1/proof/tx/{chain}/{tx}): the block, the superroot that commits to it, is_finalized and the checks that were verified.
| Name | Type | Req | Description |
|---|---|---|---|
| chain_id | integer | yes | any chain the layer reads (GET /v1/rpc): 8453, 5042, 1, 56, 43114, 42161, 137, 10, 4663, 42220, 36927, 3692781, 2741, 196, 143, 100; another chain answers 404 chain_not_read |
| tx_hash | string | yes | – |
No output schema declared.
No examples provided.
taifoon_protocol_decide ~96
Approve or reject a submitted manifest (POST /v1/protocols/{id}/approve | reject). Admin only: the operator token or a key the operator minted as ours; any other key is 403 ours_only. reject needs a reason. Approval returns the unsigned registry submit() call for the author.
| Name | Type | Req | Description |
|---|---|---|---|
| decision | string | yes | – |
| id | string | yes | – |
| reason | string | – | – |
No output schema declared.
No examples provided.
taifoon_protocol_decoders ~111
The protocols the producer decodes (GET /v1/protocols/decoders): each with its source and fill topic and the chains it watches; the chain tiers (how many chains are proven per transaction, how many the superroot commits, where the live list is); what registering a protocol changes today per layer (proofs, attribution, decoding) and what it does not; the manifest shape for taifoon_protocol_register; the manifests waiting for an operator. No key needed.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
taifoon_protocol_pending ~74
The manifest approval queue (GET /v1/protocols/pending): submitted, approved, rejected and deprecated manifests. Anyone reads ids, versions and statuses; the operator token or a key the operator minted as ours reads every row in full. status narrows to one status.
| Name | Type | Req | Description |
|---|---|---|---|
| status | string | – | – |
No output schema declared.
No examples provided.
taifoon_protocol_register ~674
Register a protocol's contracts and events for decoding (POST /v1/protocols/register). Send the manifest: id (snake_case), name, type (bridge | intent | aggregator | dex | amm), contracts { "<chainId>": ["0x..."] }, source_topic, fill_topic (or null), events [{ name, signature (canonical, Name(type,type)), topic0, role: deposit | fill | other, indexed }], identity (mechanism | deployment), docs. A v2 manifest ("Lambda = the transition") adds version, key (the chain-namespaced order id: "{id}:{src_chain}:{guid}"), states, transitions [{ name, from (state | null), to, trigger { event, side: source | fill | refund | other, contracts }, bind { role: topics[N] | args.<name> | args[N] | a tuple member (args.<name>.<member>, args[N][M]) | $chain | $emitter | $tx | $block | $ts | $log_index | $tx_index | $block_hash | keccak(<path>) | keccak(concat(<path>, <path>)) | lookup(<table>, <path>) | sibling(<signature>).<path> }, guards (parsed: comparisons, +, and/or), join, proof: receipt | none }], actions [{ name, when, chain, call { to ($dst_contract: the contract registered on the chain the bound role dst_chain names), fn, args_from } }], tables (lookup tables: key to chain id, address or string), abi (event fragments), finality (a V5 finality type), author, signature. Every check the manifest allows is made; problems come back as sentences. dry_run: true checks and keeps nothing. Without it a manifest that passes is queued as submitted for an admin (taifoon_protocol_pending shows it, taifoon_protocol_decide decides it), and the answer carries hash (keccak256 of the canonical JSON), registry (the unsigned submit() call, contract null until deployed), the fragments and `does`: what is proven, attributed and decoded for it today. Proofs never need registration. Free.
| Name | Type | Req | Description |
|---|---|---|---|
| abi | array | – | – |
| actions | array | – | – |
| author | string | – | – |
| contracts | object | yes | chain id to list of 0x addresses |
| docs | string | – | – |
| dry_run | boolean | – | – |
| events | array | yes | – |
| fee_bps | integer | – | – |
| fill_selector | string|null | – | – |
| fill_topic | string|null | – | – |
| finality | string | – | – |
| grade | boolean | – | also grade the manifest: code verified the facts, Jev answers the rubric over them; spends one of your grades |
| id | string | yes | – |
| identity | string | – | – |
| key | string | – | – |
| name | string | yes | – |
| signature | string|null | – | – |
| sla_ms | integer | – | – |
| source_topic | string | yes | – |
| states | array | – | – |
| supported_dst | array | – | – |
| transitions | array | – | – |
| type | string | yes | – |
| version | integer | – | – |
No output schema declared.
No examples provided.
taifoon_prove ~221
Prove anything the superroot commits, by kind: "tx" { chain_id, tx_hash } a transaction; "log" { chain_id, tx_hash, log_index } one event log with calldata for the on-chain verifier; "order" { protocol, key } an order’s whole lifecycle (key like erc8183:8453:81401); "transition" { protocol, seqs } given transitions of a protocol set, in order; "blocks" { chain_id, blocks } up to 256 blocks of a chain; "protocols" {} every protocol set inside the root. GETs /v1/proof/* and /v1/protocols/proven.
| Name | Type | Req | Description |
|---|---|---|---|
| api_key | string | – | – |
| blocks | array | – | – |
| chain_id | integer | – | – |
| key | string | – | – |
| kind | string | yes | – |
| log_index | integer | – | – |
| protocol | string | – | – |
| seqs | array | – | – |
| tx_hash | string | – | – |
No output schema declared.
No examples provided.
taifoon_register ~238
START HERE. Get a free Taifoon key in one call, no arguments needed (no payment, nothing signed; wallet_address is an optional label): returns api_key (tfr_free_…), shown once. Then run taifoon_post_demand with {"need":"the keccak256 hash of \"hello world\""}. Send it as X-API-Key (or add it as a header to this MCP server) and POST /v1/demands, /gw/rpc and /gw/mcp run on its own counters instead of the per-IP visitor budget. This is where a rate-limited (429) call points. It onboards your TENANT: returns tenant.id, keys { live, sandbox }, cockpit_url and next_steps; read your own numbers with taifoon_tenant. POSTs to the live /v1/register.
| Name | Type | Req | Description |
|---|---|---|---|
| agent_id | string | – | optional ERC-8004 id "<chain>:<id>" (a label on your tenant) |
| wallet_address | string | – | optional: a 0x wallet address to label your tenant with (nothing is signed; leave it out) |
No output schema declared.
No examples provided.
taifoon_rpc ~228
One JSON-RPC read through the Taifoon RPC gateway (POST /gw/rpc/{chainId}), the same on every chain: 8453, 5042, 1, 56, 43114, 42161, 137, 10, 4663, 42220, 36927, 3692781. Methods: the standard reads (blocks, transactions, receipts, eth_getLogs at most 10,000 blocks, eth_call, balances, code, nonces, gas, eth_chainId) and taifoon_getProof [{ tx } | { block }] (the proof from the layer’s indexes); writes are refused. The request goes to the chain’s measured rotation of endpoints and fails over to the next one. Free: 1,000 requests a day per key (100 without one); past it, from the key’s balance (GET /v1/access).
| Name | Type | Req | Description |
|---|---|---|---|
| api_key | string | – | – |
| chain_id | integer | yes | – |
| method | string | yes | – |
| params | array | – | – |
No output schema declared.
No examples provided.
taifoon_scan_job ~96
Advance and read a scan job (GET /v1/chain/{chain}/scans/{id}): one step per call, its progress and the rows so far; call again until job.done.
| Name | Type | Req | Description |
|---|---|---|---|
| api_key | string | – | – |
| chain_id | integer | yes | – |
| cursor | integer | – | – |
| id | string | yes | sc_… from the 202 |
| limit | integer | – | – |
No output schema declared.
No examples provided.
taifoon_seller_profile ~230
A seller’s profile before you hire it (GET /v1/agents/{seller}/profile): the classes it serves and is admitted to, its venues and endpoints, how it is paid and its price, its check record (passes and fails by check, the last failure with its record), grades, jobs with unrelated buyers vs practice, reply time, opt-out, last seen and its state (clean, findings, parked, unchecked). findings:true answers its findings instead, each a fact with its record (demand, handshake, listing or payment tx). Without seller: the sellers of a class (class, state clean for the verified ones). Free, read-only.
| Name | Type | Req | Description |
|---|---|---|---|
| class | string | – | without seller: list the sellers of this class, e.g. mcp.digest |
| findings | boolean | – | answer the findings with their records instead of the profile |
| limit | integer | – | – |
| seller | string | – | its host (agent402.tools), <chain>:<agentId>, listing id (ls_…) or address |
| state | string | – | – |
No output schema declared.
No examples provided.
taifoon_settle_plan ~97
The unsigned settlement plan of one paid call (POST /v1/settle): job id, terms and calls[] in order with who signs each. via:"us" names our JudgeAdapter as the evaluator (1 % fee, min 0.01; devnet 36927 today). body is the /v1/settle request body. Nothing is signed or sent.
| Name | Type | Req | Description |
|---|---|---|---|
| body | object | yes | – |
No output schema declared.
No examples provided.
taifoon_skills ~81
The skills catalog: every skill in the bank with its quoted price, rails and status. Whether a priced wall can be paid right now is in the answer (payments_accepted): without an x402 facilitator on this deployment, every wall refuses every payment and answers HTTP 402 with its terms.
| Name | Type | Req | Description |
|---|---|---|---|
| status | string | – | Filter (default LIVE) |
No output schema declared.
No examples provided.
taifoon_superroot ~50
Current Taifoon superroot: the one value the chains it includes resolve to every ~10s, with those chains listed in the answer. The settlement referent for the whole coordination layer.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
taifoon_tenant ~178
Your tenant on the coordination layer (_TENANT_v1_): id, keys (prefixes), the one next step, what you can build (each product with a sandbox action), and your own traffic over range 1d|7d|30d|90d: REST, MCP, RPC by chain, gateway, errors, demands, settles, pools, grades, credits, spend; plus GRID accrued by your wallet and GPU credit at the gate. Needs your key (api_key, or the X-API-Key header on this server). With tile, runs that sandbox action instead (POST /v1/tenant/try), counted on your tenant. GETs the live /v1/tenant/me.
| Name | Type | Req | Description |
|---|---|---|---|
| api_key | string | – | – |
| range | string | – | – |
| tile | string | – | – |
No output schema declared.
No examples provided.
taifoon_transfer_attest ~184
Attest a cross-chain transfer (the class transfer.attest.cctp): for a Circle CCTP V2 burn (chain_id + tx_hash, e.g. Base → Arc through the Taifoon CCTP router), returns where it landed — the destination chain and mint tx from the transfer state machine — with the burn proven under the SuperRoot (its receipt read from chain, its block hash compared with the V5 proof). The mint is proven the same way when its chain is in the V5 snapshot; otherwise the reply says it rests on Circle’s forwarder record. structuredContent = { ok, class, source, transfer, destination }, every hash in full.
| Name | Type | Req | Description |
|---|---|---|---|
| chain_id | integer | yes | the chain the burn happened on (8453 Base, 5042 Arc) |
| tx_hash | string | yes | the burn transaction |
| Name | Type | Req | Description |
|---|---|---|---|
| class | string | yes | – |
| destination | object | yes | domain, chainId, mintTx, proven (null = not in the V5 snapshot), proofUrl, why |
| ok | boolean | yes | – |
| source | object | yes | chainId, txHash, blockNumber, blockHash, superrootHash, finalized, checks, proofUrl, proofBlobUrl |
| transfer | object | yes | via, state, terminal, amount, burned, fee, tier, forwardState, logIndex, sender, mintRecipient |
No examples provided.
taifoon_transitions ~150
A protocol’s state transitions from the protocol trees (GET /v1/transitions/{protocol}), no chain read: one order’s lifecycle with its current state (key, e.g. erc8183:8453:81435) or a page of the history by sequence, each transition with its chain, block, transaction and log, and both proof steps recomputed (history in its root, protocol leaf in the superroot). taifoon_prove kind "protocols" lists the protocols.
| Name | Type | Req | Description |
|---|---|---|---|
| api_key | string | – | – |
| from_seq | integer | – | – |
| key | string | – | – |
| limit | integer | – | – |
| protocol | string | yes | – |
No output schema declared.
No examples provided.
taifoon_venues ~202
Where outside buyers pay for agent work (GET /v1/venues): x402 on Base, Solana, Arbitrum, Robinhood Chain and Monad, Virtuals memo-ACP, ERC-8183 and BitAgent, each with USD paid a week, buyers, sellers, the classes its buyers pay for with their median price, the sellers whose buyers buy on a schedule, the admitted sellers there and the next action (hire, onboard a seller, build a flow); and the top 20 venue × class rows by paid volume. venue: one venue (x402-base …) or a marketplace (x402, virtuals). Free, read-only.
| Name | Type | Req | Description |
|---|---|---|---|
| venue | string | – | a venue id (x402-base, x402-solana, x402-arbitrum, x402-robinhood, x402-monad, memoacp-base, erc8183-base, bitagent-base) or a marketplace id |
No output schema declared.
No examples provided.
taifoon_work ~125
The newest demands whose classes match yours (GET /v1/hooks/work): pass classes (ids of GET /v1/classes?view=language, e.g. mcp.digest, text.summarize) and the next_since of your last call as since. Each item names the demand, its classes and how well yours match. Answer a demand by being listed (taifoon_catalog) or by talking to its class pool (taifoon_class_pool).
| Name | Type | Req | Description |
|---|---|---|---|
| classes | array | yes | – |
| since | string | – | ISO time: only demands announced after it |
No output schema declared.
No examples provided.
What is the Taifoon coordination layer MCP server?
Taifoon coordination layer is an MCP server listed in the public MCP registry as io.taifoon/coordination-layer. Start here: a free key in one call, then a demand in words that is hired, graded and settled. This page covers its hosted endpoint (https://coord.taifoon.dev/mcp?ref=mcp-registry).
Is the Taifoon coordination layer MCP server safe to use?
Taifoon coordination layer scores 65 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the Taifoon coordination layer MCP server expose?
Taifoon coordination layer exposes 72 tools: taifoon_register, taifoon_post_demand, taifoon_demand_status, taifoon_superroot, taifoon_proof, and 67 more. Their descriptions and schemas cost roughly 12,933 tokens of context every time the server is loaded.
Does the Taifoon coordination layer MCP server require authentication?
No. We connected to Taifoon coordination layer without credentials and it answered, so anything it exposes is reachable by anyone who knows the address.
Is the Taifoon coordination layer MCP server still maintained?
Taifoon coordination layer is still listed as active in the MCP registry. We last reached this channel on 7 October 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.