Fan Token Intel

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

With no annotations provided, the description carries the full burden. It states 'Returns data, not recommendations -- interpret results yourself', disclosing that it provides raw data rather than advice. It also lists included components (market regime, signals, anomalies, etc.), which sets expectations. However, it does not mention any side effects or limitations like rate limits, so it's slightly incomplete.

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 bold for emphasis and front-loading the purpose. Every sentence contributes value without redundancy. It efficiently communicates the tool's role, usage guidance, and output nature in just a few 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 the complexity of the tool (aggregates multiple data sources) and the absence of an output schema, the description provides a good overview of what data is included. However, it lacks details on the output structure or format, which would help an agent parse the response. Still, it is mostly complete for making an informed choice.

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

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

Schema coverage is 100%, so the schema already describes both parameters well. The description reinforces their use (e.g., 'Omit for full ecosystem view' for 'focus' and the meaning of 'morning' vs 'weekly' for 'timeframe') but adds little beyond what the schema provides. A baseline of 3 is appropriate.

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

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

The description clearly identifies the tool as an 'All-in-one ECOSYSTEM briefing' that aggregates multiple data points (market regime, signals, anomalies, etc.). It distinguishes itself from the sibling tool tokenintel_token_context by specifying 'use tokenintel_token_context for a SINGLE-TOKEN deep dive', making the purpose specific and differentiated.

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

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

Explicit usage guidance is provided: 'USE THIS for a market-wide overview' and 'USE tokenintel_token_context for a SINGLE-TOKEN deep dive'. It also suggests replacing sequential calls to 6+ tools, giving clear context on when to apply this tool over alternatives.

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

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

No annotations provided; description carries full burden. It describes a read-only analysis (volume relative to average, rotation detection). There is no mention of side effects, authentication, or rate limits, but the description is consistent with a safe informational 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?

Three sentences, each adding value: defines scope, explains function, and gives concrete example of rotation detection. 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?

No output schema is provided, and the description does not explain what the tool returns (e.g., list of tokens with metrics, flow amounts). For a complex analytical tool, the lack of output format is 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?

Only parameter 'hours' is described in the schema as 'Compare last N hours vs prior period. Default: 24.' The description does not add new meaning beyond this. With 100% schema coverage, baseline of 3 is appropriate.

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

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

Description clearly states 'cross-token capital flow analysis' and explains the specific behavior: shows fan tokens gaining vs losing volume relative to average, and detects rotation. This effectively distinguishes it from sibling tools that focus on single-token or market-level analysis.

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 analyzing capital rotation across tokens, especially after whale movements. While it doesn't explicitly state when not to use or compare alternatives, the specific purpose provides clear 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 must disclose behavior. It clearly states it returns JSON Schema for the tool, and implies it is a read-only introspection. Adequate for this simple 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?

Two sentences, no wasted words. Front-loaded with the purpose, then usage guidance. Efficient and clear.

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 simplicity of the tool (single parameter, no output schema needed, read-only), the description fully covers what the agent needs to know, including the suggested order of tools.

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 single parameter 'tool_name' is already described in the schema with a clear example. The description does not add additional meaning beyond what the schema provides. Schema coverage is 100%.

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?

Describes a specific verb ('Get') and resource ('full input schema for a specific tool'). Clearly distinguishes from siblings like tokenintel_discover and tokenintel_invoke by stating its role.

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?

Tells users to use tokenintel_discover first to find tool names, guiding the correct workflow. Does not explicitly state 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?

No annotations are provided, so the description carries full burden. It discloses that the tool computes constant-product price impact at specific trade sizes (1%, 5%, 10%, 25%) and uses 'latest on-chain liquidity snapshots'. This gives a good understanding of behavior and data source, though it could explicitly state that it is read-only and has no 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?

Three sentences with no fluff. First sentence states purpose, second explains computation, third gives use case and data source. Every sentence earns its place.

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

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

The description covers purpose, computation, and data source but does not describe the output format. For a tool that returns 'depth and slippage curves', it would be helpful to specify the structure (e.g., arrays of price impact vs. amount). Given no output schema, the description could be more complete about what the agent receives.

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 one optional parameter 'token' with description. The description adds value by specifying the default behavior when omitted: 'If omitted, returns all CHZ pairs sorted by TVL.' This clarifies the parameter's semantics beyond the schema's minimal 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 uses a specific verb 'Get' and clearly identifies the resource 'DEX depth and slippage curves' with context (fan token pools on Chiliz Chain). It distinguishes from siblings by specifying the computation of price impact at fixed trade sizes, unlike other tools like tokenintel_dex_liquidity which likely provide raw liquidity data.

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 'Useful for agents evaluating execution costs before trading', providing clear when-to-use guidance. It does not explicitly state when not to use or mention alternatives, but the context and sibling tool names imply that other tools exist for different aspects (e.g., liquidity, prices). This is sufficient but not exhaustive.

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 indicates a read operation ('Get'), but does not disclose behavioral traits such as authentication needs, rate limits, or potential side effects. For a data retrieval tool, minimal transparency about safety or restrictions is present.

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, front-loaded with purpose and followed by usage context and outputs. Every sentence adds value without redundancy. 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?

Given the tool's low complexity (one optional parameter, no output schema), the description adequately covers the main function, return values (TVL, depth, reserves, slippage), and usage context. It lacks details on data limits or formats but is sufficient for agent 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?

The input schema has 100% coverage (the optional 'token' parameter is described). The description adds the context of fan tokens on Chiliz Chain but does not significantly augment parameter meaning beyond what the schema already provides. Baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Get on-chain DEX liquidity data for fan tokens on Chiliz Chain.' It specifies the resource (DEX liquidity data) and action (Get), and lists specific outputs (TVL, depth, reserves, slippage), distinguishing it from siblings like 'tokenintel_dex_depth' and 'tokenintel_price_candles'.

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

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

The description provides usage context: 'Critical for agents that want to understand execution costs before trading on-chain.' However, it does not explicitly state when not to use it or compare with alternatives like 'tokenintel_dex_depth', which may overlap. The guidance is implied but not comprehensive.

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, but the description fully describes the output (tool names and descriptions) and the filtering behavior. It is a discovery tool with no side effects, and the description accurately reflects its read-only nature.

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 plus a tip, concise and well-organized. Every sentence adds value without wasted words.

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

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

The description adequately explains the tool's purpose, input, and output. Given that there is no output schema, the description compensates by stating what is returned (tool names and descriptions). The single parameter is fully documented.

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

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

Schema description coverage is 100% (enum values are described in schema). The description repeats the categories and indicates the parameter is optional, but does not add significant meaning beyond what the schema provides.

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

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

The description clearly states that the tool 'Returns tool names and one-line descriptions, organized by category.' This is a specific verb+resource combination that distinguishes it from sibling tools which are specific action 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 call with no arguments vs. with a category, and lists all categories. It also provides a tip about loading only specific categories. 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.

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 results are market-adjusted vs CHZ, returns specific statistics (mean, t-stat, CI, etc.), and warns against using as advice. It explains the pooling behavior ('Omit a dimension to pool'). There are no contradictions. However, it does not mention any restrictions, 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 concise at three sentences, no wasted words. The first sentence effectively front-loads the core purpose and dimensions, the second lists outputs, and the third adds a critical behavioral note (pooling and disclaimer). Every sentence earns its place.

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

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

For a 7-parameter tool with no output schema, the description adequately explains the core behavior, aggregation (pooling), and output fields. It does not mention default values (e.g., horizon_min default 30 is in schema but not description) but this is acceptable given high schema coverage. The warning 'descriptive history, not advice' adds important context.

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

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

Schema description coverage is high (86%), so the schema already documents most parameters. The description mentions the core dimensions but does not add extra meaning beyond what the schema provides. For example, 'scoreline_state' is described as 'Token team's state BEFORE the event' in the schema, and the description only says 'scoreline_state'. Thus, no additional value.

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

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

The description clearly states the tool returns event-conditioned, market-adjusted token reaction profiles, specifying dimensions like event_type, event_side, minute, scoreline_state, and importance. It lists output statistics. However, it does not explicitly distinguish itself from sibling tools such as tokenintel_goal_direction_asymmetry or tokenintel_late_game_redcard_profile, so it lacks sibling differentiation.

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 no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or contexts where other tools might be more appropriate. The only clue is the phrase 'descriptive history, not advice,' which is insufficient for usage decisions.

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 fully carries the burden. It discloses that the tool returns decomposition with sample sizes and hit rates, notes that scoring is priced-in while conceding moves price, and clarifies it is descriptive not advisory. This provides excellent 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 two sentences plus a disclaimer, each sentence earning its place. It front-loads the key concept and efficiently conveys the tool's value and limitations 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?

For a tool with one optional parameter, no output schema, and no annotations, the description is thorough: it explains the concept, what is returned, the underlying insight, and uniqueness. No gaps remain 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 coverage is 100% and the only parameter 'minute_bucket' is fully defined in the schema. The description does not add extra meaning beyond the schema, meeting the baseline expectation.

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

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

The description clearly states the tool's function: analyzing how a fan token reacts when its team scores vs concedes, with market adjustment and decomposition. It distinguishes itself from siblings by noting it requires the token<->team map, making its purpose unique.

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 implicitly indicates usage for exploring scored vs conceded asymmetry, and includes 'Descriptive history, not advice' as a usage caveat. However, it does not explicitly state when to use this tool vs alternatives, though the unique capability is highlighted.

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; description briefly mentions output (addresses and delegated CHZ) but lacks detail on completeness, freshness, 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?

Two concise sentences, front-loaded with action, 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?

For a zero-parameter, simple list tool, description is sufficient; could hint at ordering or data freshness but not necessary.

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?

No parameters in schema; baseline of 4 applies as description adds no param info, but none needed.

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?

Describes specific verb 'list' and resource 'active validators on Chiliz Chain governance', distinguishes from sibling tools which cover different topics like prices and sentiment.

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?

States explicit use case 'find the best validator before staking' but does not mention when not to use or alternatives.

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

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

With no annotations provided, the description fully explains key behaviors: percentile-based grading (A=top 10%, etc.), missing pillar exclusion with weight renormalization, and the crucial caveat to cross-check coverage_summary / n_pillars because a high grade on thin coverage is not equivalent to full market depth. This is extensive and honest behavior 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 fairly long but every sentence contributes essential information: purpose, grading weights, percentile definitions, missing-data handling, usage guidance, and response format options. It is well-structured and front-loaded, though slightly dense.

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?

This is a complex tool with no output schema, so the description must compensate. It explains the scoring pillars, weight renormalization, percentile grading, and warns about coverage interpretation. It also differentiates detailed vs concise responses. However, it does not fully enumerate all fields in the detailed response, leaving some ambiguity in the exact output shape.

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

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

There is only one parameter with 100% schema description coverage, so the baseline is 3. The description adds value by noting the default ('detailed') and the size reduction (~70% smaller). However, it lists the concise output as 'symbol/grade/score/change/pillars' while the schema lists 'symbol/grade/score/change_24h only,' creating a conflicting field set that could mislead the agent.

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

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

The description opens with a specific verb+resource: 'Get health grades (A-F) for all tracked fan tokens.' It clearly distinguishes this tool from siblings by focusing on health grades and the fan-token universe, including a detailed scoring methodology.

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

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

It gives a direct use case: 'Use this to quickly filter which tokens deserve attention relative to their peers.' While it provides clear context, it does not explicitly mention when not to use or name alternative sibling tools, so it stops short of a 5.

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. Description mentions 'Auth and rate limits apply as normal' but is vague. It states result is identical to direct call, which is accurate but doesn't disclose potential destructive nature or failure modes. Adequate but minimal.

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

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

Three sentences, each essential. No wasted words. Front-loads the core action and immediately follows with critical usage instructions.

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 generic invoker without output schema, the description covers purpose, parameter details, usage guidance, and points to sibling for argument discovery. Lacks specifics on error handling or behavior, but sufficient for intended 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 coverage is 100% (baseline 3). Description adds value by giving an example tool_name value and explaining that arguments matches the tool's inputSchema, aiding dynamic understanding.

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 'Invoke any tool on the Fan Token Intel MCP server by name', using a specific verb and resource. Distinguishes from siblings by being a generic invoker, not performing specific operations.

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 instructs to pass tool_name and arguments, notes that result is identical to direct call, mentions auth/rate limits, and directs to use tokenintel_describe for required arguments first. Provides both when-to-use and alternative.

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 transparency burden. It discloses statistical caveats ('honest wide confidence intervals and sample size', 'flags cells with n<15') and adds a disclaimer ('Descriptive history, not advice'). It does not explicitly state read-only or potential side effects, but given the analytical nature, the disclosure is strong.

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 with no filler. First sentence states purpose and key metrics. Second sentence adds statistical details and disclaimer. Every sentence earns its place.

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

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

Given the tool returns a statistical profile with no output schema, the description adequately conveys the output (abnormal returns at specified intervals, confidence intervals, sample size, and low-n flags). It covers key behavioral aspects but could be more explicit about the output structure (e.g., table vs. single value).

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

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

Schema coverage is 100% with descriptions for both parameters (event_side and minute_bucket). The tool description mentions 'late game' which aligns with minute_bucket options but does not add additional semantic meaning beyond what the schema already provides. Baseline score of 3 is appropriate.

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

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

The description clearly states it returns a 'Red-card reaction profile' with specific metrics (abnormal return at +15/+30/+60m). It distinguishes itself from sibling tools like 'tokenintel_event_reaction_profile' by focusing specifically on red card events, using the phrase 'Rare and high-impact' to highlight uniqueness.

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 red card events and notes it is 'descriptive history, not advice,' but does not explicitly state when to use this tool over alternatives such as tokenintel_event_reaction_profile or provide conditions where it should not be used.

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

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

No annotations provided, so description must fully disclose behavioral traits. 'Get' implies read-only, but no mention of data freshness, rate limits, or potential costs. Lacks detail on whether data is real-time or cached.

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 sentence packed with relevant information. No fluff, front-loaded with purpose. Every word contributes.

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 no-parameter tool without output schema, the description adequately covers what data is returned. However, with many sibling tools, additional context on how this fits into the overall suite would enhance 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?

Zero parameters, so baseline is 4. Schema coverage is 100% by default. Description adds value by explaining the output contents, which is sufficient for parameter-less 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?

Clearly states it provides crypto macro context with specific data points (BTC dominance, CHZ price, funding rates, fear & greed index, risk assessment). Distinguishes from sibling tools like tokenintel_token_context which focus on individual tokens.

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?

Implies usage for macro overview but does not explicitly state when to use this vs alternatives like tokenintel_briefing or tokenintel_market_regime. No when-not guidance or prerequisites 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 full burden. It describes what data is returned but doesn't disclose behavioral traits like read-only nature, authentication needs, or rate limits. For a stateless query tool with no parameters, the description is adequate but could be more explicit about being non-destructive.

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, front-loads the essential purpose, and adds a use case. Every word contributes value, with no redundancy or filler.

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

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

Given the tool has no parameters, no output schema, and no annotations, the description fully covers the tool's purpose and usage context. It answers what the tool does and when to use it, leaving no critical 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?

The tool has zero parameters, so schema coverage is 100% by default. The description doesn't need to add parameter info. Baseline 4 is appropriate since no parameters exist to elaborate.

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 retrieves current market conditions, listing specific data points (BTC trend, CHZ momentum, fear/greed index, market regime classification). It also provides a concrete use case for filtering signal confidence, distinguishing it from sibling tools like tokenintel_macro_context or tokenintel_social_sentiment.

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 explicit guidance on when to use this tool ('for filtering or adjusting signal confidence based on macro conditions'). It doesn't mention when not to use it or compare directly to alternatives, but the context is clear enough 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?

No annotations provided, but description discloses output details: individual match records with price at kickoff, fulltime, +1h, +24h and aggregate stats. Adequate for a read-only 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?

Two concise sentences, front-loaded purpose, no 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?

Covers purpose, output fields, and parameter usage via example. No output schema exists, but description sufficiently explains return values.

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

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

Schema coverage is 100%; description does not add parameter-level meaning beyond the schema. Baseline of 3 applies.

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

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

The description states the tool does 'Historical match-to-price correlation' with a concrete example ('what happens to BAR after Champions League wins?'), clearly distinguishing it from siblings like tokenintel_match_impact_history.

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 a clear usage example and context ('ask what happens to BAR after wins'), but does not explicitly state when to avoid or mention 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 provided, the description carries full burden. It discloses that the tool returns a tape, match metadata, and an other_matches index, and states that events are never merged across fixtures. It implies read-only behavior (data retrieval), but could be more explicit about non-destructive nature. The description adds good behavioral context beyond a simple 'get data'.

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 long, front-loaded with the core purpose, and every sentence adds value. No fluff or repetition. It efficiently conveys the tool's function, input, and constraints.

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 output schema, the description adequately explains what is returned (tape with per-event details, match metadata, other_matches index). It also covers parameter options and constraints. For a specialized tool with three optional parameters, the description is 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 100%, so baseline is 3. The description adds meaning by explaining how parameters interact: match_id selects a specific fixture, while token+optional date resolves the most recent or date-selected fixture. This clarifies usage beyond the individual parameter 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 'Event-by-event reaction tape for a single match,' specifying the verb (replay), resource (match events), and details like goals, red cards, running score, and token reactions. It distinguishes from siblings by labeling it a 'non-reconstructable moat artifact' and explaining its one-fixture resolution.

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 how to use parameters (match_id vs token+date) and that events are never merged across fixtures, but it does not explicitly state when to use this tool over siblings like tokenintel_event_reaction_profile or tokenintel_match_impact_history. The guidance is implicit, not directive.

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 carries the full burden. It discloses the specific time windows for price snapshots and explains the difference between return_total_pct and return_ko_to_24h_pct, noting that the former can differ in sign from a kickoff-anchored return. This is good behavioral insight, though it does not cover side effects, authorization, 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 reasonably concise, comprising four sentences with the main purpose front-loaded. It uses helpful terminology like 'WINDOWS' and references a semantics block. The inclusion of competition and venue filters that are not present in the schema adds slight noise.

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

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

Given the lack of an output schema, the description partially compensates by detailing the two return metrics and referencing a 'semantics' block in the response. However, it does not describe the overall response structure (e.g., array of matches, fields), and there are no annotations. The completeness is adequate but not thorough.

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

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

With 100% schema coverage, the baseline is 3. The description adds value by explaining the context of the return metrics and the relationship between the time windows, which goes beyond the basic schema descriptions. However, it erroneously mentions competition and venue filters that are not in the schema, slightly detracting from accuracy.

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 'Historical match price impact data for a fan token' and specifies the verb 'Returns' with concrete time snapshots. However, it mentions filters for competition and venue that are not in the input schema, which is slightly misleading. It does not explicitly differentiate from sibling tools but is specific enough.

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 includes 'Use for backtesting sports-driven strategies', which implies an intended use case, but it lacks guidance on when not to use or how this tool compares to alternatives like tokenintel_match_event_replay or tokenintel_match_odds. No explicit exclusions or sibling comparisons.

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 default exclusion of settlement wind-down ticks, downsampling to ≤300 points, and counting of excluded ticks. Could mention any rate limits or data freshness, but overall 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 a single, dense paragraph but effectively front-loads the core purpose and key behaviors. It could be slightly more concise, but 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?

No output schema exists, so description must explain return values. It thoroughly describes the curve composition: per-market implied probabilities, source labels, pre-match vs in-play segmentation, summary stats, and downsampling. Also covers excluded ticks and discovery via sibling tool.

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

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

Schema coverage is 100% with parameter descriptions. The description adds value by explaining the token resolution logic (most recent or date-selected fixture) and the effect of include_settlement_ticks. This supplements the schema well.

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

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

The description clearly specifies the tool provides a prediction-market odds curve for a single match, detailing the data sources, preprocessing, and summary stats. It distinguishes from sibling tokenintel_odds_coverage by stating it covers a single match and directing users to that tool for discovery.

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 explains two modes of selection (match_id vs token+date) and advises to use tokenintel_odds_coverage to find matches with odds data. Provides clear context for when to use this tool versus 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?

Despite no annotations, the description fully discloses behavioral traits: it explains that in-play odds are unbackfillable, that it computes per-match tick counts by source, and that live dataset totals are computed from the table (never hardcoded). This provides sufficient transparency for safe invocation.

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 fairly concise for the amount of information it conveys. It front-loads the primary purpose and specific outputs. Minor redundancy (e.g., mentioning 'live dataset totals' twice) prevents a perfect score.

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 3 optional parameters with full schema coverage, the description provides comprehensive context about what the tool returns, its limitations (unbackfillable), and how it relates to sibling tools. It is complete enough for an agent to use effectively.

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

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

Schema coverage is 100%, so the description does not need to add extra parameter details. The description does not provide additional semantics beyond the schema's parameter descriptions. Baseline score of 3 is appropriate.

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

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

The description explicitly states the tool's function: discovering matches with prediction-market odds coverage. It details specific outputs (tick counts by source, in-play vs kickoff, etc.) and distinguishes itself from the sibling tokenintel_match_odds by stating that tool fetches probability curves for covered matches.

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 for when to use this tool (before fetching odds to check coverage) and explicitly directs the agent to tokenintel_match_odds for fetching covered matches' probability curves. It also notes the limitation that in-play odds are unbackfillable, guiding appropriate 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?

No annotations provided; description carries full burden. Discloses intervals, lookback limit (180 days), and output (OHLCV). Does not mention rate limits or data freshness, but for a historical data tool this is adequate.

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, no fluff. Front-loaded with purpose. Every sentence contributes 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 and no annotations, description explains return format (OHLCV), intervals, and lookback limit. Could mention pagination or aggregation, but sufficient for a simple data retrieval tool.

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

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

Schema coverage 100% with descriptions for all 4 parameters. Description adds minimal extra meaning beyond schema (e.g., reiterates intervals and max days). Baseline 3 is appropriate.

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

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

Clearly states verb ('returns') and resource ('Historical OHLCV price candles for any fan token'). Distinguishes from sibling tools like tokenintel_realtime_prices by specifying historical nature. No 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?

Explicitly lists use cases: 'backtesting, charting, trend analysis, or building your own signals.' Does not explicitly state when not to use or name alternatives, but the context is clear. Minor room for improvement.

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 mentions returning price_age_seconds and supporting multiple tokens, but does not explicitly state it is read-only or disclose any side effects 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?

Three sentences, each adding value: purpose, detail on return value, and usage hint. No wasted words, 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?

For a simple tool with one parameter and no output schema, it covers purpose, key behavior (staleness), and usage guidance. Minor omission of read-only nature, but overall sufficient.

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

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

Only one parameter with 100% schema coverage. Description adds a usage example but does not add significant meaning beyond the schema; baseline 3 is appropriate.

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

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

The description clearly states it gets 'the freshest available prices with staleness metadata' and distinguishes itself from sibling tools like price_candles and dex_depth by focusing on real-time prices.

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?

States to call 'before any trade decision' which gives clear context for usage. Does not explicitly exclude cases or mention alternative tools, but the sibling list makes alternatives obvious.

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 the tool returns an API key, tier, and rate limits; requires name, email, terms acceptance; has a 10-minute cooldown; and may require email verification. It also explains authentication methods. It is transparent about the registration process 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 a single paragraph but is well-structured and front-loaded. Every sentence provides necessary information without redundancy. It could be slightly more structured with bullet points, but overall it's efficient.

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

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

Given the tool's simplicity (3 parameters, no output schema), the description is comprehensive: it explains the key format, authentication, rate limits, cooldown, and what the key unlocks. No missing critical information.

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 covers 100% of parameters with descriptions. The tool description adds extra context: for email, notes that the key may require verification; for terms_accepted, includes the legal URLs. This adds value beyond the schema, earning a score above baseline 3.

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: 'Get a free Fan Token Intel API key, self-serve — no human in the loop.' It uses a specific verb and resource, and distinguishes itself from sibling tools (which are all other API tools requiring the key).

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 obtain an API key) and what it unlocks (read-only descriptive data layer, premium metered). It mentions rate limits and cooldown, but does not explicitly list alternative tools or scenarios where this tool should not be used. However, the context is clear that this is a prerequisite for other 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?

In the absence of annotations, the description thoroughly discloses behavioral traits: data source limitations ('only live social source is LunarCrush'), field availability ('sentiment and social_volume come back null'), historical ingestion status, and how data_sources labels indicate pipeline states. It also clarifies the tool's purpose is descriptive data, not a recommendation.

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 with necessary detail and front-loads the purpose. While every sentence adds value, the paragraph is slightly long but remains clear and effective.

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

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

Given the lack of an output schema, the description explains return behaviors well (galaxy_score, alt_rank, null fields, data_sources labels). It provides enough context for the agent to understand the tool's output and limitations.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. The description does not add further detail beyond the schema, which is sufficient. Baseline score of 3 is appropriate.

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

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

The description clearly states the tool provides social sentiment for fan tokens, using a specific verb ('Social sentiment') and resource ('fan token'). It differentiates from siblings by focusing solely on sentiment analysis among many token intelligence 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 provides clear context on data availability (LunarCrush feed only, retired ingestion channels) and states it is descriptive, not a recommendation. However, it does not explicitly mention when to use or avoid this tool relative 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 discloses that tool fetches realtime data across multiple sources (price, whale flow, liquidity, matches). Could be more explicit about read-only nature and rate limits, but sufficiently transparent for a data retrieval 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?

Two concise sentences with clear purpose, usage guidance, and examples. No unnecessary words; 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?

No output schema exists, so description must explain return data. It lists realtime price, CEX whale flow, on-chain liquidity with slippage, and upcoming matches. Could mention format or caveats, but it's fairly complete for a realtime data tool.

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

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

Schema coverage is 100% with one parameter 'token' already described as symbol. Description adds examples (ASR, BAR, CHZ) but schema already mentions them. Does not add significant meaning beyond schema, so baseline 3 is appropriate.

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

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

Description clearly states it is a 'SINGLE-TOKEN deep dive' listing specific data points (realtime price, CEX whale flow, liquidity with slippage, upcoming matches) and explicitly distinguishes from sibling tokenintel_briefing (market-wide overview).

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 'default tool to call before evaluating a trading decision on a specific token' and provides when to use ('when you have a target token in mind') and when not (use tokenintel_briefing for market-wide overview).

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

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

The description discloses key behavioral traits: it is real-time, data is aggregated from CEX exchanges, and it explains the sell_ratio metric. However, it lacks details on what happens in edge cases (e.g., no trades, token not found), rate limits, or data freshness guarantees. Given no annotations, the description does a good but not exhaustive job.

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 and well-structured: it starts with the core purpose, explains the key metric, provides an interpretive threshold, states the data source, and gives usage guidance. Every sentence adds value with no 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?

There is no output schema and no annotations, so the description must specify the return format. It mentions 'sell_ratio' but does not list all output fields or describe the structure (e.g., is it a single value or time series?). This lack of completeness makes it harder for an agent to correctly parse the response.

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

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

Schema coverage is 100%, so baseline is 3. The description does not add significant new semantics beyond the schema; it mentions the sell_ratio output but does not elaborate on parameters like min_trade_usd or timeframe_hours beyond what the schema already describes.

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: it gets real-time whale distribution data for a fan token, showing the ratio of whale sells to total whale activity on CEX exchanges. It distinguishes itself from siblings by explicitly directing usage: 'USE THIS for aggregate buy/sell pressure on CEX. USE tokenintel_whale_trades for individual trade rows. USE tokenintel_dex_whales for on-chain swap whales.'

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 versus alternatives: it is for aggregate buy/sell pressure on CEX, while tokenintel_whale_trades is for individual trade rows and tokenintel_dex_whales is for on-chain whales. It also gives an actionable threshold ('sell_ratio above 0.65 indicates distribution/bearish').

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