Ichimoku Signal

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

Annotations only declare readOnlyHint and openWorldHint, so the description carries the real burden and delivers: price ($0.15 USDC via x402 on Solana or Base), the no-charge-on-invalid-pair behavior, and the caveat that a 'news' field can invalidate the signal. It doesn't cover rate limits or latency, but the payment/validation behavior is exactly the kind of context annotations can't express.

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

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

Front-loads the paid aspect and the payload, then packs outputs, caveats, and routing into a tight block. Dense but nearly every clause carries information; the only mild redundancy is restating output contents when an output schema exists.

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

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

Covers cost, payment rails, input format scope, output shape, a risk caveat, and sibling routing. With an output schema present it needn't detail return structure, and nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is 100%, so both parameters (pair format including XRPL DEX syntax, and the interval enum with its default) are already fully documented in the schema. The description adds no syntax or default detail beyond 'for a crypto pair', so the baseline 3 applies.

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

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

States a specific verb+resource ('six indicators for a crypto pair in one call') and enumerates exactly which indicators (Ichimoku, RSI 14, MACD, EMA, Bollinger, OBV), so an agent can distinguish it from the sibling single-indicator tools like ichimoku_signal 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.

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

Explicitly scopes usage: 'One pair you already chose; to find which coins have a setup, use trade_setups.' That names the alternative and the condition that selects it. It also notes invalid pairs are rejected before payment, which removes a hesitation about calling it speculatively.

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

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

Annotations declare readOnlyHint=false and openWorldHint=false, so the agent already knows this is a self-contained write. The description meaningfully supplements that by stating 'nothing is run or changed automatically' and that a human reviews every report, which reframes the write as non-impacting. It stops short of describing turnaround, rate limits, or error handling.

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

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

Three short sentences, zero filler, with the core action front-loaded and the qualifying details (free, human-reviewed, non-automatic) following. The 'Free.' fragment earns its place as a decision-relevant fact.

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

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

With an output schema present, the description need not explain return values, and it covers the essentials of what the tool does and how submissions are handled. A brief note on expected follow-up (e.g., no ticket ID or reply guarantee) would round it out, but nothing needed to invoke it correctly is missing.

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

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

Schema description coverage is 100% and one parameter carries an enum, so the schema fully documents type, contact, message, and endpoint. The description's only nod to parameters is the vague phrase 'in a structured way', which adds no detail 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.

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

The description names a specific verb (report) and a precise resource (a bug, missing feature, or anything else about the service), so an agent immediately knows this is the feedback channel. It is unmistakably distinct from the market-data siblings (market_scan, price_levels, trade_setups), which are all analysis tools.

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

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

The description implies usage by enumerating the reportable categories (bug / feature / other), which maps onto when an agent should reach for it, but it never states when-not to use it or any alternative escalation path. The 'Free' and 'a person reads every report' notes add context but not selection guidance.

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

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.

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.

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.

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.

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.

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.

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

Annotations cover read-only and open-world, but the description adds important runtime context: a hard 20 calls/hour rate limit, the free tier limitation, and the upstream data sources where the free constraint may matter. It doesn't explain fallback behavior if a pair isn't found on the first exchange, which would push it to 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.

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

The first sentence front-loads purpose, output, and source in a dense but readable clause. The second sentence packs five sibling-routing rules efficiently. Slightly long, but every clause earns its place.

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

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

Despite a 1-parameter tool with an output schema, the description covers purpose, output shape, data provenance, rate limits, and sibling boundaries. An agent could correctly select and invoke this tool without opening any other documentation.

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

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

Schema coverage is 100% and the schema already documents the pair format including xrpl: prefixes and examples. The description repeats the exchange scope (top 200 coins) and examples but adds no format details beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

States a specific verb+resource: daily Ichimoku Cloud trend for a crypto pair, with explicit outputs (bullish/bearish/neutral, cloud position, tenkan/kijun cross) and data sources (Binance.US, Kraken, Gate, MEXC). It clearly distinguishes itself from ichimoku_signal by scoping to the 1d timeframe.

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

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

Explicitly routes to alternatives: ichimoku_signal for other timeframes and line values, confluence_signal for six indicators, price_levels for support/resistance, market_scan for all coins, trade_setups for ranked setups. The 20 calls/hour rate limit is also stated, giving concrete usage boundaries.

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

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

Annotations declare readOnlyHint and openWorldHint, but the description adds the crucial non-obvious context: this call is paid ($0.10 USDC via x402 on Solana or Base) and the universe excludes stablecoins. That is real added value beyond structured fields. It stops short of stating rate limits or what happens on payment failure, and the coin count is internally inconsistent (148 vs '69 of 147'), keeping it from 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.

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

A single front-loaded sentence that leads with the payment requirement, then the payload, then the alternative-tool routing. Every clause carries information, though the density (payment rails, exclusions, breadth, per-coin fields, filter, sibling contrast all in one breath) makes it slightly hard to scan.

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

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

An output schema exists, so return values need not be spelled out, yet the description still conveys the sort order, breadth summary, per-coin fields and optional filter. Combined with the disclosed cost and payment rails for a paid open-world read tool, an agent has everything needed to call it correctly.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema — the baseline is 3. The description restates the signal filter's semantics (bullish/bearish/neutral) but adds nothing about the interval parameter or the interaction between the two, so it does not exceed the schema.

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

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

States a specific verb and resource (Ichimoku Cloud signal for 148 top-200 coins) with an explicit scope note that stablecoins are excluded and the result is sorted strongest-bullish to strongest-bearish. It also names the sibling it is not (trade_setups) and the endpoint it mirrors (GET /scan), so an agent can distinguish it without opening the schema.

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

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

Explicit routing: use this for the market's direction at a glance; use trade_setups when entry, stop and targets are needed. The optional bullish/bearish/neutral filter is also described as a usage condition. Nothing is left to inference.

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

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

Beyond readOnlyHint/openWorldHint, it discloses a concrete rate limit (60 calls per hour), that no candles or signals are returned, the acceptable quote substitutions (USDT/USD/USDC), and the underlying data sources. That is substantial operational context the annotations do not carry.

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

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

Front-loads the most decision-relevant fact ('Free: before paying') and every clause carries information, but the single long sentence with nested parentheticals is dense and would read better split into two.

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

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

With an output schema present, return values need no explanation, and the description still covers sourcing, intervals, rate limits, and the no-signal caveat. Nothing needed to call it correctly is missing.

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

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

Schema description coverage is 100% and the single pair parameter is well documented, so the baseline is 3. The description adds behavioral meaning for that parameter: a different dollar quote can substitute for the one requested, which is not evident from the schema alone.

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

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

Names a specific verb and resource ('Look up a pair') and enumerates exactly what the response tells you: support status, candle source (Binance.US, Kraken, Gate, MEXC, XRPL DEX), and accepted intervals. It also differentiates itself from the signal/tooling siblings by stating it fetches no candles and returns no signal.

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

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

Gives an explicit call condition ('Free: before paying, check whether a crypto pair is supported') and routes the agent elsewhere for a different need ('for the daily trend use ichimoku_trend'). The free-vs-paid distinction makes the when-to-use decision unambiguous.

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

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

Annotations already declare readOnlyHint and openWorldHint, but the description adds substantial context: the $0.05 USDC x402 payment on Solana or Base, that validation happens before payment is charged, and the 'levels from price history, not trade advice' disclaimer. This is meaningful disclosure beyond the annotations, though payment-failure/refund behavior isn't detailed.

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

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

Front-loads the payment cost and the core resource, then packs output details into one dense sentence. Every clause carries information, though the single run-on sentence is heavy to parse.

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

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

With an output schema present, return values needn't be re-explained, yet the description helpfully summarizes the payload. Payment model, alternative tool, and rejection behavior are covered; only edge cases like timeout or partial-failure handling are absent.

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

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

Schema description coverage is 100% and both parameters (pair, interval) are thoroughly documented in the schema itself, so the schema carries the burden. The description only adds the 'one pair' constraint and the GET /levels/{pair} mapping, which is minor added value.

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

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

States a specific resource (price levels for a crypto pair) and enumerates the concrete outputs — supports/resistances, ATR, pivots, Fibonacci, Ichimoku, bias, and long/short plans — so an agent knows exactly what this returns. It also distinguishes itself from the sibling trade_setups by scoping to one pair.

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

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

Explicitly names the alternative ('for ranked plans across all coins use trade_setups') and states the single-pair constraint, plus that invalid pairs are rejected before payment. It gives clear context for use but doesn't spell out when-not conditions beyond the pair scoping.

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

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

Goes well beyond the readOnly/openWorld annotations by disclosing the x402 payment ($0.50 USDC on Solana or Base), the ranking formula (signal strength x risk/reward, penalized for volatility, nearby support/resistance, thin liquidity), and a candid backtest caveat that the setups did no better than random after fees. This is unusually rich behavioral context.

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

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

Front-loads the paid access and core purpose, then packs filters, ranking logic, and caveats efficiently. The middle clause is dense and run-on, but nearly every sentence carries information; minor tightening possible.

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

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

With an output schema present, return values need not be described. The description covers payment, scope, ranking rationale, alternatives, and a critical expectation-setting caveat, leaving no significant gap for an agent deciding whether to call it.

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

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

Schema coverage is 100%, so the schema already documents all five parameters. The description restates four of them (direction, min_rr, top, liquid_top) without adding format or syntax detail beyond what's in the schema, and omits interval entirely. Baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb+resource: it returns 'which crypto coins have a trade setup right now' across 148 top-200 coins, using a six-indicator confluence signal plus a trade plan. It explicitly distinguishes itself from siblings by naming confluence_signal and price_levels for the single-pair case.

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

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

Names the alternatives (confluence_signal, price_levels) and the condition that selects them ('for one pair you already chose'). Also enumerates the available filters (direction, min_rr, top, liquid_top) so the caller knows how to scope the result.

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