tachyo

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals key behaviors: free vs. authenticated (grounded) responses, language support (en/pl), and the need for session_token or payment. But it lacks details on rate limits, error handling, or what a 'grounded answer' entails (e.g., citation format). The disclosure is adequate but not exhaustive.

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 (three sentences) and front-loaded: it states the core purpose first, then adds language and authentication info. No redundant or missing sentences. It effectively packs key information without verbosity.

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 functionality and the free vs. unlocked distinction. It mentions prerequisites (session_token, payment) and language. However, it does not describe the return format for the grounded answer or the connect-CTA, nor error scenarios. Given no output schema, more completeness would be helpful, but the essential usage context is present.

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 by explaining parameter meanings. It mentions 'lang: en / pl' and hints at 'session_token' and 'payment' purposes, but does not describe the 'question' parameter or provide format/constraints for any parameter. For a 4-parameter tool with no schema descriptions, this is insufficient for correct parameter 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: 'Ask any market question in natural language and get a grounded answer.' It is a general-purpose question-answering tool, distinguishing it from the many specific analytical siblings like 'marketsummary__find_longs' or 'marketsummary__get_market_summary'. The verb 'ask' and resource 'market question' are specific and 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 provides usage guidance: it explains that a free query returns a 'connect-CTA' and that a grounded answer requires either a 'session_token' (from 'verify_wallet_ownership') or a 'payment' proof (via x402). This tells the agent when to use authentication/payment and what to expect. However, it does not explicitly list when NOT to use this tool compared to siblings, though the contrast is implicit.

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 full transparency burden. It discloses the data fusion (attention + price), output types (coiled, quiet_mover), resolution, and that it's not advice. No side effects or auth requirements mentioned, but the description is sufficiently informative for an analytical 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 somewhat verbose with jargon ('source-secret', 'coiled', 'quiet_mover') and repeats free/premium details. The key purpose is front-loaded but could be trimmed without losing meaning.

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, but the description explains what is returned (count + names for free, ranked list with type for premium). It covers scope, resolution, and a disclaimer. Missing are error conditions and prerequisites, but for a market data tool this is reasonable.

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 0% schema description coverage. The description mentions free vs. premium, hinting at 'payment', but does not explain the parameters' format, purpose, or default behavior. This is a significant gap given the lack of 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 states the tool identifies two types of price-attention divergence: 'coiled' (rising attention, flat/down price) and 'quiet_mover' (price up, thin attention). It also specifies scope (crypto, daily+1h resolution) and distinguishes this tool from siblings by the unique signal it uses.

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 clear context on when to use the tool (e.g., to find coins that haven't pumped yet or quiet movers) and mentions free vs. premium output tiers. However, it lacks explicit when-not-to-use guidance or direct comparisons with sibling tools like 'find_longs' or 'get_attention_shifts'.

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 results are a 'win-rate tilt, not guaranteed returns', median outcome flat, and position small. It mentions volume-gating to avoid death spirals and the 'unvalidated coiled block'. This provides good behavioral context, though it doesn't address rate limits or authentication needs.

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 core purpose, but it includes extraneous details (e.g., 'not financial advice') and technical jargon. It could be more concise by merging some sentences. Overall adequate but not 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 tool has 3 parameters with no output schema and no parameter descriptions in the schema or description. The description explains the output tiers (free vs premium) and the strategy, but lacks parameter documentation. For a screening tool, this is moderately complete but fails to guide effective 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%, and the description does not explain any of the three parameters (payment, window_days, session_token). There is no guidance on what values to provide or how they affect output. The description mentions 'down over the week' but doesn't link to window_days. This is a major gap.

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 'Long candidates — MEAN-REVERSION' and details the selection criteria (oversold, lagging BTC, volume-gated). It distinguishes this tool from others by noting it's the 'one edge read long-side' and clarifying that public catalysts/listings are excluded. This provides a clear, specific verb+resource understanding.

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 clear context: it's for mean-reversion longs, not for catalyst-based plays ('priced in'). It also differentiates free vs premium access. However, it does not explicitly compare with sibling tools like find_setups or get_trending, missing an explicit when-not-to-use statement.

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 full burden. Discloses that rankings are computed (not hallucinated), not advice, not intraday, includes data-quality flag, and explains locked output without payment/token.

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?

Dense single paragraph with all relevant info. Front-loaded with purpose. Could be slightly more structured (e.g., separate sentences for parameters), but no waste.

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

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

No output schema, but description enumerates what each setup includes (pump %, strength vs BTC, etc.) and explains access tiers. Adequate for a screening tool with tiered access.

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 0%, but description adds meaning: explains intent values, their meanings, and how payment/session_token unlock full results. Adds significant value over 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 screens for trade setups with computed signals, distinguishes from siblings with 'no hallucinated ranking', and specifies two intents (fade/momentum).

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?

Explains when to use each intent and the access tiers (free teaser vs. full via session_token/payment). Lacks explicit comparison to siblings like find_longs/find_shorts, but provides sufficient context.

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, but the description fully discloses behavior: returns catalyst type, dated-unlock flag, evidence; free gives count+top3, premium full list; warns about microcaps and that liquidity/borrow is on user. Covers output and limitations.

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 the key purpose and is well-structured. All sentences add value, but could be slightly more concise given the 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?

No output schema exists, but the description adequately explains the return value. However, it completely fails to document parameters, leaving a significant gap for a tool with three parameters. The description is incomplete for selection and 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% and the description does not explain any of the three parameters (payment, window_days, session_token). The description focuses entirely on output, leaving parameters undocumented. With no schema guidance, the agent cannot infer how to configure the tool.

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 identifies short candidates with bearish catalysts, distinguishes from momentum-based setups (siblings), and provides specific catalyst types. This is 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?

Explicitly advises when to use (bearish catalysts, not momentum), describes free vs premium output, and warns about microcap squeezes and liquidity risks. Provides both usage context and 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?

With no annotations, the description carries the full burden. It discloses source independence, mention velocity using 24h vs 7d baseline, data sparsity ('coarse'), and payment tiers. This provides useful behavioral context, though it does not explicitly state it is a read-only operation.

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 four sentences, front-loaded with the purpose, then payment tiers, then data quality considerations. 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?

The tool lacks an output schema and the description does not specify the return format (e.g., list of tickers with values). The session_token parameter is not explained. For a simple tool, the description is incomplete.

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 payment parameter (free vs premium) but does not clarify the session_token parameter. Given 0% schema description coverage, the description partially compensates but leaves one parameter undocumented.

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 'heating up or cooling down' based on mention velocity and source-independent attention. It distinguishes from siblings like get_trending by emphasizing source independence. The verb 'get attention shifts' is implied from the name and supported by the description.

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 payment tiers (free vs premium) but does not provide explicit guidance on when to use this tool versus alternatives like get_trending or get_buzz_score. There are no when-to-use or when-not-to-use instructions.

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 provided, the description carries full burden. It discloses daily resolution, relative-strength basis, free vs premium tiers, and a disclaimer. However, it does not mention idempotency, side effects, authentication requirements, or how parameters affect behavior.

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 (4 sentences), well-structured, and front-loaded with the core question. Every sentence adds value without redundancy.

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, frequency, and disclaimer, but lacks details on the return format and how to interpret the data. Given no output schema and 0% parameter coverage, more completeness would be beneficial.

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 'payment' or 'session_token' parameters. Although it mentions free vs premium, it does not map this to the payment parameter, leaving the agent without meaningful guidance.

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 measures rotation between altcoins and Bitcoin using 7-day relative strength, explicitly distinguishing it from market-cap dominance. The verb 'get' and resource 'BTC rotation' are specific, and the tool is unique 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 sets expectations with 'Daily resolution' and clarifies what the tool is not ('NOT market-cap dominance', 'Not advice'). However, it does not provide explicit guidance on when to use this tool versus alternatives like get_market_breadth or get_market_regime.

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 clearly discloses that the score is a composite attention metric, volume-weighted to prevent spikes, and explicitly states it is NOT a bullish signal or price polarity indicator. This provides good behavioral context beyond the basic purpose.

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 only three sentences that are front-loaded with the tool's purpose. Every sentence adds value: purpose, components, weighting, access tiers, and a caution. 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?

Given the tool has two undocumented parameters and no output schema, the description partially compensates by describing expected output (top 3 or full ranking with components). However, it lacks any parameter documentation and does not address edge cases or error conditions. Adequate but with 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?

Schema description coverage is 0%, and the description does not explain the two parameters (payment, session_token). While these are likely common auth/access parameters, the description misses an opportunity to link them to the free vs premium access tiers mentioned. No parameter semantics added.

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 a composite attention score for tokens, specifying it is attention-only and not a bullish signal. It explains the components (crowd mentions + desk coverage) and weighting (volume-weighted). However, it does not explicitly differentiate from sibling tools like 'get_trending' or 'get_attention_shifts', leaving some ambiguity.

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 for checking token attention scores and mentions access tiers (free vs premium). However, it lacks explicit guidance on when to use this tool versus its many siblings, or when not to use it. No alternatives or exclusions are provided.

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 the calculation logic, pricing tiers (free vs premium), and disclaims financial advice. No contradictory or missing behavior noted.

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 brief (four sentences) and front-loaded with purpose. It efficiently conveys key info without excess, though the last line could be integrated.

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 two-parameter tool with no output schema, the description covers purpose, logic, pricing, and a disclaimer. It lacks return format details but remains sufficient for use.

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?

Input schema has two parameters (payment, session_token) with 0% description coverage. The description mentions 'Free = 2 desk-ahead names; premium = both lists' implying payment affects output, but does not explain session_token or link parameters to 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 verb 'get' and the resource 'conviction gap', defining it as a comparison of editorial coverage vs crowd chatter. It uniquely specifies the computation (digest_selections vs mentions) and distinguishes it from a buy signal.

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

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

The description explains what the tool computes and explicitly states it is NOT a buy signal, providing clear usage context. However, it does not compare to or list alternatives among the many 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 carries full burden. It discloses that free access returns a locked teaser and requires unlocking via session_token or payment proof. However, it lacks details on error handling, rate limits, or output format.

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 with three sentences and a parameter list. It conveys essential information without unnecessary words, though the parameter list could be better integrated into the narrative.

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 tool with 7 parameters, no output schema, and no annotations, the description provides adequate context about payment, unlocking, and parameters. However, it does not specify the output format or what happens on failure.

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 covers section, asset_class, ticker, and timeframe with possible values, and mentions session_token and payment. However, it does not describe the 'lang' 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 identifies the tool as a paid Degen Digest with actionable calls and contract addresses, grouped by section. It lists parameters and distinguishes from sibling analysis tools by focusing on a digest/report format.

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?

While the description explains the paid nature and unlocking mechanism, it does not provide explicit guidance on when to use this tool versus alternatives like get_market_summary or other specific analysis tools among the 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?

No annotations are provided, so the description must bear the full burden. It explains free vs premium tiers and notes that breadth is limited to their tracked set, but does not disclose side effects, authorization needs, rate limits, or whether the operation is read-only. The 'Not financial advice' is a legal note, not a behavioral trait.

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 four sentences with some casual phrasing ('Real move or just the majors?'), but it efficiently conveys the core functionality, tier differences, and scope. It is front-loaded with the main purpose. However, it could be more formal and concise without sacrificing 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 annotations, no output schema, and zero schema parameter descriptions, the description should fully explain what the tool returns and how parameters affect behavior. It explains the free/premium outputs conceptually but neither describes the return format nor how to access premium via the payment parameter. The session_token parameter is ignored, leaving a significant gap.

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 relates 'payment' to free/premium tiers but does not explicitly state how to set the parameter to get premium. 'session_token' is not mentioned at all, leaving its purpose unclear. The description adds partial meaning but is insufficient for both 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?

The description clearly states the tool provides market breadth over a tracked crypto set, distinguishing free advance/decline from premium intraday pulse and relative-strength. It also clarifies it's for their own tracked set, not the whole market, and ends with a disclaim. This specificity differentiates it from siblings like get_market_summary or get_market_regime.

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 for assessing market breadth but does not explicitly state when to use this tool versus alternatives like get_market_summary. It lacks when-not-to-use or exclusion criteria, leaving the agent to infer context from the tool name and sibling list.

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 provided, the description discloses important behavioral traits: it is a 'READ' (non-predictive), offers a free label and premium detail, explains BTC trend is best-effort with null when unreachable, and explicitly states 'Not advice'. This provides good transparency beyond the basic purpose.

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, conveying the core purpose and key behavioral notes in a few sentences. However, the formatting with line breaks and special characters slightly reduces readability. The main point is front-loaded, which is good.

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 has no required parameters and no output schema, the description partially covers what the user gets: a label (free) or detailed drivers (premium). However, the two optional parameters remain unexplained, and there is no mention of return format or structure. For a simple tool this might suffice, but the lack of parameter context is a gap.

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 does not explain the two parameters (payment and session_token) at all. The schema provides zero description coverage (0%). While the description hints at a free/premium tier ('Free = the label; premium = every driver'), it fails to connect this to the 'payment' parameter or clarify the session_token. This leaves the agent without guidance on how to set these optional 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?

The description clearly states the tool determines if the market is risk-on or risk-off, providing a label (BULLISH/BEARISH/CHOPPY) based on breadth and relative strength. It explicitly distinguishes itself from a forecast, and the unique output sets it apart from sibling tools like find_longs or find_shorts which focus on specific setups.

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 that the tool is a read of the current tape, not a forecast, implying it should be used for assessing immediate market mood rather than predictions. It does not explicitly exclude alternatives, but the context makes it clear this is for a high-level regime assessment, contrasting with more specific 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 carries the burden and does well by disclosing that free usage returns top headlines, full recap requires authentication or payment, and the timeframe is clamped by tier. This gives the agent a clear picture of the tool's behavior, though it omits details about potential side effects or output format.

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 a clear opening sentence stating the tool's purpose, followed by a compact parameter listing. It front-loads the most important information. Minor improvement could be better structuring the parameter details (e.g., bullet points) for easier scanning, but overall it is 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?

For a tool with 5 parameters, no annotations, and no output schema, the description provides adequate context: filtering capabilities, tier restrictions, and authentication/payment requirements. It lacks output format or pagination details, but the core usage is well-covered.

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 adds significant meaning beyond the input schema by explaining the allowed values for timeframe (6h/24h/7d/30d with tier clamping), category (seven options), lang (en/pl), and the purposes of session_token and payment. Given 0% schema coverage, this fully compensates and makes the parameters understandable.

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 is a 'Market recap' that is filterable by timeframe and category, indicating the tool returns a summary of market information. However, it does not explicitly distinguish this recap from sibling tools like 'get_digest' or 'get_market_breadth', leaving some ambiguity about its specific 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 provides context on when to use the tool by mentioning filtering options and tier limitations (free returns headlines, full recap requires session_token or payment). However, it does not explicitly state when to use this tool over alternatives or provide any '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 full burden. It discloses that 'Energy = item count, NOT sector returns' and includes a disclaimer ('Not financial advice'), but omits details on output structure, authentication, or error behavior.

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) with front-loaded purpose. However, the first sentence is a question format, which may be less direct. Still, each sentence adds value, including free/premium differentiation and a key disambiguation.

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 complexity (grid over 6 categories, free/premium tiers) and lack of output schema, the description covers core concepts but misses parameter usage and output details, making it only adequately complete 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%, yet the description does not explain the parameters 'payment' or 'session_token'. The mention of free vs premium hints at payment control but is not explicit, leaving the agent without clear parameter semantics.

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 a narrative-energy grid over 6 recap categories, specifying the resource (sector heatmap) and distinguishing it from sibling tools that focus on other aspects like tickers or trends.

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 for exploring market conversation concentration but lacks explicit guidance on when to use this tool over siblings like get_market_breadth or get_trending. No exclusions or 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 are provided, so the description carries the full burden. It discloses that free returns a headline and full details require authorization (session_token or payment). It mentions 'No coverage' behavior. However, it does not describe what happens on invalid tokens, rate limits, or other side effects, leaving some gaps.

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 and a few phrases, but contains some redundancy (e.g., repeating 'coverage headline' and 'full timeline + price path'). It is somewhat front-loaded but could be more succinct.

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 (5 parameters, no output schema), the description provides adequate context: explains each parameter's role, output types (coverage headline vs. full timeline), and free vs. paid tiers. It does not specify exact output format, but that is acceptable without an output 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 description coverage is 0%, but the description adds meaning for most parameters: 'ticker: symbol (e.g. HYPE). window_days: 1..90.' It explains payment and session_token as methods to unlock full content. lang is mentioned only by default value. This provides substantial additional context beyond the raw 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 'What our digest said about a ticker over a window — section appearances, notes, price path.' It uses a specific verb (get/digest info), identifies the resource (ticker), and describes the output (section appearances, notes, price path). This distinguishes it from sibling tools like get_buzz_score or get_attention_shifts.

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 free vs paid: 'Free returns a coverage headline. Unlock the full timeline + price path via session_token (from verify_wallet_ownership) OR an x402 payment proof.' It also clarifies that 'No coverage = the token is off our radar.' It does not explicitly compare to alternatives, but the context is clear enough.

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?

Discloses that 1h data is freshest but coarset and flagged if missing, that horizons differ in resolution, and that free vs premium tiers affect output. With no annotations, these behavioral details add value and inform the agent about data quality and access constraints.

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 three sentences, frontloading the core purpose in the first sentence. Every sentence adds needed information (function, free/premium, data quality flags). 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?

Covers the key output and data quality, but missing important context: no explanation of session_token, no mention of authentication or rate limits, and no guidance on free vs paid usage. Given no output schema and no annotations, more completeness would help the agent use the tool correctly.

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

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

Schema has zero description coverage for parameters. The description does not explain the ticker, payment, or session_token parameters. While it hints at free vs premium, it fails to clarify what payment values are valid or how session_token is used. The agent cannot infer parameter meaning from the description.

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 multi-horizon momentum for one token including 1h, 1d, 7d moves and relative strength vs BTC, with an alignment verdict. This is specific and distinguishes it from sibling tools like get_market_summary or get_ticker_dossier.

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 explicit guidance on when to use this tool versus alternatives. Sibling tools are listed but no contrasting use cases are provided. The description implies usage for momentum analysis but does not help an agent decide when to choose this over other get_* 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 carries full burden. It clearly discloses the free vs paid behavior (top 3 vs top 15 with counts) and the authentication requirement via session_token or payment. Does not mention side effects or rate limits but covers key behavioral aspects adequately.

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 plus a line for timeframe, all front-loaded. Every part adds value: purpose, parameter options, and unlock mechanism. 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?

Covers what the tool does, parameters, and unlock mechanism. Lacks explicit return format (structure of tickers and counts) and error handling, but for a simple tool with three parameters, it is reasonably 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%, but the description fully explains all three parameters: timeframe (24h/7d/30d), session_token (from verify_wallet_ownership), and payment (x402 proof). It adds meaning that the schema lacks entirely.

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 gets trending tokens (most-mentioned tickers). The name and description align, and it distinguishes itself from sibling tools by focusing on 'trending' and mentioning free vs paid limitation, which is unique among the many 'get_' 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?

Provides context on timeframe options and free/paid unlocking, which helps decide when to use based on desired output size and authentication status. However, it lacks explicit comparison with sibling tools or guidance on when to prefer this over alternatives like get_buzz_score.

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 important behavioral traits: attention-only (no price), curated versioned set, coarse on sparse data, and 'not financial advice'. It does not mention destructive behavior, which is appropriate. 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 concise (two sentences) and front-loaded with purpose. Every clause adds value: purpose, usage, output expectations, and limitations. It avoids fluff but could be slightly more 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?

Given no output schema, the description explains return values (list + hottest for free, full trajectories + constituents for premium). It also notes versioning and data coarseness. It covers the 3 parameters adequately, though session_token is unexplained.

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 add meaning. It explains the 'narrative' parameter adequately (pass one basket or leave empty), but provides no explanation for 'payment' (only hinted by free vs premium) or 'session_token'. This leaves the AI agent guessing about those 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?

The description clearly states the tool's purpose: tracking which crypto narrative is heating up via attention trajectories across curated baskets. It specifies the verb 'track' and the resource 'narrative', and distinguishes itself from sibling tools by its unique focus on narrative velocity.

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 instructions: pass a specific narrative for one basket or leave empty for all ranked by velocity. It also differentiates free vs premium tiers, giving the AI agent actionable guidance. However, it does not explicitly state when not to use this tool 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?

With no annotations, the description discloses tier-gating, session_token requirement, and a provenance constraint. It implies read-only behavior but doesn't explicitly state mutability, rate limits, or permissions—acceptable for a check 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?

Every sentence serves a purpose: core function, chain support, free vs. full, tier-gating, provenance. No redundancy or wasted words; front-loaded with primary action.

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 purpose, return content (verdict + risks), optional enhancement with session_token, and chain support. With no output schema and no annotations, the description is appropriately complete; minor gap in detailing 'full breakdown' is acceptable.

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 meaning: lists chain options, explains session_token unlocks full breakdown, and implies token_address is the target. This compensates well for the lack of 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 the tool performs a 'rug-check' on tokens, listing specific safety aspects (honeypot, mint authority, LP lock, etc.) and supported chains, clearly distinguishing it from sibling tools (all market-related).

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 usage (free returns verdict, session_token unlocks full breakdown) and chain selection, but lacks explicit when-not or alternative tool references. Sibling context makes purpose distinct, but no exclusion 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 bears full burden. It discloses that the challenge is single-use, expires (~10 min), and returns {challenge, nonce, expires_at}. It also binds the proof to agent_id. Although it doesn't detail behavior on repeated calls or failure, the key traits are transparent.

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 yet comprehensive, front-loading the purpose. Every sentence adds essential information: step, chains, agent binding, workflow, expiration, return format. No extraneous text.

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 simple challenge-request tool with 3 params and no output schema, the description covers return format, expiration, and subsequent step. It omits failure scenarios and prerequisites (e.g., valid wallet), but these are acceptable given the simplicity and the tool's role in a verification flow.

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 description must add meaning. It explains chain ('evm' or 'solana'), agent_id ('your marketplace identity'), and implicitly address (user's wallet address). Two of three parameters are explicated, adding value 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: 'Step 1 of wallet verification: get a fresh challenge for the user to sign.' It identifies the action (get), resource (challenge), and context (wallet verification), distinguishing it from sibling tool verify__verify_wallet_ownership (step 2).

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: as step 1 of wallet verification, with a clear workflow: present challenge, have user sign, then call verify_wallet_ownership. It mentions passing agent_id to bind proof. While it doesn't explicitly state when not to use, the context is sufficient for an agent to decide.

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 describes the non-destructive nature ('does not move funds or expose keys'), the return object fields, and the linking behavior. It does not detail error conditions but sufficiently discloses key behaviors.

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 paragraphs, first sentence delivers core purpose, then details. No redundant information; every sentence adds value. Efficiently 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?

Given 5 parameters, no output schema, and no annotations, the description covers the flow, parameter semantics, and output. It mentions session_token for downstream use. Could include error handling, but is fairly complete for a step in a larger 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?

0% schema coverage means description must compensate. It explains the nonce source, chain options with signature formats, agent_id requirement, and implicitly covers address and signature. Adds substantial meaning beyond the input 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 it is Step 2 of wallet verification, with specific verb 'prove control by signing' and resource 'challenge from step 1'. It distinguishes from sibling tool 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?

Explicitly says to use after request_verification_challenge, provides chain-specific signature formats, and instructs to pass the same agent_id. It also explains the outcome and session_token for other agents. Missing explicit when-not, but context is clear.

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