Taifoon coordination layer

Vault

taifoon_vault

Reads a tenant vault and builds the owner-signed acts that control it. Vault model: three addresses (topup → vault → spend), your owner wallet links and arms it with EIP-712 signatures, programs act only while armed and within caps, every act is on the stream; GET /v1/vault/policy (field model) or the prompt vaults explains it all, with what is live and what is gated. For the legacy key balance use taifoon_account. Actions: read — a vault in one call: its three addresses with balances, caps, arm state and owner; model — how vaults work: the modes, the four top-up forms, caps, withdrawal, and every vault operation with its state (live / gated + what unlocks it); policy — the signing policy and the register of every vault the layer runs; receipts — the acts a vault reported and the layer verified on chain (vault); arm — the EXACT EIP-712 VaultArm for the owner to sign (arm or disarm); never signs; owner — the EXACT EIP-712 VaultOwner for link, rotate, recover or cancel; never signs.

Input Schema

Name	Required	Description	Default
`days`	No	how long the arm lasts (default 7, at most 30) (actions: arm)
`armed`	No	true arms (default), false disarms (always honoured, no expiry rule) (actions: arm)
`owner`	No	the 0x wallet the act installs (link, rotate, recover); omitted for cancel (the current owner) (actions: owner)
`vault`	No	the tenant vault id, vault:tenant:<tenant> (e.g. vault:tenant:tenant-3) (actions: read, arm, owner)
`action`	No	what to do (default read): read \| model \| policy \| receipts \| arm \| owner	read
`params`	No	operation parameters, e.g. { "vault": "vault:tenant:tenant-3" } (actions: policy, receipts)
`api_key`	No	your tfr_ key (actions: policy, receipts)

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedOct 18, 2026

addedInput schema / properties / action

Added value: +{
+  "default": "read",
+  "description": "what to do (default read): read | model | policy | receipts | arm | owner",
+  "enum": [
+    "read",
+    "model",
+    "policy",
+    "receipts",
+    "arm",
+    "owner"
+  ],
+  "examples": [
+    "read"
+  ],
+  "type": "string"
+}

addedInput schema / properties / api_key

Added value: +{
+  "description": "your tfr_ key (actions: policy, receipts)",
+  "type": "string"
+}

addedInput schema / properties / armed

Added value: +{
+  "description": "true arms (default), false disarms (always honoured, no expiry rule) (actions: arm)",
+  "type": "boolean"
+}

addedInput schema / properties / days

Added value: +{
+  "description": "how long the arm lasts (default 7, at most 30) (actions: arm)",
+  "maximum": 30,
+  "minimum": 1,
+  "type": "integer"
+}

addedInput schema / properties / owner

Added value: +{
+  "description": "the 0x wallet the act installs (link, rotate, recover); omitted for cancel (the current owner) (actions: owner)",
+  "type": "string"
+}

addedInput schema / properties / params

Added value: +{
+  "description": "operation parameters, e.g. { \"vault\": \"vault:tenant:tenant-3\" } (actions: policy, receipts)",
+  "type": "object"
+}

changedInput schema / properties / vault / description

Previous value: -"the tenant vault id, vault:tenant:<tenant> (e.g. vault:tenant:tenant-3)"New value: +"the tenant vault id, vault:tenant:<tenant> (e.g. vault:tenant:tenant-3) (actions: read, arm, owner)"

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

AddedOct 18, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=true, and the description adds material context beyond them: the tool never signs (stated for both arm and owner), programs act only while armed and within caps, and some operations are gated with stated unlock conditions. It does not cover rate limits or error/auth failure behavior, so not a 5.

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

Conciseness3/5

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

Front-loaded with purpose, then model, then an action list, which is reasonable for a six-action tool. However it is a dense semicolon-chained run-on, repeats 'never signs' twice, and includes a tangent pointer ('GET /v1/vault/policy ... or the prompt vaults explains it all') that dilutes rather than informs.

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?

For a 7-parameter, multi-action tool with no output schema, the description covers all six actions, the three-address vault model, arming/caps, gating and the no-signing guarantee, and even implies return content for read ('three addresses with balances, caps, arm state and owner'). Return shapes for the other actions remain implicit, keeping it below 5.

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

Parameters3/5

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

Schema description coverage is 100% and the schema already tags each field with its applicable actions, so the description is largely redundant on parameters. It adds some value by tying arm/owner payloads to what the owner signs, but gives no format details beyond the schema. Baseline 3 is appropriate.

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?

States specific verbs and resource: reads a tenant vault and constructs the owner-signed EIP-712 acts (arm/owner) that control it, then enumerates all six actions with one-line scopes. It also distinguishes itself from the sibling by name ('For the legacy key balance use taifoon_account'), so an agent can route correctly without opening a schema.

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

Usage Guidelines4/5

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

Each action carries its own selection cue (read for one-call state, model for how vaults work, policy for the signing register, receipts for verified acts, arm/owner for the exact EIP-712 payload to sign), and the account alternative is named for the legacy-balance case. It lacks explicit when-not-to-use framing beyond that one exclusion, so it stops short of a 5.

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?