omni-service-node

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

While annotations declare readOnlyHint/idempotentHint, the description adds crucial behavioral context: the $0.005 USDC cost per call and the specific return structure (risk_tier, applicable_articles, etc.) which compensates for the missing output schema. Could additionally note caching behavior 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?

Excellent structure with zero waste: single-sentence purpose statement, bulleted usage conditions, explicit return value listing, concrete example, and cost disclosure. Information is front-loaded and every sentence serves a distinct function.

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?

Comprehensive for a compliance tool: covers legal framework (EU AI Act 2024/1689), return fields, cost, and usage scenarios. Minor gap: does not explicitly note that all 3 parameters are optional (0 required), though the example demonstrates practical usage patterns.

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 detailed descriptions for each parameter. The description adds value through a concrete example call showing realistic parameter values ('Acme Corp', 'Facial Recognition Attendance System'), helping the agent understand expected input granularity beyond the schema's type 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 opens with a specific verb ('Classify') and clear resource scope ('AI system under EU AI Act 2024/1689'), explicitly distinguishing it from sibling tools like get_ai_news or get_ai_patents which handle information retrieval rather than legal compliance classification.

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 explicit 'Use this tool when:' guidance with four distinct scenarios (legal permission assessment, regulatory obligations, prohibited practices identification, and CISA alerts), offering clear boundaries for when to invoke this versus other research or intelligence 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?

While annotations declare readOnly/idempotent status, the description adds critical cost disclosure ($0.005 USDC), ranking methodology (relevance and virality scores), and detailed return structure (sentiment_summary, breaking_alerts). Does not mention rate limits or caching 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?

Well-structured with clear sections (action, usage conditions, returns, examples, cost). Each sentence earns its place. Minor verbosity in the 'Use this tool when' bullets could be condensed, but overall efficient for the information density provided.

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?

Excellent coverage given no output schema exists. Documents return fields (title, source, score, url, published_at, trending_keywords), data provenance (specific subreddits), and cost model. For a 3-parameter read-only tool, this provides complete operational 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 coverage is 100% with detailed descriptions, but the description adds valuable usage examples showing parameter combinations (e.g., 1-4 hours for breaking news, 24 for daily digest). These examples provide semantic context for parameter interplay that schema alone doesn't convey.

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 specific action ('Fetch real-time news and intelligence') and precise sources (HackerNews, specific subreddits, NewsAPI). It clearly distinguishes from academic siblings like get_arxiv_research by emphasizing 'real-time' and 'virality' versus research papers.

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?

Contains explicit 'Use this tool when:' section with four distinct scenarios covering research agents, content agents, and market monitoring. Provides clear temporal guidance ('breaking news' vs 'weekly trend analysis') through parameter examples.

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?

While annotations declare readOnly/idempotent hints, the description adds critical behavioral context missing from structured data: the $5 USDC cost per call and the complete return value structure (since no output schema exists). It documents specific return fields like 'competitive_threat_score' and 'similar_patents' that agents need to know about.

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?

Efficiently structured with front-loaded purpose statement, followed by value proposition, bulleted usage scenarios, return value documentation, example, and cost. Every sentence earns its place; no redundancy with schema or annotations. Appropriate length for the complexity (paid API with rich return data).

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?

Comprehensive for a tool without output schema: documents all return fields, discloses pricing, specifies data source (USPTO), and provides usage scenarios. Minor gap: could mention data freshness/lag time for patent filings, but adequately complete given the parameter richness and annotations provided.

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 description coverage, the baseline is 3, but the description elevates this by providing a concrete usage example (getAiPatents({ query: '...', companies: 'google,microsoft' })) that demonstrates parameter interaction and syntax (comma-separated values without spaces), adding practical semantic value beyond the schema 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 opens with a specific verb ('Search') and resource ('USPTO patent database'), clearly defining scope as AI-related filings. It distinguishes from siblings like get_ai_news or get_competitor_intel by specifying patent-specific data points (titles, abstracts, classification codes) and the USPTO source.

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 an explicit 'Use this tool when:' section with four distinct scenarios (research intelligence, investor assessment, R&D tracking, legal freedom-to-operate), clearly differentiating it from check_ai_compliance or general news tools. Each scenario maps to a specific agent type and use case.

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?

Annotations cover readOnly/destructive/idempotent hints, but description adds critical cost disclosure ('$0.005 USDC per call') not found in structured metadata. Also documents return schema fields (sector_rank, vs_btc_performance, narrative_tags) and provides realistic output example. Lacks rate limiting or caching details.

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 visual hierarchy: action statement, usage bullets, return fields, example, and cost. Front-loaded with the core purpose. Minor verbosity in the example section, but every sentence serves a distinct purpose (scoping, usage, returns, pricing).

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 lacking a formal output schema, the description comprehensively documents all return fields (10 distinct metrics per token) and provides a concrete usage example showing expected data format. Combined with annotations and single well-documented parameter, the description provides complete context for invocation.

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

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

Schema has 100% description coverage for the 'limit' parameter including usage guidance ('Use 10 for top-tier only...'). Description includes the parameter in the usage example but does not add semantic meaning beyond what the schema already provides, which is appropriate given the comprehensive schema coverage.

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

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

Description opens with specific verb 'Fetch' and precise resource 'performance data for AI/ML sector crypto tokens'. Explicitly lists covered tokens (NEAR, FET, AGIX, RNDR, WLD, TAO) and distinguishes from sibling tools like get_bittensor (single token) or get_crypto_derivatives (general crypto) by focusing on the AI sector narrative.

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 explicit 'Use this tool when:' section with four distinct scenarios covering investment, benchmarking, research thesis building, and relative performance analysis. Implicitly excludes non-AI crypto analysis by specifying 'AI token narrative' and 'AI crypto sector' throughout.

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?

Annotations already declare readOnlyHint=true and idempotentHint=true. Description adds critical cost disclosure ('$0.005 USDC per call') and enumerates return fields (ticker, analyst_firm, implied_upside_pct, etc.) compensating for missing output schema. Does not contradict annotations.

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

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

Efficiently structured with clear sections: purpose, usage triggers, return schema, examples, and cost. Every sentence provides unique value; no repetition of schema or annotation content. Front-loaded with specific action verb and resource identification.

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?

Comprehensive despite no output schema: lists all return fields explicitly, provides two usage examples covering both parameter combinations, includes pricing, and defines behavioral scope. Adequate for a 2-parameter read-only financial data tool with 100% schema coverage.

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

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

Schema coverage is 100% with detailed descriptions for both 'days' (including range 1-90 and usage guidance) and 'symbol' (empty for market-wide). Description adds concrete examples showing getAnalystRatings({ symbol: 'NVDA', days: 7 }) vs ({ days: 3 }), clarifying the optional filtering semantics visually.

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?

Opens with specific verb 'Fetch' + precise resource 'Wall Street analyst upgrades and downgrades' plus data attributes (firm name, rating change, price target). Clearly distinguishes from siblings like get_earnings or get_insider_trades by focusing specifically on analyst rating actions.

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 'Use this tool when:' section enumerates four distinct scenarios (trading agent seeking upgrades, research tracking sentiment, contrarian signal detection, consensus valuation). Examples demonstrate both filtered (symbol) and unfiltered (market-wide) usage patterns.

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?

Annotations declare readOnly/idempotent safety profile; description adds critical cost disclosure ('$0.005 USDC per call'), return value structure (breakthrough_score, trending_topics), and scope limitations (specific arXiv categories covered). Does not mention rate limits or authentication requirements, but provides substantial behavioral context beyond annotations.

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

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

Excellent structure with clear visual hierarchy: capability summary → usage triggers → return values → concrete examples → cost. No filler text; every sentence provides actionable information. Front-loaded with primary function, well-scoped for the complexity (4 parameters, rich domain).

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?

Compensates effectively for missing output schema by documenting return structure (papers metadata, breakthrough_score, top_authors). Covers cost, usage scenarios, parameter examples, and domain scope (cs categories). Complete enough for agent to invoke confidently without additional clarification.

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 establishing baseline of 3. Description adds two concrete examples showing parameter interaction patterns (query+days for topic search, category+days+limit for ranked results), which clarify how to combine filters effectively. Examples elevate this above baseline schema documentation.

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

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

Description opens with specific verb+resource ('Search ArXiv for the latest AI/ML academic papers') and enumerates unique capabilities (breakthrough detection, citation velocity). Clearly distinguishes from sibling news/patent tools like get_ai_news and get_ai_patents by specifying academic paper focus and cs.AI/cs.LG categories.

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 explicit 'Use this tool when:' section with four specific scenarios (literature review, breakthrough detection, researcher identification). Lacks explicit 'when not to use' or named sibling alternatives (e.g., contrasting with get_ai_news for news vs papers), but the contextual guidance is strong and actionable.

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?

Annotations cover safety profile (readOnly/idempotent), but description adds critical cost disclosure ('$5 USDC per call') not found in structured fields. It also compensates for missing output schema by detailing return fields (lead_score, ai_pivot_signal, etc.) and data sources. Could be 5 if it mentioned rate limits or caching 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?

Perfectly structured with zero waste: single-sentence purpose statement, bulleted usage conditions, structured return value list, concrete example, and cost warning. Every sentence earns its place and information is front-loaded with the core value proposition.

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 fully compensates by listing all return fields and providing a concrete output example ('Salesforce HOT (12 AI roles...)'). Cost transparency, multi-source data explanation (SEC/GitHub/jobs), and sibling differentiation make this complete for a complex intelligence-gathering 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 detailed parameter descriptions including examples ('salesforce', 'salesforce.com'). The description provides a usage example ('getB2bIntel({ companies: [...] })') but does not add semantic meaning beyond what the schema already documents. Baseline 3 appropriate when schema carries full load.

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?

Exceptionally specific: 'Generate Golden Lead packets for B2B sales agents' provides concrete verb + resource, while 'Cross-references SEC filings, GitHub activity, and job postings' defines scope. The HOT/WARM/COLD scoring and 'AI pivot signals' clearly differentiate this from sibling tools like get_company_profile (basic firmographics) or get_sec_filings (raw data only).

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 'Use this tool when:' section lists four specific scenarios (prioritizing outreach, detecting AI transitions, building prospect lists, going beyond firmographics). The contrast with 'basic firmographic data' implicitly guides users toward get_company_profile for simpler needs, providing clear selection criteria.

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?

Annotations cover safety profile (readOnly, idempotent, non-destructive). The description adds critical cost information ('$0.005 USDC per call') not in annotations, documents return field structure explicitly, and provides a concrete output example. Could improve by mentioning rate limits or caching 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?

Excellent structure: single-line purpose statement, bulleted usage scenarios, structured return value list, concrete example, and cost note. Every sentence earns its place with no redundancy. Information is front-loaded with the most critical context first.

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 1-parameter read-only tool, the description fully compensates for the missing output schema by explicitly listing all return fields (subnet_id, daily_emissions_tao, etc.) and providing a realistic output example. Combined with 100% schema coverage, no additional documentation is needed.

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 detailed parameter descriptions. The description adds value by including a practical usage example (getBittensor({ limit: 10 })) that demonstrates the expected calling convention and typical values, going beyond the schema's technical definition.

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 ('Get') and resource ('live Bittensor (TAO) network data'), followed by concrete data types (subnet activity, validator rewards, emissions). It clearly distinguishes from siblings like get_crypto_derivatives or get_defi_yields by specifying Bittensor/TAO subnet-specific metrics.

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

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

Provides explicit 'Use this tool when:' scenarios covering investment evaluation, research, staking rewards tracking, and mining decisions. However, it lacks explicit 'when not to use' guidance or named alternative tools (e.g., 'use get_crypto_derivatives for general price data').

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?

Annotations already declare readOnlyHint=true and idempotentHint=true. Description adds valuable behavioral context beyond annotations: discloses exact return fields (spot_price, 52w_high/low, supply_signal enums), data freshness implicitly via 24h/7d trends, and explicit cost ('$0.005 USDC per call'). Does not contradict annotations. Could improve by mentioning rate limits or caching 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?

Excellent structure with clear visual hierarchy: one-sentence purpose statement, bulleted usage conditions, structured return value documentation, concise example, and cost disclosure. Every sentence earns its place; no fluff or repetition of the tool name. Information is front-loaded with the most critical details first.

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 single-parameter read tool with no output schema, the description comprehensively compensates by enumerating all return fields (spot_price, supply_signal states, etc.), providing usage scenarios, and disclosing pricing. The combination of detailed schema (100% coverage) and rich description makes this complete despite missing formal output schema.

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

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

Schema description coverage is 100%, providing detailed documentation of the 'commodities' parameter including supported values and formats. Description provides a usage example (getCommodities({ commodities: 'gold,silver,oil' })) which reinforces the comma-separated format, but this is syntactic rather than semantic enrichment. Baseline 3 is appropriate given schema completeness.

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?

Opens with specific verb ('Get') and comprehensive resource scope ('spot prices, 24h/7d trend, and supply/demand signals for physical commodities'), immediately followed by concrete examples (gold, silver, crude oil, etc.). Clearly distinguishes from siblings like get_energy_prices or get_fx_rates by emphasizing physical commodity spot markets and supply/demand signals.

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 explicit 'Use this tool when:' section with four distinct scenarios covering macro analysis, portfolio inflation assessment, trading correlations, and supply/demand context. Names specific agent personas (portfolio agent, trading agent). Lacks explicit 'when not to use' guidance or named alternatives (e.g., when to prefer get_energy_prices over this for oil/natgas), preventing a perfect 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?

While annotations declare readOnly/idempotent status, the description adds critical behavioral context missing from structured fields: the $5 USDC cost per call (crucial for agent decision-making) and a detailed enumeration of return fields (compensating for the lack of output schema). It also provides an input/output example showing 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?

Excellent information density with clear visual hierarchy: single-sentence purpose statement, bulleted usage conditions, explicit 'Returns' list, concrete example, and cost warning. Every section earns its place without redundancy. Front-loaded with the core value proposition.

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 5+ data sources) and absence of output schema, the description compensates effectively by listing all 11 return fields explicitly. The cost disclosure and usage examples provide necessary operational context. Minor gap: no mention of error handling when data sources are unavailable.

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 description coverage for all 3 parameters, the schema carries the semantic burden. The description adds no explicit parameter guidance beyond the example usage, which warrants the baseline score of 3 for high-coverage schemas. The example does demonstrate practical usage of the 'github' and 'days' parameters.

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

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

The description explicitly states the tool 'Build[s] a full company intelligence dossier' and enumerates the specific data sources combined (SEC filings, GitHub velocity, hiring signals, patent activity, HackerNews sentiment). It clearly distinguishes itself from single-purpose siblings like get_sec_filings or get_github_velocity by positioning as a composite 'one-stop' briefing 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 an explicit 'Use this tool when:' section with four distinct scenarios (sales/BD outreach, investor due diligence, AI posture assessment, competitive research). This clearly defines the contextual boundaries and differentiates it from narrower intelligence tools in the sibling list.

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

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

Adds critical behavioral context beyond annotations: explicit cost disclosure ('$5 USDC per call'), detailed return structure (LEADER/CHALLENGER/FOLLOWER/NICHE classifications, threat levels), and concrete input/output example. Annotations cover safety profile (readOnly/idempotent), while description adds economic and functional behavior essential for agent decision-making.

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?

Excellent structure with clear information hierarchy: purpose → usage conditions → return values → example → cost. No wasted words; each sentence delivers specific actionable information. Front-loaded with core capability, followed by operational 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?

Compensates effectively for missing output schema by documenting all return fields (competitive_position, key_differentiators, threat_level, etc.) and providing a realistic example output. Complex intelligence-gathering tool is fully specified for agent use despite no formal output schema.

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

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

Schema has 100% coverage, but description adds semantic value through the concrete example showing realistic inputs ('anthropic' vs ['openai', 'google', 'mistral']) and expected output format ('Claude gaining enterprise share...'). This contextualizes the string parameters better than schema alone.

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?

Specific verb ('Build') + resource ('competitive intelligence dossier') + explicit scope (product launches, pricing, hiring, patents, funding). Clearly distinguishes from sibling tools like get_company_profile (static data) or get_funding_rounds (single data type) by emphasizing comparative analysis ('vs its competitors').

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 'Use this tool when:' section lists four distinct agent contexts (strategy, sales, early detection, investor). Each scenario clarifies specific value proposition (e.g., 'selling opportunity' for sales agents), providing clear selection criteria against alternatives like get_b2b_intel or get_company_profile.

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?

While annotations declare readOnly/idempotent hints, the description adds critical behavioral context missing from structured fields: the cost per call ('$0.005 USDC'), detailed return field documentation, and crucial interpretation semantics ('positive = longs paying shorts', 'BEARISH' signals). No contradictions with annotations exist.

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?

Excellent structure with clear sections: purpose definition, usage triggers, return specification, concrete example, and cost disclosure. Every sentence provides unique value; the example efficiently demonstrates both parameter usage and result interpretation 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 the absence of an output schema, the description compensates by listing all return fields and providing an interpreted example. However, it lacks explicit data type information or structural nesting details for the return object, which would be necessary for a perfect completeness score without an output schema.

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

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

Schema description coverage is 100%, establishing a baseline of 3. The description includes an example call demonstrating symbol usage, but does not add significant semantic meaning, validation rules, or format constraints beyond what the schema already provides for the 'symbol' and 'exchange' parameters.

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

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

The description opens with a specific verb ('Fetch') and clearly identifies the resource ('crypto futures and options market data'), listing specific data points (funding rates, open interest, liquidations, basis). It effectively distinguishes from siblings like get_onchain_data or get_defi_yields by focusing specifically on derivatives market mechanics.

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?

Contains an explicit 'Use this tool when:' section with four distinct scenarios covering sentiment analysis, squeeze detection, delta-neutral management, and exchange liquidity comparison. These guidelines explicitly map to the derivatives-specific functionality and prevent confusion with broader market data 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?

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds critical cost information ('$5 USDC per call') not found in structured data, and comprehensively documents the return structure (treasury_value_usd, top_token_holders_pct, per-proposal fields) compensating for the lack of output schema. Does not mention rate limits or caching behavior, preventing a 5.

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?

Excellent information density with clear visual hierarchy: one-sentence purpose summary, bulleted usage conditions, return value specification, concrete example, and cost notice. Every sentence delivers unique value; no tautology or repetition of the tool name. Front-loaded with the 'Fetch' action verb.

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 2-parameter tool with simple primitives (string, enum) but complex return data, the description is comprehensive. It compensates for the missing output schema by exhaustively listing return fields. Combined with annotations covering safety hints and the explicit cost disclosure, the agent has sufficient information to invoke and interpret results 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?

Input schema has 100% description coverage (both status and protocol parameters fully documented with enum explanations and supported values list). The description adds an executable example (getDaoGovernance({ protocol: 'uniswap', status: 'active' })) that demonstrates parameter interaction and expected input format, providing syntactic context beyond the schema 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?

Opens with specific verb 'Fetch' and detailed resource scope (DAO governance activity, proposals, treasury, sentiment). The enumerated list of return fields (protocol, proposal_id, votes_for, etc.) precisely defines what data the tool retrieves, clearly distinguishing it from sibling tools like get_defi_yields or get_onchain_data which lack governance-specific proposal tracking.

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?

Contains explicit 'Use this tool when:' section with four distinct, concrete scenarios (DeFi agent tracking parameter changes, token holder voting, protocol health assessment, decentralization evaluation). These guidelines clearly differentiate when to select this tool versus alternatives like get_token_unlocks or get_whale_tracker.

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?

Annotations confirm read-only/idempotent nature, freeing description to add critical cost disclosure ('$0.005 USDC per call') and detailed return structure (protocol, asset, risk_rating fields). Includes concrete example showing input/output format. Does not mention pagination or rate limits, preventing a 5.

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 sections: capability statement, usage triggers, return spec, example, and pricing. Information-dense without redundancy. Minor deduction for slight length, though all sentences serve distinct purposes (cost, returns, usage contexts).

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

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

No output schema exists, but description comprehensively compensates by enumerating all return fields (protocol, asset, chain, apy, tvl_usd, etc.) and providing a realistic example output. Given the complexity (100+ protocols, risk ratings, audit status), coverage 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 has 100% coverage with complete descriptions for 'chain' and 'minApy'. Description adds value through concrete example invocation (getDefiYields({ chain: "ethereum", minApy: 8 })), illustrating parameter interaction and syntax beyond raw schema 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?

Opens with specific verb 'Find' and resource 'DeFi opportunities' across explicitly named protocols (Aave, Compound, etc.). Clearly distinguishes from siblings like get_crypto_derivatives or get_stablecoins by focusing specifically on yield/APY aggregation.

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?

Contains explicit 'Use this tool when:' section with four distinct scenarios covering capital allocation, cross-chain comparison, portfolio rebalancing, and risk-adjusted yield seeking. Provides clear contextual triggers for agent selection.

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?

Annotations declare readOnlyHint=true and idempotentHint=true. Description adds critical cost information ('$0.005 USDC per call') not present in annotations, and documents the complete return value structure (ticker, EPS_surprise_pct, signal, guidance, etc.) to compensate for missing output schema. Does not mention rate limits or caching policies, preventing a 5.

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?

Highly structured with clear information hierarchy: one-line summary → bullet-pointed usage scenarios → return field enumeration → examples → cost. Every sentence earns its place; no repetition of schema or annotation data. Front-loaded with the most critical information (what the tool fetches).

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 having no output schema, the description comprehensively documents all return fields (ticker, company_name, EPS_estimate, EPS_actual, signal, guidance, etc.). Covers geographic scope (US public companies), temporal scope (upcoming and recent), cost structure, and usage contexts. Sufficient for an agent to understand full tool capabilities and outputs.

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

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

Input schema has 100% description coverage (days and symbols fully documented). Description adds value through two concrete examples showing function invocation patterns (getEarnings({ days: 7, symbols: 'NVDA,MSFT,AAPL' })) which illustrate typical parameter values and comma-separated ticker formatting beyond the schema's technical 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?

Description opens with specific verb ('Fetch') and resource ('earnings reports for US public companies'), followed by exact data points provided (EPS estimates vs actuals, revenue beats/misses, guidance changes, BEAT/MISS/IN-LINE signal). This clearly distinguishes from siblings like get_economic_calendar (macro events) or get_company_profile (static metadata).

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 'Use this tool when:' section lists four specific agent scenarios (trading agent seeking reporting dates, identifying earnings surprises for price gaps, portfolio risk reduction, analyst building earnings calendar). Each scenario provides clear contextual triggers for selection 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?

Annotations declare readOnly/idempotent/destructive status, so description appropriately focuses on adding cost disclosure ('$0.005 USDC per call'), return value schema (magnitude, depth_km, tsunami_warning), and external dependency (USGS). No contradictions with annotations.

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

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

Excellent information architecture: single-sentence purpose statement, bulleted usage contexts, structured return value list, concise example, and cost footnote. No wasted words; every sentence serves distinct selection or invocation guidance.

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 exists, description comprehensively documents return fields (magnitude, coordinates, tsunami_warning, etc.), includes realistic example, notes economic impact estimates, and specifies USGS data provenance. Fully compensates for missing structured output metadata.

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

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

Input schema has 100% description coverage with detailed ranges and usage guidance for 'days' and 'minMagnitude'. Description includes a syntax example but does not add substantial semantic meaning beyond the comprehensive schema documentation, warranting the baseline score for high-coverage schemas.

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 opens with specific verb 'Fetch' + exact resource 'significant recent earthquakes from USGS' + detailed data points (magnitude, epicentre, tsunami status). Clearly distinguishes from sibling get_geopolitical_crisis by specifying USGS seismic data source and physical event parameters.

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 'Use this tool when:' section lists four distinct agent personas/contexts (risk monitoring, insurance, tsunami assessment, geopolitical correlation). Lacks explicit 'when not to use' or named alternatives, but the positive guidance is highly specific and actionable.

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?

Annotations already establish read-only, idempotent, non-destructive safety profile. Description adds critical cost information ('$0.005 USDC per call'), detailed return value specification (8 fields including market_impact_assets), and a concrete invocation example. Adds substantial operational context beyond annotations without contradicting them.

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?

Excellent structure with clear visual hierarchy: single-sentence purpose definition, bulleted usage conditions, structured return value list, inline example, and cost footer. Every sentence delivers distinct value (purpose, usage, returns, example, pricing) with zero 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?

Despite absence of output schema, description comprehensively documents return structure (8 fields including conditional 'actual (if released)'), provides realistic example with syntax, and includes cost transparency. For a 2-parameter read-only tool, this is fully complete.

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

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

Input schema has 100% description coverage with detailed guidance on parameter semantics (e.g., days range 1-30, country code format). Description provides a usage example but does not add semantic meaning beyond what the schema already documents. Baseline 3 appropriate for high schema coverage.

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

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

Description opens with specific verb 'Fetch' and resource 'high-impact economic events calendar', immediately listing concrete examples (CPI, NFP, FOMC, GDP, PMI) that clearly distinguish it from siblings like get_earnings or get_commodities. The scope (consensus forecasts vs prior values, market impact ratings) further differentiates it from get_macro_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?

Contains explicit 'Use this tool when:' section with four distinct scenarios (trading position avoidance, macro scheduling, forecast comparison, market impact assessment). These guidelines clearly delineate appropriate use cases and implicitly contrast with alternatives like get_earnings (company-specific) or get_macro_data (historical rather than calendar).

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?

Adds substantial value beyond annotations: discloses pricing cost ($0.005 USDC/call), documents return structure (8 fields per commodity including supply/demand signals), and provides realistic input/output example. Does not mention rate limits or caching behavior, preventing a 5.

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 visual hierarchy: one-line summary, bullet-pointed usage contexts, returns documentation, code example, and cost. Every sentence serves agent decision-making; no filler despite detailed content.

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

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

Excellent coverage for a single-parameter tool with no output schema. Description fully compensates by detailing all return fields (name, price, unit, currency, multi-timeframe changes, signals, drivers) and operational constraints (cost), 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?

Schema has 100% description coverage (baseline 3). Description adds value via the code example showing comma-separated syntax and casing ('wti,brent,natgas'), reinforcing the expected parameter format beyond the schema's text 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?

Opens with specific verb ('Get') + resource ('global energy commodity prices') + exhaustive scope list (WTI, Brent, Henry Hub, LNG, coal, electricity). Clearly distinguishes from sibling 'get_commodities' by focusing exclusively on energy markets.

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 explicit 'Use this tool when:' section with four detailed scenarios (macro inflation modeling, trading/FX assessment, geopolitical spread analysis, transition risk). Lacks explicit 'when-not' or named alternative tools (e.g., does not direct users to 'get_commodities' for agricultural products), preventing 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?

Annotations declare readOnly/idempotent/safety profile, while description adds critical cost disclosure ('$0.005 USDC per call'), return value structure (VIX sub-fields, fear_greed_label enums), and contrarian signal logic. Does not mention rate limits or caching, but cost transparency is valuable 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?

Well-structured with clear sections: purpose → usage guidelines → returns → example → cost. Information-dense with minimal waste. Slightly verbose in usage section (4 bullets) but each serves distinct use case (trading vs risk vs contrarian). Front-loaded core purpose earns high marks.

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 lacking output schema, description comprehensively details return values including field types (0-100 range, enum labels), historical context interpretation, and signal meaning. Cost disclosure and example invocation complete the picture for a single-parameter 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 has 100% description coverage for the 'format' parameter. Description includes a usage example ('getFearIndex({ format: "summary" })') which reinforces semantics, but with full schema coverage, no additional compensation is required. Baseline 3 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 opens with specific verb ('Get') and precise resources ('VIX', 'CNN Fear & Greed composite index'), immediately distinguishing this from sibling tools like get_market_sentiment or get_trading_signal. The contrarian interpretation angle (extreme fear = buy) further clarifies its unique value proposition.

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?

Contains explicit 'Use this tool when:' section with four distinct scenarios covering trading agents, risk management, and contrarian opportunity detection. This provides clear positive guidance for selection without ambiguity.

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

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

Annotations establish read-only/idempotent safety profile. Description adds crucial behavioral context not in annotations: cost model ($5 USDC per call), return value structure (per-deal fields listed), and special handling (AI deals highlighted with tech stack). No contradictions with annotations.

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

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

Well-structured with clear progression: function → usage scenarios → return values → example → cost. Every section earns its place; the example query effectively illustrates intended use. Slightly dense but appropriately comprehensive for a commercial data tool.

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

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

No output schema exists, but description compensates by enumerating return fields (company, sector, stage, amount_usd, etc.) and noting AI-specific enhancements. Cost disclosure and 3-parameter scope are fully addressed. Adequate for tool complexity.

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

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

Schema coverage is 100% with excellent parameter descriptions (e.g., 'Use 7 for breaking rounds, 30 for monthly'). Description provides a usage example showing realistic parameter combinations, but baseline remains 3 as schema carries the full semantic burden.

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?

Opens with specific verb 'Fetch' and clearly defines the resource (VC and PE funding rounds) and specific data points returned (deal amount, lead investors, valuation, etc.). Effectively distinguishes from siblings like get_ai_news or get_company_profile by focusing specifically on funding rounds and investment 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?

Provides explicit 'Use this tool when:' section with four detailed agent scenarios (sales targeting, capital flow research, competitive monitoring, VC activity tracking). Clear contextual guidance for selection, though lacks explicit 'when not to use' or named alternative tools.

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

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

Annotations cover safety profile (readOnly, idempotent, non-destructive). Description adds critical behavioral details: cost per call ('$0.005 USDC'), return value schema (7 specific fields per pair), and live data nature. Does not mention rate limits or caching behavior, preventing a 5.

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?

Perfectly structured with front-loaded purpose statement, bulleted usage contexts, return schema specification, concrete example, and cost note. Every sentence delivers distinct 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?

No output schema exists, so description compensates by detailing all return fields (pair, rate, bid, ask, spread_pips, changes, trend). Also covers cost and usage contexts. Given the single-parameter input, this provides complete operational 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 coverage is 100%, establishing baseline 3. Description includes an example invocation showing format, but does not add semantic meaning beyond the schema's already-comprehensive description of the pairs parameter.

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

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

Opens with specific verb ('Get') + resource ('live foreign exchange rates') + clear scope ('major pairs, minor pairs, the Dollar Index (DXY), and crypto/USD crosses'). Effectively distinguishes from siblings like get_commodities or get_crypto_derivatives by specifying FX-specific coverage.

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

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

Provides explicit 'Use this tool when:' section with four distinct, concrete scenarios (trading execution, macro USD assessment, cross-currency exposure calculation, hedging). Lacks explicit 'when-not' exclusions or named alternative tools, which prevents a perfect 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?

Annotations declare the operation as read-only, idempotent, and non-destructive. The description adds critical behavioral context not present in annotations: explicit cost disclosure ('$25 USDC per call'), data source provenance (GDELT, OFAC, HackerNews), and detailed return structure (since no output schema exists). Minor gap: no mention of rate limits or caching 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?

Excellent structure with clear visual hierarchy: single-sentence purpose statement, bulleted usage guidelines, compact return value specification, example, and cost line. Every sentence earns its place; no filler text. Information is front-loaded with the most critical context (what it does) before descending into usage scenarios and technical details.

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

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

Given the absence of an output schema and the tool's complexity (multiple data sources, quantitative outputs), the description comprehensively documents return values: crisis_score range (0-100), escalation_risk enums (LOW/MEDIUM/HIGH/CRITICAL), specific market impact metrics (oil_pct, gold_pct, etc.), and auxiliary fields (OFAC_alerts, recommended_hedges). The example further clarifies expected output format.

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 description coverage, the baseline is appropriately 3. The description includes a helpful usage example (getGeopoliticalCrisis({ regions: 'middle-east' })) that demonstrates parameter syntax, but does not add semantic meaning to the parameters beyond what the schema already provides (e.g., does not explain the trade-offs of includeMarketImpact beyond the schema's 'recommended' note).

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, actionable definition: 'Real-time geopolitical crisis monitoring using GDELT event database, OFAC alerts, and social signal analysis.' It clearly identifies the resource (geopolitical crisis data) and distinguishes itself from siblings like get_macro_data or get_commodities by emphasizing multi-source intelligence (GDELT, OFAC, Reddit) and specific outputs (crisis scores, escalation risk).

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?

Includes an explicit 'Use this tool when:' section with four specific scenarios (macro tail risk assessment, trading impact on oil/gold, early warning systems, portfolio stress-testing). This provides clear differentiation from alternatives like get_market_sentiment or get_economic_calendar by specifying agent roles and use cases where geopolitical-specific data is required.

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 annotations covering read-only/idempotent safety, the description adds valuable operational context: the cost model ('$0.005 USDC per call'), the return structure ('Returns per repo: name, owner...breakthrough_signal'), and special behavioral traits ('AI/ML repositories and agentic frameworks are highlighted'). It does not contradict the annotations (readOnlyHint=true aligns with 'Fetch'). A 5 would require additional details like rate limits or cache 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 expertly front-loaded with the core function in the first sentence, followed by logically sequenced sections: usage conditions, return value specification, concrete examples, and cost information. Every sentence serves a distinct purpose with zero redundancy. The structure scales appropriately to the tool's complexity (3 parameters, rich return data, monetary cost) without bloat.

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 lacking a formal output schema, the description comprehensively documents return fields including the special 'breakthrough_signal' field. Combined with 100% input schema coverage, clear usage contexts, explicit cost disclosure, and behavioral hints, the description provides everything an agent needs to invoke the tool effectively and interpret results. No gaps remain given the tool's moderate 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 input schema has 100% description coverage, establishing a baseline of 3. The description adds invocation examples (e.g., 'getGithubTrending({ topic: "mcp", period: "weekly" })') that illustrate parameter combinations and default usage patterns, but does not significantly augment the semantic meaning beyond what the comprehensive schema descriptions already provide for topic, period, and language parameters.

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

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

The description opens with a specific verb-resource pair ('Fetch trending GitHub repositories') and immediately clarifies the scope ('by stars today/this week/this month') and filtering capabilities ('Filter by programming language and topic'). The mention of 'stars' effectively distinguishes it from sibling tool get_github_velocity, while 'AI/ML repositories and agentic frameworks are highlighted' adds domain-specific context that differentiates it from general GitHub search 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 'Use this tool when:' section provides four explicit positive use cases covering research discovery, trend detection, domain scouting, and developer recommendations. However, it lacks explicit negative guidance or named alternatives (e.g., it doesn't mention when to prefer get_github_velocity for commit activity instead of star-based trending), preventing a perfect score despite the strong contextual guidance provided.

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

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

Annotations cover safety profile (readOnly/idempotent), so description appropriately focuses on cost transparency ('$5 USDC per call') and return value structure. Deduct one point only because it omits rate limits or caching behavior, but cost disclosure is exceptionally valuable for agent decision-making.

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?

Perfectly structured with clear visual hierarchy: purpose → usage conditions → return values → example → cost. Every sentence serves distinct function; no redundancy with schema or annotations. Front-loaded with most critical 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?

Compensates exceptionally for missing output schema by exhaustively listing all return fields with types/scales (ai_pivot_score 0-100), providing concrete input/output example, and noting cost. Sufficient for agent to understand full contract without external documentation.

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

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

Input schema has 100% description coverage with detailed examples and usage guidance ('Use 7 for recent sprint, 30 for monthly'). Description provides helpful usage example but does not add semantic meaning beyond what schema already provides, warranting baseline score per rubric for high-coverage schemas.

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?

Excellent specificity with concrete verb ('Analyse'), target resource ('company's GitHub organisation'), and distinct scope ('AI pivot signals' including repos, tags, stars, commits). Clearly distinct from sibling get_github_trending via its AI-focused organizational analysis angle.

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 'Use this tool when:' section enumerates four distinct scenarios (verification, sales timing, research assessment, investor due diligence) that precisely delineate when to select this over alternatives like get_company_profile or check_ai_compliance.

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?

Annotations declare readOnlyHint/idempotentHint, but description adds critical behavioral context: cost disclosure ('$5 USDC per call'), detailed return value structure ('Returns per fund: fund_name, AUM...'), and concrete input/output example. Does not mention rate limits or error states, preventing a 5.

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?

Excellent structure: single-sentence purpose, bullet-list usage guidelines, return value specification, example, and cost. Every element earns its place; cost disclosure is critical for agent decision-making, example clarifies expected invocation pattern.

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

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

No output schema exists, but description fully compensates by listing all return fields (fund_name, AUM, top_10_holdings, etc.) and providing an example output string. Given 3 optional parameters and complex financial domain, the description provides sufficient context for correct invocation.

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

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

Schema coverage is 100% with detailed descriptions for all 3 parameters (fund, sector, quarter). Description provides a usage example showing parameter values, but does not add semantic meaning beyond what schema already documents. Baseline 3 appropriate given high schema coverage.

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

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

Description opens with specific verb 'Fetch' + resource '13F filings from the SEC' and enumerates exact data points (top holdings, new positions, sector rotation). Clearly distinguishes from sibling tools like get_sec_filings (general) and get_insider_trades (individual vs institutional) by specifying 'hedge fund' and 'major funds like Bridgewater'.

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 'Use this tool when:' section with four specific scenarios (smart money positioning, sector rotation detection, market thesis building, conviction signal identification). Provides clear contextual boundaries that differentiate it from general market data 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?

Annotations cover read-only/idempotent safety hints. Description adds critical behavioral context missing from annotations: cost ('$0.005 USDC per call'), return field structure, and signal calculation logic (bullish/bearish based on direction/size).

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 sections: purpose, usage conditions, return values, examples, and cost. Information-dense without redundancy. Front-loaded with core function in first sentence.

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

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

No output schema exists, but description compensates effectively by listing all return fields (insider_name, signal, cumulative_30d_net_buying, etc.) and providing concrete input/output examples. Cost disclosure completes the decision-making context for agents.

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 detailed descriptions for both 'days' (including range 1-180 and usage patterns) and 'symbol' (empty for market-wide). Description provides usage examples showing parameters in action, meeting baseline for high-coverage schemas.

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 opens with specific verb 'Fetch' plus exact resource 'SEC Form 4 filings' and scope 'US public companies', immediately distinguishing it from sibling get_sec_filings (general filings) and other financial data tools.

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

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

Provides explicit 'Use this tool when:' section with four concrete scenarios (trading agents following smart money, detecting unusual selling, research conviction signals, cross-referencing). Clear context but lacks explicit 'when not to use' or named alternative tools.

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

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

Annotations declare readOnlyHint=true and destructiveHint=false; description adds critical behavioral context not in structured fields: per-call cost ($0.005 USDC), exact return field specifications (company_name, ticker, status, etc.), and status enum values (UPCOMING/PRICED/WITHDRAWN). No contradictions with annotations.

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

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

Excellent structure with clear logical flow: purpose → usage scenarios → return specification → concrete example → cost disclosure. Every section earns its place; the return field list is essential given no output schema exists, and the cost transparency is operationally critical. No redundant or filler 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?

Despite no output schema, the description comprehensively documents all return fields and their semantics. For a single-parameter tool with complete schema coverage, the description successfully compensates for missing structured output documentation and includes operational details (cost) necessary for agent decision-making.

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 the 'days' parameter fully documented including range (1-90) and usage guidance. Description provides a concrete usage example (getIpoCalendar({ days: 14 })), but does not add semantic meaning beyond what the schema already specifies, warranting the baseline score for high-coverage schemas.

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?

Opens with specific verb 'Fetch' and clearly defines the resource (upcoming/recently priced IPOs) and scope (deal size, pricing range, market cap, sector, underwriter). Distinctly differentiates from siblings like get_earnings, get_sec_filings, or get_company_profile by focusing specifically on new listing pipeline 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?

Provides explicit 'Use this tool when:' section with four specific scenarios covering trading, research, sector analysis, and risk appetite assessment. Lacks explicit 'when not to use' guidance or named alternative tools, but the contextual signals provide clear selection criteria.

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?

Annotations declare readOnlyHint/idempotentHint, but description adds critical behavioral context not present in structured fields: explicit data sources (Greenhouse/Lever/etc.), cost disclosure ('$5 USDC per call'), and detailed return value structure (company_name, open_ai_roles_count, etc.) compensating for missing output schema. No contradictions with annotations.

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

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

Well-structured with clear information hierarchy: purpose → usage contexts → return values → example → cost. While lengthy, every sentence serves a distinct purpose (business context for 'why', return spec for 'what to expect', cost for operational constraints). No redundant or filler content despite the length required to compensate for missing output schema.

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?

Exceptionally complete given constraints. Despite no output schema, description comprehensively documents return fields (company_name, open_ai_roles_count, seniority_mix, etc.), provides concrete input/output example, discloses financial cost, and specifies exact data sources. Combined with 100% schema coverage and clear annotations, the agent has all necessary information to invoke and interpret results.

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

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

Schema description coverage is 100%, establishing baseline 3. Description includes a helpful code example showing parameter usage (getJobPivots({ roles: [...] })), but does not add substantial semantic meaning beyond the schema's detailed descriptions for 'roles' and 'companies' parameters. Example illustrates syntax but schema already explains the concepts thoroughly.

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 opens with specific verb 'Identify' + resource 'companies actively hiring for agentic AI roles' + explicit data sources 'Greenhouse, Lever, HackerNews Who's Hiring, and Remotive'. Clearly distinguishes from sibling tools like get_company_profile (general company data) and get_b2b_intel (general B2B intelligence) by focusing specifically on hiring signals as buyer intent indicators.

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 explicit 'Use this tool when:' section with four specific agent scenarios (sales, market research, VC/investor) that clearly establish appropriate contexts. However, lacks explicit 'when-not' guidance or named alternative tools from the sibling list (e.g., doesn't direct users to get_company_profile for general firmographic data), preventing a perfect score per rubric standards.

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?

Annotations cover safety profile (readOnly/idempotent/non-destructive). Description adds critical behavioral context: output structure (detailed per-country return fields), cost disclosure ($0.005 USDC per call), and example invocation. Does not cover error handling or caching, but adds significant value beyond annotations.

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

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

Well-structured with front-loaded purpose, followed by usage conditions, return value specification, example, and cost. Every sentence provides distinct value (purpose, triggers, outputs, syntax, pricing) 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?

No output schema exists, but description fully compensates by listing all return fields (policy_rate, CPI_yoy, M2_growth, etc.). Single parameter with complete schema coverage and clear annotations make this fully specified for agent 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 has 100% coverage for the single 'countries' parameter. Description adds an explicit code example (getMacroData({ countries: 'US,EU,JP' })) that clarifies invocation syntax and comma-separated formatting, enhancing the schema definition.

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?

Specific verb 'Fetch' + comprehensive resource list (macroeconomic fundamentals including rates, CPI, M2, etc.). Distinguishes from siblings like get_fx_rates or get_commodities by emphasizing the unique rate_environment signal (HAWKISH/DOVISH/NEUTRAL) and broad fundamental coverage.

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

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

Explicit 'Use this tool when:' section with four specific scenarios covering investment decisions, macro trading alignment, inflation assessment, and economic expansion analysis. Provides clear contextual triggers for agent selection.

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?

Annotations already declare readOnly/idempotent/destructive hints, so the description adds crucial behavioral context: specific cost disclosure ('$0.005 USDC per call'), detailed return value schema (ticker, volume_surge_ratio, catalyst detection), and calculation methodology (volume vs 30-day average). Deducted one point for lacking rate limits or error condition documentation.

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?

Perfectly structured with clear information hierarchy: one-line summary → usage scenarios → return value documentation → concrete examples → cost. No filler text; every sentence provides actionable information for agent decision-making.

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?

Excellent compensation for missing output schema by explicitly documenting all return fields (ticker, company_name, volume_surge_ratio, catalyst, etc.). Includes cost information critical for API tools. Would benefit from rate limit or caching notes, but adequately complete for a market 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% with excellent descriptions for 'type' (including enum semantics) and 'limit'. The description adds value through concrete JSON examples showing valid parameter combinations (e.g., { type: 'gainers', limit: 5 }), which clarifies usage patterns beyond the schema 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 opening sentence provides a specific verb ('Get') and resource ('top gaining, top losing, and most actively traded stocks'), along with specific data points returned (volume surge signals, percentage moves). It clearly distinguishes from siblings by specifying 'stocks' (excluding crypto/commodities) and focusing on intraday momentum/volume rather than sentiment or fundamentals.

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?

Contains an explicit 'Use this tool when:' section with four specific scenarios (trading agents seeking momentum, identifying volume catalysts, morning brief generation, sector leadership analysis). Lacks explicit 'when not to use' guidance or named sibling alternatives, though the stock-specific scope implicitly differentiates it from crypto/commodity 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?

Annotations declare readOnly/idempotent/safe, but description adds critical cost information ('$0.005 USDC per call') and detailed return structure (fear_greed_index 0-100 scale, specific fields). Includes behavioral example showing RISK_OFF during high VIX. Minor gap: no rate limits or latency mentioned.

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?

Excellent structure with clear section headers (Use this tool when, Returns, Example, Cost). Front-loaded purpose statement. Every sentence delivers distinct value—no repetition of schema or annotation data. Appropriate length for complexity.

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

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

No output schema exists, but description compensates by exhaustively listing return fields with formats (fear_greed_index 0-100, overall_signal values). Cost disclosure included. Missing: pagination details if many assets requested, or error scenarios. Adequate for 1-parameter read-only 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 has 100% description coverage ('Comma-separated list of asset tickers...'), establishing baseline 3. Description includes usage example ('getMarketSentiment({ assets: "BTC,ETH,GOLD,SPY" })') reinforcing format, but does not add semantic depth (e.g., max tickers, validation rules) beyond what schema already 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?

Opens with specific verb 'Get' and resource 'market risk appetite', listing exact outputs (Fear & Greed index, RISK_ON/RISK_OFF signal). Clearly distinguishes from sibling tools like get_fear_index (narrower scope) by positioning as comprehensive market pulse.

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 'Use this tool when:' section with four specific scenarios (risk positioning, trading pulse, portfolio exposure, trending tokens). Provides clear decision criteria for when to select this over specialized siblings like get_trading_signal or get_market_movers.

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?

Annotations cover read-only/idempotent safety properties, but the description adds critical cost information ($0.005 USDC per call) not present in structured fields. It also discloses return field structure and data sources (options activity, news signals). Could mention caching behavior or rate limits for a 5.

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 information hierarchy: purpose → usage conditions → return schema → example → cost. No filler text; every sentence conveys distinct operational context (e.g., 'based on options activity' explains rumour methodology).

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 100% schema coverage and comprehensive annotations, the description compensates for missing output_schema by enumerating all return fields (acquirer, target, deal_value_usd, etc.) and providing a realistic example output. Cost disclosure completes the operational 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 coverage is 100% with excellent field descriptions, establishing baseline 3. The description adds value through the concrete invocation example showing camelCase function naming and realistic parameter values ('ai', 30), helping the agent map tool to execution syntax beyond the raw schema.

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

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

The description opens with a specific verb+resource ('Track merger and acquisition activity') and immediately details the scope (announced deals, rumoured targets, premiums, regulatory status). It clearly distinguishes from sibling tools like get_funding_rounds (VC/private equity) or get_company_profile (general corporate data) by focusing specifically on M&A event tracking.

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 'Use this tool when:' section lists four specific agent scenarios (event-driven trading, sector consolidation thesis, regulatory approval checks, target/acquirer assessment). This provides clear selection criteria versus alternatives like get_b2b_intel or get_competitor_intel.

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?

Annotations cover safety profile (readOnly, idempotent), so description adds complementary context: temporal volatility ('prices change frequently'), explicit return field enumeration, and crucial operational cost ('$0.005 USDC per call'). Does not contradict annotations. Could mention caching or rate limits for a 5.

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?

Excellent structure with front-loaded purpose statement followed by bulleted usage criteria, return value specification, concrete example, and cost disclosure. Every sentence provides distinct value; no redundancy with structured metadata.

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?

Absence of output schema is fully compensated by explicit enumeration of returned fields (provider, model_name, costs, etc.). Temporal context (frequent price changes) and economic context (per-call cost) make this complete for a data retrieval tool with simple inputs.

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 description coverage for the single 'providers' parameter, the schema already documents comma-separated format and supported values. The description provides a helpful usage example, but this reinforces rather than significantly extends the schema semantics, warranting the baseline score.

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?

Opens with specific verb 'Compare' + clear resource 'AI model inference pricing' + explicit scope 'across all major providers' and specific attributes (input/output cost, context window). Distinguishes from sibling tools like get_ai_news or get_ai_tokens by focusing specifically on pricing economics.

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?

Contains explicit 'Use this tool when:' section with four specific scenarios: cost-effective model selection, cost optimization, post-update price checks, and routing layer construction. Each bullet provides clear activation criteria distinguishing it from generic data retrieval 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?

Annotations declare readOnly/idempotent hints, so description appropriately focuses on adding cost disclosure ('$0.005 USDC per call') and return value structure (detailed list of returned fields). No contradictions with annotations. Adds valuable context about data freshness (24h/7d metrics) not covered in structured fields.

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 sections: purpose statement, usage scenarios, return documentation, example, and cost. Front-loaded with the core action. Length is appropriate given the lack of output schema—every sentence serves a distinct purpose (scoping, usage guidance, return documentation, pricing).

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?

Excellent compensation for missing output schema by documenting return fields (name, floor_price_eth/usd, wash_trade_pct, etc.) and providing concrete example output. Includes cost information critical for agent decision-making. For a single-parameter tool, provides comprehensive context despite no structured output definition.

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 collections parameter is well-documented in the schema itself (OpenSea slugs, comma-separated format). Description includes usage example showing the parameter format, but this is illustrative rather than adding semantic meaning beyond the schema definition. Baseline 3 appropriate given high schema coverage.

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

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

Opens with specific verb 'Monitor' + resource 'NFT market' and enumerates specific data points (floor prices, wash trade detection, market health signal). Distinguishes from siblings like get_crypto_derivatives or get_onchain_data via NFT-specific metrics (floor prices, collection sentiment) that are unique to this 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 explicit 'Use this tool when:' section with four detailed scenarios (risk assessment, purchase decisions, wash trading detection, DeFi lending risks). Clear contextual guidance for selection, though lacks explicit 'when not to use' or named alternative tools from the sibling list.

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

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

Annotations cover the safety profile (readOnly, idempotent), but the description adds crucial behavioral context: explicit cost disclosure ($0.005 USDC per call), detailed return value structure for each chain type compensating for the missing output schema, and 'live' data freshness indicators. Does not mention rate limits or caching behavior, preventing a 5.

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?

Perfectly structured with zero waste: single-sentence capability summary, bulleted usage conditions, explicit return field documentation, concrete examples, and cost disclosure. Despite the richness, it avoids verbosity; every section earns its place and supports agent decision-making.

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

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

Given the absence of an output schema, the description comprehensively documents return values for all three data categories (BTC, ETH, DeFi) including specific field names. It also includes critical operational context (cost per call) often omitted from tool descriptions. Complete for a multi-modal data fetching 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?

With 100% schema description coverage, the baseline is 3. The description adds value by providing concrete invocation examples (getOnchainData({ chain: 'eth' })) that demonstrate how parameter values map to specific behavioral outputs, clarifying the semantic difference between 'eth', 'btc', and 'defi' selections beyond the schema's enum 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 opens with a specific verb (Fetch) and comprehensively lists the exact resources covered (BTC mempool/fees, ETH gas oracle, DeFi TVL across 500+ protocols, yield opportunities). It clearly positions this as the broad on-chain metrics aggregator, distinguishing it from more specialized siblings like get_whale_tracker or get_token_unlocks through its explicit scope declaration.

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?

Excellent explicit guidance via 'Use this tool when:' followed by four distinct scenarios covering transaction preparation, DeFi yield hunting, network health assessment, and macro analysis. This provides clear selection criteria that help the agent choose this over alternatives like get_crypto_derivatives or get_defi_yields.

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?

Annotations declare readOnlyHint=true and destructiveHint=false. The description adds critical behavioral context not in annotations: explicit cost disclosure ('$0.005 USDC per call'), detailed return value structure ('Returns per flow: ticker, expiry...'), and classification logic (bullish/bearish sentiment, sweep vs. block trade types). No contradictions with annotations.

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

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

Excellent structure with purpose paragraph, bullet-pointed usage guidelines, return value specification, concrete examples, and cost disclosure. Every element earns its place; no redundant text. The examples efficiently demonstrate both input syntax and expected output interpretation.

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 exists, the description compensates fully by enumerating all returned fields (ticker, expiry, strike, type, premium_usd, etc.). It also discloses API costs and provides usage examples. Complete for a financial data tool with 2 parameters and complex return structure.

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 description coverage, the baseline is 3. The description adds value through concrete examples showing parameter interaction: 'getOptionsFlow({ symbol: "SPY", minPremium: 500000 })' demonstrates the minPremium threshold concept and symbol format, adding semantic meaning beyond the schema 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 explicitly states the tool detects 'unusual options activity — large block trades, sweeps, and dark pool prints' with specific verbs (Detect, Identifies, classifies). It clearly distinguishes from siblings like get_crypto_derivatives or get_trading_signal by focusing specifically on institutional options flow and smart money positioning.

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 explicit 'Use this tool when:' section with four specific scenarios including following institutional flow, detecting smart money direction, and scanning before earnings. While highly detailed on when-to-use, it lacks explicit when-not-to-use guidance or named alternatives (e.g., vs. get_trading_signal).

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?

Annotations confirm read-only, non-destructive, idempotent behavior. The description adds critical cost information ('$0.005 USDC per call') not present in annotations, and details return structure (per-deal fields and aggregate metrics) compensating for the missing output schema. No contradictions with annotations.

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

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

Excellent structure with clear sections: purpose statement, usage contexts, return value specification, example, and cost. Every sentence delivers value. The example is succinct and illustrative. No redundancy or filler content.

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

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

Comprehensive for a 2-parameter tool with no output schema. The description fully documents return values (both individual deal fields and aggregate analytics), usage contexts, and operational cost. Combined with complete parameter annotations, no gaps remain for agent decision-making.

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

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

Input schema has 100% description coverage with clear defaults and ranges. The description provides a concrete usage example (getPrivateEquity({ sector: 'ai', days: 30 })) that reinforces parameter interaction, but does not add substantial semantic meaning beyond what the schema already provides. Baseline 3 is appropriate given high schema coverage.

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

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

The description opens with a specific verb ('Fetch') and clearly defines the resource (PE/VC deal flow) plus specific data points covered (funding rounds, exits, dry powder, sector shifts). It distinguishes from sibling 'get_funding_rounds' by emphasizing broader scope beyond just funding rounds.

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 'Use this tool when:' section provides four distinct, concrete scenarios covering research, sector analysis, market indicators, and business development contexts. While highly specific, it lacks explicit 'when not to use' guidance or named alternatives (e.g., does not reference get_funding_rounds for narrower queries).

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, confirming safe read operations. The description adds critical behavioral context not in annotations: the cost ($0.005 USDC per call) and detailed return value documentation (since no output schema exists). It does not contradict annotations.

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

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

The description is efficiently structured with clear sections: data overview, usage conditions, return fields, examples, and pricing. Every sentence earns its place; the return value documentation is necessary given the absence of an output schema, and the examples demonstrate realistic usage patterns 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 the lack of an output schema, the description comprehensively documents all return fields (median_sale_price, mortgage_rate_30yr, regional_breakdown, etc.) and provides concrete examples of expected outputs. Combined with cost disclosure and usage guidelines, this provides complete contextual coverage for a single-parameter 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 description coverage is 100%, with the 'region' parameter fully documented including all valid options ('national', 'new-york', 'miami', etc.). The description provides usage examples but does not add semantic meaning beyond the comprehensive schema documentation, meeting the baseline for high-coverage schemas.

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 'Fetch US real estate market data' and enumerates specific metrics (median home prices, mortgage rates, ARM, inventory, days-on-market, affordability index). This clearly distinguishes it from sibling tools like get_macro_data or get_commodities by specifying housing-specific indicators.

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 'Use this tool when:' section provides four explicit scenarios: macro agents assessing consumer wealth, REIT investment analysis, mortgage rate leading indicators, and Fed rate decision impacts. This directly contrasts with alternatives like get_macro_data by specifying exactly which analytical contexts require housing-specific data.

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?

Annotations already indicate read-only, non-destructive, idempotent operations. The description adds critical behavioral context not in annotations: the $5 USDC cost per call (essential for agent resource planning), the AI-relevance scoring mechanism (0-100), and detailed return structure (since no output schema exists). It does not contradict annotations.

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

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

The description is well-structured with clear sectioning (purpose, usage conditions, returns, example, cost). While information-dense, every element serves a necessary function—particularly the cost disclosure and return field documentation required due to the missing output schema. Minor verbosity in the returns list prevents a perfect 5.

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

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

Given the absence of an output schema, the description comprehensively enumerates return fields (company, ticker, ai_relevance_score, key_passages, etc.). It covers the domain (SEC forms), the specific AI focus, the cost model, and provides concrete search examples. This is complete for a financial data retrieval 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?

With 100% schema description coverage, the structured schema already fully documents all four parameters including usage guidance (e.g., 'Use 1-7 for breaking disclosures'). The description provides a helpful usage example but does not need to compensate for schema gaps, warranting the baseline score of 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 opens with a precise action ('Search real-time SEC filings') and specific resource scope ('8-K, 10-K, 10-Q, S-1') focused on 'AI/autonomous operations mentions.' It clearly distinguishes from siblings like get_ai_news (news vs regulatory filings) and get_company_profile (general info vs AI-specific SEC text).

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 'Use this tool when:' section provides four explicit, role-based scenarios (research agent, investor agent, compliance agent) that clearly delineate when to use this versus alternatives like check_ai_compliance or get_ai_patents. It explicitly states the intent (detecting AI risk factors, material investments) rather than leaving it implied.

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?

Annotations cover safety profile (readOnly, non-destructive, idempotent) and open-world hint. The description adds critical behavioral context missing from annotations: explicit cost ($0.005 USDC per call), detailed return value structure (listing all fields like utilisation_pct and supply_signal), and a concrete example showing expected output format. This compensates well for the lack of output 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?

Exceptionally well-structured with clear visual hierarchy: resource definition → usage scenarios → return specification → example → cost. Every sentence serves a distinct purpose. Information is front-loaded with the core capability stated immediately. No redundancy or filler content.

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

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

For a single-parameter tool with 100% schema coverage but no output schema, the description achieves comprehensive completeness. It manually documents the return structure field-by-field, provides a concrete example output, specifies pricing, and details four distinct usage personas. Nothing essential is missing given the tool's scope.

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

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

Input schema has 100% description coverage with detailed explanations of the 'nodes' parameter syntax and valid values (3nm, 5nm, etc.). With full schema coverage, baseline is 3. The description reinforces this with an example call but does not add substantial semantic meaning beyond what the schema already 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 opens with a specific verb ('Get') and comprehensively lists the resources covered (TSMC/Samsung/Intel fab rates, lead times, shortage signals, AI chip availability). It clearly distinguishes from siblings like get_commodities by emphasizing fabrication-specific metrics (process nodes, fab utilisation) rather than generic commodity pricing.

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 an explicit 'Use this tool when:' section with four distinct, concrete scenarios (tech investors, supply chain agents, AI chip demand analysis, macro constraints). This offers excellent contextual guidance. Lacks explicit 'when-not' guidance or named sibling alternatives (e.g., 'use get_commodities for general materials'), preventing a perfect 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?

Annotations cover safety (readOnly/idempotent), but the description adds crucial behavioral context: specific return fields (baltic_dry_index, container_rates, etc.), cost per call ($0.005 USDC), and input/output examples. No contradictions with annotations.

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

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

Perfectly structured with clear sections (purpose, usage conditions, returns, example, cost). Every sentence earns its place; the bullet points enhance scannability without verbosity.

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

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

Despite lacking an output schema, the description comprehensively documents return values, provides realistic examples, discloses operational costs, and maps use cases to the specific data returned. Complete for a single-parameter 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?

With 100% schema coverage, the baseline is 3. The description adds value by providing a concrete usage example showing comma-separated route syntax and linking inputs to example output values ('Asia-Europe $4,200/40ft'), enhancing semantic 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 opens with a specific verb ('Get') and clearly identifies the resource ('global shipping and freight rates'), enumerating specific indices (BDI, Freightos, port congestion) that distinguish it from sibling tools like get_commodities or get_macro_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?

Provides excellent contextual guidance through four specific 'Use this tool when' scenarios covering macro analysis, supply chain risk, inflation assessment, and geopolitical monitoring. Lacks explicit 'when-not' exclusions or named alternative tools, preventing 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?

Annotations declare read-only/idempotent, but description adds critical cost disclosure ('$0.005 USDC per call') and compensates for missing output schema by documenting all return fields (kp_index 0-9 scale, storm_level G1-G5, etc.) plus concrete example output. No contradictions with annotations.

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

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

Perfectly structured with clear sections: Purpose → Usage Conditions → Return Values → Example → Cost. Every sentence earns its place; even the return value documentation is compact yet complete. Excellent information density 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?

Despite lacking output schema, description is fully complete due to exhaustive return field documentation (7 fields explained with ranges/enumerations) and realistic example. Single parameter thoroughly covered. Appropriate for tool 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 of the single 'alerts' parameter, establishing baseline 3. Description adds value by contextualizing what alerts contain ('solar radiation storms and geomagnetic disturbances') and providing executable example syntax getSpaceWeather({ alerts: true }).

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?

Opens with specific verb 'Fetch' and clear resource 'NOAA space weather data'. Enumerates specific data points (KP index, solar flux, X-ray flare class) that clearly distinguish it from sibling tools like get_earthquake_monitor or get_commodities. Zero ambiguity about function.

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 'Use this tool when:' section with four distinct scenarios (satellite/GPS risk, HF radio disruption, power grid monitoring, financial market correlation). Provides concrete thresholds (G3+ storms) and affected domains (aviation/shipping) that enable precise agent selection.

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?

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds critical behavioral context not in annotations: the cost ('$0.005 USDC per call') and comprehensive return value documentation (symbol, current_price, peg_deviation_pct, etc.) since no output schema exists. It does not contradict annotations.

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

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

Excellent structure: one-sentence purpose summary, bullet-pointed usage guidelines, structured return value list, concrete example, and cost note. Every sentence serves a distinct function; information is front-loaded and scannable 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?

Given the lack of an output schema, the description comprehensively documents all return fields with data types and scales (e.g., 'depeg_risk_score (0-100, 100=imminent)'). It also includes cost information and usage examples, making it complete for a single-parameter 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?

With 100% schema description coverage, the baseline is 3. The description adds value by providing a concrete example call (getStablecoins({ tokens: 'USDT,USDC,DAI' })) that clarifies the expected input format and usage pattern beyond the schema's technical 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 opens with a specific verb ('Monitor') and comprehensively lists the resource (stablecoin health) including specific metrics tracked (peg deviation, supply changes, market cap, backing composition, depeg risk score). It clearly distinguishes from siblings like get_defi_yields or get_crypto_derivatives by focusing on health/peg stability rather than yields or derivatives 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?

Explicit 'Use this tool when:' section lists four distinct, concrete scenarios (DeFi peg verification, collapse detection, counterparty risk assessment, yield farming comparison). This provides clear guidance on when to select this tool over alternatives like get_defi_yields or get_onchain_data.

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?

Adds significant value beyond annotations: discloses pricing ('$0.005 USDC per call'), details return structure (token_name, unlock_type, impact_signal fields), and provides concrete input/output example. Since no output schema exists, the return value documentation is critical behavioral context not covered by annotations.

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

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

Well-structured with clear visual hierarchy: purpose statement → usage bullets → return specification → example → cost. Every section earns its place; no redundant filler. Front-loaded with core value proposition ('selling pressure').

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?

Comprehensive for a single-parameter tool lacking output schema. Description compensates fully by enumerating all return fields and providing realistic example output. Covers cost, use cases, and data semantics. Annotations cover safety profile (readOnly/idempotent), leaving description free to focus on business logic.

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

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

Input schema has 100% description coverage for the 'days' parameter including usage guidance ('Use 7 for immediate week...'). Description references the parameter only in the example call, adding minimal semantic value beyond the schema's comprehensive documentation. Baseline 3 appropriate given schema carries full load.

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?

Opens with specific verb ('Track') and resource ('token vesting unlock events'), immediately clarifying scope within crypto asset analysis. Distinguishes clearly from sibling tools like get_whale_tracker or get_onchain_data by focusing specifically on vesting schedules and selling pressure events.

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 'Use this tool when:' section lists four specific scenarios (avoiding unlocks, identifying pre-market sell pressure, diagnosing price weakness, timing entries). Provides clear contextual boundaries distinguishing it from general market data 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?

Annotations declare readOnlyHint=true and idempotentHint=true. The description adds critical cost information ('$0.005 USDC per call') not found in annotations, and comprehensively documents the return structure (11 specific fields including confidence scores and trend direction) despite the absence of an output schema. Deducted one point for lacking rate limits or cache duration details.

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?

Perfectly structured with logical flow: summary → usage conditions → supported inputs → return values → example → cost. Every sentence serves a distinct purpose. The example is appropriately specific without being verbose, and the cost disclosure is prominently placed for agent budget awareness.

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 complex financial tool with no output schema, the description compensates exceptionally well by enumerating all 11 return fields with their semantics (e.g., 'confidence (0-100)', 'BUY/SELL/HOLD'). The annotations cover the safety profile. Minor gap: no mention of error handling for invalid symbols or unavailable markets.

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 description coverage, the baseline is met. The description adds value by categorizing timeframes by trading style ('scalping', 'intraday', 'swing') and providing a concrete usage example (getTradingSignal({ symbol: 'XAUUSD'...)), which helps the LLM understand the expected calling pattern beyond the raw schema 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 opening sentence states the specific action ('Generate a BUY, SELL, or HOLD signal') and the resource ('trading instrument'), plus enumerates the specific technical analysis components included (RSI, EMA, ATR, etc.). This clearly distinguishes it from sibling data-fetching tools like 'get_fx_rates' or 'get_market_sentiment' which provide raw data rather than actionable entry/exit recommendations with calculated risk-reward ratios.

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?

Contains an explicit 'Use this tool when:' section with four specific scenarios (concrete entry/exit recommendations, validating trading ideas, systematic strategies, momentum analysis). It also lists supported symbols and timeframes, providing clear boundaries for valid inputs and implicitly contrasting with fundamental analysis tools like 'get_analyst_ratings' or 'get_earnings' in the sibling list.

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

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

Annotations declare read-only/idempotent safety, while the description adds critical behavioral context not in structured fields: per-call cost ('$0.005 USDC per call'), detailed return schema (listing agent_name, token_ticker, etc. since no output schema exists), and an invocation example with expected output format. No contradictions with annotations.

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

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

Well-structured with clear information hierarchy: purpose → usage conditions → return values → example → cost. Each sentence adds unique value (especially the cost disclosure and return field enumeration). Slightly dense but appropriate for the financial data complexity.

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?

Comprehensive despite lacking an output schema: it enumerates all return fields (agent_name, price_usd, holder_count, etc.), specifies the data refresh nature ('live data'), discloses API costs, and provides concrete usage examples. Fully sufficient for an agent to understand tool capabilities and outputs.

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% description coverage for the 'limit' parameter (including range, default, and usage guidance), so the description does not need to compensate. The description mentions no parameter details, which is acceptable given the schema's completeness, warranting the baseline score of 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 opens with a specific verb ('Get') and precisely identifies the resource ('Virtuals Protocol ecosystem' AI agents), listing exact data points (token prices, market cap, 24h volume). It clearly distinguishes from sibling tool 'get_ai_tokens' by specifying the Virtuals Protocol niche and naming specific agents like LUNA and AIXBT.

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 an explicit 'Use this tool when:' section with four specific scenarios covering investment monitoring, performance tracking, research analysis, and market ranking. While highly contextual, it does not explicitly name alternative tools (e.g., 'use get_ai_tokens for general AI tokens'), which would earn 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?

While annotations declare readOnlyHint=true and idempotentHint=true, the description adds critical behavioral context not in structured fields: the $5 USDC per-call cost, the specific return schema (wallet_address, direction, signal enums), and the semantic meaning of signals (BULLISH/BEARISH/NEUTRAL). No contradictions with annotations.

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

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

Well-structured with clear sections: summary, usage conditions, returns specification, example, and cost. Information is front-loaded with the core purpose first. While longer than minimal, every section earns its place by compensating for missing output schema and documenting cost implications.

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?

Fully compensates for the absence of an output schema by enumerating all return fields (wallet_address, amount_token, signal, etc.) and providing a concrete example output. Essential commercial context (the $5 USDC cost) is disclosed, which is critical for agent decision-making when selecting between this and potentially free alternatives.

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

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

Input schema has 100% description coverage with detailed explanations of 'chain' enum values and 'minValueUSD' thresholds. The description adds value by providing a concrete usage example (getWhaleTracker({ chain: 'btc', minValueUSD: 5000000 })) that demonstrates how parameters interact to filter for institutional-scale Bitcoin movements.

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 ('Monitor') and clearly defines the resource (on-chain large wallet movements for BTC/ETH). It distinguishes from sibling 'get_onchain_data' by specifying the focus on whale wallets, exchange inflows/outflows, and smart money behavior with directional signals (bearish/bullish).

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?

Contains an explicit 'Use this tool when:' section with four specific scenarios covering crypto trading agents, exchange flow analysis, whale wallet tracking, and DeFi capital flow detection. This provides clear boundaries for when to select this tool over alternatives like 'get_crypto_derivatives' or 'get_market_sentiment'.

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?

Annotations indicate readOnly/idempotent, which the description respects by using 'aggregates' (read operation). The description adds critical behavioral context not in annotations: the $100 USDC cost per call (essential for agent decision-making), the specific return fields (latest_arxiv_breakthroughs, github_trending_ai_repos, etc.), and an example input/output mapping. Minor gap: doesn't explicitly address the openWorldHint implications (real-time data volatility) or latency expectations for this expensive bundle operation.

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

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

Highly structured with clear visual hierarchy: summary sentence, bullet-pointed usage conditions, returns list, code example, and cost disclosure. Every sentence earns its place. No fluff or tautology. The em-dash and bullet formatting maximize scannability for an AI agent parsing the text.

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

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

Given the tool's complexity (aggregating 6+ disparate data sources) and lack of output schema, the description compensates well by explicitly listing return fields and providing a concrete example. The cost disclosure is critical for a paid tool. Minor gap: given the $100 cost and bundle nature, brief mention of error handling (partial failure behavior) or rate limiting would strengthen 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 100% schema description coverage for the single 'focus' parameter, the baseline is 3. The description provides usage examples ('agentic ai autonomous'), but these duplicate the examples already present in the JSON schema description. No additional semantic clarification (e.g., format constraints, interaction with the default value) is provided beyond the schema.

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

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

The description clearly states the tool 'aggregates ArXiv research + GitHub trending + job pivots + AI model prices + AI tokens + AI regulatory news into a comprehensive AI industry intelligence report.' Specific verb (aggregates) + resource (AI economy data) + scope (comprehensive report) provided. It effectively distinguishes itself from siblings (e.g., get_arxiv_research, get_github_trending) by emphasizing the bundled, multi-dimensional nature of the output.

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?

Excellent explicit guidance via 'Use this tool when:' section listing four specific scenarios (AI research agent, VC agent, tracking adoption signals, strategy agent). Clearly positions against alternatives by specifying when to use this 'complete picture in one call' versus individual getter tools, and identifies target users/agents.

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?

While annotations declare readOnlyHint=true and idempotentHint=true, the description adds critical behavioral context not in structured fields: the $50 USDC cost per call and the complete return value structure (company_profile, investment_thesis, etc.) to compensate for the missing output schema. It does not disclose latency or caching behavior, preventing a perfect score.

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?

Excellent structure with clear visual hierarchy: purpose statement → usage conditions → return values → example → cost. Every sentence earns its place; the cost disclosure is critical for agent decision-making, and the return list compensates for missing output schema. No redundancy with schema or annotations.

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 high complexity (8 distinct return components) and lack of output schema, the description adequately compensates by enumerating all return fields (ai_adoption_score, key_risks, etc.). It covers cost, usage contexts, and parameters. Minor gap: does not specify if data is real-time vs cached or typical response latency.

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 description coverage, the baseline is 3. The description adds value by providing a concrete code example (`runBundleCompanyDeep({ company: 'nvidia', github: 'nvidia' })`) that demonstrates the exact calling convention and parameter usage pattern, clarifying how the optional 'github' parameter relates to the company name.

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 phrase ('runs full company profile...') and explicitly lists the bundled resources (competitor intel, hedge fund positioning, SEC filings, etc.). It clearly distinguishes this from sibling tools like `get_company_profile` or `get_competitor_intel` by positioning itself as the comprehensive aggregation ('The most comprehensive company intelligence available').

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?

Contains an explicit 'Use this tool when:' section with four distinct scenarios covering investor due diligence, sales briefings, AI posture research, and detailed report writing. This provides clear persona-based guidance on when to select this bundle versus individual component 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?

Annotations declare read-only, idempotent, non-destructive traits. The description adds critical cost transparency ($25 USDC per call) that annotations cannot express, and documents the return structure (network_metrics, whale_movements, etc.) in lieu of an output schema. It could achieve a 5 by noting cache duration or rate limits, but the cost disclosure is highly valuable.

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

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

The description is well-structured with clear sections (purpose, usage conditions, returns, example, cost) and front-loads the value proposition. While lengthy, every sentence serves a distinct purpose; the bullet points efficiently compress multiple use cases. Minor redundancy exists between the opening sentence and the returns list.

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 high complexity (aggregating six distinct data sources) and absence of an output schema, the description compensates adequately by enumerating return fields and providing a concrete example output. The cost disclosure is essential for an expensive operation. It misses only operational details like cache TTL or rate limiting.

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 description coverage for the single 'chains' parameter—including default values, supported enums, and formatting guidance—the schema carries the full semantic load. The description includes an example call, but this merely echoes the schema's default value rather than adding new constraints or behavioral context.

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 compound verb ('aggregates') and exhaustively lists the six data domains bundled (on-chain metrics, whale tracker, DeFi yields, AI tokens, derivatives, stablecoin health). It clearly positions the tool as a comprehensive 'single report' alternative to individual data fetches, distinguishing it from siblings like get_whale_tracker or get_defi_yields.

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 explicit 'Use this tool when:' section provides four distinct scenarios (trading agent execution prep, DeFi health assessment, alpha opportunity identification, portfolio rebalancing) that contrast with using individual component tools. The phrase 'in one efficient call' signals when to prefer this over chaining 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?

Annotations declare readOnly/idempotent/non-destructive hints. The description adds critical behavioral context not in annotations: the $200 cost per call, response time expectations (30s vs 60-90s implied in parameter descriptions), and detailed return value structure (crisis_scores, escalation_trajectory, recommended_hedges). It could improve by mentioning error handling or rate limiting.

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 sections: value proposition, usage conditions, return values, example, and cost. Every sentence earns its place. Minor deduction for slightly marketing-heavy language ('War Room', 'deepest') in the opening, though appropriate for the high-stakes domain.

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 lacking an output schema, the description comprehensively documents return values (crisis_scores, market_impact_estimates, social_viral_signals, etc.). Combined with rich annotations and 100% parameter coverage, the description provides sufficient context for an agent to invoke this complex multi-source intelligence tool correctly.

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

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

With 100% schema coverage, the schema carries the primary documentation load. The parameter descriptions within the schema are excellent (explaining 'standard' vs 'deep' timing and supported region values). The main description adds value through the concrete usage example showing the expected input format.

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 aggregates 'GDELT crisis monitoring + escalation scoring + oil/gold/USD/defence market impact modelling + OFAC sanctions alerts + Reddit/HackerNews viral signal processing'. It positions itself as 'the deepest geopolitical intelligence bundle', distinguishing it from the simpler sibling 'get_geopolitical_crisis' and broader bundles like 'run_bundle_macro_global'.

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?

Contains an explicit 'Use this tool when:' section with four specific scenarios (macro trading reaction, risk stress-testing, real-time crisis intelligence, multi-conflict monitoring). It explicitly names the target agent types (macro trading agent, risk agent) and includes cost information ($200 USDC) to guide invocation 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?

Annotations cover readOnly/idempotent/destructive traits. Description adds critical behavioral context not in structured data: $50 USDC cost per call, detailed return structure (per country metrics + global risk score), and an example demonstrating thesis generation. Does not contradict annotations.

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

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

Excellent structure: one-sentence summary, bulleted usage conditions, returns specification, concrete example, and cost note. Every sentence earns its place; no fluff despite covering complex multi-dimensional functionality.

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 exists, description adequately compensates by listing return fields (interest_rate, CPI, macro_regime, etc.) and global outputs. Covers cost and usage contexts. Minor gap: does not mention data freshness/frequency or rate limits for this expensive ($50) operation.

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

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

Input schema has 100% description coverage with detailed explanation of comma-separated format and supported codes. Description provides usage example (runBundleMacroGlobal({ countries: 'US,EU,JP' })) which reinforces syntax, but schema already fully documents semantics. Baseline 3 appropriate per calibration.

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 explicitly states it 'aggregates macro indicators + FX rates + interest rate environment + inflation data + consumer/labour data across multiple economies into a single macro intelligence report.' Specific verbs (aggregates) and comprehensive resource listing clearly distinguish it from siblings like get_macro_data (single indicator) or get_fx_rates (single asset class).

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 explicit 'Use this tool when:' section with four specific scenarios (macro trading agents, portfolio regime assessment, cross-country comparison, FX positioning). However, lacks explicit 'when-not' guidance or named sibling alternatives (e.g., 'use get_macro_data instead for single-country queries').

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?

Annotations declare read-only, idempotent, non-destructive properties. The description adds critical behavioral context not in annotations: the $25 USDC cost per call, the specific return structure (six data categories), and an invocation example showing exact syntax. No contradictions with annotations.

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

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

Excellent information hierarchy: one-line summary, bullet-pointed usage conditions, return value enumeration, code example, and cost disclosure. Every sentence earns its place; no redundant fluff despite the length.

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

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

Despite lacking an output schema, the description compensates by enumerating all six return data categories. For a complex aggregation tool with financial cost implications, it covers pricing, rate limits (implied by 'up to 10 symbols'), return values, and usage scenarios comprehensively.

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 detailed parameter description. The description adds value by providing a concrete JavaScript-style invocation example (runBundleMarketIntel({ symbols: [...] })) demonstrating function naming conventions and parameter passing, plus context about supported asset classes in the example.

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 specific verbs ('combines', 'packs') and explicitly lists the six data sources aggregated (trading signals, on-chain data, macro, options flow, insider trades, earnings). It distinguishes itself from single-source sibling tools (get_trading_signal, get_onchain_data, etc.) by positioning as a comprehensive 'bundle' and noting 'Best value for active trading agents'.

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 explicit 'Use this tool when' section with four distinct scenarios (active trading position sizing, cross-referencing technical/institutional flow, pre-market prep, risk management). The cost disclosure ($25 USDC) and 'Best value' claim implicitly guide users toward individual data tools for narrow queries.

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?

Annotations cover safety (readOnlyHint=true, destructiveHint=false). Description adds crucial behavioral context not in annotations: the $500 USDC cost, that results are 'fully synthesised' with a global risk score, and the comprehensive scope of returned data. Minor gap: no mention of latency expectations for 56 aggregated calls or caching 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?

Perfectly structured with distinct sections (capability, usage triggers, returns, cost). Every sentence earns its place—no fluff. Front-loaded with the key differentiator (56 endpoints) and prioritizes cost information (critical for a $500 tool) at the end.

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 complex aggregation tool wrapping 56 endpoints, the description comprehensively details return contents (macro environment, geopolitical scores, crypto health, etc.) despite lacking an output schema. Cost transparency is excellent. Minor deduction for not mentioning rate limits, error handling partial failures, or latency expectations given the heavy aggregation workload.

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% description coverage with clear explanations for both parameters (regions defaulting to 'all', companies being optional). Description references these implicitly in the returns section but adds minimal semantic guidance beyond what the schema already provides. Baseline 3 appropriate given schema completeness.

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 explicitly states this combines 'ALL 56 endpoints' into a 'sovereign-grade intelligence report' and enumerates specific coverage areas (macro, geopolitical, crypto, AI economy, etc.). The 'most comprehensive' claim and $500 pricing clearly distinguishes it from sibling bundle tools (starter, macro_global, etc.) and individual endpoint 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?

Excellent explicit guidance via 'Use this tool when:' section listing four specific high-stakes scenarios (sovereign funds, war-room briefs, maximum context needs). The cost comparison ($500 vs $100+ separately) explicitly guides trade-offs between this and calling individual endpoints or smaller bundles.

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?

Annotations declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds critical behavioral context not in annotations: the cost structure ($0.50 vs $0.025), the specific return payload structure (compliance_status, market_sentiment, etc.), and the scope limitation ('broad market context snapshot'). It does not contradict annotations.

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

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

Perfectly structured and front-loaded: opening sentence defines the bundle composition, second sentence states the ideal use case, followed by explicit usage conditions, return values, an example, and cost. Every sentence earns its place; the cost disclosure is essential information for an agent optimizing API spend.

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 exists, the description compensates by explicitly listing all five return components (compliance_status, market_sentiment with enum values RISK_ON/OFF, trading_signal, macro_overview, top_5_news_stories). It covers the economic cost model, usage scenarios for a complex bundled operation, and clarifies the relationship between input parameters and output data.

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 description coverage, the baseline is 3. The description adds value by providing a concrete code example (runBundleStarter({ symbol: 'XAUUSD', assets: 'BTC,ETH,GOLD' })) that demonstrates how the two parameters interact to produce a 'Full gold trading context.' It also clarifies the economic rationale affecting parameter selection.

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 'calls compliance + market sentiment + trading signals + macro data + news in a single bundled request'—a specific verb and compound resource. It distinguishes itself from the 50+ sibling tools (particularly the individual component tools like get_trading_signal and other bundles like run_bundle_macro_global) by positioning itself as the 'initialising' or 'morning brief' option for broad context rather than deep 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?

Contains an explicit 'Use this tool when:' section with four specific scenarios including initialization, cost optimization, daily brief generation, and orientation before deeper calls. It explicitly names the economic alternative ('5 Tier 1 tools for $0.025 if called separately'), giving the agent clear decision criteria for when to use this bundle versus individual 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?

Annotations establish read-only, idempotent, non-destructive nature. Description adds critical cost transparency ('$0.005 USDC per call') and detailed return value specification (match_probability ranges, risk_level enum values, recommended_action) compensating for missing output schema. Does not mention authentication requirements.

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?

Excellent structure with clear section headers (implicit via colons), bullet points for use cases, and concise examples. Information is front-loaded with the core function first, followed by usage contexts, returns, and cost. No wasted words.

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

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

Given the high compliance stakes and absence of structured output schema, the description comprehensively documents return fields (risk levels, match probability scale), cost implications, and jurisdictional coverage. Adequate for safe agent operation in a regulated domain.

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 complete property descriptions. Description adds concrete usage examples ('Mahan Air' with country code 'IR', crypto wallet address format) that illustrate parameter semantics and expected responses, enhancing understanding beyond schema 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?

Opens with specific verb ('Screen') and comprehensive resource list ('person, company, vessel, or crypto wallet against OFAC, EU, UN, and UK sanctions lists'). Distinct from siblings which focus on market data, AI, and financial intelligence rather than compliance screening.

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 explicit 'Use this tool when:' section with four concrete scenarios (KYC onboarding, payment verification, trade counterparty checks, crypto wallet screening). Clear context for usage but lacks explicit 'when not to use' or named alternatives.

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