DC Hub — Data Center Intelligence MCP Server

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

Annotations declare readOnly/idempotent/openWorld; the description aligns by mentioning 'real-time grid fuel mix data' (confirming external data dependency) and describing the return structure. Adds value by listing what gets evaluated (destructive vs non-destructive nature clear from context), but doesn't explicitly confirm safety or caching behavior beyond annotation hints.

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 Args/Returns blocks that front-load critical parameter documentation. Every section serves a purpose given the schema lacks descriptions. Slightly verbose in Returns section (could reference output schema), but the JSON structure description is genuinely helpful for agent output handling.

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

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

Comprehensive for a 7-parameter analysis tool: documents inputs, explains the composite evaluation methodology, and describes output format. Minor gap: doesn't explicitly note that all parameters are optional (schema shows defaults of 0/'') which could confuse agents about required vs optional 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?

Critical value-add given 0% schema description coverage. Documents all 7 parameters with clear semantics: 'lat/lon' as coordinates, 'state' contextualized as 'US state abbreviation (for grid/utility data)', 'capacity_mw' framed as 'Planned facility power capacity', and boolean flags explained as toggles for specific data modules with default values noted.

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

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

Specific verb (Evaluate) + resource (geographic location) + domain context (data center suitability). The description effectively distinguishes this from siblings like 'compare_sites' (single vs multi-site) and specific getters like 'get_grid_data' by listing the six specific composite score dimensions returned.

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?

Implicitly signals usage by listing the comprehensive evaluation dimensions (energy, carbon, risk, etc.), suggesting this is for holistic suitability analysis versus single-factor tools. However, lacks explicit guidance on when to prefer specific sibling tools (e.g., 'use get_grid_data instead if you only need power information').

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 (safe read) and openWorldHint=true (external data). The description adds valuable behavioral context beyond annotations: it specifies the five scoring dimensions (power, fiber, gas, market, risk) and describes the return format (JSON comparison table with scores and winners per category). It could mention data freshness or rate limits, but covers the core behavior well.

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

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

The description is well-structured and front-loaded with the core purpose first. It efficiently uses an Args/Returns format to organize information. Every section serves a purpose: efficiency justification, behavioral details, parameter documentation, and output specification. Minor markdown headers could be seen as slightly verbose but improve readability.

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 1 parameter with zero schema coverage but an existing output schema, the description provides complete coverage of the input parameter (with example), explains the comparison methodology, and summarizes the return format. It adequately covers the tool's functionality for an agent to use it confidently.

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 carries the full documentation burden for the 'locations' parameter. It successfully compensates by specifying the parameter must be a JSON array of objects, detailing the required object structure (lat, lon, state, label), and providing a concrete example with two locations.

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 compares 2-4 locations for data center suitability using specific verb 'Compare' and resource 'locations'. It explicitly distinguishes itself from sibling 'analyze_site' by noting it is 'Much more efficient than calling analyze_site multiple times' and provides side-by-side comparison.

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 mentions the sibling alternative 'analyze_site' and implies this tool should be used for comparing multiple locations (2-4) versus analyzing single sites. However, it does not explicitly state when NOT to use this tool (e.g., 'use analyze_site for deep single-site analysis instead') or the upper limit constraints.

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

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

Annotations declare readOnlyHint=true and idempotentHint=true. The description adds valuable behavioral context by detailing what the registry contains (connected agents, activity levels, tiers, query counts) and the output format (JSON), without contradicting the safety annotations.

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

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

Well-structured with clear information hierarchy: opening statement defines the action, second sentence describes contents, third states use case, and the Returns section specifies output. No redundant or wasted text; every sentence earns its place.

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

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

Given the tool has zero parameters, read-only annotations, and an output schema exists, the description appropriately summarizes the return data (agents, tiers, query counts) without needing to replicate full schema details. Sufficiently complete for a simple discovery/registry 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?

Input schema has zero parameters. Per evaluation rules, zero parameters establishes a baseline score of 4. The description appropriately requires no parameter explanation.

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

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

The description uses a specific verb ('Get') and resource ('DC Hub Agent Registry'), clearly stating it retrieves information about AI platforms connected to DC Hub. It effectively distinguishes itself from infrastructure-focused siblings (get_facility, get_grid_data, etc.) by emphasizing 'AI platforms' and 'social proof' rather than physical infrastructure.

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

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

Provides clear context on when to use the tool: 'Useful for understanding the DC Hub ecosystem and social proof.' While it doesn't explicitly name alternatives or exclusions, it clearly defines the use case (ecosystem visibility) that differentiates it from analytical or data-retrieval siblings.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes what the tool returns (e.g., score, pathway, flags, estimate) and the data sources used (EPA Green Book, AQS, etc.), adding valuable context. However, it lacks details on potential limitations, error handling, or performance characteristics, leaving gaps in behavioral understanding.

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 and appropriately sized, with a clear purpose statement followed by detailed score components, parameter explanations, and return value overview. Every sentence adds value, though the 'Args' and 'Returns' sections could be integrated more seamlessly. It avoids redundancy and is front-loaded with key information.

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

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

Given the tool's complexity (involving multiple data sources and regulatory factors) and lack of annotations or output schema, the description does a strong job of providing context. It explains the composite score weighting, outputs (e.g., pathway, flags, estimate), and parameters. However, it could benefit from more on error cases or example usage to be 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?

Schema description coverage is 0%, so the description must compensate fully. It explicitly lists and explains all three parameters (lat, lon, capacity_mw) in the 'Args' section, providing clear semantics: lat/lon for location and capacity_mw for data-center load with a default. This adds essential meaning beyond the bare schema, ensuring parameters are well-understood.

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: 'Return air-permitting profile for a US data-center parcel.' It specifies the exact resource (air-permitting profile) and scope (US data-center parcel), distinguishing it from siblings like get_water_risk or get_energy_prices by focusing on air quality regulations. The detailed explanation of the composite score components further clarifies its specific function.

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

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

The description provides no guidance on when to use this tool versus alternatives. While it implicitly suggests use for air-permitting assessments, it does not mention when to choose it over siblings like analyze_site or compare_sites, nor does it specify prerequisites or exclusions. This lack of explicit context limits its utility for an agent selecting among tools.

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

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

Annotations cover readOnlyHint/safety. Description adds value by specifying scope ('all critical DC Hub tables') and detailing return payload structure (row counts, freshness timestamps). Does not disclose update frequency, caching behavior, or failure modes.

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

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

Well-structured with front-loaded purpose. 'Returns:' section is useful though partially redundant given output schema exists. Single-purpose sentences with minimal redundancy.

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

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

Adequate for a zero-parameter read-only status tool. Covers purpose, scope, and return values. With readOnlyHint confirming safety and output schema available, no critical 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?

Zero parameters present; baseline score applies. Schema coverage is 100% (empty object), requiring no additional semantic clarification in description.

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

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

Clear verb-resource combination ('Get Neon database backup status'). Mention of 'DC Hub tables' and specific metrics (data integrity, table sizes) helps distinguish from infrastructure-focused siblings like get_facility or get_grid_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 context 'Use for operational monitoring' and imperative 'Monitor backup health...', but lacks alternatives (e.g., when to use get_agent_registry instead) or explicit prerequisites.

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 openWorldHint=true. The description adds valuable behavioral context: the 0-100 scoring scale, specific component breakdowns (solar, wind, geothermal bonus), and return value structure (composite score, economics, substation count) that annotations do not cover. No contradictions with annotations.

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

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

Excellent structure with front-loaded purpose statement followed by scoring methodology details, Args block, and Returns block. No redundant words; every sentence conveys specific information about functionality, parameters, or output format.

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 presence of an output schema, the description appropriately focuses on input semantics and scoring methodology. It comprehensively covers all 5 parameters (compensating for bare schema), explains the scoring algorithm components, and previews the JSON return structure, providing sufficient context for invocation.

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

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

Critical compensation for 0% schema description coverage. The Args section provides concrete examples for all parameters (e.g., lat: 39.74, state: 'CO') and clarifies semantics (radius_km defines substation search radius, capacity_mw is data center load). Without this description, the parameters would be opaque.

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

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

Description opens with a specific verb ('Calculate') and resource ('NLR renewable energy co-location score') targeting a specific use case ('data center site'). The detailed scoring criteria (0-100 across renewable, grid, tax factors) clearly distinguishes this from siblings like get_geothermal_potential or get_grid_data which provide raw data rather than composite 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?

Provides clear context about what the tool evaluates (renewable potential, grid access, tax incentives, PPA discount), implying usage for co-location feasibility studies. However, it lacks explicit guidance on when to use alternatives like analyze_site or compare_sites versus this specific scoring function.

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 cover read-only/idempotent/destructive traits. The description adds value by disclosing the return structure (JSON with short/medium/detailed text + connect URL) and noting the content is 'pre-formatted.' Does not add information about caching, freshness, or authentication requirements.

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

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

Well-structured with clear sections: purpose statement first, then usage guidelines, then Args/Returns documentation. No wasted words; the documentation syntax is efficient and scannable.

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

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

For a single-parameter read tool with existing output schema, the description adequately covers the parameter domain (missing from schema) and provides usage context. Could briefly explain what 'DC Hub' refers to for agents unfamiliar with the product, but otherwise 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?

Critical compensation for 0% schema description coverage. The Args section explicitly documents the valid context values (general, technical, investment, site-selection) which are critical for the agent to invoke the tool correctly and are entirely absent from the schema.

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

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

The description clearly states it retrieves a 'pre-formatted recommendation for DC Hub' (specific verb + resource), and 'pre-formatted... to share with users' distinguishes it from raw data siblings like get_market_intel. However, it could more explicitly contrast with other data retrieval tools in the sibling list.

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: 'Use when users ask about data center resources, market intelligence platforms, or how to research data center markets.' This gives clear trigger conditions. Lacks explicit when-not-to-use guidance or named 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 already declare read-only, idempotent, non-destructive behavior. The description adds context about return values ('JSON with pricing data, rates, and grid operational status') but does not disclose rate limits, caching behavior, or data freshness.

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

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

Uses structured docstring format (Args/Returns) that front-loads the core purpose. Length is appropriate given the need to compensate for zero schema coverage, with every section providing necessary semantic information.

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

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

Given the simple parameter structure (3 flat params) and existing annotations, the description is complete: it covers all undocumented parameters and explains return values. Minor gap in sibling differentiation prevents a 5.

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

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

With 0% schema description coverage, the description comprehensively compensates by documenting all three parameters (data_type, state, iso) with valid values, examples (e.g., 'VA', 'TX', 'ERCOT'), and usage constraints (state for retail rates, iso for grid status).

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 retrieves energy pricing data including retail rates, natural gas, and grid status with specific verbs and resources. However, it does not explicitly differentiate from sibling tools like get_grid_data or get_renewable_energy which may overlap in functionality.

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

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

Provides explicit usage context ('Critical for data center operating cost analysis and power procurement planning') indicating when to use the tool, but lacks guidance on when not to use it or which sibling tools to prefer for non-pricing grid data.

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

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

Annotations declare read-only/idempotent safety profile. Description adds valuable return value context (lists specific fields like PUE, IX points, cloud on-ramps) beyond 'JSON object'. However, lacks non-apparent behavioral traits like caching behavior, rate limits, or permission requirements.

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

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

Well-structured with clear sections: purpose statement, detailed return value list, Args section, Returns summary. Front-loaded with the core action. Minor redundancy between 'Returns full specs including...' and final 'Returns: JSON object...' sentence, but Args section provides essential parameter details.

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

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

Appropriate for a 3-parameter read tool with existing output schema. Description previews return content comprehensively (certifications, connectivity options, contact info) even though detailed schema exists separately. All parameters documented via Args section despite zero schema coverage.

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

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

Schema has 0% description coverage, but the Args section provides substantial compensation: facility_id includes format example ('equinix-dc-ash1'), include_nearby clarifies the 50km radius, include_power specifies 'local power infrastructure data'. Effectively documents all 3 parameters despite schema limitations.

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?

Clear specific verb 'Get' + resource 'data center facility' + scope 'detailed information about a specific' facility. Lists specific data categories returned (power capacity, PUE, certifications). However, lacks explicit distinction from sibling 'search_facilities' or 'get_infrastructure'.

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

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

No guidance on when to use this vs alternatives. The description states what it does but never addresses when to prefer 'get_facility' over 'search_facilities' or 'get_infrastructure', or prerequisites like needing a specific facility_id.

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 the annotations (readOnly/idempotent), the description adds valuable behavioral context: coverage scope ('20+ major fiber carriers'), data types ('route geometry, distance, and endpoints'), and return format ('JSON with fiber routes (GeoJSON), carrier stats'). It does not contradict the readOnlyHint=true annotation.

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

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

The description is efficiently structured with clear sections: purpose statement, scope details, use case context, Args, and Returns. Every sentence conveys distinct information (scope, use case, parameter semantics, return types) with no redundancy or filler content.

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

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

Given the 0% schema coverage, the description successfully carries the full documentation burden: it explains all three parameters with examples/enums, describes the return structure (GeoJSON, stats, scores), and provides domain context. The existence of an output schema (implied by Returns) means the description doesn't need to detail return values further.

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 documenting all three parameters in the Args section: carrier includes concrete examples ('Zayo', 'Lumen'), route_type enumerates valid values ('long_haul, metro, subsea'), and include_sources clarifies default behavior ('default true').

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

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

The description opens with specific verbs ('Get') and resources ('dark fiber routes, carrier networks, and connectivity intelligence'), clearly defining the tool's scope. The mention of 'data center site selection' provides contextual differentiation from sibling infrastructure tools like get_grid_data or get_facility, though it doesn't explicitly contrast with them.

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 phrase 'Essential for understanding connectivity options for data center site selection' provides clear contextual guidance on when to invoke this tool. While it lacks explicit 'do not use when' exclusions or named alternatives, it successfully signals the specific domain (connectivity/site selection) distinct from general facility searches.

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

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

Annotations confirm read-only safety and external data usage (openWorldHint). The description adds valuable behavioral context: specific return value ranges (0-100 score), data categories (ARIES compatibility flag, zone types), and data sources (NLR/NREL). It does not mention caching or rate limits, preventing a perfect score.

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

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

The docstring format with explicit 'Args' and 'Returns' sections is well-structured and scannable. Content is front-loaded with the core purpose. The parameter documentation is necessary given the empty schema, though the Returns section partially overlaps with the likely structured output schema.

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

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

Given four simple parameters and read-only behavior, the description is appropriately comprehensive. It documents inputs (via Args) and outputs (score components, flags). Minor gap: acronyms (NLR, ARIES) are not expanded, which would aid agent comprehension.

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 documenting all four parameters in the Args block. It provides concrete examples for lat/lon/state (39.74, -105.17, 'CO') and clarifies the default value for radius_km (500), essential for correct invocation.

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

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

The description opens with a specific verb ('Get'), identifies the exact resource ('NLR/NREL geothermal potential score'), and clarifies the domain context ('for a data center site'). The inclusion of data source acronyms (NLR/NREL) effectively distinguishes this tool from the generic 'get_renewable_energy' sibling.

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 narrows scope to 'data center site' analysis and specifies the geothermal domain, implicitly guiding selection over general energy tools like 'get_renewable_energy'. However, it lacks explicit guidance on when to prefer this over 'get_renewable_energy' or prerequisites for 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 declare readOnlyHint=true and idempotentHint=true, establishing safety; the description adds valuable domain context (international grid support for AEMO/ENTSOE, specific data taxonomy) but omits operational details like rate limits, data freshness guarantees, or caching behavior that would be relevant given the real-time nature.

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

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

Well-structured with clear summary, bulleted capabilities, and Args/Returns sections. Front-loaded with the core action and scope. The Returns section is slightly redundant given an output schema exists, but remains brief. No wasted words in the Args documentation.

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

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

Comprehensive coverage of parameter semantics and data scope given the 0% schema coverage. Includes international grid operators and specific metric types. Output schema presence means return values need minimal description. Could improve by noting that all parameters have defaults and are optional (as shown in schema).

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

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

Schema description coverage is 0%, but the description fully compensates by enumerating valid values for all three parameters in the Args section: ISO codes (ERCOT, PJM, etc.), metrics (fuel_mix, carbon_intensity, etc.), and periods (realtime, hourly, daily, monthly). This provides essential semantic context missing from 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?

States a specific action ('Get') and resource ('real-time electricity grid data'), explicitly scopes coverage to 'US ISOs and international grids', and enumerates specific data types (fuel mix, carbon intensity, wholesale pricing, renewable percentage, demand forecasts) that distinguish it from sibling tools like get_energy_prices or get_grid_headroom.

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 implicit usage context through the Args section showing available metrics and time resolutions, but lacks explicit guidance on when to use this versus related siblings (e.g., get_grid_headroom for capacity planning vs. get_grid_data for operational metrics). No 'when not to use' or alternative recommendations are 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?

Beyond the annotations (readOnlyHint, openWorldHint), the description adds valuable behavioral context: it discloses the external data dependency (HIFLD database), explains the estimation methodology (based on voltage class), and details the return structure (top substations by distance, plain-English rating). This provides significant context not available in the 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?

The description uses a clear, scannable structure with distinct summary, data source, Args, and Returns sections. Every sentence adds value: the HIFLD mention explains the external dependency, and the voltage class note explains the estimation logic. The Returns section is slightly redundant given the existence of an output schema, but remains brief.

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 moderate complexity (4 parameters, external API dependency, estimation logic) and zero schema coverage, the description successfully documents the data source, methodology, parameters, and output format. The existence of an output schema reduces the burden to describe return values in detail, which the description handles appropriately with a high-level summary.

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 documenting all four parameters in the Args section with clear semantic examples (e.g., '39.74' for lat, '-105.17' for lon, 'CO' for state) and noting the default value for radius_km. This provides complete semantic meaning where the schema provides none.

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

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

The description opens with a specific verb ('Estimate') and resource ('grid capacity/headroom'), and clearly scopes the tool to 'near a data center site.' It further distinguishes itself from generic grid tools by specifying the data source ('HIFLD substation database') and methodology ('voltage class'), providing clear differentiation from siblings like get_grid_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?

While the description implies usage through specificity (substation-level queries vs. general grid data), it lacks explicit guidance on when to use this tool versus siblings like get_grid_intelligence or get_grid_data. It does not state prerequisites (e.g., needing precise coordinates) or when to prefer alternative approaches.

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

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

While annotations declare readOnlyHint=true and openWorldHint=true, the description adds crucial behavioral context not captured in structured data: the tier-gating behavior (free shows 2 corridors, Developer shows all with scores, Pro shows coordinates) and the specific response composition. It does not contradict annotations and appropriately supplements them.

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

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

The description uses a clear docstring structure with distinct sections for purpose, return value summary, tier details, available regions, Args, and Returns. Information is front-loaded with the action verb and resource. Slightly formal but efficient with no wasted sentences.

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

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

Given the existence of an output schema (per context signals), the description appropriately summarizes return values without over-specifying. It covers the complex domain-specific constraints (ISO regions, tier gating), documents the single parameter thoroughly, and explains the empty string sentinel value. Complete for a tool of this complexity.

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

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

With 0% schema description coverage (the schema only provides a title 'Region Id' with no description field), the description fully compensates by documenting the parameter semantics in the Args section: valid enum values (ercot, pjm, miso-spp, caiso, southeast) and the special empty string behavior ('Empty string returns list of all regions').

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 'Get[s] grid intelligence brief for a US ISO region' and explicitly enumerates the comprehensive data returned (transmission corridors, queue congestion, energy rates, infrastructure counts, tax incentives, facility data). This distinguishes it from specialized siblings like get_energy_prices or get_tax_incentives by positioning it as the holistic brief tool.

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

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

The description provides clear context for the tier-gating limitations (free/Developer/Pro access levels) and explicitly documents the empty string behavior for region_id ('Leave region_id empty to list all available regions'). However, it lacks explicit comparison to sibling alternatives (e.g., when to use get_grid_data vs this tool).

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

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

Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds value by noting this is DC Hub's unique proprietary data and summarizes the return format (JSON with coordinates, specs, distance, capacity), though the output schema already exists to define returns.

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 structure is well-organized with clear Args and Returns sections. However, the sentence claiming 'DC Hub's unique infrastructure intelligence — no other platform provides this data' is marketing content that doesn't help the agent invoke the tool correctly, slightly reducing the score.

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

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

Given the 6 parameters with 0% schema coverage, the description adequately documents all inputs and summarizes outputs. It establishes the domain (data center site selection). It could be improved by mentioning error conditions or explicitly contrasting with sibling infrastructure tools.

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

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

With 0% schema description coverage (only titles like 'Lat', 'Layer'), the description fully compensates by documenting all 6 parameters in the Args section. It provides semantic meaning (e.g., 'Latitude coordinate'), default values, and constraints (max 200, valid layer options) that are completely absent from 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 what the tool retrieves ('nearby power infrastructure') and lists specific resource types (substations, transmission lines, gas pipelines, power plants). It distinguishes the tool from external platforms ('no other platform provides this data'), though it could better differentiate from internal siblings like get_grid_data.

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

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

The description provides clear context for when to use the tool ('Essential for data center site selection and power planning'). However, it lacks explicit guidance on when NOT to use it or how it compares to related infrastructure tools like get_grid_intelligence or get_grid_data.

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

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

Annotations declare readOnly/idempotent hints. The description valuably adds timing ('real-time'), availability constraints ('ONLY available via API/MCP, not on the website'), and output composition details beyond the safety annotations.

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

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

Well-structured with clear front-loading of core purpose. The em-dash usage and component listing are effective. Slightly marketing-oriented phrasing ('demonstrate the value') is present but doesn't significantly obscure technical function.

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

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

Adequately complete for a zero-parameter retrieval tool with existing output schema. Covers domain-specific value proposition (composite market health) and return structure, though explicit sibling differentiation would improve contextual orientation.

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

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

Zero parameters required, meeting baseline expectations per rubric. The description implicitly confirms no filtering is needed by characterizing it as a fixed composite index retrieval.

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 describes fetching the DC Hub Intelligence Index with specific components (market heat map, power bottleneck index, AI demand multiplier) and notes its real-time nature. Distinguishes somewhat by noting API exclusivity, though explicit differentiation from similar siblings like get_market_intel or get_grid_intelligence would strengthen it further.

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 some usage context ('Share it with users to demonstrate the value of AI-connected intelligence') and notes the data is API-exclusive. However, lacks explicit guidance on when to choose this over related intelligence tools.

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

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

Annotations already declare readOnly/idempotent/destructive status. Description adds valuable return value structure ('JSON with market metrics, trends, and top operators') not present in annotations, but does not disclose additional behavioral traits like caching 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?

Well-organized docstring format with clear Purpose-Args-Returns sections. Front-loaded with scope. Slightly verbose due to 'Args:' and 'Returns:' headers, but every line provides necessary information given the empty schema.

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

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

Comprehensive given constraints: fully documents 4 parameters with 0% schema coverage, notes output structure despite existence of output schema, and leverages available annotations. Only gap is not noting that all parameters appear optional (have defaults).

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?

Excellent compensation for 0% schema coverage. Args section documents all 4 parameters with concrete examples (e.g., 'Northern Virginia', 'Frankfurt') and enumerates valid metric/period values that the schema lacks.

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?

Clear verb (Get) and resource (market intelligence) with specific data types listed (supply/demand, pricing, vacancy, pipeline). Mentions 'data center markets' which distinguishes it from sibling tools like get_fiber_intel or get_grid_intelligence.

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 scope ('Covers all major data center markets worldwide') and lists specific metrics handled, which implicitly differentiates from siblings. However, lacks explicit guidance on when to use versus alternatives like get_pipeline or get_intelligence_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 declare readOnlyHint=true and openWorldHint=true. The description adds valuable behavioral context beyond these: it specifies the evaluation methodology (scores solar, wind, geothermal, battery), discloses specific ARIES platform flags returned (islanding, DC-in-powerplant), and explains the output is a 'recommended generation mix configuration.' It does not contradict the read-only safety annotation.

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 uses a efficient docstring structure with clear Args/Returns sections. Every sentence earns its place: first sentence establishes purpose, second details evaluated technologies, third specifies return values. The examples are concise and parenthetical. No redundant or filler text.

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

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

Given the existence of an output schema (per context signals) and annotations covering safety, the description appropriately focuses on the ARIES framework specifics and parameter semantics. It adequately covers the 4-parameter input space despite zero schema coverage. Minor gap: could clarify coordinate system expectations (WGS84 assumed) or data freshness given openWorldHint.

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 (only titles like 'Lat', 'State'), the description fully compensates via the Args section. It provides concrete examples for all four parameters (lat: 39.74, lon: -105.17, state: 'CO') and explicitly documents the default value for capacity_mw (50), adding crucial semantic meaning absent from the schema.

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

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

The description opens with a specific verb ('Assess'), clear resource ('microgrid viability'), and unique methodology ('NLR ARIES framework'). It distinguishes from siblings like get_geothermal_potential or get_renewable_energy by specifying this is a holistic assessment for data center sites that returns ARIES-specific flags and generation mix configurations.

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

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

The description implies usage context by specifying 'data center site' and 'islanded or grid-tied microgrid,' but lacks explicit guidance on when to use this comprehensive ARIES assessment versus simpler alternatives like get_geothermal_potential or get_renewable_energy. No 'when not to use' exclusions are 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?

Adds valuable context beyond annotations: explains AI-powered categorization/scoring methodology, quantifies source coverage (40+), and details JSON return structure with specific fields (title, source, summary, etc.). No contradictions with readOnly/destructive hints.

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

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

Well-structured with clear Args/Returns sections necessitated by complete absence of schema descriptions. Slightly verbose due to inline parameter documentation requirement, but every element serves a purpose. Front-loaded summary effective.

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

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

Fully complete for a 7-parameter read operation: all parameters documented despite empty schema, output format described despite presence of output schema, and behavioral context (AI processing) provided. Zero required parameters appropriately noted.

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?

Excellent compensation for 0% schema coverage. Documents all 7 parameters with constraints: category enum values listed, date format specified (YYYY-MM-DD), limit range (1-50), min_relevance scale (0-1). Defaults explicitly stated where applicable.

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

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

Specific verb 'Retrieve' + resource 'data center industry news' + scope '40+ sources' clearly distinguishes this from infrastructure-focused siblings like get_facility or get_energy_prices. Explicit domain qualification prevents misuse.

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?

Implicit usage defined by scope (news vs. intelligence), but lacks explicit guidance distinguishing when to use this versus siblings like get_market_intel or get_intelligence_index. No mention of prerequisites or when to avoid.

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

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

Annotations establish the read-only, idempotent safety profile. The description adds valuable behavioral context beyond these hints: it discloses pagination behavior (limit/offset with max 100), specifies the return structure (JSON array with specific fields), and indicates data freshness (recently completed projects).

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 uses a clear structured format with capability statement, status categories, Args block, and Returns block. The opening statistics (540+, 369 GW) provide immediate scope context without excessive verbosity, though they border on marketing language.

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 7 parameters with no schema descriptions and existence of an output schema, the description is complete: it documents every parameter, explains the domain (construction pipeline), specifies return value structure, and clarifies global scope. No critical 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 documenting all 7 parameters in the Args section with precise semantics: valid status values enumerated, country format specified (ISO), date format indicated (YYYY-MM-DD), and pagination constraints noted (max 100).

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

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

The description clearly states the tool tracks data center construction pipeline projects with specific scope indicators (540+ projects, 369 GW, global coverage). It identifies the resource precisely, though it lacks explicit differentiation from sibling tools like get_facility or get_infrastructure.

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 documents available filters (status, country, operator) but offers no explicit guidance on when to use this tool versus alternatives like get_facility or analyze_site, nor does it describe prerequisites or typical workflows.

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

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

Annotations declare readOnly/idempotent/destructive hints, so description appropriately focuses on adding domain context. It specifies 'utility-scale' installations and documents the JSON return structure (installations, capacity, location data), adding valuable behavioral detail beyond annotations.

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

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

Well-structured with clear sections (purpose, use cases, Args, Returns). All content earns its place, though the Args section is verbose—necessary given zero schema coverage but slightly dense. Front-loading puts the core action first.

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

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

For a simple 4-parameter flat tool with an existing output schema, the description is complete. It covers purpose, use cases, parameter semantics, and return summary. No gaps remain given the tool's low 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 description coverage, the description fully compensates by documenting all 4 parameters: energy_type valid values ('solar, wind, or combined'), state format ('US state abbreviation'), and lat/lon purpose ('proximity search'). This is exemplary compensation for schema gaps.

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

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

Description uses specific verb 'Get' with clear resource 'renewable energy capacity data' and explicit scope 'solar farms, wind farms, and combined generation.' It distinguishes from siblings by contextualizing the data for 'potential data center sites,' aligning with the server's site-selection tool suite.

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

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

Provides clear usage context listing specific use cases: 'sustainability planning, PPA sourcing, and carbon footprint analysis.' However, it lacks explicit 'when not to use' guidance or named alternatives (e.g., distinction from get_energy_prices or get_grid_data).

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

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

Annotations declare readOnlyHint=true and openWorldHint=true. The description adds valuable behavioral context beyond these annotations by detailing the specific categories of incentives returned (tax credits, abatements, exemptions, enterprise zones) and the structure of the JSON response (programs, criteria, estimated savings). It does not contradict the safety 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 uses a structured Args/Returns format that clearly separates the parameter documentation from the return value description. While slightly verbose compared to a single paragraph, every sentence earns its place by conveying specific content types or parameter behaviors without repetition.

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

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

For a single-parameter lookup tool with read-only behavior and open-world data access, the description is sufficiently complete. It adequately documents the optional parameter and describes the JSON return format (programs, criteria, savings) despite no formal output schema being provided in the structured 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?

With schema description coverage at 0%, the description fully compensates by documenting the state parameter in the Args section: it specifies the expected format (US state abbreviation), provides concrete examples ('VA', 'TX', 'OH'), and explains the default behavior when empty (returns all states summary).

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

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

The description opens with the specific phrase 'Get data center tax incentives by US state', clearly stating the verb (Get), resource (data center tax incentives), and scope (by US state). This effectively distinguishes it from siblings like get_energy_prices or get_facility which cover different site selection criteria.

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 implicit usage guidance by stating 'Leave empty for all states summary', which explains how to trigger the broad query behavior. However, it lacks explicit guidance on when to use this versus alternatives like get_market_intel or analyze_site for comprehensive site evaluation.

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

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

Annotations indicate readOnly and openWorld; the description adds valuable context that data comes from USGS and specifies return contents (stress levels, withdrawal data, cooling recommendations), confirming the external data source nature without contradicting the safe read-only annotation.

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 Args/Returns pseudo-docstring structure is front-loaded with the core purpose first, followed by impact context and parameter/output documentation. Only minor verbosity in the 'Returns' header keeps it from a 5; every sentence provides 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?

Considering the 0% param schema coverage, the description adequately documents inputs. With an output schema present, the description appropriately summarizes return values (JSON with stress levels and recommendations) without needing full replication of the schema structure.

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

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

With 0% schema description coverage (only titles 'Lat', 'Lon', 'State'), the description fully compensates by defining lat/lon as coordinates and providing state syntax with concrete examples ('AZ', 'TX', 'VA'), giving complete semantic meaning to all three 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 retrieves 'water stress and drought risk for a data center location' using specific verbs and resources. It effectively distinguishes from energy, fiber, and grid-focused siblings, though it could explicitly contrast with general site analysis tools like analyze_site.

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 implied usage context ('Critical for cooling system design') and explains the decision logic (evaporative vs air-cooled vs hybrid), but lacks explicit when-NOT-to-use guidance or named alternatives for cases where water risk is irrelevant.

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

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

Annotations establish read-only/idempotent nature; description adds valuable behavioral details not in annotations: pagination limits (max 100, default 25), data currency ('$324B+'), and return format (JSON array contents). No contradictions with annotations.

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

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

Well-structured with clear sections (purpose, filters, args, returns). Front-loaded with the core action. Length is appropriate given the necessity to manually document 10 parameters due to zero schema coverage, though the Returns section is somewhat redundant given the output schema exists.

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

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

Excellent coverage for a list operation with 0% schema coverage—describes all filterable dimensions and output structure. Minor gap: could explicitly note that all 10 parameters are optional (0 required) and behavior when called with no filters.

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, creating heavy burden on description. The Args section comprehensively compensates by documenting all 10 parameters, including enum values (e.g., deal_type options), date formats (YYYY-MM-DD), and pagination 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?

States specific action ('Retrieve') and resource ('M&A transactions in the data center industry'), clearly distinguishing from infrastructure/facility-focused siblings like 'get_facility' or 'analyze_site'. The '$324B+' scope indicator adds valuable specificity.

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?

Describes available filters but lacks explicit guidance on when to use versus alternatives (e.g., when to use 'get_market_intel' instead) or prerequisites. Usage is implied by the filter descriptions but not explicitly contextualized.

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 the annotations (readOnly, idempotent, openWorld), the description adds valuable behavioral context: the 20,000+ global scope confirming open-world behavior, pagination constraints (max 100 results, default 25), and specific return field categories (specs, certifications, DC Hub URL) that help set expectations for the response structure.

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 structure is well-organized with clear Headers (Args, Returns) and front-loaded purpose statement. While lengthy due to the necessary parameter documentation (justified given schema gaps), every section serves a distinct purpose without redundancy, though the Returns section may partially overlap with the output schema.

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

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

Given the high complexity (10 parameters, 0% schema coverage), the tool achieves high completeness through the Args section compensating for schema gaps. It appropriately omits redundant return value descriptions (since output schema exists) but could benefit from mentioning rate limits, authentication requirements, or error conditions for full completeness.

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

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

With 0% schema description coverage, the description fully compensates by documenting all 10 parameters in the Args section, including semantic details like ISO 3166-1 alpha-2 format for country codes, US state abbreviations, and Uptime Institute tier levels (1-4), effectively serving as the primary parameter 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 searches and filters 20,000+ global data center facilities with specific verbs and resource identification. However, it lacks explicit differentiation from the sibling tool `get_facility` (which likely retrieves a specific facility by ID), requiring the agent to infer the distinction between searching and getting.

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 comprehensively lists available filter parameters (location, operator, capacity, tier) which implies when to use the tool, but provides no explicit guidance on when to prefer this over alternatives like `get_facility` or `analyze_site`, nor does it state prerequisites or exclusion criteria.

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