Taifoon coordination layer

Grade a delivery

taifoon_grade

Grades work with calibrated answers on your own TypeSafe key, and reads the judge's decisions. For proving a chain fact use taifoon_prove. Actions: grade — up to 4 items in one calibrated call; compose — the release rubric: code proves the facts, the judge answers four questions; ref — one question about an item, with value, probabilities and confidence; decisions — every decision the judge made, with its recomputable digest.

Input Schema

Name	Required	Description	Default
`id`	No	one decision id, for its full record and calldata (actions: decisions)
`kind`	No	kind (actions: decisions)
`mode`	No	mode (actions: compose)
`olas`	No	olas (actions: compose)
`items`	No	items (actions: grade)
`limit`	No	limit (actions: decisions)
`model`	No	model (actions: compose)
`state`	No	state (actions: compose, ref)
`action`	No	what to do (default grade): grade \| compose \| ref \| decisions	grade
`job_id`	No	job id (actions: compose)
`record`	No	where the decision and its answers are also written on chain: none (default: receipt and digests only), devnet (free), base, or the name or chain id of any live network, or a list of them; GET /v1/judge/record/networks lists the live networks with the price of a record now. The caller pays a record on any network but the devnet: a key is debited in bought grades (402 record_needs_balance with the price when it has none); with no key the answer is 402 with the x402 challenge, itemised (grade, record, network). A network that is not live answers 400 record_network_not_live with the live ones (actions: compose)
`answers`	No	mode answers: id → { value, confidence, probabilities } for each of the four questions prepare returned (actions: compose)
`api_key`	No	api key (actions: grade, compose, ref)
`options`	No	options (actions: grade, ref)
`trading`	No	a trading epoch to grade: { mandate: { markets[], venues[], period { from, to }, max_order_size, max_notional, max_position, allow_short?, kind?, owner?, attribution? }, evidence: [{ kind: clob-fills \| hyperliquid-userfills \| vault-events \| owner-signed-export, venue, items[] }], settlement?, stepper?, submitted? }; code runs the class checks (each kind's reader verifies what it can), then Jev answers over those facts (actions: compose)
`chain_id`	No	chain id (actions: compose)
`question`	No	question (actions: grade, ref)
`price_usdc`	No	price usdc (actions: compose)
`answered_by`	No	answered by (actions: compose)
`execution_id`	No	execution id (actions: compose)
`handshake_id`	No	handshake id (actions: compose)
`typesafe_key`	No	typesafe key (actions: grade, compose, ref)
`prepare_digest`	No	prepare digest (actions: compose)

Schema Changelog

Changes observed during successful MCP inspections.

Changed24 schema fields changedOct 18, 2026

addedInput schema / properties / action

Added value: +{
+  "default": "grade",
+  "description": "what to do (default grade): grade | compose | ref | decisions",
+  "enum": [
+    "grade",
+    "compose",
+    "ref",
+    "decisions"
+  ],
+  "examples": [
+    "grade"
+  ],
+  "type": "string"
+}

addedInput schema / properties / answered_by

Added value: +{
+  "description": "answered by (actions: compose)",
+  "enum": [
+    "n8n-typesafe"
+  ],
+  "type": "string"
+}

addedInput schema / properties / answers

Added value: +{
+  "description": "mode answers: id → { value, confidence, probabilities } for each of the four questions prepare returned (actions: compose)",
+  "type": "object"
+}

addedInput schema / properties / api_key / description

Added value: +"api key (actions: grade, compose, ref)"

addedInput schema / properties / chain_id

Added value: +{
+  "description": "chain id (actions: compose)",
+  "type": "integer"
+}

addedInput schema / properties / execution_id

Added value: +{
+  "description": "execution id (actions: compose)",
+  "type": "string"
+}

addedInput schema / properties / handshake_id

Added value: +{
+  "description": "handshake id (actions: compose)",
+  "type": "string"
+}

addedInput schema / properties / id

Added value: +{
+  "description": "one decision id, for its full record and calldata (actions: decisions)",
+  "type": "string"
+}

addedInput schema / properties / items / description
```
Added value: +"items (actions: grade)"
```

addedInput schema / properties / job_id

Added value: +{
+  "description": "job id (actions: compose)",
+  "type": "string"
+}

addedInput schema / properties / kind

Added value: +{
+  "description": "kind (actions: decisions)",
+  "enum": [
+    "pad",
+    "suggest",
+    "assemble",
+    "ref",
+    "grade",
+    "study"
+  ],
+  "type": "string"
+}

addedInput schema / properties / limit

Added value: +{
+  "description": "limit (actions: decisions)",
+  "maximum": 200,
+  "minimum": 1,
+  "type": "integer"
+}

addedInput schema / properties / mode

Added value: +{
+  "description": "mode (actions: compose)",
+  "enum": [
+    "single",
+    "prepare",
+    "answers"
+  ],
+  "type": "string"
+}

addedInput schema / properties / model

Added value: +{
+  "description": "model (actions: compose)",
+  "type": "string"
+}

addedInput schema / properties / olas

Added value: +{
+  "description": "olas (actions: compose)",
+  "type": "string"
+}

addedInput schema / properties / options / description
```
Added value: +"options (actions: grade, ref)"
```

addedInput schema / properties / prepare_digest

Added value: +{
+  "description": "prepare digest (actions: compose)",
+  "type": "string"
+}

addedInput schema / properties / price_usdc

Added value: +{
+  "description": "price usdc (actions: compose)",
+  "type": "number"
+}

addedInput schema / properties / question / description
```
Added value: +"question (actions: grade, ref)"
```

addedInput schema / properties / record

Added value: +{
+  "description": "where the decision and its answers are also written on chain: none (default: receipt and digests only), devnet (free), base, or the name or chain id of any live network, or a list of them; GET /v1/judge/record/networks lists the live networks with the price of a record now. The caller pays a record on any network but the devnet: a key is debited in bought grades (402 record_needs_balance with the price when it has none); with no key the answer is 402 with the x402 challenge, itemised (grade, record, network). A network that is not live answers 400 record_network_not_live with the live ones (actions: compose)",
+  "items": {
+    "type": [
+      "string",
+      "integer"
+    ]
+  },
+  "type": [
+    "string",
+    "integer",
+    "array"
+  ]
+}

addedInput schema / properties / state

Added value: +{
+  "description": "state (actions: compose, ref)",
+  "type": "string"
+}

addedInput schema / properties / trading

Added value: +{
+  "description": "a trading epoch to grade: { mandate: { markets[], venues[], period { from, to }, max_order_size, max_notional, max_position, allow_short?, kind?, owner?, attribution? }, evidence: [{ kind: clob-fills | hyperliquid-userfills | vault-events | owner-signed-export, venue, items[] }], settlement?, stepper?, submitted? }; code runs the class checks (each kind's reader verifies what it can), then Jev answers over those facts (actions: compose)",
+  "type": "object"
+}

addedInput schema / properties / typesafe_key / description

Added value: +"typesafe key (actions: grade, compose, ref)"

removedInput schema / required

Removed value: -[
-  "items",
-  "typesafe_key"
-]

AddedSep 29, 2026

TDQS

A3.7/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=true, so the safety profile is carried by structured data. The description adds the auth requirement ('on your own TypeSafe key'), which is useful context, but says nothing about mutation effects, idempotency of the write actions, or rate limits beyond what annotations supply.

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 purpose, then the sibling alternative, then a compact action list. Dense but well organized, though jargon like 'recomputable digest' and 'release rubric' costs some clarity without adding much for the agent.

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

Completeness3/5

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

With 23 parameters, nested objects, and no output schema, the description covers the four actions but omits the many supporting parameters (job_id, execution_id, handshake_id, trading, price_usdc, answered_by, prepare_digest). Return-value behavior is not described and no output schema exists to compensate, leaving gaps for a tool this complex.

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 description coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema by mapping the action enum to concrete semantics ('up to 4 items in one calibrated call', 'one question about an item, with value, probabilities and confidence'). It still leaves many of the 23 parameters (job_id, execution_id, price_usdc, prepare_digest) unexplained in the prose.

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

Purpose4/5

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

States a specific verb+resource ('Grades work ... reads the judge's decisions') and enumerates the four actions it dispatches. It explicitly names taifoon_prove as the sibling for proving a chain fact, so an agent can distinguish it from that alternative. The multi-action nature makes the top-line purpose slightly diffuse, but it is clearly conveyed.

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?

Provides routing: 'For proving a chain fact use taifoon_prove' gives an explicit alternative with its selecting condition, and each action gets a one-line when-to-use gloss (grade, compose, ref, decisions). No explicit exclusions beyond the prove pointer, but 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 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?