Tachyo

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

No annotations are provided, so the description carries full burden. It discloses that free usage yields a connect-CTA, while a grounded answer needs authentication via session_token or x402 payment. This is valuable behavioral context beyond a simple function statement.

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 just two sentences, front-loading the core purpose in the first sentence. Every word adds value with no redundancy or fluff.

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?

No output schema is present, so the description should indicate return format. It mentions 'grounded answer' and 'connect-CTA' but lacks details on structure, error handling, or rate limits. Adequate but not fully comprehensive.

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 0%, so the description must compensate. It explains 'lang' as language, links 'session_token' to verify_wallet_ownership, and 'payment' to x402 proof. However, it does not explain constraints on 'question' or behavior of default values, leaving gaps.

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 states the tool's function: 'Ask any market question in natural language and get a grounded answer.' This is a specific verb-resource pair that distinguishes it from sibling tools, which are more specialized queries.

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 provides context: language options, free version returns a connect-CTA, and grounded answer requires session_token or payment. It implies prerequisites but does not explicitly state when not to use or compare to siblings.

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?

Given no annotations, the description discloses read-like behavior (no mention of mutation), data sources (secret attention + price), granularity (daily/1h), and disclaimer (not advice). It omits rate limits and exact auth needs but provides sufficient context for a non-destructive tool.

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 paragraph with clear front-loading of purpose. Every sentence adds value, though the 'Not advice' tag could be placed elsewhere. No wasted words.

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 tool has no output schema and two underspecified parameters. The description covers output types and access levels but lacks full parameter details and exact output format. Adequate for a simple tool but not fully 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?

Schema description coverage is 0%. The description partially explains 'payment' via free vs premium tiers, but does not detail valid values or when to set. 'session_token' is completely unexplained, leaving the agent uninformed about its purpose.

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 states the tool identifies coins with attention vs price divergence, using terms 'coiled' and 'quiet_mover'. It specifies the resource (coins with both attention and price) and distinguishes from sibling tools like get_attention_shifts or get_buzz_score.

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 mentions free vs premium access and crypto-only scope, but does not explicitly state when to use this tool vs alternatives. No instructions on when-not-to-use or prerequisites.

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?

The description covers behavioral aspects beyond basic purpose: it mentions volume gating (survival-gated to avoid death spirals), the edge is a win-rate tilt, median outcome flat, position small, and includes a disclaimer (not financial advice). No annotations exist, so the description carries full burden.

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 longer than necessary but each sentence adds value—covering purpose, criteria, pricing, and risk. It front-loads the key idea and avoids redundancy. Could be slightly tighter but is well-structured.

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 comprehensive for purpose and behavior, but lacks parameter documentation and has no output schema. Given the tool's three parameters and the absence of explanation, the description is incomplete for full usability.

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 0%, and the description does not explain the three parameters (payment, window_days, session_token). While the description explains the tool's logic well, it fails to document what these parameters do, leaving the agent without guidance on how to configure the call.

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 states the tool finds long candidates using mean-reversion, specifies the criteria (oversold, beaten-down, down over the week, lagging BTC, still basing today), and distinguishes it from public catalysts/listings. This provides a specific verb+resource with clear scope.

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 explains when to use this tool (for mean-reversion longs) and what it is not (public catalysts/listings). It also mentions pricing tiers. However, it does not explicitly contrast with siblings like find_shorts or find_setups, though it implicitly does by stating it's the 'one edge read long-side'.

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?

The description discloses that rankings are from computed signals (not hallucinated), details the components of each setup (pump %, strength vs BTC, weak score, etc.), and notes that numbers are from daily candles + digest, not intraday. It also explains free vs paid access, providing full transparency without 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 well-structured, starting with the main purpose, then intents, output fields, data sources, and access model. It is slightly verbose but each part adds value, making it informative without being overly long.

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 no output schema and sibling tools, the description covers the output fields and access requirements adequately but lacks details on return format, error handling, and prerequisites (e.g., needing a wallet verification). It is sufficient for a screening tool but has gaps.

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 0% schema description coverage, the description partially compensates by explaining the 'intent' parameter's two values and the roles of 'session_token' and 'payment' for unlocking. However, it does not detail their exact formats or requirements.

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 states the tool screens for trade setups ranked from computed signals, with no hallucinated ranking. It explains the two intents (fade and momentum) and distinguishes itself from sibling tools like find_longs and find_shorts by being a general setup finder.

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 explaining the two intents and the unlock mechanism, but does not explicitly state when to use this tool versus siblings like find_longs or find_shorts. It lacks guidance on prerequisites or alternatives.

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?

No annotations provided, so description carries burden. It mentions output tiers and risk warning but does not state if tool is read-only or if it has side effects. Adequate but not comprehensive.

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?

Single paragraph is fairly concise and front-loads purpose, but could be better structured (e.g., bullet points for clarity). Description earns its 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?

Describes output but completely omits parameter documentation. Without output schema, description should cover both inputs and outputs; it fails on input coverage.

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 0% and description does not explain any of the three parameters (payment, window_days, session_token). Fails to add meaning beyond 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?

Clearly states it finds short candidates with bearish catalysts, distinguishing from momentum-based setups. Verb-noun structure is specific and informative.

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?

Provides context on when to use (coins with fundamental catalysts), describes free vs premium output, and warns about liquidity and squeeze risk. Could explicitly compare to siblings but overall clear.

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?

With no annotations, the description carries full burden. It discloses that the attention signal is source-independent, mentions data coarseness ('sparse data → coarse'), and states it is not advice. These are useful behavioral traits, though it could elaborate on safety or restrictions.

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 concise, consisting of a few sentences with no filler. It is front-loaded with the core purpose. Minor improvement could be structuring the free/premium info more clearly, but overall it's efficient.

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 lacks details on the return format, how to interpret results, and does not explain both parameters adequately. Given no output schema and low parameter coverage, the description should be more complete to guide correct invocation.

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 0% for parameter descriptions, so the description must add meaning. It implies that 'payment' determines free vs premium output, but it does not explain 'session_token' or confirm the parameter mapping. The added value is partial.

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 states it returns attention shifts (heating up/cooling down) based on mention velocity, with a specific source-independent approach. However, it does not explicitly distinguish from sibling tools like get_buzz_score or get_trending, though the unique focus on velocity-based attention is implied.

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 provides usage context by differentiating free vs premium outputs, but it does not specify when to use this tool over siblings or any conditions/exclusions. It offers some guidance on payment-dependent behavior.

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?

The description discloses daily resolution, free vs premium features, and states it is not financial advice. In the absence of annotations, this provides adequate behavioral transparency, though it could explicitly mention it is read-only.

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 concise (3 sentences) and front-loaded with the key question. Every sentence adds value: purpose, feature breakdown, and caveats. No wasted words.

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 tool's purpose and output tiers but omits critical parameter information. Given no output schema and low schema coverage, the description is incomplete for an agent to invoke the tool correctly without additional 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?

The input schema has 2 parameters (payment, session_token) with 0% description coverage. The tool description does not explain their purpose or usage, leaving the agent without guidance on how to set these parameters.

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?

Description clearly defines the tool's function: measuring 7-day relative strength rotation between BTC and altcoins. It uses specific language ('Is money rotating into alts or back into BTC?') and distinguishes from market-cap dominance, making it unambiguous.

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 is for assessing rotation trends and differentiates from market-cap dominance. However, it does not explicitly state when to use this tool over alternatives like get_market_breadth or get_market_regime, leaving some ambiguity for the AI agent.

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?

With no annotations, the description carries the burden. It discloses the composite nature, volume-weighting, and what it is not (attention only, no price polarity). However, it does not mention access requirements (session_token, payment), rate limits, or data freshness.

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 sentences: first explains what the tool does and its key features, second clarifies limitations. No unnecessary words, purpose 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?

Covers the core function and output expectations (ranking for premium, top 3 for free), but lacks detail on parameter handling and return format. Given the simple nature, it is adequate but not fully 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?

Schema coverage is 0%, yet the description provides no explanation for the two parameters (payment, session_token). The free vs premium distinction hints at payment usage but does not specify values or how to use the parameter.

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 states the tool provides a composite attention score for tokens, explains it is volume-weighted, and distinguishes between free (top 3) and premium (full ranking) tiers. It also clarifies it is attention only, not a bullish signal, which differentiates it from potential sibling 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 use for identifying buzzing tokens and warns against using it as a bullish signal, but does not explicitly state when to use or not use this tool versus siblings, nor does it specify prerequisites like authentication or payment tier.

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?

No annotations are provided, so the description carries the full burden. It discloses the behavioral trait of computing a gap based on 'digest_selections vs mentions' and explains free vs premium access limitations. It also includes 'Not financial advice.' However, it does not detail effects of input parameters or side effects.

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 relatively concise at three sentences and front-loads the core concept. However, the use of parentheses and dashes makes it slightly cluttered, but it remains clear and efficient.

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 complexity of the tool's unique calculation, the description provides the core idea and differentiates from siblings. However, it lacks parameter context, output schema details, and any mention of dependencies or prerequisites, leaving gaps for a complete understanding.

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 input schema has 2 parameters (payment, session_token) with 0% schema description coverage. The description does not explicitly explain these parameters; it only indirectly relates payment to free/premium tiers. There is no parameter-level documentation to add meaning 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 states the tool's purpose: to show where editorial coverage leads or lags crowd chatter, with specific definitions for 'desk_ahead' and 'crowd_ahead'. It distinguishes itself from siblings by mentioning the unique cadence comparison using digest_selections vs mentions.

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 conveys when to use the tool (to compare editorial coverage vs crowd chatter) and explicitly states it is NOT a buy signal. However, it lacks explicit guidance on when not to use it or how it compares to alternative sibling tools.

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?

With no annotations, the description handles behavioral disclosure well: it states the digest is premium, free access returns a locked teaser, and unlocking requires session_token or payment. It lacks details on error responses or rate limits, but the core behavior is clear.

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 concise, with the purpose stated first, followed by parameter details and unlock instructions. It avoids redundancy but could be slightly more structured (e.g., bullet points for parameters).

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 no output schema and no annotations, the description covers the paid nature, unlock mechanism, and filter options. However, it does not describe the return format (e.g., structure of the digest) or what happens on error, leaving gaps for an agent.

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 0%, so the description must compensate. It explains the values for section, asset_class, ticker, and timeframe with examples, but does not cover the lang parameter or the format of session_token and payment. The defaults are not mentioned, leaving some ambiguity.

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 states it returns the 'paid Degen Digest' with actionable calls, and lists filter options. It distinguishes itself from sibling tools by specifying it's a premium digest, but could be more explicit about the verb 'get'.

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 explains the tool returns a paid digest and how to unlock it, but it does not provide guidance on when to use this tool versus other sibling tools like marketsummary__get_market_summary or marketsummary__get_ticker_dossier. No explicit alternatives are mentioned.

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?

No annotations provided, so description bears full burden. It discloses that breadth is over 'OUR tracked set' and includes 'not financial advice.' However, it omits side effects, auth requirements, or rate limits, leaving gaps in transparency.

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 relatively concise, using a brief introductory sentence and a structured explanation of free vs premium. Minor repetition ('stated as such') but overall efficient.

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?

No output schema exists, yet the description does not describe the return format or structure. It explains conceptual breadth measures but leaves users guessing about the actual data shape, making it incomplete for a tool with 2 parameters and no output guidance.

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 0%, so description must compensate. It hints at 'payment' values via 'Free = ... Premium = ...' but does not explicitly link to the payment parameter or define session_token. Incomplete parameter mapping.

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 states it provides market breadth over a tracked crypto set, contrasting free vs premium features. It avoids tautology and gives specific context, but does not explicitly distinguish from sibling tools like get_market_summary.

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 lacks guidance on when to use this tool versus alternatives. It mentions free vs premium but no context on selecting it over siblings such as get_buzz_score or get_token_momentum_card.

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?

The description discloses that it is a read operation (not a forecast), the output types, the free/premium distinction, and the best-effort nature of BTC trend (null if unreachable). With no annotations provided, this adequately covers behavior, though additional details on error handling or rate limits would improve it.

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 concise (3 sentences) and front-loads the main purpose. It uses bullet-like formatting for clarity. However, it could be slightly more structured, e.g., separating parameter usage.

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 simple schema (two optional params, no output schema), the description provides good context about the output and limitations. However, it lacks explanation of the parameters, which is a gap in completeness for execution.

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 input schema has two parameters (payment, session_token) with defaults but no descriptions. Schema coverage is 0%, so the description should compensate, but it only hints at 'free = label; premium = every driver' without explaining the parameters themselves. Most agents would not understand how to use payment or session_token.

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 states the tool's purpose: getting the current market regime (risk-on/risk-off) using a breadth and relative-strength composite. It specifies outputs (BULLISH/BEARISH/CHOPPY) and distinguishes itself as a read, not a forecast, differentiating it from predictive tools among siblings.

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 this is for current state assessment (not forecast) and mentions free vs premium versions, but it does not explicitly state when to use this tool versus alternatives like get_market_breadth or get_market_summary. No direct exclusions or alternative recommendations.

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?

With no annotations, the description discloses key behaviors: timeframe clamping by tier, free returns top headlines only, and the need for session_token or payment for full recap. This provides useful operational 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?

The description is two sentences: first sets purpose, second details parameters and restrictions. No wasted words, information is front-loaded and efficiently organized.

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 no output schema or annotations, the description covers parameter ranges, tier limits, and auth needs. It doesn't explain return format, but the core functionality is well-addressed.

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 description explains the semantics and allowed values for timeframe, category, lang, and the access conditions for session_token and payment, compensating for the 0% schema description coverage.

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 states it returns a 'Market recap' filterable by timeframe and category. While it doesn't explicitly distinguish from all siblings, the mention of filtering and tier limitations adds specificity.

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 use for obtaining a summary but does not compare to other tools like get_market_breadth or get_trending. It provides context on free vs. full access but lacks explicit when-to-use or when-not-to-use 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?

With no annotations, the description carries the burden. It discloses that energy is item count (not returns) and includes a disclaimer. However, it lacks details on data freshness, auth requirements, or edge cases, limiting full transparency.

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 front-loaded with a clear question and efficiently covers the grid categories, free/premium split, and key caveats in a few lines. No extraneous content.

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 concept and a caveat, but misses details on output format, how to interpret the heatmap, and parameter usage. With no output schema or annotations, more context is needed for full completeness.

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 two parameters (payment, session_token) are not described at all, despite 0% schema coverage. The description fails to add any meaning beyond the schema, leaving agents uninformed about their purpose or usage.

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 states the tool's purpose: showing where market conversation is concentrated via a narrative-energy grid over 6 categories. It distinguishes itself from other tools by focusing on sector heatmap rather than returns or single metrics, but does not explicitly contrast with siblings.

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 provided on when to use this tool versus alternatives like get_buzz_score or get_attention_shifts. The description mentions free vs premium tiers but does not specify contexts or exclusions.

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?

With no annotations, the description carries full burden. It discloses that the tool returns our narrative (not on-chain), that free returns a headline while full data requires auth/payment, and that 'No coverage' means the token is off radar. It does not mention side effects, rate limits, or errors, but provides substantial 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?

The description is concise, front-loads the purpose, and avoids fluff. Each sentence adds value. Could be slightly more structured with bullet points but is efficient overall.

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 no output schema, the description adequately explains return types (headline vs full timeline, price path) and auth requirements. It covers core functionality but omits error handling, pagination, or detailed return format. Still, it provides sufficient context for an agent to use the tool.

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 0%, so description must compensate. It adds meaning for ticker (symbol example) and window_days (range 1..90), and explains session_token and payment for unlocking. However, lang and default values are not mentioned, and not all parameters get equal treatment.

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 states the tool retrieves a dossier of what the digest said about a ticker over a window, including section appearances, notes, and price path. It distinguishes from sibling tools like get_digest (full digest) and get_attention_shifts (attention metrics) by focusing on per-ticker historical coverage.

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 mentions free vs paid usage (headline vs full timeline via session_token or payment), and explains 'No coverage' meaning. However, it does not explicitly compare to other sibling tools or specify when to use this tool over alternatives like get_digest or track_narrative.

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?

No annotations are provided, so the description must fully disclose behavioral traits. It mentions edge cases (1h flagged if possibly-missing, 'no coverage' meaning off radar) but does not state whether the tool is read-only, requires authentication, or has rate limits. The description partially covers behavior but leaves important aspects unaddressed.

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-loaded with the key output metrics. It efficiently explains free vs premium, the 1h flag, and 'no coverage'. While dense, it avoids unnecessary detail and covers the main points in a single paragraph.

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 no output schema and minimal input schema, the description adequately describes the output (momentum metrics, alignment verdict, free/premium distinction, edge cases) but fails to describe input parameters. An agent would not know how to specify the token or handle payment/session tokens, making it incomplete for invocation.

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 0%, placing full burden on the description to explain parameters. The description mentions 'one token' but does not clarify the 'ticker' parameter or the optional 'payment' and 'session_token' parameters. No additional semantics are provided beyond the schema's basic 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 clearly states the tool returns multi-horizon momentum (1h, 1d, 7d) and relative strength vs BTC with an alignment verdict. It distinguishes free vs premium outputs and notes edge cases like missing 1h data and 'no coverage'. This provides a specific verb+resource that differentiates from sibling tools like get_buzz_score or get_conviction_gap.

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 is for single-token momentum analysis using multiple horizons and relative strength. However, it does not explicitly state when to use this tool vs alternatives like get_buzz_score or get_attention_shifts, nor does it provide exclusions. The context is clear but lacks comparative 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?

In the absence of annotations, the description discloses key behaviors: free access returns top 3, full ranking requires session_token or payment proof, and timeframe options. It does not mention rate limits or data freshness.

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 sentences are front-loaded with purpose and include all necessary information without redundancy. Every part 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?

Given the lack of output schema and minimal schema descriptions, the description covers purpose, parameters, and the free vs paid distinction. It does not specify the exact output structure (e.g., JSON format), but the mention of 'tickers' and 'counts' is sufficient.

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 0% schema description coverage, the description adds meaning for all three parameters: timeframe values are listed, and payment/session_token are explained as unlocking full ranking. It lacks format details for payment and session_token.

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 states the tool returns trending tokens as 'the most-mentioned tickers', specifying a concrete verb and resource. It distinguishes from siblings by focusing on mention count-based trending.

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 provides context on free vs paid usage (top 3 vs top 15) and timeframe options, but does not explicitly state when to use this tool over alternatives or when not to use 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?

With no annotations, the description carries the full burden. It discloses that the tool provides attention data only (no price), is coarse on sparse data, is a curated versioned set with constituents shown, and includes a 'not financial advice' disclaimer. It does not explicitly state read-only behavior but it's reasonably inferred.

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 concise (3-4 sentences), front-loaded with the purpose, and wastes no words. Every sentence adds value: purpose, parameter usage, tier differences, and limitations.

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 main behavior, parameter usage for narrative, and limitations. However, it omits explanation of the `payment` and `session_token` parameters, and does not describe output format (though no output schema exists). It is adequate but not 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?

Schema description coverage is 0%. The description only addresses the `narrative` parameter by listing allowed values and usage hint; `payment` and `session_token` are not mentioned at all, leaving them undocumented despite implying a free vs premium model.

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 states the tool tracks attention trajectory across curated narrative baskets, listing specific categories (e.g., defi, l1_l2). It conveys a specific verb-resource relationship, but does not explicitly differentiate from sibling tools like get_attention_shifts or get_trending.

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 provides usage context: passing a `narrative` for one basket or leaving empty for all ranked by velocity. It also distinguishes free vs premium tiers. However, no explicit when-to-use or when-not-to-use guidance compared to sibling tools is given.

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?

No annotations provided, so description must reveal behavioural traits. It mentions tier-gating and a provenance note about self-contained results, but lacks details on side effects, permissions, or rate limits. For a tool performing external checks, more transparency is warranted.

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?

Description is concise (4 sentences) but front-loads the key purpose and chains. The provenance note could be placed elsewhere, but overall no unnecessary words.

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 basic input and tier logic but lacks details on output format (verdict and top risks) and no output schema. Agent may need more info on what the returned verdict looks like. However, with multiple sibling tools, this is still functional.

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 0%, but description adds significant meaning: enumerates supported chains (eth, bsc, base, etc.), explains session_token role (unlocks full breakdown), and token_address is clear. This complements the schema well.

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?

Description clearly states the tool performs a 'rug-check' on a token, listing specific checks (honeypot, mint authority, LP lock, taxes, holders, contract verification). It is distinct from sibling tools which focus on market summaries and verification.

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?

Provides clear guidance: free version returns verdict + top risks, passing session_token unlocks full breakdown, and lists supported chains. Implicitly suggests using session_token from verify_wallet_ownership for full detail. Could explicitly state when not to use or alternatives.

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?

The description discloses key behaviors: the challenge is single-use and expires after ~10 minutes, and the return object includes challenge, nonce, and expires_at. It does not cover error cases or authorization requirements, but given the simplicity of the tool, the transparency is adequate. No annotations exist so the description carries full burden.

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 concise yet comprehensive, fitting all essential information into a few sentences. It is front-loaded with the core purpose and step indication, then expands on parameters, usage flow, expiration, and return format with no wasted words.

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 tool's low complexity (3 simple parameters, no output schema), the description provides all necessary context: purpose, step in a larger flow, parameter details, behavioral traits (single-use, expiry), and the return structure. No output schema exists, so the description compensates by explicitly stating the return fields.

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 input schema has 0% description coverage, so the description must compensate, and it does thoroughly. It explains the purpose of each parameter: chain (with allowed values 'evm' or 'solana'), address (the user's wallet address to verify), and agent_id (marketplace identity). It adds context beyond the schema's defaults and types.

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 states the tool's purpose: 'Step 1 of wallet verification: get a fresh challenge for the user to sign.' It distinguishes from the sibling tool verify_wallet_ownership by explicitly noting it is step 1 and that subsequent steps involve calling the sibling with the returned nonce and signature.

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 provides explicit usage guidance: it is the first step, the challenge is presented to the user to sign, and then verify_wallet_ownership should be called with the nonce and signature. It also specifies that chain can be 'evm' or 'solana', and that agent_id binds the proof to the marketplace identity.

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?

With no annotations, the description carries full burden. It discloses that the tool does not move funds or expose keys, and describes the return fields. However, it does not mention any potential side effects, authorization requirements, or rate limits.

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 well-structured and front-loaded with purpose, but the parameter details make it slightly verbose. Every sentence adds value, but some phrasing could be tightened without losing clarity.

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 no output schema, the description fully explains the return values and the overall verification workflow. It also connects to other agents via session_token, providing complete context for the tool's role in the process.

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?

Despite 0% schema description coverage, the description adds thorough meaning to each parameter: nonce is from the challenge, chain specifies signature format, agent_id must match, signature is over the challenge text, and address is the wallet address. This fully compensates for the missing 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 explicitly states it is step 2 of wallet verification, proving control by signing a challenge. It clearly distinguishes from sibling tools, particularly the preceding step 'request_verification_challenge'.

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 explains to use the nonce from step 1 and pass the same agent_id. It outlines the outcome (linking wallet, session_token) and mentions interoperability with other agents. It does not explicitly state when not to use this tool, but the step-2 context provides implicit guidance.

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