Fan Token Intel

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

No annotations provided, so description carries full burden. Notes it returns data not recommendations, but doesn't explicitly confirm read-only nature or disclose other behavioral traits like rate limits or permissions.

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 with clear use cases and alternatives. Front-loaded with purpose. Slightly verbose 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?

Given the tool's complexity (aggregating multiple data types) and lack of output schema, the description adequately lists what the briefing includes and clarifies it's not investment advice. Completely covers expected functionality.

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 useful context: 'Omit for full ecosystem view' for focus parameter, and explains timeframe meanings ('morning' = 24h, 'weekly' = 7-day). Augments schema descriptions.

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

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

Clearly states it is an all-in-one ecosystem briefing covering market regime, signals, anomalies, health matrix, sports calendar, and whale activity. Distinguishes from sibling tool tokenintel_token_context by scope level.

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 tells when to use this tool (market-wide overview) and when to use alternative (single-token deep dive with tokenintel_token_context). Also advises to interpret results independently.

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 for behavioral disclosure. It describes the analysis (read-only) but does not explicitly state it is non-destructive, require no authentication, or mention any limitations like data freshness 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 concise (two sentences) and front-loaded: the first sentence summarizes the core purpose. Every sentence adds value without unnecessary detail.

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 does not explain the format or structure of results. However, it sufficiently conveys the tool's purpose and what it detects, and the sibling context clarifies the domain. A brief mention of output 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?

Schema coverage is 100% (one parameter 'hours' described). The description adds minimal value beyond the schema, merely restating 'Compare last N hours vs prior period' and the default value already present in the schema.

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

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

The description clearly states it performs cross-token capital flow analysis, shows volume changes for fan tokens, and detects capital rotation. This specifically distinguishes it from sibling tools like tokenintel_whale_flows (single-token whale movements) and tokenintel_price_candles (price 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 implies usage for analyzing capital rotation among fan tokens, but does not explicitly state when to use this tool over alternatives or provide exclusions. No guidance on prerequisites or when not to use it.

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

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

No annotations are provided, so the description must disclose behavioral traits. It states the tool returns JSON Schema with parameter details, which is accurate for a read-only introspection tool. However, it does not explicitly mention that the tool has no side effects or destructive potential, but given the straightforward nature, it 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?

The description is two sentences long, with the primary purpose stated first. It is concise, contains no fluff, and 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 the tool's simplicity (one parameter, no output schema), the description fully covers what the tool does, what it returns, and how to use it in conjunction with sibling tools. No additional details are 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?

Schema coverage is 100%, so baseline is 3. The description only provides an example value for the parameter, which adds minimal semantic value beyond what is already in the schema. No additional constraints or formatting details are given.

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: 'Get the full input schema for a specific tool.' It identifies the verb and resource precisely, and distinguishes from siblings by mentioning tokenintel_discover for finding tool names and tokenintel_invoke for calling the tool.

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 a usage hint: 'Use tokenintel_discover first to find tool names,' which provides a clear sequence. It implies this tool is for when you need the schema to invoke a tool; however, it does not explicitly state 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?

Discloses computation method (constant-product price impact), specific trade sizes, and data source (latest on-chain snapshots). No annotations provided, so description carries full burden; adequately transparent for a read-only data 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 concise sentences, each adding value: core function, computation details, and use case. 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?

Adequate for a simple tool with one optional parameter, but lacks output structure details. Without output schema, description could mention what is returned (e.g., list of depth curves).

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 adds useful default behavior detail ('If omitted, returns all CHZ pairs sorted by TVL'), exceeding baseline.

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 'Get' and specific resource 'DEX depth and slippage curves for fan token pools on Chiliz Chain'. Distinguishes from sibling tool tokenintel_dex_liquidity by focusing on depth and price impact computation.

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 usage context ('evaluating execution costs before trading') but does not explicitly mention when not to use or suggest alternative sibling tools.

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

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

With no annotations provided, the description carries full burden and clearly states the tool returns specific data types (TVL, depth, reserves, slippage), which is sufficient for a read-only tool. No behavioral contradictions or omissions noted.

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

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

The description is extremely concise with two sentences: one stating the action and returns, another stating the use case. Every sentence adds value without redundancy.

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

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

Given no output schema, the description adequately explains the return fields. It does not mention pagination or limits, but for a simple single-parameter tool, it is fairly 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% and the description adds value by contextualizing the parameter (fan tokens on Chiliz Chain) and the default behavior (all pools sorted by TVL), which goes beyond the schema's explanation.

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 on-chain DEX liquidity data for fan tokens on Chiliz Chain and lists specific return fields. However, it does not explicitly differentiate from the sibling tool 'tokenintel_dex_depth', which may have overlapping functionality.

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

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

The description implies usage by stating it is critical for understanding execution costs before trading, but it does not specify when not to use it or mention alternative tools for different scenarios.

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 adequately describes the tool's behavior: returns tool names and descriptions organized by category, with optional filtering. It does not explicitly state that it is read-only or has no side effects, but 'discover' implies safe inquiry. The description is transparent enough for a non-destructive tool.

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

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

The description is extremely concise: two sentences plus a tip. Every sentence adds value, with the most critical information (purpose and usage) front-loaded. No unnecessary words or repetition.

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 (single optional parameter, no output schema, read-only nature), the description is complete. It covers what the tool does, how to use it, what categories are available, and even offers a server configuration tip. No gaps remain for a discovery 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?

The single parameter 'category' is fully described in the schema with an enum and description. The description adds value by listing the categories and explaining the two modes (all vs filtered). Schema coverage is 100%, and the description enhances understanding 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 explicitly states the tool's purpose: 'Discover available tools on the Fan Token Intel MCP server.' It specifies the verb (discover), resource (tools), and output format (names and one-line descriptions by category). This clearly distinguishes it from sibling tools, which are all specific data or analysis 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 concrete usage guidance: 'Call with no arguments for all categories, or specify a category to filter.' It lists all valid categories and offers a practical tip about connecting with modules. This gives the agent clear options and context for when to use each variant.

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. States 'descriptive history, not advice' implying non-actionable nature. But does not explicitly mention that it is read-only, safe, or any rate limits/permissions. Adds moderate behavioral context.

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

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

Single concise paragraph, front-loaded with key concept. Every sentence provides unique information. 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 tool with 7 parameters and no output schema, the description adequately explains the return format, how to use parameters (conditioning and pooling), and the data nature. Missing explicit mention of read-only status or authentication, but overall complete.

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

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

Schema description coverage is high (86%), so baseline is 3. The description adds high-level semantics like 'omit a dimension to pool' and explains the sample size aspect, which goes beyond the schema. Does not provide deep per-parameter details beyond what schema already has.

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 token reaction profiles for football events conditioned on multiple dimensions. It specifies exact output statistics (mean/median abnormal return, t-stat, etc.) and distinguishes from sibling tools by being a data-driven profile tool.

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

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

Provides clear usage context: define dimensions to condition on, omit to pool. Emphasizes it's descriptive not advisory. However, does not explicitly compare with siblings like tokenintel_match_event_replay or tokenintel_late_game_redcard_profile to guide when to use this tool.

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

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

No annotations provided, so description carries full burden. Discloses output: scored-vs-conceded decomposition with sample sizes and directional hit rates. States it's market-adjusted and descriptive history, not advice. Implicitly read-only. Adds value beyond schema.

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 informative but slightly verbose. Contains multiple clauses and caveats. Could be streamlined, but every sentence adds value. Well-structured for the amount of detail.

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 one optional parameter, the description fully explains what is returned (decomposition, sample sizes, hit rates), the market-adjustment, and the exclusive data requirement. Adds important qualifier 'not advice'. Complete for agent understanding.

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

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

Only one parameter (minute_bucket) with 100% schema coverage. Schema already describes the parameter. Description adds context about overall time intervals (+15/+30/+60m) but not directly about the parameter. 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 the tool analyzes fan token reaction when team scores vs concedes, market-adjusted vs CHZ at specific intervals. Differentiates from siblings by noting 'only computable here (needs the token<->team map)'. Specific verb+resource+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?

Explains that the blended 'all goals' number hides real signal, implying use this for decomposed view. States 'only computable here' to indicate exclusivity. Does not explicitly state when not to use, but context is clear.

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

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

With no annotations provided, the description carries full burden. It correctly indicates a read-only, non-destructive operation by stating it shows data. It could be more explicit about being read-only, but it's 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 wasted words. The action is front-loaded and immediately 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?

For a simple tool with no parameters and no output schema, the description is complete enough. It covers purpose and use case. Minor omission: no mention of data freshness or 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?

The tool has zero parameters, so the baseline is 4. The description adds value by explaining the output (validator addresses and delegated CHZ), which goes beyond the empty input schema.

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

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

The description clearly states it lists active validators on Chiliz Chain governance, showing addresses and delegated CHZ. The verb 'List' and specific resource 'active validators on Chiliz Chain governance' leave 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?

The description explicitly says 'Use this to find the best validator before staking,' providing clear usage context. However, it does not mention alternative tools or when not to use it, which slightly reduces the score.

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

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

No annotations provided, so description carries full burden. Clearly describes output (grades, scores, change) and optional concise format. Does not mention auth or rate limits, but as a read operation this is acceptable.

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?

Efficient description: two sentences plus usage tip. Front-loaded with purpose, no fluff, 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 no output schema, description adequately explains output content (grades, scores, dimensions) and optional concise format. Sufficient for this simple list-returning 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%, description adds context for when to use concise format ('~70% smaller', omit detail) beyond enum 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?

Clearly states verb 'Get health grades' for resource 'all tracked fan tokens', lists scoring dimensions (price momentum, volume, social, whale pressure), and distinguishes from siblings by unique health assessment purpose.

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 use to filter which tokens deserve attention, explains grade meanings (A/B strong, D/F weak), and provides usage tip for concise format. Lacks explicit 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, the description adds transparency by stating that auth and rate limits apply as normal and that the result is identical to calling the tool directly. This covers key behavioral aspects.

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 unnecessary words. Each sentence provides essential information: purpose, usage, and prerequisite step.

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 meta-tool with two parameters and no output schema, the description covers invocation, argument discovery, and behavioral implications, making it complete for an agent to use 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?

The description explains that tool_name is a string like 'tokenintel_whale_flows' and that arguments should match the tool's inputSchema, adding meaning beyond the schema's property definitions.

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 invokes any tool on the server by name and passes arguments, which is specific and distinct from sibling tools that are individual functionality 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?

It advises using tokenintel_describe first to get required arguments, providing clear context on when to use this tool. It doesn't explicitly state when not to use it, but the guidance 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?

With no annotations, the description bears full responsibility. It discloses key behavioral traits: market-adjusted returns, time intervals, confidence intervals, sample size flags, and a disclaimer ('not advice'). It does not mention permissions or rate limits, but for a read-only data tool, this is sufficient.

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) with all key information front-loaded: what it is, what it returns, and a disclaimer. 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 or annotations, the description explains the output well (abnormal returns, intervals, flags). However, it could be more explicit about the format of the returned data (e.g., a table or list).

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 covers 100% of parameters with descriptions, so baseline is 3. The description adds context (red cards) but does not provide additional parameter semantics beyond the schema, such as format or 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's purpose: analyzing market reactions to red card events, adjusted vs CHZ, with specific output metrics. It distinguishes itself from sibling tools like tokenintel_event_reaction_profile by focusing exclusively on red cards.

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 (rare, high-impact) but does not explicitly state when to use this versus alternatives like tokenintel_event_reaction_profile or tokenintel_goal_direction_asymmetry. It lacks explicit when-not and 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?

No annotations are provided, so the description must carry the full burden of behavioral transparency. It lists outputs but does not mention if it's read-only, latency, authentication requirements, or data freshness. For a macro context tool, additional behavioral details would be useful but not critical.

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 sentence listing all key outputs, which is concise. However, it could be slightly more structured (e.g., bullet points) for clarity, but overall it is efficient 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 the tool has no parameters and no output schema, the description adequately lists all returned data points. It is complete for its purpose, though it could mention update frequency or data sources for 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?

With zero parameters and 100% schema description coverage, the description adds meaning beyond the schema by explaining the type of data returned (macro context metrics). Baseline 4 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: retrieving current crypto macro context. It lists specific data points (BTC dominance, CHZ price, funding rates, fear & greed index, risk environment assessment), distinguishing it from siblings 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?

The description does not explicitly state when to use this tool versus alternatives. It implicitly suggests use for broad market overview, but lacks guidance on when not to use or alternative tools like tokenintel_briefing or tokenintel_market_regime. The no-parameter schema implies it's a simple fetch, but no explicit usage context.

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

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

With no annotations, the description fully explains the tool is a read operation returning specific market data. No hidden side effects or destructive behavior are implied, and the scope of data is clearly listed.

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 perfectly sized. The first sentence immediately states the action and outputs; the second sentence adds context. No redundant words, every part earns its place.

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

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

For a zero-parameter tool without output schema, the description completely covers what the tool does and returns. It is sufficient for an agent to understand and use 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?

There are no parameters, so the schema coverage is 100%. The description adds value by specifying what the tool returns (market conditions), which is extra information beyond the empty schema. Baseline for 0 params is 4.

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 gets current market conditions including specific indicators (BTC trend, CHZ momentum, fear/greed index, regime classification), distinguishing it from sibling tools like tokenintel_social_sentiment or tokenintel_macro_context by focusing on market regime 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?

The description provides explicit usage guidance: 'Useful for filtering or adjusting signal confidence based on macro conditions.' This tells the agent when to apply the tool, though it does not include explicit when-not-to-use or alternative names.

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 details the output (individual match records, price points, aggregate stats) and mentions 'backtested data with price impact percentages'. No annotations are provided, so the description carries full burden; it adequately conveys the tool's read-only nature and expected behavior.

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

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

The description is concise with two well-structured sentences. The first sentence defines the tool's core function, and the second elaborates on returns. No unnecessary words or fluff.

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

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

Despite no output schema, the description adequately explains return values (individual records and aggregate stats). With 5 parameters and 2 enums, the description covers the essential behavior. Minor omission: it does not explicitly list filter parameters available, but the schema covers them.

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 documents all parameters. The description adds context via the example but does not provide additional semantic meaning beyond what the schema offers. 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: 'Historical match-to-price correlation' with a concrete example ('what happens to BAR after Champions League wins?') and specifies the output (individual match records with prices, aggregate stats). It distinguishes itself from siblings like tokenintel_match_impact_history by focusing on price correlation and impact percentages.

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 use case ('Ask what happens to BAR after Champions League wins?'), implying when to use it. However, it does not explicitly state when not to use it or name alternatives, though the sibling context highlights 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 the tool resolves one fixture based on token+date, returns tape, metadata, and index, and that events are never merged across fixtures. However, it does not mention authentication requirements, rate limits, or any potential side effects, leaving some gaps.

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

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

Description is dense and informative but slightly verbose. First sentence packs a lot of information; overall it is well-structured with clear separation of what the tool does and parameter behavior. No wasted sentences, but could be streamlined slightly.

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 thoroughly explains return values: tape (with events, timing, running score, scoreline state, market reactions at multiple intervals), match metadata, and other_matches index. It also covers special behavior (no merging across fixtures). This is complete for the tool's 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 has 100% coverage, baseline 3. Description adds meaning beyond schema by explaining how token+date resolves one fixture (date-selected or most recent) and that match_id selects that fixture. It clarifies the interaction between parameters, which is valuable.

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 specifies the tool provides an 'event-by-event reaction tape for a single match' with detailed events (goals/red cards) and market reactions. It distinguishes from siblings by emphasizing its unique 'non-reconstructable moat artifact' and that events are never merged across fixtures, making purpose 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?

Usage context is implied through description of what it returns and parameter behavior, but there is no explicit guidance on when to use this tool versus alternatives like tokenintel_event_reaction_profile or tokenintel_goal_direction_asymmetry. No 'when not to use' or alternative recommendations.

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

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

No annotations provided, so description carries full burden. It discloses return data structure (price snapshots and returns per match) and available filters. It does not discuss authentication, rate limits, or side effects, but as a read-only data retrieval tool, this is acceptable.

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 front-load the purpose and use case. No wasted words. Penalty for including filter options not in the schema, which harms clarity.

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

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

With no output schema, description partially compensates by describing returned data (price snapshots and returns). However, it omits response format details and includes unsupported filters, leaving gaps in 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 100% with descriptions for all parameters. However, the description mentions filters for 'competition' and 'venue' that are not present in the input schema, which is misleading and adds false information. This reduces the value added 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?

Description clearly states what the tool does: returns historical match price impact data for a fan token with specific snapshot timings (kickoff, fulltime, +1h, +24h). It distinguishes itself from siblings by focusing on historical match impact, which is unique among the listed 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?

Description explicitly mentions 'Use for backtesting sports-driven strategies,' providing a clear use case. However, it does not mention exclusions or alternative tools, though the context is sufficient for understanding when 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?

No annotations are provided, so the description carries the full burden. It transparently states the data returned (OHLCV), intervals, and lookback constraint. It does not cover potential edge cases like missing data or rate limits, but its straightforwardness is sufficient.

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 the primary purpose, and includes key constraints and use cases without fluff. Each 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 the tool's simplicity (4 parameters, no output schema, many siblings), the description covers purpose, inputs, and use cases adequately. Minor gaps like error handling or return format details are not critical for a 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 is 100%, so baseline is 3. The description adds minimal extra meaning beyond summarizing the schema (intervals, lookback, candle fields). No new syntactic or contextual details are provided.

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 providing historical OHLCV price candles for fan tokens, specifying intervals and lookback limit. It distinguishes itself from siblings like tokenintel_realtime_prices by focusing on historical 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 lists use cases (backtesting, charting, trend analysis) which implies when to use it. However, it does not explicitly mention when not to use it or name alternative tools, missing an opportunity to differentiate further.

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 returns price_age_seconds and supports batching, but lacks details on caching, update frequency, or side effects. Adequate but not comprehensive.

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

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

Three short sentences: purpose, key output field, usage guidance. Every sentence adds value, front-loaded with essential info. No extraneous text.

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

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

Lacks output schema, so description should explain return structure. Only mentions price_age_seconds, not price values or token identifiers. Incomplete for reliable agent use. Adequate for a simple tool but missing details.

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 a clear parameter description. The description confirms batching but adds no new meaning beyond 'supports multiple tokens'. 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 fetches the freshest prices with staleness metadata, using specific verbs like 'Get'. It distinguishes from siblings (e.g., price_candles for historical data) by emphasizing real-time nature and staleness info.

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 says to call this before any trade decision, providing clear context for use. It omits direct alternatives or when-not-to-use, but the guidance is sufficiently precise for a tool with many siblings.

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

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

With no annotations, the description carries the full burden. It transparently explains that data comes from LunarCrush aggregated feed, that native feeds may be inactive, and that overall_sentiment is computed only from active sources. It also clarifies it is descriptive, not a recommendation. This provides a good understanding of the tool's behavior.

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

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

The description is concise, consisting of four sentences that efficiently convey the tool's purpose, data sources, and output considerations. No extraneous information is present, and key points are front-loaded.

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

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

Given no output schema, the description adequately covers the tool's inputs and expected output (including data_sources field and computation logic). It provides a solid understanding of what the tool returns and how it behaves, though a bit more detail on the output structure could 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?

Schema coverage is 100%, so the schema already describes both parameters. The description adds minor value by providing example token symbols (ASR, BAR, PSG) and mentioning the lookback window, but does not significantly enhance understanding 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 that the tool provides social sentiment for a fan token, driven by LunarCrush aggregated feed, and lists specific metrics (galaxy score, alt rank, social volume, sentiment). It also mentions native feeds and computation logic, distinguishing it from sibling tools like tokenintel_briefing or tokenintel_market_regime.

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

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

The description provides clear context for when to use the tool (for social sentiment data) and mentions checking data_sources for active feeds, but does not explicitly state when not to use it or name alternatives. The implied usage is clear, but lacks 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 data provided but does not explicitly state read-only nature or limitations. Minor gap for a 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?

Two sentences: first lists capabilities, second gives usage guidance. No wasted words, front-loaded with 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?

Simple tool with one param, no output schema. Description covers all input semantics and contextual use, including sibling differentiation. Fully adequate.

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?

Single parameter 'token' has schema description 'Token symbol (e.g., ASR, BAR, CHZ)'. Description adds no extra meaning beyond schema, so baseline 3 for 100% 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?

Description clearly states it's a 'SINGLE-TOKEN deep dive' specifying data types (realtime price, CEX whale flow, on-chain liquidity, upcoming matches) and distinguishes from sibling tokenintel_briefing.

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 instructs to use tokenintel_briefing for market-wide overview, providing clear 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?

Discloses data is aggregated from CEX exchanges in real-time and explains the significance of the sell_ratio threshold (0.65 bearish). Lacks details on potential limitations like rate limits, but for a read tool this is solid. No annotations, so description carries full burden.

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

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

Concise, well-structured. Front-loads purpose and metric, then immediately provides usage guidance. Every sentence adds value; no unnecessary 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?

Explains output concept (sell_ratio) and its interpretation, which compensates for missing output schema. However, does not describe the full return format (e.g., other fields). Adequate for a simple tool but could be more 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 covers all parameters (100%). Description adds value by giving token examples, explaining sell_ratio interpretation, and specifying CEX data source. Provides context beyond schema for the output metric.

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

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

Clearly states it gets real-time whale distribution data, defines the key metric (sell_ratio), and provides interpretation. Distinguishes from sibling tools by naming alternatives.

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 states when to use this tool (aggregate buy/sell pressure on CEX) and directs to siblings for individual trades (tokenintel_whale_trades) and on-chain whales (tokenintel_dex_whales).

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