Read-only crypto research skills that check a price, RSI and ATR against independent sources.
Scored across 9 tools
Each tool targets a distinct analytical dimension: prediction-market odds, macro liquidity, historical base rates, narrative convergence, news verification, derivatives positioning, spot prices, technicals, and track record. Despite similar-sounding suffixes, the resource and question each tool answers are clearly separated.
Most names follow a clear snake_case '<object>_<check/crosscheck/verify>' pattern that is easy to predict. A few outliers like 'crowd_odds', 'move_base_rate', and 'narrative_convergence' break the verb pattern, but the naming remains readable and memorable.
Nine tools is a well-scoped count for a crypto research and validation server. Each tool earns its place by covering a separate verification source or method without redundancy.
The set covers the major independent verification axes for crypto analysis: market expectations, liquidity, base rates, social/news signals, positioning, prices, technicals, and historical plan performance. A combined summary or aggregate evidence tool would be a nice addition, but the core workflow is fully usable without it.
Prediction-market implied probability that a token trades higher than now at a horizon: the Polymarket 'above $K on ' ladder (Kalshi's KXD ladder as fallback) expiring within a day of now + horizon, liquid strikes only, made monotone and interpolated at spot. BTC, ETH, SOL, XRP (and DOGE on Kalshi); null when no market.
| Name | Required | Description | Default |
|---|---|---|---|
| spot | No | Price to read the ladder at (default: Binance spot, which is what Polymarket's crypto ladders resolve on) | |
| symbol | Yes | Token symbol, e.g. BTC | |
| horizon_days | No | 1 to 14 (default 7) |
| Name | Required | Description |
|---|---|---|
| data | No | |
| tool | Yes | |
| as_of | No | |
| status | Yes | |
| request | No | |
| summary | No | |
| trace_id | No | |
| warnings | No | |
| data_mode | No | |
| availability | No | |
| schema_version | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by disclosing concrete behavioral details: Polymarket as primary source, Kalshi as fallback, expiry tolerance relative to horizon, liquid-strike filtering, monotonicity enforcement, interpolation at spot, supported symbols, and null behavior when no market exists. No contradiction exists with the readOnly/destructive annotations.
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 description is a single dense sentence with no filler. The core definition is front-loaded, and each clause adds necessary operational detail: source, fallback, strike selection, interpolation, supported assets, and null case. This is appropriately sized for the complexity.
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?
The description is complete for a read-only probabilistic lookup tool. It covers data sources, fallback behavior, filtering rules, supported symbols, and edge-case null output. An output schema exists, so return-value documentation is not required in the description.
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 baseline is 3. The description adds meaningful context for how parameters drive the calculation: the expiry window is tied to horizon_days, spot is the interpolation point, and symbol support is enumerated. This enriches but does not duplicate the schema descriptions.
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 clearly defines the tool's purpose: computing a prediction-market implied probability that a token trades higher than its current price at a given horizon. Though it lacks an explicit verb like 'calculate' or 'fetch,' the resource and concept are specific. It does not explicitly distinguish itself from sibling tools, though the prediction-market angle differentiates it implicitly.
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?
No guidance is given about when to use this tool versus alternatives such as price_crosscheck or positioning_check. The description implies usage for market-implied probability, but it does not state conditions, exclusions, or alternative routing. Without that, an agent has to infer appropriateness from the tool name and surrounding context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Macro liquidity from DefiLlama (no key): 7-day and 30-day change of the total USD stablecoin supply, and of DeFi TVL on the token's own chain (ETH, SOL, BNB, AVAX and other L1/L2 tokens). Each leg reports its own as_of and availability; a token without a chain of its own gets no TVL rather than a borrowed one.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Token symbol, e.g. SOL |
| Name | Required | Description |
|---|---|---|
| data | No | |
| tool | Yes | |
| as_of | No | |
| status | Yes | |
| request | No | |
| summary | No | |
| trace_id | No | |
| warnings | No | |
| data_mode | No | |
| availability | No | |
| schema_version | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only annotations, the description adds meaningful behavioral context: no API key is needed, each leg has independent as_of/availability, and a chainless token yields no TVL rather than a fabricated value. These details materially change how an agent interprets results and are exactly the kind of non-obvious behavior worth stating.
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?
Two dense sentences with no repetition: the first states source, scope, and metric window, and the second handles reporting semantics and edge cases. The most decision-relevant facts are front-loaded.
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?
For a single-parameter tool with an output schema and annotations already covering safety, the description covers source, access, metrics, per-leg freshness, and missing-data behavior. An agent has everything needed to invoke it correctly and interpret its result shape.
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?
The schema already documents the symbol parameter, but the description adds useful semantics by explaining that the symbol determines the token's own chain and that chainless tokens affect the TVL leg. It stops short of listing accepted symbol formats or validation rules, so it improves on the schema without fully replacing it.
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 pinpoints the data source (DefiLlama), the exact metrics (7-day and 30-day changes in stablecoin supply and chain-specific DeFi TVL), and the token-scoping behavior. This makes it obvious the tool is a macro-liquidity lookup and clearly separates it from sibling tools like price_crosscheck and technicals_crosscheck.
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 the use case—checking macro liquidity without an API key—and even flags an edge case (no chain => no TVL), but it never explicitly says when to choose this over sibling tools or when it should be avoided. The guidance is situational rather than comparative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Empirical probability that a token moves k ATRs (up or down, touched or closed beyond) within h days, counted from ~400 days of OKX daily candles on days in the same ATR tercile as today, with a time-split holdout. Pass RYO's atr_14_pct to measure the distance in RYO's ATR; k=0 with event=close gives the plain 'higher after h days' rate.
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | Distance in ATRs (default 1) | |
| as_of | No | YYYY-MM-DD: use only candles closed before this day (scoring a past call) | |
| event | No | Default touch | |
| symbol | Yes | Token symbol, e.g. SOL | |
| direction | No | Default up | |
| atr_14_pct | No | RYO's ATR(14) as % of price (analyze_token or deep_analysis) | |
| horizon_days | No | 1 to 14 (default 3) |
| Name | Required | Description |
|---|---|---|
| data | No | |
| tool | Yes | |
| as_of | No | |
| status | Yes | |
| request | No | |
| summary | No | |
| trace_id | No | |
| warnings | No | |
| data_mode | No | |
| availability | No | |
| schema_version | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint=true annotation, the description discloses the empirical methodology: ~400 days of OKX daily candles, ATR tercile conditioning, and time-split holdout. It also reveals the edge-case behavior of k=0 and event=close. No contradiction with annotations.
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 description is dense and front-loaded with the key definition, and every sentence adds meaningful information. It loses a point for using 'h days' without explicitly mapping h to horizon_days and for leaving RYO jargon unexplained, which could briefly confuse an agent.
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?
For a 7-parameter tool, the description covers the core calculation, data source, conditioning, and special parameter combinations, while the output schema presumably covers return shape. Minor gaps include not explaining the as_of scoring nuance or the exact effect of the time-split holdout on interpretation, but overall it is sufficiently complete.
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?
With 100% schema coverage, the baseline is 3, but the description adds real semantic value: it explains the meaning of k and h, tells how atr_14_pct should be sourced and used, and clarifies the k=0/event=close interaction. This goes well beyond the generic schema descriptions.
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 states the tool's core output: an empirical probability that a token moves k ATRs within h days. It is specific about the data source, conditioning, and validation, and the niche 'base rate' purpose clearly distinguishes it from the listed siblings like crowd_odds or liquidity_check.
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?
It gives explicit usage instructions for special cases: passing atr_14_pct to measure in RYO's ATR and using k=0 with event=close to get the plain higher-after-h-days rate. It does not explicitly name alternatives or state when not to use the tool, but the context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Monitor up to 20 user-selected voices (Telegram public channels, Bluesky and X handles) and report which tokens they mention, lexicon-scored sentiment per token, conviction and urgency, and whether the voices converge: at least two voices carry a non-zero net sentiment on the token and every one of them has the same sign.
| Name | Required | Description | Default |
|---|---|---|---|
| hours | No | Look-back window in hours (default 24) | |
| tokens | No | Symbols to track; default = every cashtag, ticker or name of a known major found | |
| voices | Yes | Up to 20 ids like tg:WatcherGuru, bs:handle.bsky.social or x:handle |
| Name | Required | Description |
|---|---|---|
| data | No | |
| tool | Yes | |
| as_of | No | |
| status | Yes | |
| request | No | |
| summary | No | |
| trace_id | No | |
| warnings | No | |
| data_mode | No | |
| availability | No | |
| schema_version | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds substantial behavioral context beyond those: lexicon-scored sentiment, conviction and urgency reporting, a 20-voice limit, and the exact convergence rule of at least two voices with non-zero same-sign net sentiment. No contradiction with annotations.
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 description is a single dense sentence with no filler; it front-loads the monitoring target and includes only essential scope, sources, scoring, and convergence details. It could be lightly restructured for readability, 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?
With an output schema present and full parameter descriptions, the description covers the tool's purpose, voice sources and limits, reporting dimensions, and convergence definition. Nothing critical for selecting or invoking the tool is missing, though it does not mention rate limits or latency.
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 the parameters are already documented in the schema. The description reinforces voices/tokens semantics and ties them to the convergence workflow, but it does not add new parameter-level details beyond what the schema already provides.
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 states a specific action ('monitor/report') on a clearly defined resource: up to 20 user-selected voices and the tokens they mention. It also defines the core output precisely with the convergence condition, making it unmistakably distinct from siblings like news_verify or positioning_check.
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 use case is implied clearly: when an agent needs token-level sentiment, conviction, urgency, and convergence across Telegram/Bluesky/X voices, this is the tool. However, it names no alternatives and provides no explicit when-to-use or when-not-to-use guidance relative to the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a crypto news claim: count independent domains reporting it (four outlets' RSS headlines plus Tavily or Venice web search), count those whose headline leans the opposite way, and attach the token's RYO analyze_token evidence so the story and the market read sit side by side.
| Name | Required | Description | Default |
|---|---|---|---|
| claim | Yes | The story to verify, in one sentence | |
| symbol | No | Token symbol to attach market evidence for | |
| max_results | No | Search results to inspect (default 6, max 20) |
| Name | Required | Description |
|---|---|---|
| data | No | |
| tool | Yes | |
| as_of | No | |
| status | Yes | |
| request | No | |
| summary | No | |
| trace_id | No | |
| warnings | No | |
| data_mode | No | |
| availability | No | |
| schema_version | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the operation read-only and non-destructive. The description goes further by disclosing the actual process: RSS headlines from four outlets, Tavily or Venice web search, counting conflicting coverage, and attaching market evidence. This gives the agent a useful mental model of what the tool does without contradicting the annotations.
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 dense sentence earns its place: it states the purpose, the evidence sources, the counting logic, and the output framing. It is front-loaded with the core action and avoids filler.
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?
Given the output schema exists and annotations carry the safety profile, the description covers the essential inputs, method, and outcome. The only minor ambiguity is the reference to 'RYO analyze_token evidence,' which is not defined, but the overall flow is still understandable.
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 each parameter already has a meaningful description. The tool description restates the role of the claim and symbol in context but does not add new parameter-level detail beyond the schema, so the baseline of 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 opens with a specific verb and resource ('Verify a crypto news claim') and expands into the exact method: counting independent domains, counting opposite-leaning headlines, and attaching RYO token evidence. This clearly differentiates it from siblings like price_crosscheck or narrative_convergence, which address different questions.
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 imperative opening ('Verify a crypto news claim') makes the intended use case explicit. It does not name sibling tools or state when not to use it, but the context is clear enough that an agent can infer when this tool is relevant over the market-focused alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decide, field by field, whether RYO's deep_analysis derivatives block can be cited as evidence about this token (identical values across other tokens, sign conflicts with OKX coin-terms open interest), and report OKX perp positioning: premium over spot on OKX and Hyperliquid, 24 h open-interest change in coins, long/short account ratio and its 100-hour percentile, and for BTC/ETH Deribit's DVOL implied 7-day move as a check on stop distance.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Token symbol, e.g. SOL | |
| atr_stop_pct | No | Stop distance in % of price (e.g. RYO's 1.5 x atr_14_pct), checked against the DVOL implied 7-day move | |
| peer_derivatives | No | Same-day RYO derivatives blocks for other symbols: [{symbol, funding_rate_bps, open_interest_change_24h_pct}]; taken from the day's scorecard locks when omitted | |
| ryo_btc_funding_bps | No | Latest BTC funding from RYO monitor_market_sentiment_shift (evidence.funding.latest_bps) | |
| reference_derivatives | No | RYO deep_analysis data.derivatives for this symbol; fetched from RYO when omitted and a RYO key is set |
| Name | Required | Description |
|---|---|---|
| data | No | |
| tool | Yes | |
| as_of | No | |
| status | Yes | |
| request | No | |
| summary | No | |
| trace_id | No | |
| warnings | No | |
| data_mode | No | |
| availability | No | |
| schema_version | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the read-only/destructive annotations by revealing the tool's internal decision behavior: it compares identical values across peers, checks sign conflicts with OKX open interest, and reports multiple positioning metrics rather than just fetching numbers. It does not mention fallback fetching or rate limits, but annotations and the output schema cover much of the safety profile.
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 description is a single dense sentence but it is front-loaded with the core decision and has no filler; each clause maps to a real behavior or output metric. It is somewhat run-on, but the information density is appropriate for the tool's complexity.
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?
For a 5-parameter tool with nested objects and an output schema, the description covers the central decision logic and the complete list of reported metrics. It leaves optional-parameter handling to the schema and does not add sibling routing guidance, but it is functionally complete for an agent that can read the schema.
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% with rich parameter descriptions, so the baseline is 3. The description adds value by linking peer_derivatives to the 'identical values' evidence check and clarifying that atr_stop_pct is checked against the DVOL 7-day move, reinforcing the role of parameters already documented in 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?
The description opens with a specific action ('Decide, field by field...') and names the exact resource (RYO's deep_analysis derivatives block) plus the output scope (OKX/Hyperliquid perp positioning, Deribit DVOL). This is tightly differentiated from siblings like liquidity_check and price_crosscheck, so an agent can tell what the tool does without inspecting 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?
The description gives a clear context: use this when you need to decide whether the deep_analysis derivatives block is citable evidence and want a full perp positioning report. It does not name alternatives or exclusions, but the purpose is specific enough that routing is unlikely to be ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch independent USD spot prices for a symbol from CoinGecko, Coinbase, Kraken, Binance and DefiLlama (no keys), drop a source that disagrees with the rest as an outlier, report median and spread, and flag how far a reference price (e.g. RYO's) deviates from them.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Token symbol, e.g. SOL | |
| reference_path | No | Where the reference price came from | |
| reference_price | No | Price to compare against, e.g. RYO deep_analysis price | |
| reference_fear_greed | No | A Fear & Greed value to compare with alternative.me |
| Name | Required | Description |
|---|---|---|
| data | No | |
| tool | Yes | |
| as_of | No | |
| status | Yes | |
| request | No | |
| summary | No | |
| trace_id | No | |
| warnings | No | |
| data_mode | No | |
| availability | No | |
| schema_version | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and destructiveHint annotations, the description adds meaningful behavioral detail: it fetches from five specific sources with no API keys, performs outlier removal, and computes median/spread. This gives the agent a realistic picture of what will happen, including the fact that live external data is involved.
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 description is a single dense sentence but every clause delivers value: sources, key-free access, outlier logic, and output metrics. It is grammatically complex but not bloated; splitting it into two sentences would improve readability without adding length.
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?
The description covers the core algorithm, the data sources, the lack of API keys, and the reference-price comparison, which is sufficient for an agent to understand how to invoke the tool. The presence of an output schema relieves the description of explaining return values, but it doesn't address edge cases like source failures or missing references.
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 the baseline is 3. The description adds context for symbol, reference_price, and reference_path by explaining how they fit into the crosscheck, but reference_fear_greed is not mentioned at all. The description doesn't substantially compensate beyond 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?
The description names a specific action ('Fetch independent USD spot prices'), the resources (CoinGecko, Coinbase, Kraken, Binance, DefiLlama), and the analytical outputs (median, spread, deviation flag). This clearly distinguishes price_crosscheck from sibling analytical tools like liquidity_check or technicals_crosscheck.
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 the tool should be used when an agent needs an independent multi-source price comparison and a reference-price deviation check, e.g. against RYO's price. However, it never explicitly states when to use this tool versus alternatives, nor does it mention any exclusion criteria or prerequisite conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recompute RSI(14) and ATR(14) (Wilder smoothing) from 200 closed UTC-day candles (OKX, else Binance, else CoinGecko 4h OHLC aggregated to days) plus 1d/7d/30d performance, and report how far reference values (e.g. RYO's) deviate from the independent calculation.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | lookback for performance, 7..90 (indicators always use 200 closed daily candles) | |
| symbol | Yes | Token symbol, e.g. SOL | |
| reference_atr_14 | No | ATR(14) in USD to compare against | |
| reference_rsi_14 | No | RSI(14) to compare against |
| Name | Required | Description |
|---|---|---|
| data | No | |
| tool | Yes | |
| as_of | No | |
| status | Yes | |
| request | No | |
| summary | No | |
| trace_id | No | |
| warnings | No | |
| data_mode | No | |
| availability | No | |
| schema_version | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds valuable behavioral detail beyond the annotations: exact candle count (200), source selection order (OKX, else Binance, else CoinGecko 4h aggregated), smoothing method, and the fact that indicators ignore the days parameter.
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 dense sentence packs every essential fact: calculation method, data source fallback, candle aggregation, performance windows, and output intent. There is no wasted wording, and the core operation is front-loaded.
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 does not need to explain return shapes. It adequately covers inputs, data sourcing, and derivation logic. It leaves minor ambiguity around behavior when reference values are omitted, but the schema marks them optional and the core computation path is clear.
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 the baseline is 3. The description goes further by clarifying that days only affects performance lookback while indicators always use 200 closed daily candles, and by explaining what the reference RSI/ATR values are compared against. This adds meaning beyond the raw property names.
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 opens with a precise verb ('Recompute') and names exact resources: RSI(14), ATR(14) with Wilder smoothing, 1d/7d/30d performance, and deviation from reference values. It also distinguishes itself from the sibling price_crosscheck by focusing on technical indicators rather than price, so an agent can select it unambiguously.
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 clearly states the use case: verify independently calculated technical indicators against reference values such as RYO's. It gives concrete context for when to invoke the tool, though it does not explicitly mention when not to use it or name the sibling alternative as a fallback.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How RYO's own deep_analysis plans have fared: locked daily for 25 majors and settled on OKX hourly candles (stop or +1R target first, 24 h or 72 h). Returns counts by verdict and by confluence state, plans whose verdict leans against their own direction, and the latest locked verdict. Omit the symbol for all tokens.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | No | Token symbol, e.g. SOL; omit for every token | |
| horizon_hours | No | 24 (default) or 72 |
| Name | Required | Description |
|---|---|---|
| data | No | |
| tool | Yes | |
| as_of | No | |
| status | Yes | |
| request | No | |
| summary | No | |
| trace_id | No | |
| warnings | No | |
| data_mode | No | |
| availability | No | |
| schema_version | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only and non-destructive behavior, and the description adds meaningful context beyond them: plans are 'locked daily for 25 majors and settled on OKX hourly candles (stop or +1R target first, 24 h or 72 h)'. It also discloses what is returned without contradicting the annotations.
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 description is compact and front-loads the core purpose, followed by methodology and output summary. It has no filler, though the dense parenthetical about settlement rules could be slightly clearer.
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 adequately covers purpose, methodology, key output categories, and parameter behavior. It is complete enough for an agent to call correctly, though the meanings of 'verdict' and 'confluence state' are left to surrounding context.
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 both parameters are already documented. The description reinforces 'omit the symbol for all tokens' and the 24/72 hour horizon, but adds no semantic detail beyond 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?
The description clearly specifies the resource ('RYO's own deep_analysis plans') and what the tool does ('Returns counts by verdict and by confluence state...'). It distinguishes itself from the market-snapshot siblings by focusing on historical verdict performance, but it does not explicitly name or contrast a sibling.
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 context implies it should be used when one wants RYO plan-performance breakdowns, and the parameter hints ('Omit the symbol for all tokens', '24 h or 72 h') give operational guidance. However, nothing explicitly states when to choose this over sibling tools or excludes any alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
crowd_oddsliquidity_checkmove_base_rate1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "Summary": {
+ "additionalProperties": true,
+ "properties": {
+ "headline": {
+ "default": "",
+ "title": "Headline",
+ "type": "string"
+ },
+ "key_points": {
+ "items": {
+ "type": "string"
+ },
+ "title": "Key Points",
+ "type": "array"
+ }
+ },
+ "title": "Summary",
+ "type": "object"
+ }
+ },
+ "additionalProperties": true,
+ "properties": {
+ "as_of": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "As Of"
+ },
+ "availability": {
+ "additionalProperties": true,
+ "title": "Availability",
+ "type": "object"
+ },
+ "data": {
+ "additionalProperties": true,
+ "title": "Data",
+ "type": "object"
+ },
+ "data_mode": {
+ "default": "unknown",
+ "enum": [
+ "live",
+ "mixed",
+ "simulated",
+ "unknown"
+ ],
+ "title": "Data Mode",
+ "type": "string"
+ },
+ "request": {
+ "additionalProperties": true,
+ "title": "Request",
+ "type": "object"
+ },
+ "schema_version": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Schema Version"
+ },
+ "status": {
+ "enum": [
+ "ok",
+ "partial",
+ "unavailable"
+ ],
+ "title": "Status",
+ "type": "string"
+ },
+ "summary": {
+ "$ref": "#/$defs/Summary"
+ },
+ "tool": {
+ "title": "Tool",
+ "type": "string"
+ },
+ "trace_id": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Trace Id"
+ },
+ "warnings": {
+ "items": {
+ "type": "string"
+ },
+ "title": "Warnings",
+ "type": "array"
+ }
+ },
+ "required": [
+ "tool",
+ "status"
+ ],
+ "title": "Envelope",
+ "type": "object"
+}narrative_convergence2 fields changedInput schema / properties / tokens / descriptionPrevious value: -"Symbols to track; default = every cashtag found"New value: +"Symbols to track; default = every cashtag, ticker or name of a known major found"Output schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "Summary": {
+ "additionalProperties": true,
+ "properties": {
+ "headline": {
+ "default": "",
+ "title": "Headline",
+ "type": "string"
+ },
+ "key_points": {
+ "items": {
+ "type": "string"
+ },
+ "title": "Key Points",
+ "type": "array"
+ }
+ },
+ "title": "Summary",
+ "type": "object"
+ }
+ },
+ "additionalProperties": true,
+ "properties": {
+ "as_of": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "As Of"
+ },
+ "availability": {
+ "additionalProperties": true,
+ "title": "Availability",
+ "type": "object"
+ },
+ "data": {
+ "additionalProperties": true,
+ "title": "Data",
+ "type": "object"
+ },
+ "data_mode": {
+ "default": "unknown",
+ "enum": [
+ "live",
+ "mixed",
+ "simulated",
+ "unknown"
+ ],
+ "title": "Data Mode",
+ "type": "string"
+ },
+ "request": {
+ "additionalProperties": true,
+ "title": "Request",
+ "type": "object"
+ },
+ "schema_version": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Schema Version"
+ },
+ "status": {
+ "enum": [
+ "ok",
+ "partial",
+ "unavailable"
+ ],
+ "title": "Status",
+ "type": "string"
+ },
+ "summary": {
+ "$ref": "#/$defs/Summary"
+ },
+ "tool": {
+ "title": "Tool",
+ "type": "string"
+ },
+ "trace_id": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Trace Id"
+ },
+ "warnings": {
+ "items": {
+ "type": "string"
+ },
+ "title": "Warnings",
+ "type": "array"
+ }
+ },
+ "required": [
+ "tool",
+ "status"
+ ],
+ "title": "Envelope",
+ "type": "object"
+}news_verify1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "Summary": {
+ "additionalProperties": true,
+ "properties": {
+ "headline": {
+ "default": "",
+ "title": "Headline",
+ "type": "string"
+ },
+ "key_points": {
+ "items": {
+ "type": "string"
+ },
+ "title": "Key Points",
+ "type": "array"
+ }
+ },
+ "title": "Summary",
+ "type": "object"
+ }
+ },
+ "additionalProperties": true,
+ "properties": {
+ "as_of": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "As Of"
+ },
+ "availability": {
+ "additionalProperties": true,
+ "title": "Availability",
+ "type": "object"
+ },
+ "data": {
+ "additionalProperties": true,
+ "title": "Data",
+ "type": "object"
+ },
+ "data_mode": {
+ "default": "unknown",
+ "enum": [
+ "live",
+ "mixed",
+ "simulated",
+ "unknown"
+ ],
+ "title": "Data Mode",
+ "type": "string"
+ },
+ "request": {
+ "additionalProperties": true,
+ "title": "Request",
+ "type": "object"
+ },
+ "schema_version": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Schema Version"
+ },
+ "status": {
+ "enum": [
+ "ok",
+ "partial",
+ "unavailable"
+ ],
+ "title": "Status",
+ "type": "string"
+ },
+ "summary": {
+ "$ref": "#/$defs/Summary"
+ },
+ "tool": {
+ "title": "Tool",
+ "type": "string"
+ },
+ "trace_id": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Trace Id"
+ },
+ "warnings": {
+ "items": {
+ "type": "string"
+ },
+ "title": "Warnings",
+ "type": "array"
+ }
+ },
+ "required": [
+ "tool",
+ "status"
+ ],
+ "title": "Envelope",
+ "type": "object"
+}positioning_check4 fields changedInput schema / properties / atr_stop_pctAdded value: +{
+ "description": "Stop distance in % of price (e.g. RYO's 1.5 x atr_14_pct), checked against the DVOL implied 7-day move",
+ "type": "number"
+}Input schema / properties / peer_derivatives / descriptionPrevious value: -"Same-day RYO derivatives blocks for other symbols: [{symbol, funding_rate_bps, open_interest_change_24h_pct}]"New value: +"Same-day RYO derivatives blocks for other symbols: [{symbol, funding_rate_bps, open_interest_change_24h_pct}]; taken from the day's scorecard locks when omitted"Input schema / properties / reference_derivatives / descriptionPrevious value: -"RYO deep_analysis data.derivatives for this symbol"New value: +"RYO deep_analysis data.derivatives for this symbol; fetched from RYO when omitted and a RYO key is set"Output schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "Summary": {
+ "additionalProperties": true,
+ "properties": {
+ "headline": {
+ "default": "",
+ "title": "Headline",
+ "type": "string"
+ },
+ "key_points": {
+ "items": {
+ "type": "string"
+ },
+ "title": "Key Points",
+ "type": "array"
+ }
+ },
+ "title": "Summary",
+ "type": "object"
+ }
+ },
+ "additionalProperties": true,
+ "properties": {
+ "as_of": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "As Of"
+ },
+ "availability": {
+ "additionalProperties": true,
+ "title": "Availability",
+ "type": "object"
+ },
+ "data": {
+ "additionalProperties": true,
+ "title": "Data",
+ "type": "object"
+ },
+ "data_mode": {
+ "default": "unknown",
+ "enum": [
+ "live",
+ "mixed",
+ "simulated",
+ "unknown"
+ ],
+ "title": "Data Mode",
+ "type": "string"
+ },
+ "request": {
+ "additionalProperties": true,
+ "title": "Request",
+ "type": "object"
+ },
+ "schema_version": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Schema Version"
+ },
+ "status": {
+ "enum": [
+ "ok",
+ "partial",
+ "unavailable"
+ ],
+ "title": "Status",
+ "type": "string"
+ },
+ "summary": {
+ "$ref": "#/$defs/Summary"
+ },
+ "tool": {
+ "title": "Tool",
+ "type": "string"
+ },
+ "trace_id": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Trace Id"
+ },
+ "warnings": {
+ "items": {
+ "type": "string"
+ },
+ "title": "Warnings",
+ "type": "array"
+ }
+ },
+ "required": [
+ "tool",
+ "status"
+ ],
+ "title": "Envelope",
+ "type": "object"
+}price_crosscheck1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "Summary": {
+ "additionalProperties": true,
+ "properties": {
+ "headline": {
+ "default": "",
+ "title": "Headline",
+ "type": "string"
+ },
+ "key_points": {
+ "items": {
+ "type": "string"
+ },
+ "title": "Key Points",
+ "type": "array"
+ }
+ },
+ "title": "Summary",
+ "type": "object"
+ }
+ },
+ "additionalProperties": true,
+ "properties": {
+ "as_of": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "As Of"
+ },
+ "availability": {
+ "additionalProperties": true,
+ "title": "Availability",
+ "type": "object"
+ },
+ "data": {
+ "additionalProperties": true,
+ "title": "Data",
+ "type": "object"
+ },
+ "data_mode": {
+ "default": "unknown",
+ "enum": [
+ "live",
+ "mixed",
+ "simulated",
+ "unknown"
+ ],
+ "title": "Data Mode",
+ "type": "string"
+ },
+ "request": {
+ "additionalProperties": true,
+ "title": "Request",
+ "type": "object"
+ },
+ "schema_version": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Schema Version"
+ },
+ "status": {
+ "enum": [
+ "ok",
+ "partial",
+ "unavailable"
+ ],
+ "title": "Status",
+ "type": "string"
+ },
+ "summary": {
+ "$ref": "#/$defs/Summary"
+ },
+ "tool": {
+ "title": "Tool",
+ "type": "string"
+ },
+ "trace_id": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Trace Id"
+ },
+ "warnings": {
+ "items": {
+ "type": "string"
+ },
+ "title": "Warnings",
+ "type": "array"
+ }
+ },
+ "required": [
+ "tool",
+ "status"
+ ],
+ "title": "Envelope",
+ "type": "object"
+}technicals_crosscheck2 fields changedInput schema / properties / days / descriptionPrevious value: -"Look-back in days (default 30, max 90)"New value: +"lookback for performance, 7..90 (indicators always use 200 closed daily candles)"Output schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "Summary": {
+ "additionalProperties": true,
+ "properties": {
+ "headline": {
+ "default": "",
+ "title": "Headline",
+ "type": "string"
+ },
+ "key_points": {
+ "items": {
+ "type": "string"
+ },
+ "title": "Key Points",
+ "type": "array"
+ }
+ },
+ "title": "Summary",
+ "type": "object"
+ }
+ },
+ "additionalProperties": true,
+ "properties": {
+ "as_of": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "As Of"
+ },
+ "availability": {
+ "additionalProperties": true,
+ "title": "Availability",
+ "type": "object"
+ },
+ "data": {
+ "additionalProperties": true,
+ "title": "Data",
+ "type": "object"
+ },
+ "data_mode": {
+ "default": "unknown",
+ "enum": [
+ "live",
+ "mixed",
+ "simulated",
+ "unknown"
+ ],
+ "title": "Data Mode",
+ "type": "string"
+ },
+ "request": {
+ "additionalProperties": true,
+ "title": "Request",
+ "type": "object"
+ },
+ "schema_version": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Schema Version"
+ },
+ "status": {
+ "enum": [
+ "ok",
+ "partial",
+ "unavailable"
+ ],
+ "title": "Status",
+ "type": "string"
+ },
+ "summary": {
+ "$ref": "#/$defs/Summary"
+ },
+ "tool": {
+ "title": "Tool",
+ "type": "string"
+ },
+ "trace_id": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Trace Id"
+ },
+ "warnings": {
+ "items": {
+ "type": "string"
+ },
+ "title": "Warnings",
+ "type": "array"
+ }
+ },
+ "required": [
+ "tool",
+ "status"
+ ],
+ "title": "Envelope",
+ "type": "object"
+}verdict_track_record2 fields changedInput schema / properties / horizon_hours / enumAdded value: +[
+ 24,
+ 72
+]Output schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "Summary": {
+ "additionalProperties": true,
+ "properties": {
+ "headline": {
+ "default": "",
+ "title": "Headline",
+ "type": "string"
+ },
+ "key_points": {
+ "items": {
+ "type": "string"
+ },
+ "title": "Key Points",
+ "type": "array"
+ }
+ },
+ "title": "Summary",
+ "type": "object"
+ }
+ },
+ "additionalProperties": true,
+ "properties": {
+ "as_of": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "As Of"
+ },
+ "availability": {
+ "additionalProperties": true,
+ "title": "Availability",
+ "type": "object"
+ },
+ "data": {
+ "additionalProperties": true,
+ "title": "Data",
+ "type": "object"
+ },
+ "data_mode": {
+ "default": "unknown",
+ "enum": [
+ "live",
+ "mixed",
+ "simulated",
+ "unknown"
+ ],
+ "title": "Data Mode",
+ "type": "string"
+ },
+ "request": {
+ "additionalProperties": true,
+ "title": "Request",
+ "type": "object"
+ },
+ "schema_version": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Schema Version"
+ },
+ "status": {
+ "enum": [
+ "ok",
+ "partial",
+ "unavailable"
+ ],
+ "title": "Status",
+ "type": "string"
+ },
+ "summary": {
+ "$ref": "#/$defs/Summary"
+ },
+ "tool": {
+ "title": "Tool",
+ "type": "string"
+ },
+ "trace_id": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Trace Id"
+ },
+ "warnings": {
+ "items": {
+ "type": "string"
+ },
+ "title": "Warnings",
+ "type": "array"
+ }
+ },
+ "required": [
+ "tool",
+ "status"
+ ],
+ "title": "Envelope",
+ "type": "object"
+}move_base_ratepositioning_checkverdict_track_recordnarrative_convergencenews_verifyprice_crosschecktechnicals_crosscheckCrypto market signals and portfolio telemetry. 6 tools pay-per-call in USDC, no API key.
Crypto market signals, technical indicators, and sentiment analysis for AI agents.
Research Crypto X posts, assets and authors with source links, chain filters and stored prices.
Crypto fundamentals, sentiment, whale tracking and influencer call accuracy for traders and agents.
Add one secure layer between your agents and this server.
