Taifoon coordination layer

Prove a chain fact

taifoon_prove

Read-onlyIdempotent

Proves blocks, transactions, logs and transfers under the Taifoon superroot. For reading chain data without a proof use taifoon_chain. Actions: tx — one transaction inside the superroot (chain, tx); item — anything the superroot commits, by kind: tx, log, receipt, state; block — a block under the superroot (proof.verify.v5); superroot — the current superroot and the chains it includes; transfer — attest a cross-chain CCTP transfer; finality — what a V5 finality type id means.

Input Schema

Name	Required	Description	Default
`key`	No	key (actions: item)
`kind`	No	kind (actions: item)
`seqs`	No	seqs (actions: item)
`action`	No	what to do (default tx): tx \| item \| block \| superroot \| transfer \| finality	tx
`blocks`	No	blocks (actions: item)
`api_key`	No	api key (actions: item)
`tx_hash`	No	tx hash (actions: tx, item, transfer)
`type_id`	No	type id (actions: finality)
`chain_id`	No	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 (actions: tx, item, block, transfer)
`protocol`	No	protocol (actions: item)
`log_index`	No	log index (actions: item)
`block_number`	No	Block number on that chain (actions: block)

Schema Changelog

Changes observed during successful MCP inspections.

Changed13 schema fields changedOct 18, 2026

addedInput schema / properties / action

Added value: +{
+  "default": "tx",
+  "description": "what to do (default tx): tx | item | block | superroot | transfer | finality",
+  "enum": [
+    "tx",
+    "item",
+    "block",
+    "superroot",
+    "transfer",
+    "finality"
+  ],
+  "examples": [
+    "tx"
+  ],
+  "type": "string"
+}

addedInput schema / properties / api_key / description
```
Added value: +"api key (actions: item)"
```

addedInput schema / properties / block_number

Added value: +{
+  "description": "Block number on that chain (actions: block)",
+  "type": "integer"
+}

addedInput schema / properties / blocks / description
```
Added value: +"blocks (actions: item)"
```

addedInput schema / properties / chain_id / description

Added value: +"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 (actions: tx, item, block, transfer)"

addedInput schema / properties / key / description
```
Added value: +"key (actions: item)"
```
addedInput schema / properties / kind / description
```
Added value: +"kind (actions: item)"
```
addedInput schema / properties / log_index / description
```
Added value: +"log index (actions: item)"
```
addedInput schema / properties / protocol / description
```
Added value: +"protocol (actions: item)"
```
addedInput schema / properties / seqs / description
```
Added value: +"seqs (actions: item)"
```

addedInput schema / properties / tx_hash / description

Added value: +"tx hash (actions: tx, item, transfer)"

addedInput schema / properties / type_id

Added value: +{
+  "description": "type id (actions: finality)",
+  "maximum": 15,
+  "minimum": 0,
+  "type": "integer"
+}

removedInput schema / required
```
Removed value: -[
-  "kind"
-]
```

AddedOct 4, 2026

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already establish read-only, idempotent, non-destructive, open-world behavior. The description adds proof-specific context such as proof.verify.v5, CCTP transfer attestation, and finality type-id interpretation, though it does not describe auth requirements or output shape.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded and compact, using semicolons to keep the action map dense without wasted prose. It is appropriately sized for a tool with six distinct actions, though the single-paragraph action list is somewhat heavy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With rich annotations, complete schema parameter descriptions, and no output schema, the description covers the tool's purpose, alternative sibling, and action semantics well. It omits return-value or error details, but those are not essential for selecting and invoking the tool in this context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is complete, so the baseline is 3, but the description adds meaning for the action enum beyond the schema's raw value list. It explains what each action does and associates some actions with relevant parameters, which helps the agent invoke the right mode.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: proving blocks, transactions, logs and transfers under the Taifoon superroot. It also names the sibling taifoon_chain and clearly differentiates proof-based reads from ordinary chain reads.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says to use taifoon_chain when reading chain data without a proof, and it enumerates each supported action with enough meaning for an agent to choose the right one. The action list functions as concrete per-mode usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Taifoon coordination layer tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?