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 that free usage returns a connect-CTA and that a grounded answer is unlocked via session_token or payment proof. This meaningfully informs the agent of auth-dependent behavior, though it does not mention idempotency 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 a concise paragraph (two sentences) that efficiently conveys purpose, usage modes, and language options. It is front-loaded with the core purpose and adds details without excess. Slight improvement could be made by separating parameters more clearly.

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 4 parameters, the description covers the essential aspects: what it does, how to get results, and language support. It lacks explicit return format or error behavior, but these are secondary for a straightforward question-answering tool. The description is adequate for an agent to select and invoke it correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It explains 'lang' (en/pl) and the auth parameters (session_token from verify_wallet_ownership, x402 payment proof). However, it does not describe the 'payment' default (empty string) or the 'question' parameter beyond implying it holds the natural language query.

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 uses a specific verb ('ask') and resource ('market'), distinguishing it from sibling tools that handle specific queries like get_digest 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 clear context on when to use the tool (for general market questions) and explains how to access different levels of results: free returns a connect-CTA, while a grounded answer requires session_token or payment. However, it does not explicitly list 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?

No annotations provided, so description carries full burden. It does not state whether the tool is read-only, if it requires authentication beyond session_token, or any side effects. The 'Not advice' disclaimer is present but insufficient for behavioral traits.

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 and front-loaded with the core purpose. It defines terms, tiers, and constraints without excessive verbosity, though the multiple lines 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?

The description covers output format per tier, asset type, and resolution. However, with no output schema, it lacks details on exact response structure, error handling, or what happens when no data matches.

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 clarify the two parameters (payment, session_token). The reference to 'free' vs 'premium' hints at payment's role but is not explicit; session_token is completely unexplained.

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-price divergence ('coiled' and 'quiet_mover'), defines these terms, and distinguishes from sibling tools by focusing on divergence rather than raw attention 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 mentions crypto-only and provides resolution details, but does not explain when to use this tool versus siblings like 'get_attention_shifts' or 'get_trending'. No explicit when-not or alternative 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?

Discloses key traits: survival-gated by volume, win-rate tilt, median outcome flat, and not financial advice. With no annotations, description carries full burden and does so well.

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, information-dense but lacks clear structure. Some padding (e.g., premium vs free explanation) could be streamlined, but not overly verbose.

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 and 0% parameter coverage. Description covers domain logic but omits input/output specifics. Users cannot infer how to set parameters or parse results.

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 description provides zero information about the three parameters (payment, window_days, session_token). This is a critical failure for tool 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 defines the tool's purpose: finding long candidates based on mean-reversion, specifically oversold names that haven't bounced. It distinguishes itself from catalyst-based tools and sets 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?

Provides context on when to use (mean-reversion) and when not (catalyst-based longs). Mentions premium vs free tiers but doesn't explicitly name sibling tools for comparison.

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 data source (daily candles + digest), the nature (not advice, not intraday), and the paywall behavior. Missing details like error handling 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 with sections for purpose, intents, output details, data source, and access. Each sentence adds value, though slightly longer than necessary.

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 (3 params, no output schema, no annotations), the description covers core functionality, intents, output fields, and access tiers. Missing edge cases or error scenarios, but adequate for selection.

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 adds meaning: intent parameter is explained, session_token and payment are linked to unlocking. However, payment format (x402) is not elaborated, partially compensating.

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 two intents (fade and momentum). The purpose is specific and distinct from siblings like find_longs/find_shorts, though not explicitly compared.

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 two intent options and access tiers (free vs. paid), guiding usage within the tool. However, it does not specify when to use this tool over siblings like find_longs/find_shorts.

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 limitations (liquidity and borrow on user, microcaps can squeeze) and includes a disclaimer. With no annotations, this is comprehensive for a read-only 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?

Well-structured and informative, but could be slightly more concise. Front-loads the core purpose.

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 tool function and limitations well, but lacks parameter documentation, which is a gap given no schema descriptions and no 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?

Does not explain the input parameters (payment, window_days, session_token) despite 0% schema description coverage. Only hints at payment affecting free vs premium.

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 the tool finds short candidates with bearish catalysts, distinguishes from momentum-based setups, and lists specific catalyst types (unlock, insider distribution, exchange inflow).

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 guidance on free vs premium tiers, but does not explicitly state when to use this tool instead of siblings like find_longs or find_setups, though it hints at different signal types.

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 provides valuable behavioral context: source-independence, reliance on mention velocity, 24h vs 7d baseline, free vs. premium limitations, and data sparsity leading to coarse output. It also includes a disclaimer ('Not advice'). This exceeds minimal 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 reasonably concise, front-loading the core purpose and adding key details in subsequent sentences. However, the phrasing is slightly informal and could be more structured (e.g., bullet points).

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 what the tool returns (rising/cooling rankings with velocity) and mentions limitations, but lacks specifics on output format for premium tier and does not explain how to interpret the velocity metric. Given no output schema, more completeness would be helpful.

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

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

The schema has 0% coverage for parameters; the description partially compensates by hinting that 'payment' relates to free/premium access but does not explain 'session_token'. Without mapping parameters to their purpose, the agent may misuse them.

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 attention shifts (heating/cooling) based on mention velocity, differentiating it from sibling tools like get_trending or get_buzz_score. However, it uses a question format rather than a direct verb phrase, slightly reducing clarity.

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 attention shift analysis and mentions free vs. premium tiers, but does not explicitly state when to use it over alternatives or provide exclusion criteria. Usage guidance is implied rather than explicit.

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, the free/premium distinction, and a disclaimer ('Not advice'). It also clarifies the metric is relative-strength rotation. However, with no annotations present, the description fails to address important behavioral traits such as authentication requirements, rate limits, or that it is a read-only operation. The payment parameter is hinted at but not explained.

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 highly concise: three sentences that front-load the core purpose and include important clarifications. No extraneous information, every sentence adds value.

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

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

Despite clear purpose, the description lacks details on return format, how to interpret 'direction + leading/lagging counts' vs 'full leaders/laggards board', and does not explain input parameters. Given no output schema and no annotations, the description should provide more context for correct 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?

Schema description coverage is 0%, and the description does not explain the two parameters ('payment' and 'session_token'). It implies that payment affects output (free vs premium), but this is not explicit. The description does not adequately compensate for the lack of schema documentation, leaving agents uncertain about 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 measures rotation between alts and BTC based on 7-day relative strength, using a specific verb-resource pair ('get rotation'). It distinguishes from sibling market summary tools by focusing on relative-strength rotation rather than other metrics like dominance or breadth.

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 clarifies that this is about rotation, not market-cap dominance, and notes daily resolution and that it is not advice. It mentions free vs premium features, giving context on access. However, it does not explicitly name alternative tools or specify when to use this over siblings like get_market_breadth.

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?

Despite no annotations, the description fully reveals behavioral traits: the scoring method (composite, volume-weighted), tiered access (free vs. premium), and the explicit caveat that it indicates attention only, not price direction. This goes beyond basic disclosure.

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 exceptionally concise, using two sentences to convey purpose, behavior, and exclusions. It front-loads the core purpose ('Which tokens are buzzing right now') and avoids redundant info, making every sentence earn 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?

The description sufficiently explains the output behavior (top 3 vs. full ranking, components) and the non-price nature of the score. However, given the absence of output schema and parameter details, the omission of input parameter context leaves a gap, preventing 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 description adds no meaning to the two parameters ('payment' and 'session_token'), which are undocumented in the schema (0% coverage). With low schema coverage, the description should compensate but fails entirely, leaving the agent guessing 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 returns a composite attention score for tokens, specifying components (crowd mentions, desk coverage) and volume-weighting. It distinguishes itself from siblings like get_trending by emphasizing 'Attention ONLY' and pricing tiers, making the resource and scope 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 a clear disclaimer: 'Attention ONLY — NOT a bullish signal, no price polarity,' which guides when not to use. However, it does not explicitly compare to alternatives like get_attention_shifts or mention specific use cases, so it lacks explicit exclusions or sibling references.

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 exist, so the description bears full responsibility. It discloses the tool's non-financial-advice nature, the meaning of 'desk_ahead' vs. 'crowd_ahead', and the output differentiation by payment tier. It does not cover error handling or authentication needs, but the core behavior is well explained.

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 but not overly terse; every sentence adds value (purpose, distinction, access levels, disclaimer). It could be slightly more streamlined, but it is well-organized and front-loads key information.

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 absence of an output schema and rich annotations, the description adequately explains the output concepts and access tiers. However, the complete omission of parameter semantics leaves a significant gap for an agent attempting to invoke 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?

With 0% schema description coverage and no mention of the two parameters ('payment', 'session_token') in the description, an agent receives no guidance on what values to provide or their significance. The description adds no meaning beyond the schema's bare structure.

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

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

The description clearly defines the tool's purpose: comparing editorial coverage ('desk_ahead') to crowd chatter ('crowd_ahead') using a unique proprietary computation. It uses specific verbs ('leads or lags') and explicitly distinguishes the tool from siblings by highlighting its exclusive capability ('nobody else can compute').

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 states it is 'NOT a buy signal' and explains free vs. premium access, providing context for when to use the tool. However, it does not explicitly state when not to use it or offer alternatives among siblings, so it lacks full 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?

No annotations provided, so description carries full burden. It discloses the premium nature, locking behavior, and authentication options, but does not mention error handling, rate limits, or output format, leaving some behavioral 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 about 100 words, front-loaded with the purpose, and efficiently lists parameter options in a readable format. It is concise without being overly brief, earning its sentences.

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 7 params with 0% schema coverage, the description covers purpose, parameters, and payment but lacks output description, error scenarios, and detailed authentication flow. It is 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?

With 0% schema description coverage, the description adds meaning for 6 of 7 parameters (section, asset_class, ticker, timeframe, payment, session_token), explaining their values and purposes. Only 'lang' is omitted, which has a clear default.

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 the 'paid Degen Digest' with actionable calls and contract addresses, grouped by section. It lists the filtering parameters, distinguishing it from sibling tools that offer different summary types.

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 free use returns a locked teaser, and unlocking requires a session_token or x402 payment proof, providing clear guidance on when to use and how to access full content. It does not explicitly compare to alternatives but the context is sufficient.

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 carry the full burden. It discloses the proxy nature, bucket categories, squeeze-risk, and free/premium model. However, it does not explicitly state that the operation is read-only or safe, nor does it describe side effects or failure modes.

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 long, starting with a clear question that indicates purpose. It efficiently covers the proxy, buckets, free/premium, and 'unknown' case without fluff. It uses some jargon but remains focused and 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?

Given no output schema and no annotations, the description provides a good overview: input (ticker), output (bucket with categories, squeeze-risk, optional exact volume), and access model. It lacks error handling or response format details, but covers core functional behavior adequately.

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. It explains that 'ticker' identifies the token, and describes the purpose of 'session_token' and 'payment' for premium access. It integrates parameter context naturally, though it does not specify formats or constraints.

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: assessing token liquidity via a daily-USD-volume proxy, with specific bucket categories and a squeeze-risk flag. It distinguishes from sibling tools by focusing solely on liquidity, unlike tools for attention, buzz, 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 sizing into a token without moving the price, but does not explicitly state when to use this tool versus alternatives. It mentions free vs premium access but lacks guidance on prerequisites 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?

No annotations provided, so description carries the burden. It discloses that the tool covers only 'our tracked set' not the whole market, explains the free/premium data components, and includes a disclaimer. This provides useful behavioral context beyond a basic read 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?

Description is moderately concise but includes some redundant phrasing ('stated as such', 'Not financial advice') and a bullet-like structure. It is front-loaded with a question but could be tighter without losing substance.

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 2 parameters, the description explains the data components (advance/decline, intraday pulse, relative-strength) and scope. However, it omits return format, examples, and parameter handling, leaving gaps for an agent to invoke correctly.

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

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

Schema description coverage is 0% with two parameters ('payment', 'session_token') left unexplained. Description does not clarify their meaning, format, or impact. The free/premium distinction relates to payment but is not explicitly linked to the parameter. This is a critical 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 clearly states the tool returns market breadth over a tracked crypto set, with a specific verb 'get' and resource 'market breadth'. It distinguishes free vs premium features but does not explicitly differentiate from sibling tools like 'get_market_summary' or 'get_trending', so not a perfect 5.

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 vs alternatives. Hints at free vs premium use cases but lacks context on prerequisites or when to prefer other sibling tools. Agents are left to infer usage.

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 the burden. It clearly states the tool is non-predictive ('NOT a forecast'), describes the output labels and drivers, and discloses that BTC trend is best-effort and null when unreachable, never faked. It also includes a disclaimer ('Not advice'). Missing details like rate limits or auth needs, but sufficiently transparent for a read-only market indicator.

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-5 lines) and well-structured: a question-answer intro, then bullet-like explanations. Every sentence adds value (purpose, method, tier differentiation, edge case handling, disclaimer). Could be slightly tighter, but overall efficient and easy to parse.

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

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

Given no output schema, the description reasonably explains the output for both free (label) and premium (drivers list). It covers edge cases (BTC trend null) and practical usage. With only 2 optional parameters, this level of detail is largely sufficient, though a brief note on return format (e.g., string vs object) would improve 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?

Schema coverage is 0%, so the description must explain parameters. It mentions 'Free = the label; premium = every driver' which hints at a payment parameter, but does not explicitly describe the `payment` or `session_token` parameters, their values, or how they affect behavior. The description fails to add meaning beyond the schema, leaving agents guessing about how to invoke correctly.

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 determine if the market is risk-on or risk-off (BULLISH/BEARISH/CHOPPY) by reading the tape, not forecasting. It explains the composite of breadth and relative strength over a tracked crypto set, distinguishing free vs premium output. This is specific and differentiates from siblings like get_market_breadth or 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 explicitly states it is a read of the tape, not a forecast, guiding agents to use it for current regime assessment rather than predictions. It mentions free vs premium tiers, implying payment usage, but does not explicitly list when not to use or alternative tools. However, the context from sibling tools suggests it for quick regime check, not for detailed analysis.

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?

Since no annotations are provided, the description fully discloses behavioral traits: tier limitations, clamping of timeframe, and unlocking mechanisms. It also lists valid input values, giving agents a clear understanding of tool behavior without contradictions.

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, using a single well-structured paragraph with key information front-loaded. Every sentence provides valuable detail without redundancy, making it easy for the agent to parse.

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

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

The description covers input parameters, tiers, and unlocking options thoroughly. However, it does not specify the return format or structure (e.g., JSON fields) for the output, which would be useful given the absence of an output schema. Still, it is mostly complete for a filtering 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?

With 0% schema description coverage, the description compensates excellently by explaining the semantics of all five parameters: timeframe (with clamping), category, lang, session_token, and payment (including source and purpose). This adds significant value beyond the bare 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 explicitly states 'Market recap' with filtering options, clearly indicating the tool's purpose of retrieving a market summary. It uses a specific verb ('get') and resource ('market summary'), and the context of sibling tools (e.g., get_attention_shifts, get_buzz_score) makes its general recap function distinct.

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 usage context: acceptable values for timeframe, category, and lang, along with tier-based constraints (free ≤24h, connected ≤7d). It explains how to unlock the full recap via session_token or payment proof, guiding the agent on when to use each parameter. However, it does not explicitly exclude alternative 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?

No annotations are provided, so the description carries the burden. It discloses that 'energy = item count, NOT sector returns' and mentions free vs premium tiers, which adds value. However, it does not discuss latency, data source, caching, or whether the tool 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 three sentences, front-loaded with an engaging question. It efficiently conveys the core idea, tiers, and a key clarification. Minor verbosity ('Not financial advice') is acceptable.

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 2 undocumented parameters, no output schema, and many siblings, the description lacks completeness. It does not explain the output format, parameter usage, or when to prefer this tool over alternatives. The free vs premium distinction is helpful but insufficient.

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 must explain the parameters. It does not mention 'payment' (likely for tier) or 'session_token' (likely for authentication) at all. No added meaning beyond the schema's default values.

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 across six categories. It distinguishes from siblings by focusing on a heatmap of energy (item count) over fixed recap categories, not sector returns or buzz scores.

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 when you want narrative concentration across categories, but it does not provide explicit when-to-use, when-not-to-use, or alternatives. Siblings like 'get_buzz_score' or 'track_narrative' could overlap, but no guidance 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?

With no annotations, the description carries full burden and is transparent: it discloses de-identification, free vs premium tiers, authentication requirements, valid window_hours values, and notes that the signal is unvalidated and not financial advice.

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 dense single paragraph but conveys all necessary information efficiently. A bit more structure (e.g., bullet points) could improve scannability, but it is reasonably concise.

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 what the output contains (top tickers + direction for free; full board with net USD, wallet counts, etc. for premium). It covers all parameters, usage context, and limitations, making it complete for an agent to decide and invoke 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 descriptions are absent (0% coverage), but the description adds meaning for all three parameters: window_hours options (6/12/24/48), session_token source (verify_wallet_ownership), and payment as x402 proof. It explains free vs premium functionality tied to 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?

The description clearly states it provides a list of tickers being net-bought by smart money/KOL wallets, a de-identified market-wide net-USD accumulation feed. It distinguishes from siblings by focusing on smart money flow, not general trends or whale alerts.

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

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

It explains free vs premium access and required authentication (session_token or payment). It does not explicitly list when not to use it or compare to siblings, but the context from sibling names provides 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 full burden. It discloses free vs. paid behavior, authentication requirements, and the meaning of 'No coverage'. It clarifies the output is narrative, not on-chain scoring. While it lacks rate limits or idempotency, the disclosure is strong for an unannotated 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 dense but efficient, front-loading the main purpose. It uses about four sentences with no wasted words. Formatting is slightly informal with line breaks but remains readable.

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 0% parameter descriptions, the description provides good context: free vs. paid, parameter constraints, authentication flow, and possible output (coverage headline vs. full timeline). It lacks explicit return structure but is sufficient for a tool of this complexity.

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 ticker (e.g., HYPE), window_days (1..90), session_token, and payment in context. Lang is not explained, but four of five parameters are covered with meaningful guidance, 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 retrieves what the digest said about a ticker over a window, including section appearances, notes, and price path. It distinguishes itself from siblings by specifying 'OUR narrative on the token (not on-chain scoring)' and mentions free vs. paid access, making it very clear.

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 parameter usage (ticker, window_days) and conditions for full access (session_token or payment). It indicates free returns a coverage headline and when 'No coverage' applies. However, it does not explicitly state when not to use this tool or compare directly with 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 burden. It discloses that the 1h measure is the freshest but coarsest and may be missing, and explains 'No coverage' meaning. However, it does not cover error handling, permissions, or what happens if the ticker is invalid.

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, but could be better structured with bullet points or clearer separation of concepts. No redundant 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?

Given no output schema and moderate complexity, the description lists returned components but lacks details on output format, error cases, or pagination. The sibling tools list is large, but description does not help agent differentiate sufficiently.

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 implies 'ticker' is a token ticker and hints that 'payment' controls free vs premium stack, but does not explicitly describe 'session_token' or provide any format/validation details. Only marginal additional meaning.

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

No explicit guidance on when to use this tool versus alternatives. It mentions free vs premium but does not explain when this tool is preferred over other market summary tools. No when-not-to-use or alternative naming.

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 and discloses important behavioral traits: free tier returns top 3, full ranking requires session_token or payment proof. This goes beyond the schema by explaining access restrictions, though 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?

The description is extremely concise: two sentences that front-load the purpose and cover key details. Every sentence adds value without repetition or unnecessary 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?

Given no output schema and 0% schema coverage, the description provides sufficient context: what the tool returns (top tickers with counts for full ranking), timeframe options, and access tiers. It could mention return structure (e.g., list of tickers with counts) but is adequate for a list 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 description coverage is 0%, so the description must add meaning. It explains the timeframe parameter options (24h, 7d, 30d) and the role of session_token and payment for unlocking. It adds value but does not fully specify formats or exact allowed values beyond the examples.

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 — the most-mentioned tickers,' using a specific verb and resource. It distinguishes itself from sibling tools like marketsummary__get_buzz_score or marketsummary__get_attention_shifts by focusing on overall trending tokens based on mention count.

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 (to get trending tokens by mentions) and explains the difference between free (top 3) and full ranking (top 15) via session_token or payment. However, it does not explicitly compare with alternative tools or specify 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?

The description indicates the tool returns public whale data and is read-only ('Public whale data' implies no side effects). It explains the data is not financial advice and mentions different access tiers. Without annotations, it adequately covers behavioral expectations.

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 core purpose and provides necessary detail without being overly verbose. Every sentence adds value, though it could be slightly more concise. The structure is clear and scannable.

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, parameters, usage hints (free vs. premium), and behavioral context. It does not detail the exact return format, but given no output schema, this is acceptable for a list-oriented tool. Overall, it provides sufficient context for an AI agent to correctly invoke 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?

The input schema has three parameters with no descriptions. The tool description adds meaning to all: 'ticker' is explained as optional filter, 'session_token' and 'payment' are described as authentication methods for premium data. This fully compensates for the 0% schema 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 the tool retrieves recent large on-chain moves from the whale feed, specifying what data is returned (tokens, USD size, direction). It distinguishes itself from sibling tools by focusing on whale alerts rather than general market summaries or other metrics.

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 optional filtering by ticker and the two authentication methods (session_token or payment) for premium access. It provides context on free vs. premium usage, but does not explicitly state when not to use this tool or suggest alternative tools for different purposes.

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 important behavior: 'attention only (no price)', 'coarse on sparse data', 'curated versioned set, constituents shown', and 'not financial advice'. These add transparency about what the tool does and does not provide. However, it does not mention authentication, rate limits, or update frequency.

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 of moderate length. It packs essential information: purpose, parameter usage, subscription differences, and limitations. While dense, it avoids unnecessary words. It could benefit from bullet points for clarity, but it remains concise and front-loaded with key information.

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 (narrative tracking, multiple baskets, free/premium) and the absence of an output schema, the description covers the main points. It hints at output format: 'list + hottest' vs 'full trajectories + constituents'. However, it does not fully specify the output structure, data freshness, or how constituents are shown. It is adequate but leaves some ambiguity.

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 explain all parameters. It only explains the `narrative` parameter ('Pass `narrative` for one basket, or leave empty for all ranked by velocity'). The `payment` and `session_token` parameters are not described, leaving the agent without guidance on how to use them. This is a significant 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 clearly states that the tool tracks the attention trajectory of crypto narratives across curated baskets. It lists specific basket names (defi, l1_l2, etc.), explains the optional `narrative` parameter, and distinguishes free vs premium outputs. This provides a specific verb+resource with clear scope, distinguishing it from 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 explains when to use the tool: to see which narrative is heating up. It gives explicit guidance on the `narrative` parameter (pass for one basket, empty for all ranked by velocity) and mentions subscription tiers (free vs premium). However, it does not explicitly state when not to use this tool versus siblings like `marketsummary__get_buzz_score` or others, though the purpose implies differentiation.

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. It discloses that results are self-contained and warns against speculating about data provenance. It mentions tier-gating and the role of session_token, providing good context for agent 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?

Description is compact with no redundant sentences. It front-loads the purpose, lists chains, explains free vs full, mentions tier-gating, and includes a provenance note. Every sentence adds value.

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, description explains output as 'verdict + top risks' for free and 'full breakdown' with session_token. It lacks details on error handling or output structure, but is sufficient for a safety check tool. Minor gaps prevent a 5.

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 description adds meaning: chain lists supported values and CAIP-2 form, session_token is tied to verify_wallet_ownership and unlocks full breakdown, and token_address is implied as the target. This compensates for schema 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 performs a 'rug-check' on a token, listing specific safety checks (honeypot, mint authority, etc.) and supported chains. It is distinct from sibling tools, which are market summary or verification 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 explains that a free call returns a verdict and top risks, while passing a session_token unlocks a full breakdown, and notes it is tier-gated. It does not explicitly state alternatives or when not to use, but the context is 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 challenge is single-use and expires in ~10 minutes, and specifies the return format. However, it does not mention failure modes, authentication requirements, or side effects. Still, it provides enough behavioral context for safe usage.

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, front-loaded with purpose, and no superfluous words. Every sentence adds value: purpose, parameter details, workflow, and return value. It is highly concise and 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?

Despite no output schema, the description explicitly states the return format: {challenge, nonce, expires_at}. It covers the entire process from initiation to next step. Given the tool's simplicity (3 params, no nested objects), the description is complete for effective 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?

Schema description coverage is 0%, so description must compensate. It explains 'chain' (evm/solana) and 'agent_id' (binds proof to identity), but fails to describe the required 'address' parameter. Two of three parameters are clarified, leaving a notable gap for the essential address field.

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 1 of wallet verification' and 'get a fresh challenge', specifying the verb and resource. It distinguishes itself from sibling tool 'verify__verify_wallet_ownership' by being the first step, making its purpose very clear.

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 guidance on when to use this tool: as the first step before calling 'verify_wallet_ownership'. It details the workflow: present challenge, have user sign, then call verify with nonce+signature. It also mentions chain options and agent_id usage, leaving no ambiguity.

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 the full burden. It discloses that the tool does not move funds or expose keys, and describes the success outcome (wallet linked, session_token). It also specifies return fields. This is transparent for a verification action.

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, well-structured paragraph of five sentences. Every sentence adds value: purpose, chain details, parameter relationships, outcome, safety reassurance. No redundancy or excessive 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?

Given the tool has 5 parameters, no annotations, and no output schema, the description covers nearly all essential aspects: purpose, prerequisites (challenge, agent_id, address), chains, signature format, return values, and integration with sibling tools. It could be slightly more complete by noting error cases.

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 coverage, the description adds significant semantic meaning: it explains chain options and signature formats, defines nonce as coming from the challenge, and clarifies that agent_id must match. This compensates well for the lack of schema documentation.

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

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

The description explicitly states the tool is 'Step 2 of wallet verification: prove control by signing the challenge from step 1.' This clearly identifies the verb (verify) and resource (wallet ownership) and distinguishes it from the 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?

The description provides clear context by naming it as step 2 and referencing the challenge from step 1, implying a two-step process. It also explains chain specifics and the need for matching agent_id. However, it does not explicitly state when not to use this tool or mention alternatives.

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