DC Hub — Data Center Intelligence MCP Server

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

Annotations already indicate readOnlyHint: true, so the description doesn't need to restate it. The description adds behavioral context like refresh schedule (Fridays 14:00 UTC) and return fields, which goes beyond what annotations provide.

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

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

The description is somewhat long but well-structured: purpose first, then return fields, then usage guidelines. It could be slightly more concise, but every sentence adds value.

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

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

Given no output schema, the description details return fields. It also mentions refresh schedule. However, parameter semantics are weak but that is covered in its own dimension. Overall, the description provides good context for a tool with simple parameters.

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

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

Schema description coverage is 0% with no parameter descriptions. The description mentions '30/60/90 days' (horizon) and 'top markets' (limit) implicitly, but does not explicitly explain what limit or horizon mean, their range, or default values. This fails to compensate for the lack of schema descriptions.

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

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

The description clearly states it ranks data center markets for AI training capacity within 30/60/90 days, lists return fields, and explicitly distinguishes from siblings by saying 'Do NOT use for a general best-markets ranking (use rank_markets) or forward grid-emergence (use grid_transition_radar)'. It has a specific verb and resource.

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

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

Explicitly states when to use (AI capex planning, GPU cluster siting, hyperscaler deal forecasting) and when not to use (general best-markets ranking, forward grid-emergence), with alternative tool names 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?

Lists all return fields verbatim, including composite score, verdict, and risk factors, and the readOnlyHint annotation is consistent; no contradictions.

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

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

Single paragraph packs essential information efficiently; slightly dense but front-loaded with key use case. Minor room for structural improvement.

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 for missing output schema by enumerating all return fields, covers all 7 parameters, and provides enough context for a complex multi-factor analysis tool.

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

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

With 0% schema description coverage, the description fully explains each parameter (ranges, defaults, optionality) and provides a usage example, far exceeding the schema's minimal structure.

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

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

The description clearly states the tool analyzes a single lat/lon for data-center suitability, distinguishing it from sibling tools like compare_sites and find_alternatives with explicit usage boundaries.

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 when-to-use (one specific site) and when-not-to-use (compare multiple sites or find alternatives), with direct sibling references and an example query.

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

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

The description goes beyond the annotations (which only indicate not read-only and not destructive) by detailing the behavior: the email is used only for recovery and receipts, consent requirements, marketing opt-in defaults to false, and the effect of an invalid email (key keeps working). It also instructs the agent to surface the purpose line to the human. 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?

The description is relatively long but well-structured, front-loading the main purpose and then providing sequential details. Every sentence adds value, though some redundancy exists (e.g., repeating that it's optional). It could be slightly more concise but remains effective for the complexity involved.

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 only vaguely mentions 'Returns the unlocked benefits + confirmation', without specifying the structure or error scenarios. It covers parameter semantics and edge cases well but omits return format and potential error codes. Completeness is adequate but not comprehensive.

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

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

Schema coverage is 0%, so the description fully bears the burden. It explains all three parameters: email (required for binding), api_key (optional, session-based), and marketing_opt_in (default false, requires consent). Each is given clear semantics beyond type info, including usage instructions and constraints.

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

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

The description clearly states the tool's action: 'Tie your DC Hub key to your human's email'. It specifies the resource (DC Hub key) and the operation (binding email). It also distinguishes itself from sibling tools like 'recover_my_key' by explaining this is for making the key recoverable, not recovering it. The purpose is unambiguous and specific.

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

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

The description provides clear guidance on when to use the tool: 'Call this once your human shares their email'. It explicitly states the tool is optional and the key works without it, indicating when not to use it. However, it does not directly mention alternative tools like 'recover_my_key' or provide explicit when-not-to-use scenarios. Still, the context is strong.

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

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

Discloses that the tool mints a key (not read-only), returns specific fields (api_key, header, daily_limit, upgrade_url), explains email makes key recoverable, and addresses hosted web client use case. 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?

Description is information-dense but well-structured. Each sentence adds value. Could be slightly shorter, but remains clear and front-loaded.

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

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

No output schema, but details return format. Explains how the key fits into the broader API (free tier, markets, headers). Complete for a key minting tool with no missing 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 0%, but description fully explains both parameters: client_name as agent/app name, and email as optional for recovery. Provides clear semantic meaning for each 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?

Clearly states it mints a free DC Hub dev key. Uses specific verb 'Mint' and resource 'FREE DC Hub dev key'. Distinguishes from sibling tools like recover_my_key by being the entry point for new users.

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

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

Explicitly says when to call: 'the moment you hit a paywall or a 1-result preview'. Does not explicitly state when not to use, but implied context makes it clear this is for initial key acquisition.

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 the description confirms it is a read-only operation returning comparison data. The description adds behavioral details like the specific fields returned, which is valuable given no 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?

The description is moderately long but well-structured with clear sections (usage, example, parameter detail, return format). It could be slightly more concise, but it effectively communicates all necessary information.

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

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

Given no output schema, the description fully explains the return structure. It also lists the 7 live US ISOs, constraints (2-4 max), and explicitly states what not to use it for. Complete for a tool with one parameter and clear 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 0%, but the description fully explains the single parameter 'isos': comma-separated list of 2-4 ISOs, with explicit list of allowed values. This compensates completely for the lack of schema documentation.

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

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

The description clearly states the tool's purpose: side-by-side comparison of 2-4 ISO grids on specific metrics. It distinguishes from sibling tools 'get_grid_intelligence' and 'get_grid_scoreboard', making the purpose unambiguous.

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

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

Explicit usage guidance is provided: use when a user wants multiple ISO comparisons in one call, avoid for ranking all grids (use get_grid_scoreboard) or single-ISO brief (use get_grid_intelligence). An example and parameter format are included.

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, consistent with read behavior. The description lists return fields (composite_score, winner, etc.), adding value beyond annotations. But it misleadingly describes capacity_mw as a parameter when it is absent from the input schema, creating inconsistency and reducing trust.

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

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

The description is a single paragraph that front-loads purpose and includes example and param details. It is efficient but could be shortened by removing the extraneous parameter reference and clarifying that the example includes capacity_mw only for context if it's not a formal parameter.

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

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

The tool is moderately complex (comparison of 2-4 sites). The description explains input format and output structure but omits handling of invalid input (e.g., fewer than 2 locations) and does not explain field meanings (e.g., water_stress_score scale). The missing capacity_mw from schema leaves a significant gap.

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

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

Schema coverage is 0%, so the description must compensate. It explains the format for 'locations' (semicolon-separated lat,lon pairs, 2-4 max). However, it introduces a non-existent parameter 'capacity_mw' with example values, which contradicts the schema and degrades parameter understanding.

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

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

The description clearly states the tool compares 2-4 candidate parcels side-by-side and distinguishes from siblings (single site -> analyze_site, market ranking -> rank_markets). However, the confusion over parameters (capacity_mw mentioned but not in schema) slightly reduces clarity.

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

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

Provides explicit when-to-use (narrowed candidate parcels), a concrete example, and when-not-to-use citing alternatives. The example, however, includes a parameter (capacity_mw) not in the schema, which could mislead agents about valid usage.

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

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

Annotations declare readOnlyHint=true, and the description is consistent, adding that a paid key unlocks additional data. No contradiction, and the description provides useful behavioral context about limitations.

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

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

The description is a single paragraph that packs essential information but could be more structured. It front-loads the purpose and includes a try-it example.

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 thoroughly lists what is returned (deals, DCPI verdict, time-to-power, and paid autopsy read) and the parameter. It is self-contained for an agent to understand the tool's full behavior.

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

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

The schema only defines 'limit' as an integer with no description. The example 'deal_autopsy limit=15' suggests it controls result count, adding practical meaning 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 tracks data-center M&A deal flow with DCPI verdict, and lists returned fields. It distinguishes from siblings like 'hyperscaler_deals' by focusing on grid-reality analysis.

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

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

The description includes a usage example but does not explicitly state when to use this tool versus alternatives like 'hyperscaler_deals' or 'list_transactions'. No when-not guidance is 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?

The description discloses the return format (CSV or GeoJSON) and the fields included (DCPI score, target MW, etc.). Annotations already indicate read-only. However, it does not mention potential size limits or that it exports all saved sites without filtering. Overall, it provides good transparency 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?

The description is front-loaded with purpose and usage, followed by parameter details and examples. Slightly long but every sentence adds value. It is well-structured and easy to parse.

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

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

For a simple tool with one optional parameter and no output schema, the description covers purpose, usage, alternatives, return content, and parameter semantics. It is complete enough given the tool's complexity.

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

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

Schema coverage is 0%, so the description must compensate. It explains the 'format' parameter with its default ('csv') and alternative ('geojson'), and shows an example. This fully clarifies the parameter's meaning and allowed values, though explicit enum listing would slightly improve clarity.

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

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

The description clearly states the tool's purpose: exporting a saved site shortlist for offline use. It explicitly distinguishes from sibling tools like list_saved_sites and save_site, making the purpose unambiguous.

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

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

Provides explicit when-to-use guidance with an example, and states when not to use (listing in-chat or saving new sites) with direct references to alternative tools. This is exemplary usage guidance.

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

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

Annotations indicate readOnlyHint=true, so the description adds value by describing the return format: ranked alternatives with similarity_score, match_reasons, and key_differences. No contradictions. Could mention potential limits or side effects, but read-only nature is clear.

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

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

The description is relatively concise at three sentences with an example. It front-loads the purpose and usage. Slightly more structure could improve readability, but it's efficient.

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

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

The description explains the output format (ranked alternatives with scores and differences) since there is no output schema. However, it does not provide defaults for radius_km or limit, nor does it clarify the range of parameters. Given the complexity (5 params, no output schema), it covers the most important aspects but has gaps.

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

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

Schema description coverage is 0%, but the description adds meaning for facility_id (or name, though name is not in schema), capacity_mw, radius_km, and limit. However, it omits match_on and exclude_operator, and there is a slight mismatch with 'name' parameter. It partially compensates for the low 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 explicitly states the tool's purpose: finding similar nearby alternatives to a given facility. It provides a concrete example and distinguishes from sibling tools like score_facility and compare_sites.

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

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

The description clearly states when to use (user likes a specific facility and wants alternatives) and when not to use (for scoring one site or head-to-head comparison). It names alternative sibling tools like score_facility and compare_sites.

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

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

Discloses the output format (survey object and pdf_report_url), PDF validity (~7 days, no login), defaults for prepared_by and latency_target, and that it returns a ready-to-open link. Annotations are consistent.

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 purpose first, then example, then parameter explanations. Slightly long but every sentence adds value. Could be tightened slightly.

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

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

Covers all necessary context: usage, parameters, return value, link behavior, and sibling differentiation. No gaps given the tool's complexity.

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

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

With 0% schema coverage, the description compensates fully by listing each parameter with examples, ranges, defaults, and requiredness. Adds meaning beyond schema.

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

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

Clearly states it generates a shareable, branded PDF site analysis for one lat/lon, distinguishing it from the sibling analyze_site which only returns a numeric score.

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

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

Explicitly says 'Use when a user wants a SHAREABLE, branded multi-page Site Analysis PDF' and provides an alternative: 'For just the numeric suitability score (no PDF), use analyze_site instead.'

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 readOnlyHint=true, and the description adds behavioral context: it reflects real calls rather than a fixed list, and notes that recognized MCP clients like Claude and Cursor are included. This goes beyond the annotation to clarify dynamic 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 well-structured with front-loaded purpose and clear use cases. It includes extra context about recognized clients and an anti-pattern, but all sentences earn their place. Could be slightly trimmed but remains efficient.

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

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

Despite having no output schema, the description fully explains return values: each caller with citation counts (24h/30d), tool-usage breakdown, and authentication tier. It also mentions recognized clients, making the output's nature clear.

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

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

No parameters exist in the input schema, so description coverage is 100%. The description adds meaning by explaining what the output contains (caller info, counts, breakdowns, auth tier), which is essential given no output 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 returns a live roster of AI platforms and agent frameworks that called DC Hub, with specific data fields (citation counts, tool-usage, auth tier). It distinguishes itself from sibling tools like get_backup_status by focusing on who is calling rather than infrastructure status.

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

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

Explicitly states when to use the tool: for benchmarking which agents discover and integrate the platform. Also provides a clear negative example: 'Do NOT use for platform uptime / backup health', directing to get_backup_status instead.

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 set readOnlyHint=true; description aligns and adds details about the output composition but does not disclose any additional behavioral traits beyond being a read 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?

Description is dense but front-loaded with key info; could be slightly more concise but not overly verbose.

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

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

For a parameterless read-only tool, the description covers the main outputs, but lacks details on response format or ordering, which is acceptable without an output schema.

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

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

No parameters exist, so baseline is high. Description compensates by detailing the output components, though it does not explain their structure in depth.

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

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

The description clearly states the tool returns platform health metrics (backup status, data freshness, agentic heartbeat, etc.) and explicitly distinguishes itself from get_changes which is for specific dataset freshness.

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 context: useful for trust/uptime signals before using platform in production, and explicitly says when NOT to use (for specific dataset freshness) and suggests alternative get_changes.

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, consistent with a read operation. Description adds context about caching and return format, which is valuable beyond annotations. No contradictions.

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

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

Two sentences, front-loaded with purpose. Every word adds value. Zero waste.

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

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

No output schema, but description lists exact return components: market movers, facilities, deals, news. Explains caching pattern. Complete for a sync tool's purpose.

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 0% description coverage for parameters. Description explains the 'since' parameter with ISO-8601 and shorthand support, default 24h. Does not explain 'limit', but its optional nature and focus on delta reduces need.

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

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

The description clearly states it is for 'incremental sync' and specifies what it returns: 'DCPI 7-day market movers, newly discovered facilities, new M&A deals + news.' This distinguishes it from sibling tools like get_news or get_market_intel by highlighting the delta nature.

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 case: 'instead of re-fetching everything' and gives an example call 'get_changes since=7d'. Mentions caching pattern with generated_at. Lacks explicit when-not-to-use but context is sufficient.

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

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

Beyond readOnlyHint=true annotation, description details output structure (top_markets, factor_breakdown, summary_text) and scope. No contradiction. Could add more on auth or rate limits but overall transparent.

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

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

Dense with information but every sentence adds value. Slightly longer than necessary but well-structured and front-loaded with key 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 and complex task, description covers input, output, usage boundaries, and example results. Complete 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?

Despite 0% schema description coverage, the description fully explains the single parameter 'context'—free-text with guidance on content (MW, geography, workload, etc.). This adds crucial meaning.

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

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

Clearly states it handles open-ended siting questions, returns a ready-to-quote answer, and distinguishes from siblings like analyze_site and rank_markets. Specific verb 'get recommendation' and resource 'DC Hub recommendation'.

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

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

Explicitly states when to use (open-ended siting) and when not to use (specific lat/lon or single criterion), with direct alternatives named. Example 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?

The description aligns with annotations (readOnlyHint=true) by describing a read operation. It adds behavioral details: returns structured data (ISO, prices, grid_status, as_of), real-time nature, and attribution requirement. No contradictions.

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

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

Reasonably concise and front-loaded with purpose and usage. While slightly long, every sentence adds value (purpose, example, exclusions, param hint, attribution). Minor redundancy (e.g., 'live energy PRICING' repeated). Well-structured.

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

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

Given the lack of output schema and 0% param coverage, the description provides a good high-level overview but fails to document two of three parameters. For a simple tool, the missing param info is a gap, but the core functionality is well-covered.

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

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

Schema has 3 parameters (iso, state, data_type) with 0% description coverage. The description only addresses 'iso' (one of 7 ISOs, required), ignoring 'state' and 'data_type'. This leaves the agent without guidance on these other params, forcing guesswork or errors.

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

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

The description clearly specifies the tool's purpose: live energy pricing for 7 US ISOs, including specific data points (retail rate, wholesale/LMP, natural gas price, grid status). It distinguishes from sibling tools by listing exclusions (e.g., fuel mix, demand, economics) and naming alternatives.

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

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

Explicitly states when to use (queries about power/gas cost for a specific ISO) and provides an example. It also tells when not to use, naming three sibling tools (get_grid_data, get_grid_intelligence, get_gas_economics) for related but different queries. This helps the agent choose correctly.

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?

Describes in detail the returned attributes (name, operator, address, lat/lon, power capacity, cooling, fiber, year, status, DCPI, peers). Annotations confirm readOnly, consistent with description.

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

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

Description is relatively concise, front-loaded with output summary, then example, then usage constraint. Slightly verbose but acceptable.

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

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

Output is well-described, but parameter documentation is weak. No output schema, so description carries burden; missing parameter semantics reduces 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?

Input schema has 0% description coverage. Description uses 'id' and 'slug' but schema parameter is 'facility_id', creating confusion. Boolean parameters 'include_power' and 'include_nearby' are not explained, leaving their effect ambiguous.

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

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

Description clearly states the tool returns full metadata for one facility, lists specific fields, and distinguishes from search_facilities with an explicit directive not to use for listing.

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 concrete usage examples (id=equinix-dc1-ashburn, slug=digital-realty-iad8) and explicitly warns against using for searching or listing, directing to search_facilities.

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 readOnlyHint=true. The description adds context about the return format (GeoJSON FeatureCollection with specific properties) and outputs ready for Leaflet/Mapbox, which is beyond what annotations provide. No contradictions.

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

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

The description is front-loaded with purpose, includes a helpful example, and lists parameters. It is not overly verbose but could be slightly more concise. Every sentence adds value.

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

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

Given the three parameters, no output schema, and annotations present, the description adequately covers purpose, usage, return format, and limitations. It does not mention pagination or rate limits, but it is sufficient for typical use.

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

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

Schema coverage is 0%, so the description must compensate. It documents two parameters (carrier and route_type) with allowed values, adding meaning. However, it omits the third parameter 'include_sources' (boolean), which is incomplete. Partial compensation.

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

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

The description clearly states the tool's purpose: scoring fiber depth, mapping routes, and assessing dark-fiber availability. It gives a concrete example and distinguishes from sibling tools like get_facility and analyze_site, making the purpose unambiguous.

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

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

The description explicitly specifies when to use the tool (scoring, mapping, assessing) and when not to (use get_facility for single facility, analyze_site for IX scores). The example further clarifies usage context.

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

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

Annotations have readOnlyHint=true, consistent with read operation. Description adds behavior: lat/lon ranges, radius defaults and range, expected return fields including score, near_net_bucket, carrier_count, etc. No contradictions.

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

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

Single paragraph, well-structured: starts with purpose, gives example, describes parameters, lists return fields, and ends with exclusions. Every sentence adds value; no waste.

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

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

No output schema, but description enumerates all return fields (score, near_net_bucket, nearest_carrier_km, carrier_count, top_carriers, single_carrier_risk, fiber_coverage_km, verdict_short). Covers use case, limitations, and sibling tools. Complete for the tool's complexity.

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

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

Schema coverage 0%; description compensates fully: explains lat (-90..90), lon (-180..180), radius_km (default 50, range 5-200). Provides example call with values. Adds meaning beyond 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?

States specific verb and resource: get FIBER-READINESS for one parcel/site with lat/lon. Lists key outputs (near-net distance, carrier count, single-carrier risk). Clearly distinguishes from siblings: get_fiber_intel for routes, analyze_site for multi-factor scores.

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

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

Explicitly states when to use: when needing fiber-readiness verdict for a single site. Provides an example query and parameters. Also specifies when NOT to use: for mapping routes (use get_fiber_intel) or full site suitability (use analyze_site).

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, indicating a safe read operation. The description reinforces this by detailing the return structure and data fields, adding behavioral context. It does not contradict annotations and provides transparency about the output format, though it could mention any rate limits or authentication needs.

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

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

The description is front-loaded with a clear purpose statement and then provides details in a structured manner. It is somewhat lengthy but each sentence adds value, efficiently covering purpose, usage, parameters, and return structure.

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

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

Given no output schema, the description thoroughly explains the return object structure, including nested fields like scenarios_usd_per_mwh. It covers all necessary context for a data retrieval tool, and the 0 required parameters and simple parameter types mean no gaps remain.

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

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

With 0% schema description coverage, the description fully compensates by explaining the market parameter expects a slug (with examples like 'northern-virginia') and the heat_rate_btu_per_kwh parameter is optional for custom scenarios. This adds significant meaning beyond the bare schema types.

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

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

The description clearly states it provides behind-the-meter gas economics for US data-center markets, listing specific outputs like Henry Hub spot, basis differential, and levelized costs. It explicitly differentiates from sibling tools by noting what not to use it for (e.g., electricity grid fuel mix via get_grid_data, per-state gas suitability via get_gas_index), leaving no ambiguity about its purpose.

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

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

The description provides explicit when-to-use (BTM developer comparing against PPA) and when-not-to-use guidance, including clear alternatives (get_grid_data, get_gas_index). It also mentions the tool pairs with get_gas_index, offering comprehensive usage direction.

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, but the description adds substantial behavioral context: it returns a composite score, sub-scores, pipeline count, operators, verdict, and attribution requirements. It also explains the two modes of operation (with or without state).

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 detailed but front-loaded with the core purpose and parameter behavior. Each sentence adds value, though it is somewhat verbose. Could be slightly more concise without loss of clarity.

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

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

Given no output schema, the description thoroughly explains the return format (composite scores, sub-scores, verdict) and covers both parameter use cases. It is complete enough for agents to understand the tool's behavior and output.

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 0% description coverage, but the description compensates by explaining the state parameter (2-letter code, e.g., TX) and what it returns, and that omitting state gives national ranking with optional limit. This adds meaning 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 returns the Data Center Gas Index (DCGI), a per-state natural-gas suitability score for data centers. It distinguishes from sibling tools by explicitly saying not to use for electricity grid or live gas pricing, and naming alternative tools.

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

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

The description explicitly states when to use (for gas suitability) and when not to use (for electricity grid, power headroom, live gas pricing), naming alternatives (get_grid_data, get_grid_intelligence, get_energy_prices). It also provides an example call.

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?

Description discloses that it is read-only (consistent with readOnlyHint=true), describes what is returned, and explicitly states what is omitted ('gas storage / LNG / firm pipeline capacity are deliberately OMITTED'). Adds 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?

Description is long but well-structured, front-loading the purpose and then detailing return fields. However, some details about the return object could be streamlined if an output schema existed. Slightly verbose but clear.

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

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

Given no output schema and two parameters with no schema descriptions, the description provides extensive information about return data and constraints. However, it fails to explain the 'state' parameter, which is a notable incompleteness.

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

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

Input schema has two parameters (state and region) with no descriptions. Description only explains the 'region' parameter as taking a US state code or name, but does not mention or explain the 'state' parameter, leaving ambiguity. With 0% schema coverage, this is a significant gap.

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

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

Description clearly states the tool is for gas-fired or behind-the-meter power economics for data centers in US states, lists the data it fuses, and distinguishes from siblings like get_grid_intelligence and get_gas_index.

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

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

Explicitly states when to use ('Use when a human asks about...') and when not to ('Do NOT use for electricity grid headroom (use get_grid_intelligence) or the DCGI score alone (use get_gas_index).').

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. Description adds that data is raw real-time telemetry for one ISO, covering scope and data freshness. No contradictions. Slightly limited in describing return format or latency.

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

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

Single paragraph but front-loaded with purpose, followed by boundaries and alternatives. Efficient but could be broken into clearer sections. 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 3 parameters (none required, no enums, no output schema), the description covers purpose, usage boundaries, and alternatives adequately. Missing explicit parameter descriptions for metric and period, but overall sufficient for tool selection.

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

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

Schema has 3 parameters with 0% description coverage. Description only partially explains ISO (with example) but does not explain metric or period parameters. Fails to compensate for missing schema descriptions.

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

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

Clearly states it provides real-time electricity grid data for 7 US ISOs, listing specific data types (fuel mix, demand, 24h demand curve). It explicitly distinguishes from sibling tools by stating what not to use it for and naming alternatives.

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

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

Provides explicit usage context: when to use (for real-time grid data for US ISOs) and when not to use (for power-availability, interconnection queue, retail pricing), with direct references to alternative tools (get_grid_intelligence, get_energy_prices).

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 readOnlyHint=true, consistent with a query tool. The description adds behavioral context: explains that for balancing authorities, return fields are generation mix only; mentions that demand, headroom, queue depth remain ISO-level for the 7 ISOs. 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?

Description is front-loaded with purpose and example, then details parameters and return fields, then exclusions. It is fairly long but well-structured. Could be slightly more concise without losing essential context.

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 (3 parameters, rich output, no output schema), the description provides comprehensive coverage: usage example, parameter details, valid values, return fields list, and exclusions. However, it misses explicit error handling or edge cases.

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

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

Schema covers 3 parameters with 0% description coverage. The description only details region_id, including aliases and valid values. It mentions that iso and region are accepted as aliases, but the schema shows them as separate properties, leading to ambiguity. The description partially compensates but doesn't fully clarify all parameters.

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

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

The description clearly states the tool serves to answer questions about grid capacity and interconnection queues for a single ISO or balancing authority. It uses specific verbs like 'get grid-headroom + interconnection-queue brief' and distinguishes from siblings like compare_isos and get_grid_scoreboard.

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 when to use (e.g., 'Use when a user asks...') and explicitly mentions what not to use (avoid comparing ISOs, use compare_isos instead; avoid global ranking, use get_grid_scoreboard). However, it doesn't cover other potential misuse cases.

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 provide readOnlyHint=true; description adds data sources (EIA, Elexon, ENTSO-E, AEMO), notes AU is unranked due to data limitations, and mentions attribution (CC-BY-4.0). No contradictions.

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

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

Description is front-loaded with core purpose, then provides detailed context. Each sentence adds value; not overly verbose. Appropriate length for the 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, but description covers return values (percentages, mix, demand), explains AU unranked, lists sources. Very complete for a zero-parameter 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?

No parameters exist. Schema coverage is 100% (no params). Baseline for zero parameters is 4; description adds no param info (unnecessary).

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 'Live GLOBAL grid scoreboard' and lists regions, specifying it returns renewable %, gas %, fuel mix, demand. It distinguishes from siblings compare_isos (pairwise) and get_grid_data (single ISO).

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

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

Explicitly tells when to use this tool: 'One call answers "which grid worldwide is greenest, or most gas-reliant, for siting a data center?" — vs compare_isos (pairwise) or get_grid_data (single ISO).' Also ends with 'Try: get_grid_scoreboard.'

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, so the safety profile is covered. The description adds context: it returns raw nearby assets joined to HIFLD/EIA datasets, and includes a caution about not using for site-suitability. It could have mentioned pagination or limits, but it's not contradictory and adds value.

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

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

The description is concise, front-loads the purpose, includes a helpful example, and a clear warning. Every sentence adds value; no fluff.

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

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

Given the tool has 6 parameters and no output schema, the description covers the main purpose and usage well, but lacks details on the output format beyond mentioning distance and capacity. It also doesn't describe default values, error cases, or behavior of all parameters. Adequate but with room for improvement.

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

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

The schema has 0% description coverage for 6 parameters. The description mentions lat, lon, and radius_km in the example, and voltage is implied but not explicitly described. Parameters like layer, limit, and min_voltage_kv are not explained at all. The description partially compensates but leaves significant gaps.

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

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

The description clearly states it returns nearby infrastructure for a location, listing specific asset types (substations, transmission lines, gas pipelines, power plants) and provides an example call. It distinguishes itself from the sibling tool analyze_site by explicitly saying not to use it for a site-suitability verdict.

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

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

The description gives explicit usage guidance: it provides an example call and warns against using it for a single scored site-suitability verdict, directing to the sibling tool analyze_site. This clarifies when to use and when not to use the tool.

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

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

Annotations already declare readOnlyHint=true. The description adds that the tool is real-time and details return components (index value, percentile, trends). Although it doesn't mention rate limits or specifics about data freshness, it provides sufficient context for a read-only query.

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

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

The description is concise: two sentences plus a usage example. It front-loads the purpose, uses active voice, and every sentence adds value. No redundant information.

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

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

Given no parameters and no output schema, the description covers the tool's input, output, and relation to siblings. It could mention data freshness or update frequency, but the provided details are sufficient for an agent to use the tool correctly.

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

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

The input schema has no parameters, so schema coverage is 100% by default. The description includes an example with 'market=northern-virginia', which is not part of the schema and could mislead. Since no parameters exist, the description does not need to add parameter info, but the example is inconsistent with 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 specifies the tool returns a composite market health score (0-100) and lists underlying components. It explicitly differentiates from siblings like get_market_intel and rank_markets, making the purpose very clear.

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

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

The description provides explicit guidance: use for a single market's composite health, avoid for full metric set (get_market_intel) or ranking (rank_markets). Also includes a usage example with a market parameter.

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 the description confirms it's a snapshot, adding details like sources (ERCOT GIS, etc.) and specific fields (queued_load_total_gw, queued_load_data_center_gw). It also notes provenance in top_subregions. However, it does not explicitly state what happens when no 'iso' parameter is provided (presumably returns all ISOs), so there is a minor gap.

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 longer than ideal but efficiently front-loaded with main purpose, followed by special ERCOT detail, then usage guidelines. Every sentence adds value; no redundant information. Could be slightly more terse, but acceptable for the 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?

Despite no output schema, the description covers return values: queued_load_total_gw, queued_load_data_center_gw (for ERCOT, with specific numbers), and top_subregions with provenance. It also notes that other ISOs return null for data_center_gw. For a simple single-parameter tool, this is sufficient 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 0%, but the description compensates by explaining the 'iso' parameter: 'Pass iso=ERCOT (or any of 7) to drill down.' It lists the 7 ISOs in the text (ERCOT, PJM, MISO, SPP, CAISO, NYISO, ISO-NE), effectively providing enumeration. It does not specify optionality explicitly, but the schema shows no required parameters.

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

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

The description clearly states the tool returns an ISO interconnection queue snapshot with generation capacity and optionally ERCOT large-load data. It distinguishes itself from siblings get_grid_intelligence (single-site time-to-power) and grid_transition_radar (forward-looking emergence).

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

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

Explicitly states when to use: 'Use for queue-depth site-selection and AI/data-center-load saturation intel.' And when not to use: 'Do NOT use for a single-site time-to-power read (use get_grid_intelligence) or forward-looking emergence (use grid_transition_radar).' Alternatives are named.

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

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

The description discloses that the tool includes a narrative block that must be quoted with attribution (CC-BY-4.0), adding context beyond the readOnlyHint annotation. No contradictions.

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

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

The description is concise yet fully informative, front-loading the key outputs and adding usage guidance. Every sentence adds value with no redundancy.

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

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

Given one parameter and no output schema, the description covers all output fields and usage context. Minor gap in parameter explanation, but overall complete for the tool's purpose.

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

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

The single parameter 'market_slug' has no schema description and the tool description does not explain its format or provide examples. With 0% schema coverage, the description should compensate but falls short.

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 specifies the tool provides DCPI rank for a single market with scores and a narrative block. It explicitly distinguishes from sibling tools like rank_markets and compare_isos, clarifying its unique scope.

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

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

The description states when to use ('should I build here?') and when not to use (ranking many markets or comparing ISOs), and names alternative tools (rank_markets, compare_isos).

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 readOnlyHint=true, consistent with description. Description adds useful context: return fields, parameter format (market slug), and that it's for a single market. No contradictions.

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

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

Very concise: two sentences plus return list. Front-loaded with purpose. Every sentence adds value.

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

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

The main use case is well-covered, but optional parameters (metric, period, compare_to) are not explained. No output schema, but return fields are fully listed. Needs more on how to use the other parameters.

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

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

Only one of four parameters (market) is described in detail with examples. Metric, period, and compare_to are not explained. Schema has 0% description coverage, so description should compensate more.

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

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

The description clearly states the tool retrieves data for a single data-center market, with specific metrics. It distinguishes from siblings like rank_markets and get_facility, and provides a concrete example.

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

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

Explicitly says when to use ('when user asks about ONE market') and when not to use (not for ranking or single facility). Provides clear 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?

Adds value beyond readOnlyHint annotation by detailing refresh frequency (30 min), sources, returned fields, and entity extraction. No behavioral traits 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?

Concise yet informative; sentences are purposeful. Front-loaded with core purpose, then details, example, and exclusions. 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?

Explains return values (title, summary, source, published_at, entities) despite no output schema. Covers refresh frequency and sources. Lacks explicit mention of pagination or behavior for large limit, but overall adequate.

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

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

Schema coverage is 0%, so description must compensate. Mentions only 'topic' (category) parameter in example and filter list. Does not explain query, source, date ranges, min_relevance, or limit behavior beyond the example. Partial 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?

Clearly states it returns curated data center industry news from 40+ trade sources, refreshed every 30 min, with specific fields (title, summary, source, published_at, entities). Distinguishes from siblings by specifying it's not for structured M&A deal data or construction pipeline.

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

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

Explicitly says 'Industry news only' and provides when-not-to-use with specific alternatives (list_transactions, get_pipeline). Includes an example query and mentions filtering by topic.

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 include readOnlyHint: true, which is consistent with a read-only pipeline query. The description adds behavioral context by specifying the return structure (projects with fields like name, operator, capacity_mw, etc.) and that it returns a generated_at timestamp. No contradictions.

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

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

The description is relatively long but well-structured, front-loading the purpose and example. Every sentence adds value, and it avoids redundancy. It could be slightly more concise, but it is efficient for an AI agent.

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

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

With 7 parameters, no required ones, and no output schema, the description provides comprehensive explanations for all parameters, the return structure, usage context, and exclusions (not for operational or deal flow). It leaves no significant gaps for an AI agent to make correct decisions.

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

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

Schema description coverage is 0%, so the description must compensate. It explains each parameter with examples and constraints: status enum values, operator examples, country ISO-2 format, min_capacity_mw example, expected_completion_before ISO date, and limit/offset for pagination. It also describes the return structure. A minor gap: does not specify if limit/offset have defaults, but overall it adds significant value beyond the schema.

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

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

The description clearly states the tool provides a forward-looking construction pipeline (540+ projects, 369 GW) and answers user queries about what is being built, announced, or permitted. It distinguishes from sibling tools by naming alternatives like search_facilities and list_transactions.

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

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

Explicitly says 'Use when a user asks "what is being built / announced / permitted"' and provides a detailed example. It also states 'Do NOT use for already-operational facilities (use search_facilities) or for the M&A deal flow (use list_transactions)', giving clear when-not-to-use guidance.

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

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

Annotations set readOnlyHint=true, confirming non-destructive behavior. Description adds detail on data breadth (nationwide, including non-ISO regions), return contents (summary, largest projects), and status codes, enhancing transparency without contradiction.

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

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

Description is front-loaded with purpose, then details data contents, filtering options, and exclusions. Each sentence adds value, though could be slightly more compact. Structure is logical and easy to scan.

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

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

Given no output schema, description comprehensively covers return format (summary with MW mix, largest projects), data source (EIA-860M), geographic coverage, and filtering. Also differentiates from numerous siblings effectively.

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

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

Despite 0% schema description coverage, description explains most parameters: state (2-letter code), ba (balancing-authority/ISO code), status (with code mappings P/L/T, U/V, TS), and min_mw. Only 'limit' is not described, but overall adds substantial meaning beyond schema.

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

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

Description clearly states 'Use when a user asks WHERE NEW POWER GENERATION is coming online', specifies the resource (forward supply pipeline), and distinguishes from siblings by explicitly naming alternatives (get_grid_intelligence, get_grid_data, get_pipeline) and their contexts.

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 when-to-use (e.g., 'how much new generation is planned in Virginia...'), examples ('Try: get_power_pipeline state=VA'), and when-not-to-use (already-operating capacity, data-center construction) with alternative tool names.

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

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

Annotations indicate readOnlyHint=true, and description adds details about return structure and data source. No contradictions, but could mention data freshness or rate limits.

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

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

Four efficient sentences with example query, front-loaded purpose, and no redundant information. Each sentence adds value.

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

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

Covers all necessary aspects: use cases, parameters, return structure, data source, and exclusions. No output schema needed as description enumerates return fields.

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

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

Despite 0% schema description coverage, the description fully explains each parameter: energy_type enum values, state format, optional lat/lon proximity, and omissions.

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

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

The description clearly states the tool's purpose: siting renewable data centers, sizing PPAs, or assessing RE100/24-7-CFE feasibility. It distinguishes from siblings by explicitly excluding live grid and non-US use cases.

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 when-to-use and when-not-to-use guidance, including alternative tools (get_grid_data, get_grid_scoreboard) and specific use cases.

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 provide readOnlyHint, so the description adds value beyond it by detailing return structure, citation requirement, and scope (one US state). Could mention data freshness or errors, but overall strong.

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

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

Description is front-loaded with use case, example, parameter, return structure, and exclusions. Slightly long but every sentence is valuable; could be tighter.

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 provides detailed return structure. Covers parameter, usage boundaries, and attribution. Adequate for a simple read tool with one required parameter.

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

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

Schema coverage is 0% but description explains 'state (2-letter US code; required)' and includes example usage. Adds meaning beyond bare schema. Minor inconsistency: description says required but schema doesn't enforce it.

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

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

The description clearly states the tool returns data-center tax incentive packages by US state. It uses specific verb+resource ('get tax incentives') and distinguishes from siblings like analyze_site and rank_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?

The description explicitly says when to use ('when a user asks what tax breaks does <state> give data centers?') and when not to use (not for combined multi-factor site read or ranking markets), naming 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?

Discloses data sources (USGS, Drought Monitor), free tier, and return fields. No contradiction with annotations (readOnlyHint=true). Adds context beyond 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 examples and no unnecessary information. Every sentence adds value, making it easy for an agent to parse.

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

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

Given no output schema, the description covers return fields and data joins. With 3 optional parameters and clear usage, it 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?

Adds significant meaning beyond schema: explains lat/lon range, state/county format, and that lat/lon gives most precise read. Schema coverage is 0%, but description compensates fully.

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

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

The description clearly states it's for scoring a US site for cooling-water sustainability, with a specific example and parameter options. It distinguishes itself from siblings like get_infrastructure and analyze_site by specifying its scope.

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

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

Explicitly tells when to use (water factor only) and when not to (for infrastructure or multi-factor site analysis). Also explains parameter selection (lat+lon for precision, state/county as 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 readOnlyHint=true, and the description aligns by describing a read-only radar report. It adds behavioral details: returns BUILD verdict, excess-power headroom, short time-to-power, ISO rollup, grid-headroom leaderboard, and with paid key a transition thesis. No contradictions.

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

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

The description is well-structured with a bold opening phrase and clear segmentation, though slightly verbose. Every sentence adds value, and it front-loads the core purpose.

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

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

Given no output schema, the description adequately explains the return components and conditions (paid key). It covers usage boundaries and provides an example, making it complete for a non-mutating report tool.

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

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

Schema description coverage is 0%, yet the description does not explain all parameters. It only implies max_months via the example, but limit is not mentioned. The description adds little to no semantic meaning beyond the schema's type information.

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 is highly specific: 'Forward-looking "where is the next hyperscale-friendly grid emerging" radar.' It clearly states the tool returns US markets + ISOs, a rollup, and a leaderboard, and explicitly distinguishes from retrospective reports and sibling tools like get_interconnection_queue and rank_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?

The description provides explicit when-to-use and when-not-to-use guidance. It contrasts with 'where capacity landed' reports and warns against using for current ISO queue (use get_interconnection_queue) or present-day market ranking (use rank_markets). It also gives an example invocation: 'grid_transition_radar max_months=24'.

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. The description adds valuable behavioral context: live feed with 10-min refresh, source (dchub news pipeline), extraction method (regex for $ and MW), and classification by actor. No contradictions.

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

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

The description is front-loaded with the tool's core purpose and key details, and every sentence adds value: purpose, scope, source, extraction, refresh, and usage guidance. It is appropriately sized for the tool's 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?

The description covers purpose, usage, behavioral context, and sibling differentiation well. However, it lacks any description of the output format or the 'limit' parameter, which would be useful for complete understanding. The absence of an output schema increases the burden on the description.

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

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

The input schema has one optional integer parameter 'limit' with no description, and the schema_description_coverage is 0%. The description does not explain this parameter, leaving the agent to guess its purpose (likely pagination). Since the description must compensate for low coverage, this is a significant gap.

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

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

The description clearly identifies the tool as a live feed tracker for hyperscaler AI deals, specifying key players and deal types. It distinguishes itself from sibling tools like list_transactions and deal_autopsy by explicitly stating what it is and is not for.

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

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

The description provides explicit when-to-use (tracking AI capex events, capacity announcements, competitive intel) and when-not-to-use guidance (historical M&A comp set, single-deal teardown), directly naming alternative tools (list_transactions, deal_autopsy). It also gives context on typical deal velocity ($1B+/week).

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 set readOnlyHint=true, and the description adds behavioral context like 'returns an array of saved sites with details' and 'persistent shortlist built by save_site', consistent with read-only operation.

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

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

Description is front-loaded with purpose and examples. Minor verbosity ('FREE with a key') but overall efficient and well-structured.

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

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

Given no output schema, the description fully explains return format and relates to save_site, providing complete context for a simple list tool.

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

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

The tool has zero parameters, and schema coverage is 100%. The description adds value by detailing the return fields (name, market, lat/lon, etc.), which compensates for absence of params.

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 'Use when a user asks to see or review their saved DC Hub shortlist', identifies the resource as 'saved sites', provides clear examples, and distinguishes from sibling tools save_site and export_dataset.

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 when-to-use context with examples, and explicitly states what not to do and which tools to use instead: 'Do NOT use to add a site (use save_site) or to download the list as a file (use export_dataset)'.

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 readOnlyHint=true, and the description adds behavioral context like the dataset size, date range, and that many deals are undisclosed. No contradictions.

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

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

The description is a single, dense paragraph that efficiently conveys key information, example, and exclusions without unnecessary text.

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

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

Despite no output schema, the description fully explains return fields and filter options, making it self-contained for understanding tool behavior.

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

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

Schema coverage is 0%, but description mentions filters for year, min_value_usd, region, buyer, and target. However, it does not explain limit, offset, date range fields, or other schema parameters, leaving gaps.

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

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

The description clearly states the tool lists M&A and capital transactions in the data center sector, specifies the number of deals, date range, and return fields. It distinguishes from sibling tools like hyperscaler_deals and deal_autopsy.

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

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

Explicitly provides when to use (broad M&A flow with filters) and when not to use (hyperscaler deals or deal autopsy), and gives a direct example call with parameters.

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

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

Discloses indicative nature and limitations: 'INDICATIVE auto-routed road corridors — NOT engineered alignments; subject to survey, DBYD and carrier confirmation.' Mentions return values including cost and diversity. No contradiction with annotations (readOnlyHint: true, which is consistent with a planning tool).

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

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

Description is well-structured: purpose first, then example, parameter list, returns, caveats, exclusions. Slightly long but every sentence adds value. Could be tightened, but clear.

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

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

For a tool with no output schema, the description adequately explains return values (length, geometry, diversity, cost). Addresses limitations and alternative tools. Complete for its 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?

Despite 0% schema description coverage, the description explains all 5 parameters: from (lat,lng or address), to (lat,lng or address), n (1-6, default 4), fibre (720F/1440F), bore_m (optional integer). Adds meaningful type and format info beyond 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 states a specific verb ('plan') and resource ('fibre lead-in routes'), with clear context: from a data-center site to a carrier hotel/POP. It explicitly distinguishes from sibling tools by stating not to use for site suitability (use analyze_site) or fiber-provider footprints (use get_fiber_intel).

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 when-to-use context ('can I get N diverse fibre routes into this site...') and when-not-to-use directives with alternative tool names. Includes a concrete example with parameters.

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 include readOnlyHint=true, matching the read-only nature. Description adds output structure details (fields in returned objects) and constraints (300+ market set, generated_at timestamp). No contradiction.

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: purpose, example, parameters, output, boundaries. Slightly verbose but each sentence adds value. Front-loaded with main usage.

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?

Complete for a tool with 4 parameters, no output schema, and many siblings. Output structure fully described, parameters enumerated, and usage boundaries clear.

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 no descriptions (0% coverage), but description fully compensates: lists criteria enum values, region enum values, limits with range (1-50), and explains min_capacity_mw as a floor filter. Also provides a concrete 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 clearly defines the tool as ranking markets across 300+ set, using specific verbs and resource. It distinguishes from siblings like get_market_intel (deep read) and analyze_site (lat/lon scoring).

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 when-to-use: 'top N markets for X' and when-not: 'Do NOT use for a deep read on ONE market' or 'scoring a specific lat/lon'. Also provides an example query.

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

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

Discloses key behaviors: never returns key over wire, sends via email, confirmation is uniform for enumeration safety. Adds significant context beyond annotations (readOnlyHint=false, destructiveHint=false).

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?

Compact and front-loaded. Every sentence adds value: purpose, input, behavior, usage guidance, return. 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 one parameter and no output schema, description fully covers what the tool does, how to use it, and what to expect. Includes security and enumeration-safety details.

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

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

Single parameter 'email' is described as the human's bound email and required. Schema has 0% coverage, so description compensates well but could add format or validation details.

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

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

Clearly states it recovers a lost DC Hub key by emailing it to the bound address. Distinguishes from sibling tools like bind_email or claim_free_key by specifying the recovery context.

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

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

Explicitly says use when human had a key, lost it, and knows the bound email. Implicitly warns against use for other purposes, but could be more explicit about when not to use.

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 write operation (readOnlyHint=false, destructiveHint=false). Description adds that it WRITES one site, is free, returns an id, and builds a persistent shortlist. No contradiction with annotations.

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

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

Single paragraph front-loads purpose, then lists parameters, usage flow, and exclusions. Every sentence adds value, but could be slightly more compact.

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 save tool with 7 parameters and no output schema, the description covers purpose, parameters, usage flow, what it does (writes, returns id), exclusions, and provides an example. It is complete and actionable.

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 0% description coverage. Description lists all seven parameters and explains the required lat/lon format with an example. It adds meaning beyond schema, though 'market' and 'state' are not further defined.

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 saves a candidate data-center site to track it across sessions. It uses specific verbs ('save') and resource ('site'), and distinguishes from siblings by listing what not to use (list_saved_sites, export_dataset, score_facility).

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

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

Explicitly states when to use (save a site with lat/lon) and when not to (reading, downloading, scoring). Provides an example call and a prerequisite (claim_free_key if no key). Recommends a follow-up action (set_site_alert).

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

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

The description discloses the tool's read-only nature, matching the readOnlyHint annotation. It details the return values (composite score, tier_classification, peer comparison, per-dimension detail) and the weighting options, providing 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?

The description is concisely structured: purpose first, then example, parameter details, return value summary, and exclusions. Every sentence adds value, and the front-loading of purpose aids quick understanding.

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

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

Given the simplicity (2 params, no output schema), the description provides complete context: what the tool does, when to use it, how to use it (with example), parameter semantics, return values, and explicit exclusions. No gaps are evident.

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

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

With 0% schema description coverage, the description adds essential meaning. It explains the weighting parameter's enum values and default, and indicates that facility_id or name can be used, supplementing the schema's limited property names.

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

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

The description clearly states the tool's purpose: scoring one existing facility across seven specific dimensions. It uses a specific verb ('score') and resource ('facility'), and distinguishes from sibling tools by listing alternatives (analyze_site, compare_sites, find_alternatives).

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

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

The description explicitly tells when to use the tool ('when a user wants an independent 0-100 grade for ONE existing facility') and provides explicit exclusions with alternative tools, e.g., 'Do NOT use for a raw lat/lon parcel (use analyze_site), to compare 2 or more sites (use compare_sites), or to find similar sites (use find_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 only include readOnlyHint=true. Description adds behavioral context: scope (global existing facilities), returned fields, and filter dimensions. No contradiction. More detail on pagination or performance would elevate further.

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

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

Three sentences: purpose, example, usage guidelines. No redundancy. Every sentence adds value. Efficiently packed without being verbose.

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

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

Given 10 parameters with 0% schema coverage, no output schema, and no nested objects, description provides solid overview and example. Missing details on error handling, pagination, and all parameters, but covers core use case well.

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

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

Schema coverage is 0%, but description lists several filter dimensions (country, state, market, capacity, operator, fiber, status, DCPI verdict) and gives an example using country, state, min_mw, status. However, parameters like city, tier, limit, query, offset, max_capacity_mw are not explicitly explained, leaving gaps.

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

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

Description explicitly states it searches 21,000+ global data center facilities with specific filters. Lists return fields and distinguishes from sibling tools (get_pipeline, get_facility). Highly specific verb+resource+scope.

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

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

Provides example query and explicitly states when NOT to use (for pipeline or full facility). Names alternative tools directly, giving clear context for tool 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 are minimal (readOnlyHint=false, destructiveHint=false). The description adds behavioral context: it's a subscription (mutation) for future notifications, not a query. Mentions tier restrictions (free email vs paid webhook) and that email destination is forced to bound address. 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?

The description is a single paragraph that front-loads the main purpose and includes essential details. It is efficient but could benefit from clearer structure (e.g., separating usage constraints from examples). The example is helpful but adds length.

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

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

Given no output schema, the description explains the subscription action and notification channel but lacks details on what the alert contains, how to manage/delete alerts, or idempotency. It covers usage well but misses some operational context needed for complete understanding.

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

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

Schema coverage is 0% (no descriptions in schema). Description compensates by explaining channel values ('email', 'webhook') and destination format (URL for webhook). Market parameter is illustrated via example ('northern-virginia') but not fully specified; however, the example and context provide reasonable guidance. Significant value added over raw schema.

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

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

The description clearly states the tool subscribes to movement alerts for a DCPI market, with a specific verb ('Subscribe') and resource ('DCPI market movement alerts'). It distinguishes itself from the sibling tool get_market_dcpi_rank by explicitly noting this is for subscribing to future movements, not reading current 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 when-to-use instructions: 'Subscribe to movement alerts' vs 'Do NOT use to read a market right now (use get_market_dcpi_rank)'. Also notes prerequisites (bind_email first) and differentiates free vs Pro usage (email vs webhook). Clear alternatives and context.

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

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

Discloses behavioral traits beyond annotations: free vs pro email handling, that the alert is delivered to bound email on free tier, and that it returns {ok, alert_id, message}. No contradictions with annotations (readOnlyHint=false, destructiveHint=false).

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

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

Description is well-structured: starts with purpose, then usage guidelines, then parameter details, then example. Slightly verbose but every sentence adds value. Could be trimmed slightly, but overall efficient.

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

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

Given 4 parameters, no output schema, and complexity of tiers, the description covers all necessary context: prerequisites (bind_email), parameter details, example, return format, and exclusions. Completely adequate for an agent to correctly invoke the tool.

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

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

Despite 0% schema description coverage, the description fully explains all four parameters: saved_site_id (required integer, source), trigger_type (enum with default), threshold (number with default), notify_email (required, bound on free). Adds meaning beyond schema by providing defaults, valid values, and 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?

Description clearly states it arms an email watch on a saved site, listing triggers (dcpi_change, capacity_change, new_facility_nearby). It distinguishes from siblings save_site (saving a new site) and set_market_alert (watching a whole market), ensuring the agent knows exactly what the tool does.

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

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

Explicitly tells when to use: after calling save_site, with prerequisites (bind_email for free tier). Also states when not to use: for whole markets or saving new sites, naming specific alternative tools. Provides a step-by-step loop and an example invocation.

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 provide readOnlyHint=true, and the description adds behavioral context: it describes the full flow (find->rank->shortlist->verdict), notes the paid key feature for synthesis, and lists output components (DCPI verdict, excess-power headroom, etc.). No contradictions.

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

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

The description is moderately long but well-structured: purpose, output outline, example, usage exclusions. Each sentence adds value. Slightly verbose but overall efficient.

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

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

Given the tool has 5 parameters, no output schema, and only readOnlyHint annotation, the description covers main inputs and outputs adequately. It explains the return values and flow, providing enough context for an agent to decide on 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 description coverage is 0%, so the description should compensate. It explains the roles of capacity_mw, region, and max_months via the example and context, but limit and verdict remain unexplained. Partial coverage, insufficient for full understanding.

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

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

The description states a specific verb+resource: 'Guided end-to-end data-center site selection.' It differentiates from siblings by explicitly mentioning when not to use it (e.g., use analyze_site for a single parcel, use get_dchub_recommendation for open-ended questions), making the purpose clear and distinct.

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

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

The description provides explicit when-to-use guidelines (capacity target, geography, deadline), when-not-to-use (single parcel, open-ended questions), and includes an example invocation. This fully informs the agent about appropriate usage conditions.

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

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

The description explains the double opt-in process, the confirmation email, and that no marketing flag is set. This adds behavioral context beyond the annotations (readOnlyHint=false, destructiveHint=false), clarifying it's a write operation but not destructive.

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

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

The description is verbose with promotional language and multiple clauses. While it captures key points, it could be more concise. Structure is somewhat stream-of-consciousness; important info like parameters is embedded mid-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?

The description covers the return format ({ok, sent, message}) and explains the opt-in flow. For a subscription tool with no output schema, this is fairly complete, but it lacks error handling or invalid email scenarios.

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

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

The description states 'email (required)' but the input schema has no 'required' field, making email technically optional per schema. This contradicts the schema, reducing clarity. For source, it adds 'optional tag' but no format or allowed values. Despite low schema coverage (0%), the description provides minimal and partially inaccurate parameter info.

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 subscribes a human to a weekly digest with specific content (DCPI movers, new facilities, etc.). The verb 'subscribe' and resource 'digest' are explicit. It also distinguishes itself from the alternative of hand-building the API call.

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

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

The description explicitly says 'Only call once your human shares their email and wants a weekly email.' It also recommends preferring this tool over hand-building the POST request, providing clear guidance on when to use it and an alternative.

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

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

Describes the unlock process, checkout links, session binding, and that the next call returns full data. No annotation contradictions; adds context beyond the safety flags.

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?

Information-dense and front-loaded with purpose, then covers usage, pricing, alternatives, param, and return. Every sentence adds value, though slightly lengthy.

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

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

Covers return object, follow-up behavior, pricing tiers, and session binding, making the tool's impact fully understandable 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?

Despite 0% schema coverage, the description explains the optional `reason` parameter's purpose ('what you were trying to do, so your human sees why it matters'), adding value.

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

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

The description clearly states the verb 'Unlock' and resource 'DC Hub's full depth', and distinguishes from sibling tool `claim_free_key` by specifying when to use each.

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

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

Explicitly defines when to call (preview, locked tool, or human wants full data) and provides an alternative (`claim_free_key`) for the free tier.

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

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

The description reveals that the tool returns 'honest, source-verified differentiators' with proof URLs and citation lines, which adds behavioral context beyond the annotations' readOnlyHint. No contradiction with annotations.

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

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

The description is thorough and well-structured with clear sections, though it is somewhat lengthy. It front-loads the use case and is mostly efficient, but a few phrases could be tightened without losing value.

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

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

For a comparison tool with 21+ competitors and no output schema, the description sufficiently details the return content (differentiators, proof URLs, citation, head-to-head pages) and usage constraints. It provides complete guidance for an agent to use the tool correctly.

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

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

The input schema has one optional 'competitor' parameter with no description. The tool's description adds full meaning: 'Optional: competitor=<name> for that vendor's direct comparison-page link.' This compensates for the low schema description coverage of 0%.

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

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

The description clearly states that the tool is used to compare DC Hub to other data-center data sources and answer positioning questions. It specifies the exact resources (comparison vendors) and distinguishes itself from sibling 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?

The description explicitly tells when to use the tool ('Use when a human asks how DC Hub compares...') and when not to use it ('Do NOT use to query infrastructure data itself'), with reference to alternatives (the data tools).

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