Skip to main content
Glama

Taifoon coordination layer

by io.taifoon
OverviewDiscussionsAdmin

Get a key

taifoon_register

Creates a tenant with a free key (tfr_free_…, shown once), or a free RPC key with its gateway URL and allowance. For reading an existing account use taifoon_account. Actions: tenant — a tenant and a free key in one call; wallet_address is an optional label, nothing is signed; rpc — a free RPC key for chain_id (default 1284) with the gateway URL, the allowance and the x402 terms; with payment, credits the key.

Input Schema

NameRequiredDescriptionDefault
txNoa settled subscribe payment whose credit was not written (actions: rpc)
usdcNousdc (actions: rpc)
actionNowhat to do (default tenant): tenant | rpctenant
api_keyNoapi key (actions: rpc)
paymentNothe x402 PAYMENT-SIGNATURE header value (base64) for the accepts a previous call returned (actions: rpc)
agent_idNooptional ERC-8004 id "<chain>:<id>" (a label on your tenant) (actions: tenant)
chain_idNothe chain you want to read (default 1284 Moonbeam); the answer names its gateway URL (actions: rpc)
pay_chain_idNothe pay chain of the transfer quote; absent = Base (actions: rpc)
wallet_addressNooptional: a 0x wallet address to label your tenant with (nothing is signed; leave it out) (actions: tenant)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed10 schema fields changed
    • addedInput schema / properties / action
      Added value: +{
+  "default": "tenant",
+  "description": "what to do (default tenant): tenant | rpc",
+  "enum": [
+    "tenant",
+    "rpc"
+  ],
+  "examples": [
+    "tenant"
+  ],
+  "type": "string"
+}
    • changedInput schema / properties / agent_id / description
      Previous value: -"optional ERC-8004 id \"<chain>:<id>\" (a label on your tenant)"New value: +"optional ERC-8004 id \"<chain>:<id>\" (a label on your tenant) (actions: tenant)"
    • addedInput schema / properties / api_key
      Added value: +{
+  "description": "api key (actions: rpc)",
+  "type": "string"
+}
    • addedInput schema / properties / chain_id
      Added value: +{
+  "description": "the chain you want to read (default 1284 Moonbeam); the answer names its gateway URL (actions: rpc)",
+  "type": "integer"
+}
    • addedInput schema / properties / pay_chain_id
      Added value: +{
+  "description": "the pay chain of the transfer quote; absent = Base (actions: rpc)",
+  "enum": [
+    8453,
+    42161,
+    5042,
+    143,
+    4663
+  ],
+  "type": "integer"
+}
    • addedInput schema / properties / payment
      Added value: +{
+  "description": "the x402 PAYMENT-SIGNATURE header value (base64) for the accepts a previous call returned (actions: rpc)",
+  "type": "string"
+}
    • addedInput schema / properties / tx
      Added value: +{
+  "description": "a settled subscribe payment whose credit was not written (actions: rpc)",
+  "type": "string"
+}
    • addedInput schema / properties / usdc
      Added value: +{
+  "description": "usdc (actions: rpc)",
+  "maximum": 500,
+  "minimum": 1,
+  "type": "integer"
+}
    • changedInput schema / properties / wallet_address / description
      Previous value: -"optional: a 0x wallet address to label your tenant with (nothing is signed; leave it out)"New value: +"optional: a 0x wallet address to label your tenant with (nothing is signed; leave it out) (actions: tenant)"
    • removedInput schema / required
      Removed value: -[]
  2. Changed2 schema fields changed
    • changedInput schema / properties / wallet_address / description
      Previous value: -"0x wallet address that will own the key"New value: +"optional: a 0x wallet address to label your tenant with (nothing is signed; leave it out)"
    • changedInput schema / required
      Previous value: -[
-  "wallet_address"
-]New value: +[]
  3. Changed1 schema field changed
    • addedInput schema / properties / agent_id
      Added value: +{
+  "description": "optional ERC-8004 id \"<chain>:<id>\" (a label on your tenant)",
+  "type": "string"
+}
  4. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare non-read-only, non-idempotent, open-world. The description adds real context beyond them: the key is shown once, nothing is signed for wallet_address, and payment credits an existing key. It doesn't cover error/rate-limit behavior, but adds meaningful operational detail.

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?

Front-loads the core action and alternative, then organizes detail by action. Dense but every clause carries information relevant to one of the actions; no filler.

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 9-parameter, no-output-schema tool, the description covers both actions, key delivery ('shown once'), and the x402/payment path, so an agent has enough to call it. Return-value detail is partially implied rather than fully specified.

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 coverage is 100%, so all nine parameters are already documented with per-action tags. The description largely restates schema facts (chain_id default 1284, wallet_address as optional label) rather than adding syntax or format beyond it, so baseline 3 applies.

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 a specific verb (creates) and concrete resources (tenant with free key, or free RPC key), and explicitly names the sibling taifoon_account for the read case. An agent can distinguish it from taifoon_account without opening either 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?

Explicitly routes the read case to taifoon_account and breaks out the two actions (tenant vs rpc) with what each returns. It lacks an explicit statement of when to pick rpc over tenant beyond the descriptions, but the context is clear.

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 toolsInspect
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