Ichimoku Signal

Ichimoku Cloud signal ($0.01 via x402)

ichimoku_signal

Read-only

Paid ($0.01 USDC via x402 on Solana or Base): the full Ichimoku Cloud signal for a crypto pair on any timeframe (1m to 1M): bullish/bearish/neutral, cloud position, tenkan/kijun cross, price and tenkan, kijun, senkou span A/B values. A "news" field flags recent news (hack, delisting, unlock, legal action) that can break the signal. One pair, Ichimoku only: for six indicators use confluence_signal, for entry/stop/targets price_levels. Requires an x402-capable MCP client; invalid pairs are rejected before payment.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`pair`	Yes	Crypto pair, e.g. BTC-USDT, SOL-USDT, TAO-USDT or ETHUSDT (Binance.US, then Kraken, Gate and MEXC: covers the top 200 coins). For the XRP Ledger DEX: xrpl:XRP-RLUSD, xrpl:SOLO-XRP, or with the issuer, xrpl:SOLO.rsoLo2S1kiGeCcn6hCUXVrCpGMWLrRrLZz-XRP
`interval`	No	Candle interval, default 1h

Output Schema

TableJSON Schema

Name	Required	Description
`news`	No	Only when the news check is on: news from the last 72 hours that can break a technical signal (TypeSafe Jev). The signal itself never changes; treat high as a reason to wait.
`pair`	No	The pair, e.g. BTC-USDT
`price`	No	Last price
`signal`	No	bullish, bearish or neutral (absent on the payment requirement)
`accepts`	No	Only on an unpaid call: the x402 payment options
`interval`	No	Candle interval, e.g. 1h, 4h, 1d
`kijun_sen`	No
`timestamp`	No
`tenkan_sen`	No
`cloud_position`	No
`tenkan_kijun_cross`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 10, 2026

addedOutput schema / properties / news

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": true,
+      "properties": {
+        "checked_headlines": {
+          "type": "number"
+        },
+        "headlines": {
+          "description": "Up to 3 recent headlines naming the coin, with url and published",
+          "items": {
+            "additionalProperties": {},
+            "type": "object"
+          },
+          "type": "array"
+        },
+        "probability": {
+          "type": [
+            "number",
+            "null"
+          ]
+        },
+        "risk": {
+          "description": "high: a headline reports a hack, delisting, unlock, legal action or similar for this coin; elevated: maybe; none: nothing found",
+          "enum": [
+            "high",
+            "elevated",
+            "none"
+          ],
+          "type": "string"
+        }
+      },
+      "required": [
+        "risk"
+      ],
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Only when the news check is on: news from the last 72 hours that can break a technical signal (TypeSafe Jev). The signal itself never changes; treat high as a reason to wait."
+}

Changed1 schema field changedOct 9, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": true,
+  "properties": {
+    "accepts": {
+      "anyOf": [
+        {
+          "items": {
+            "additionalProperties": {},
+            "type": "object"
+          },
+          "type": "array"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "Only on an unpaid call: the x402 payment options"
+    },
+    "cloud_position": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "interval": {
+      "description": "Candle interval, e.g. 1h, 4h, 1d",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "kijun_sen": {
+      "type": [
+        "number",
+        "null"
+      ]
+    },
+    "pair": {
+      "description": "The pair, e.g. BTC-USDT",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "price": {
+      "description": "Last price",
+      "type": [
+        "number",
+        "null"
+      ]
+    },
+    "signal": {
+      "anyOf": [
+        {
+          "enum": [
+            "bullish",
+            "bearish",
+            "neutral"
+          ],
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "bullish, bearish or neutral (absent on the payment requirement)"
+    },
+    "tenkan_kijun_cross": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "tenkan_sen": {
+      "type": [
+        "number",
+        "null"
+      ]
+    },
+    "timestamp": {
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "type": "object"
+}

Changed1 schema field changedOct 6, 2026

changedInput schema / properties / pair / description

Previous value: -"Crypto pair, e.g. BTC-USDT, SOL-USDT, TAO-USDT or ETHUSDT (Binance.US, then Kraken, Gate and MEXC: covers the top 200 coins)"New value: +"Crypto pair, e.g. BTC-USDT, SOL-USDT, TAO-USDT or ETHUSDT (Binance.US, then Kraken, Gate and MEXC: covers the top 200 coins). For the XRP Ledger DEX: xrpl:XRP-RLUSD, xrpl:SOLO-XRP, or with the issuer, xrpl:SOLO.rsoLo2S1kiGeCcn6hCUXVrCpGMWLrRrLZz-XRP"

Changed1 schema field changedSep 24, 2026

changedInput schema / properties / pair / description

Previous value: -"Crypto pair, e.g. BTC-USDT, SOL-USDT, TAO-USDT or ETHUSDT (Binance.US, then Kraken, then Gate: covers the top 100 coins)"New value: +"Crypto pair, e.g. BTC-USDT, SOL-USDT, TAO-USDT or ETHUSDT (Binance.US, then Kraken, Gate and MEXC: covers the top 200 coins)"

Changed1 schema field changedSep 24, 2026

changedInput schema / properties / pair / description

Previous value: -"Binance.US spot pair, e.g. BTC-USDT, SOL-USDT or ETHUSDT"New value: +"Crypto pair, e.g. BTC-USDT, SOL-USDT, TAO-USDT or ETHUSDT (Binance.US, then Kraken, then Gate: covers the top 100 coins)"

First observedSep 23, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only cover readOnlyHint and openWorldHint; the description adds far more: the $0.01 USDC x402 payment across Solana or Base, the pre-payment validation behavior ('invalid pairs are rejected before payment'), and the 'news' field that can invalidate the signal. Cost and failure semantics are exactly the behavioral context an agent cannot infer from annotations or schema.

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-loaded with cost then capability, and every clause carries information (scope, outputs, news caveat, sibling routing, client requirement). It is a dense, run-on single sentence, which slightly hurts scannability, but there is little waste.

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

Completeness5/5

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

Output schema exists so return values need not be explained; despite that, the description still names the key output fields. Combined with payment model, sibling routing, and invalid-pair handling, an agent has everything needed to invoke this correctly.

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 interval enum is fully specified in the schema, so the description's restatement of 'any timeframe (1m to 1M)' and 'one pair' adds no syntax or format detail beyond it. Baseline 3 applies when the schema already carries parameter documentation.

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+resource (Ichimoku Cloud signal for a crypto pair on any timeframe) and enumerates the concrete outputs (bullish/bearish/neutral, cloud position, tenkan/kijun cross, indicator values). It explicitly separates itself from siblings by naming confluence_signal and price_levels as different scopes.

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?

Explicit routing: 'One pair, Ichimoku only: for six indicators use confluence_signal, for entry/stop/targets price_levels.' It also states the client prerequisite ('Requires an x402-capable MCP client'), so the agent knows both when to pick this tool and when it is ineligible to call it.

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

All Ichimoku Signal 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?