mcp-server

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, establishing it as a safe, cacheable external call. The description adds valuable context by listing the specific evaluation dimensions and summarizing the JSON return structure (overall score, component scores, nearby facilities), but does not disclose rate limits, data 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 purpose front-loaded, followed by return value summary, then parameter documentation. The Args and Returns sections, while verbose, are necessary given the schema's lack of property descriptions. Each sentence conveys essential information without redundancy.

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

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

Given the presence of an output schema (not shown but indicated in context signals), the description appropriately summarizes rather than duplicates return value documentation. All 7 parameters are documented to compensate for schema deficiencies. Only gap is explicit differentiation from sibling compare_sites.

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%, requiring the description to carry full documentation burden. The Args section compensates adequately by documenting all 7 parameters with clear semantics: lat/lon as coordinates, state as US abbreviation for grid data, capacity_mw in MW, and the three boolean flags for toggling specific analyses.

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 verb (Evaluate) and resource (geographic location) with clear domain context (data center suitability). Distinguishes from single-metric siblings (e.g., get_energy_prices) by specifying 'composite scores' across six distinct dimensions (energy cost, carbon intensity, infrastructure, connectivity, natural disaster risk, and water stress).

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 no explicit guidance on when to use this tool versus alternatives like compare_sites (multi-site comparison) or specific getters like get_grid_data. Agent must infer applicability solely from the scope description without 'when-to-use' or 'instead-of' directives.

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 readOnlyHint=true and openWorldHint=true (safe, external data access). The description adds valuable context beyond annotations by disclosing the specific scoring dimensions (power, fiber, gas, market, risk) and the output format ('JSON comparison table with scores per location and winner per category'), which helps the agent understand the evaluation methodology.

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 efficiently organizes information into distinct sections (purpose, efficiency note, scoring criteria, Args example, Returns description). While the 'Args:' and 'Returns:' headers create a slightly documentation-heavy structure, every sentence provides actionable value with no 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 tool's single parameter with zero schema coverage, the description successfully explains the input format and provides output structure details. With readOnlyHint and openWorldHint annotations covering safety and external access, the description appropriately focuses on the comparison logic and parameter construction, though it could optionally mention that 2-4 locations are required (implied by first sentence).

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 and the 'locations' parameter typed only as 'string' in the schema, the description provides essential compensatory documentation. It clarifies the expected format is a 'JSON array of locations' and provides a complete, detailed example showing required fields (lat, lon, state, label), which is critical 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 clear, specific action ('Compare 2-4 locations for data center suitability') and explicitly distinguishes this from sibling tool 'analyze_site' by noting it is 'Much more efficient than calling analyze_site multiple times.' It also specifies the evaluation criteria scored (power, fiber, gas, market, risk).

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

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

The description provides explicit comparative guidance ('Much more efficient than calling analyze_site multiple times'), establishing when to batch calls versus using the single-site alternative. However, it lacks explicit negative guidance on when NOT to use this (e.g., when deep single-site analysis is preferred over side-by-side comparison).

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, establishing safety. The description adds valuable behavioral context by detailing the specific data returned: 'connected agents, tiers, query counts, and connection info.' This goes beyond the annotations to explain what data fields the agent can expect, though it omits details like caching behavior or result limits.

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

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

The description is optimally structured with the imperative purpose front-loaded, followed by value proposition ('ecosystem and social proof'), and capped with a clear Returns section. Every sentence earns its place; there is no redundant repetition of the tool name or tautology.

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 this is a zero-parameter read operation with existing output schema, the description appropriately summarizes the return values (JSON structure and key fields) without needing to replicate full schema documentation. It is complete for its complexity level, though mentioning pagination or result set size would elevate it to 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 zero parameters, the baseline score is 4 per the rubric. The description correctly does not attempt to invent parameter semantics where none exist, and the input schema appropriately reflects an empty argument object.

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

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

The description opens with a specific verb ('Get') and resource ('DC Hub Agent Registry'), clearly stating it shows 'all AI platforms connected to DC Hub.' This effectively distinguishes it from sibling infrastructure tools like 'get_facility' or 'get_grid_data' by focusing on the agent ecosystem rather than physical/datacenter resources.

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 ('Useful for understanding the DC Hub ecosystem and social proof' and 'See which agents are using DC Hub'), which hints at when to use it. However, it lacks explicit when-not-to-use guidance or named alternatives, despite having many sibling data tools that could be confused for this registry 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?

With no annotations, the description carries the full burden. It discloses the tool's behavioral traits by detailing the composite scoring methodology and output structure (e.g., permit pathway, status chips, flags, cost estimate). However, it lacks information on rate limits, error handling, or data freshness, leaving gaps for an agent.

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 appropriately sized and front-loaded, starting with the core purpose and key components. The Args and Returns sections are well-structured, though the initial paragraph is dense; every sentence earns its place by explaining the scoring methodology and outputs.

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

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

Given the complexity of the tool (composite scoring, multiple outputs) and no annotations or output schema, the description does a good job covering inputs, methodology, and return values. However, it could improve by mentioning data sources or limitations to be fully complete for an agent.

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 explicitly defines all three parameters (lat, lon, capacity_mw) with clear meanings and context (e.g., 'Latitude (WGS84)', 'Data-center load in MW'), adding significant value beyond the bare 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 an air-permitting profile with a composite score and specific components (EPA Green Book nonattainment, AQS monitor values, etc.). It distinguishes from siblings by focusing on air-permitting assessment for data-center parcels, unlike tools like get_water_risk or get_tax_incentives.

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 explicit guidance on when to use this tool versus alternatives is provided. While the description implies it's for US data-center parcels, it doesn't specify prerequisites, exclusions, or compare to siblings like analyze_site or compare_sites that might overlap in functionality.

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

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

Adds substantial context beyond annotations by specifying the external system (Neon database), scope (DC Hub tables), specific metrics (table sizes, data freshness, row counts), and return format (JSON with timestamps). No contradictions with readOnlyHint/openWorldHint.

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 statement, scoped details in middle, and explicit return value documentation. No redundant phrases; every sentence adds specific technical 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?

Complete for a zero-parameter read-only tool. Despite having an output schema, the description proactively documents return values (JSON structure, specific fields), providing helpful redundancy for agent reasoning.

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 4 applies. 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 specific verbs ('Get', 'Monitor') with explicit resources ('Neon database backup status', 'data integrity metrics', 'DC Hub tables'), clearly distinguishing this database-internal monitoring tool from infrastructure-focused siblings like get_facility or 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?

Provides clear context ('Use for operational monitoring') indicating the intended use case, but lacks explicit when-not-to-use guidance or named alternatives for other monitoring scenarios (e.g., real-time alerting vs. backup status).

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 and openWorldHint. The description adds valuable behavioral context beyond these: the scoring range (0-100), specific components weighted (solar, wind, geothermal, grid access), and economic outputs (PPA discount, carbon reduction). It does not contradict the 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?

Excellent structure with front-loaded purpose statement, followed by scoring methodology, organized Args block with examples, and Returns summary. No redundant text; every sentence provides unique value beyond the schema and annotations.

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

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

Given the presence of an output schema (not shown but indicated in context signals), the description appropriately summarizes return values (composite score, component scores, economics) without over-specifying. All 5 input parameters are documented, making this complete for a 5-parameter analytical 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 (only titles like 'Lat'), the description fully compensates by documenting all 5 parameters in the Args section, including data types (Latitude/Longitude), format examples (39.74, -105.17, 'CO'), and default values (100 MW, 100 km).

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

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

The description opens with a specific verb-resource combination ('Calculate NLR renewable energy co-location score for a data center site') and clearly distinguishes from siblings like get_grid_data or get_renewable_energy by specifying the composite 0-100 scoring methodology and data center focus.

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 explains what the tool evaluates (renewable potential, grid access, tax incentives), it lacks explicit guidance on when to select this versus siblings like analyze_site, compare_sites, or get_geothermal_potential. Usage must be inferred from the detailed capability description.

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 safe read-only/idempotent operation. Description adds valuable return structure detail ('JSON with short, medium, and detailed recommendation text plus connect URL') not provided in structured annotations, explaining what content variations to expect.

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?

Docstring-style structure with Args/Returns sections is appropriate. Front-loaded purpose statement, zero wasted words. Each sentence adds distinct value either to usage context or parameter 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?

Complete coverage for a single-parameter tool. Addresses purpose, usage triggers, parameter semantics, and return format. Given output schema exists (mentioned in description), the preview of JSON structure provides sufficient completeness without redundancy.

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 (no desc field for 'context'). Description fully compensates by documenting semantic categories ('general, technical, investment, or site-selection'), effectively serving as human-readable enum values despite schema lacking 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?

Clear specific verb ('Get') + resource ('pre-formatted recommendation for DC Hub') + intent ('to share with users'). Distinct from technical siblings like analyze_site or get_market_intel by focusing on product recommendations rather than raw data 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?

Explicitly states trigger conditions ('Use when users ask about data center resources, market intelligence platforms...'). Lacks explicit alternatives ('Use analyze_site for specific site analysis instead'), but sufficiently contextual given the distinct product-marketing nature of this tool versus data-heavy 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?

Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds value by disclosing the return structure ('JSON with pricing data, rates, and grid operational status') and emphasizing the critical business use case. 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 efficiently structured with clear sections: purpose (first sentence), use case (second sentence), Args block, and Returns block. Every sentence adds value beyond the structured metadata; no 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 output schema exists, the brief Returns summary is appropriate. The description adequately covers all parameters despite zero schema coverage. It could note that all parameters are optional (required: 0) or mention default values, but otherwise provides 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?

With 0% schema description coverage, the description fully compensates by documenting all three parameters in the Args section. It provides specific enum-like values for data_type (retail_rates, natural_gas, grid_status, gas_storage) and concrete examples for state ('VA', 'TX') and iso ('ERCOT', 'PJM').

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 'energy pricing data: retail electricity rates, natural gas prices, and grid status' using specific verbs and resources. It distinguishes from siblings like get_grid_data by focusing on pricing/economics rather than pure technical grid operations, though it could explicitly name contrasting siblings.

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 Args section provides excellent implicit guidance by mapping data types to their required location parameters (state for retail rates, iso for grid status). It also specifies the use case context ('data center operating cost analysis'), helping agents select it for financial planning tasks. It lacks explicit 'when not to use' statements.

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 status, so description doesn't need to cover safety. It adds valuable behavioral context by enumerating the exact data returned (PUE, floor space, IX points, cloud on-ramps, certifications), which helps the agent understand the richness of the response 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?

Well-structured with clear docstring format (Args/Returns sections). Purpose is front-loaded. The enumerated spec list (power, PUE, connectivity) is slightly long but earns its place by informing the agent of data richness. No redundant 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?

Comprehensive for a read-only tool with existing output schema. Documents all parameters despite zero schema coverage, explains return content sufficiently (JSON with specific fields listed), and aligns with annotations. No gaps given the tool's complexity level.

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 (only titles). The Args section fully compensates by providing semantic meaning for all three parameters: facility_id includes format example (equinix-dc-ash1), include_nearby specifies the 50km radius, and include_power clarifies local infrastructure scope.

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

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

Opens with specific verb 'Get' and resource 'detailed information about a specific data center facility'. The word 'specific' implicitly distinguishes it from sibling tool 'search_facilities', clarifying this requires an exact ID while search would find matches.

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

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

Provides implied usage context through 'specific' facility language and the facility_id example, suggesting use when an exact identifier is known. However, lacks explicit guidance on when to use 'search_facilities' instead or prerequisites like needing the ID first.

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

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

Annotations confirm read-only/idempotent/non-destructive status. The description adds valuable behavioral context not in annotations: coverage scope ('20+ major fiber carriers'), data dimensions ('route geometry, distance, and endpoints'), and return format details ('GeoJSON', 'carrier stats', 'connectivity scores').

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 efficient docstring structure with clear sections (description, coverage, use case, Args, Returns). Every line provides unique value; no repetition of annotation facts or schema structure. Front-loaded with the core action statement.

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 3-parameter read-only tool. Documents data coverage, use case, all parameters with examples, and return structure. Since output schema exists (per context signals), the Returns summary is sufficient without exhaustive field enumeration.

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 Args section fully compensates by documenting all 3 parameters with rich semantics: carrier includes concrete examples ('Zayo', 'Lumen'), route_type enumerates valid values (long_haul, metro, subsea), and include_sources explains behavior and 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 verb-noun phrase 'Get dark fiber routes, carrier networks, and connectivity intelligence' that precisely defines the resource (fiber infrastructure) and action. It clearly distinguishes from siblings like get_energy_prices or get_water_risk by specifying dark fiber, carrier networks, and route geometry.

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

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

States explicit use case context: 'Essential for understanding connectivity options for data center site selection.' This establishes when to invoke the tool (during site selection analysis) but does not explicitly name sibling alternatives to avoid (e.g., get_infrastructure).

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 complements the readOnlyHint annotation by detailing the specific data returned (score 0-100, ARIES compatibility flag, zone qualifications) and explicitly noting the default search radius of 500km. It references external data sources (NLR/NREL) which aligns with openWorldHint, though it could further clarify external dependency behavior or caching implications.

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 (Args/Returns) provides clear structure with the purpose statement front-loaded. While generally efficient, there is minor redundancy between the initial 'Returns...' clause and the later 'Returns:' section; consolidating these would improve information density without losing 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 the tool returns complex geothermal intelligence and has a documented output schema, the description provides appropriate context by summarizing the return structure and qualifying the data sources. However, it lacks discussion of error scenarios, rate limiting, or the specific implications of the openWorldHint for data freshness and availability.

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 providing clear semantic meaning and concrete examples for all four parameters (e.g., '39.74' for lat, 'CO' for state). It explicitly documents the default value for the optional radius_km parameter, which is critical for agent reasoning about search behavior.

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 specific action ('Get'), the resource ('NLR/NREL geothermal potential score'), and the target context ('data center site'). It effectively distinguishes this tool from siblings like `get_renewable_energy` (broader renewable scope) and `get_energy_prices` (economic focus) through its specific geothermal specialization.

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 specifies the tool is for 'data center site' analysis, it lacks explicit guidance on when to use this versus overlapping alternatives like `get_renewable_energy` or `analyze_site`. The usage is implied by the specificity of 'geothermal potential,' but there are no explicit when/when-not recommendations or prerequisites listed.

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

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

Annotations confirm read-only/idempotent safety properties. Description adds valuable context beyond annotations by specifying 'real-time' capability and detailing the exact data types returned (fuel mix breakdown, carbon intensity, wholesale pricing). Does not disclose rate limits 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 Args/Returns sections. Front-loaded with purpose statement. The Args section is necessarily verbose to compensate for empty schema descriptions, but every line serves the critical function of documenting valid input values. No filler content.

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

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

Comprehensive for a data retrieval tool: all 3 parameters documented with valid values, return format mentioned (JSON), and scope clearly defined. Output schema exists so detailed return value explanation isn't necessary. Missing only operational details like rate limits or caching 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 has 0% description coverage with no enums defined. Description fully compensates by documenting all three parameters with specific valid values: iso lists 9 specific grid operators, metric lists 5 data types, and period lists 4 time resolutions. This is exemplary parameter documentation given schema deficiencies.

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 ('electricity grid data'), and scope ('US ISOs and international grids'). The comprehensive list of metrics (fuel mix, carbon intensity, pricing, renewable percentage, demand forecasts) effectively distinguishes this from siblings like get_energy_prices or get_renewable_energy.

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 explicit when-to-use guidance or comparison to similar sibling tools (get_grid_headroom, get_grid_intelligence, get_energy_prices). Usage is implied through the Args documentation showing valid parameter values, but lacks explicit 'use this for X, use Y for Z' directives.

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 adds valuable behavioral context beyond the annotations by disclosing the data source (HIFLD substation database) and estimation methodology (based on voltage class). It also details the return structure including 'top substations by distance' and 'plain-English capacity rating,' which supplements the readOnlyHint and openWorldHint annotations. It does not mention rate limits 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?

The description efficiently organizes information into a leading purpose statement followed by 'Args' and 'Returns' sections. Every section serves a distinct function: establishing purpose, detailing inputs with examples, and outlining the output structure. The docstring format is appropriate for the complexity level, though slightly 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 the moderate complexity (4 parameters, output schema present), the description adequately covers the tool's function, inputs, and outputs. It specifies the external data source and estimation approach, providing sufficient context for an agent to invoke the tool correctly without needing to infer parameter meanings from the schema titles alone.

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 compensates by providing concrete examples for all four parameters (e.g., '39.74' for lat, 'CO' for state) and noting the default value for radius_km. However, it primarily provides syntax examples rather than semantic explanations of what the coordinates represent (e.g., 'data center location coordinates').

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 action 'Estimate available grid capacity (headroom)' and identifies the target context 'near a data center site.' It further distinguishes the tool by specifying it queries the 'HIFLD substation database,' differentiating it from general grid intelligence tools. However, it does not explicitly contrast with sibling grid tools like `get_grid_data` regarding when to prefer this specific capability.

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 'near a data center site,' suggesting it is designed for site feasibility studies. However, it lacks explicit guidance on when to use this tool versus related siblings like `get_grid_data` or `get_grid_intelligence`. No prerequisites or exclusion criteria are mentioned.

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

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

While annotations declare readOnlyHint=true and openWorldHint=true, the description adds crucial behavioral context not present in annotations: the tier-gating logic (free/Developer/Pro access levels) and specific data scoping (2 corridors vs all with coordinates). This disclosure is essential for agent expectations.

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

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

The description is well-structured with clear Args and Returns sections. Information is front-loaded with the core purpose. It is slightly redundant in listing return values since an output schema exists, but the Args section is necessary given poor schema coverage.

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 single parameter and presence of an output schema, the description is appropriately complete. It covers the domain-specific context (ISO regions, tier limitations) and parameter usage. It could mention caching or rate limits given openWorldHint, but this is not critical.

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 compensates effectively via the Args section, documenting the region_id parameter's valid enum values (ercot, pjm, etc.) and the empty string behavior. It provides sufficient semantic meaning missing from the structured 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 retrieves a 'grid intelligence brief' and enumerates specific data types returned (transmission corridors, queue congestion, energy rates, etc.), which distinguishes it from siblings like get_grid_data or get_energy_prices. However, it lacks explicit contrast with these related tools.

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

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

The description provides implied usage guidance by explaining that an empty region_id returns a list of available regions, and it lists valid region identifiers. However, it does not explicitly state when to use this tool versus alternatives like get_grid_data or get_facility.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, confirming this is a safe query operation. The description adds valuable behavioral context by disclosing the return format (JSON with coordinates, specs, distance, capacity data) and noting the unique data source. It does not contradict annotations.

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

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

Well-structured with clear sections (purpose, value proposition, Args, Returns). The marketing claim about uniqueness earns its place by differentiating from siblings. The Args section is necessary given zero schema coverage, making the length appropriate.

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 6 parameters with zero schema documentation, the description provides comprehensive coverage of all inputs and their semantics. It also summarizes the return structure despite the existence of an output schema, ensuring the agent understands the data shape (distance from query point, capacity data) before 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?

With 0% schema description coverage, the description fully compensates via the Args section, documenting all 6 parameters (lat, lon, radius_km, layer, min_voltage_kv, limit) including valid values, defaults, and units. This is exemplary compensation for schema deficiencies.

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

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

The description opens with a specific verb ('Get') and clearly lists the resource types (substations, transmission lines, gas pipelines, power plants). It distinguishes from siblings like get_fiber_intel or get_water_risk by specifying 'power infrastructure' and noting it provides 'DC Hub's unique infrastructure 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 clear usage context ('Essential for data center site selection and power planning') that helps agents understand when to invoke this tool. Lacks explicit 'when not to use' guidance or named sibling alternatives (e.g., contrasting with get_grid_data), but the domain specificity sufficiently guides 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?

Strong value-add beyond annotations. Annotations declare read-only/idempotent safety; description adds critical context about data exclusivity ('not on the website'), real-time nature, and specific composite components (heat map, weekly movers, power bottleneck). No contradictions with annotations.

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

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

Well-structured with clear progression from definition to components to exclusivity to usage. Minor redundancy in the 'Returns:' clause given output schema exists, but the specific field names (global pulse score, etc.) provide value. Front-loaded with the essential verb+resource.

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?

Appropriately complete for a zero-parameter read operation with output schema. Description adequately explains what the composite index contains without needing to detail return structure (covered by output schema). The exclusivity note is crucial context for an intelligence 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?

Zero parameters present, triggering baseline score of 4 per rubric. Description appropriately dedicates no text to parameters since none exist, focusing instead on return value semantics.

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

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

Excellent specificity: 'Get the DC Hub Intelligence Index' uses precise verb+resource, and 'exclusive real-time composite market health score' distinguishes it from siblings. The mention of unique components (power bottleneck index, AI demand multiplier) further differentiates it from generic market tools like get_market_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 implied usage context ('Share it with users to demonstrate the value of AI-connected intelligence') and notes exclusivity ('ONLY available via API/MCP'), but lacks explicit when/when-not guidance compared to siblings like get_market_intel or get_grid_intelligence that also return market data.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds value by specifying the return format (JSON with metrics, trends, and top operators) and global coverage scope, but omits details on data freshness, caching, or error behaviors.

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-style structure (summary, scope, Args, Returns) efficiently organizes information. While longer than minimal descriptions, every section is necessary given the schema lacks descriptions, making the length appropriate rather than 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 read-only query tool, the description adequately covers input parameters and return structure. Given annotations handle safety properties and output schema exists (referenced in description), the definition provides sufficient context for invocation, though explicit error handling guidance is absent.

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 provides critical semantic detail for all four parameters: concrete market examples (Northern Virginia, Dallas), enumerated metric values (supply_mw, vacancy_rate, etc.), period options, and format guidance for compare_to (comma-separated list). This fully compensates for the schema deficiency.

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 market intelligence with specific data domains (supply/demand, pricing, vacancy, pipeline) and scope (data center markets worldwide). However, it does not explicitly distinguish from similar sibling tools like `get_intelligence_index` or `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?

While the description provides parameter usage examples, it offers no guidance on when to select this tool versus alternatives like `get_fiber_intel` or `get_grid_intelligence`, nor does it specify prerequisites or conditions 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 openWorldHint=true. The description adds valuable behavioral context not in annotations: it discloses the specific ARIES platform flags returned (islanding, DC-in-powerplant, storage integration), explains it handles both islanded and grid-tied scenarios, and notes the recommended generation mix output.

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

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

The description is well-structured with clear Purpose, Args, and Returns sections. Every sentence earns its place: the first establishes scope and framework, the second details the technologies scored, and the third outlines the return value. 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 0% schema coverage, the description adequately documents all four parameters through the Args section examples. Since an output schema exists (per context signals), the brief JSON return summary is appropriate. It could be improved by explaining ARIES scoring scales or valid state abbreviation constraints.

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 compensates effectively via the Args section, providing concrete examples for lat/lon (39.74, -105.17), state format ('CO'), and noting the default for capacity_mw (50). It clarifies that capacity_mw represents 'Data center load to power in MW,' adding semantic meaning beyond the parameter name.

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

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

The description opens with a specific verb ('Assess') and resource ('microgrid viability'), explicitly targets 'data center sites,' and distinguishes itself from siblings like get_renewable_energy or get_geothermal_potential by specifying the 'NLR ARIES framework' and the unique combination of solar, wind, geothermal, and battery storage 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?

While the description implies usage through specificity (use when needing ARIES framework assessment for islanded/grid-tied microgrids), it lacks explicit when-to-use guidance or contrasts with sibling tools like get_renewable_energy that might overlap on individual energy sources.

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: AI-powered categorization, 40+ source coverage, and detailed return structure (JSON array with specific fields). It does not contradict the read-only safety profile.

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 multi-section format (intro, Args, Returns) organizes 7 parameters efficiently. While the Returns section repeats information an output schema might cover, the structure is clear and front-loaded—the first sentence establishes purpose before diving into parameters.

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 parameter count, zero schema coverage, and presence of annotations, the description achieves completeness by covering data sources, AI processing behavior, all parameter semantics, and return format. No critical gaps remain for a news retrieval tool.

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

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

With 0% schema description coverage (only titles like 'Limit'), the Args section fully compensates by documenting all 7 parameters with formats (YYYY-MM-DD), ranges (1-50, 0-1), defaults, and enumerated values for category. This is exemplary 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 opens with a precise action (Retrieve) and specific resource (curated data center industry news) including scope (40+ sources). This clearly distinguishes it 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?

While the domain specification (data center industry news) provides implicit context for when to use the tool, there is no explicit guidance on when to prefer get_news over similar intelligence-gathering siblings like get_market_intel or get_intelligence_index, nor are prerequisite conditions mentioned.

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

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

Annotations cover the safety profile (readOnlyHint=true, destructiveHint=false). The description adds valuable scope context (540+ projects, 369 GW global coverage) and briefly describes the return structure. However, it omits behavioral details like rate limits, pagination behavior beyond parameter definitions, or caching considerations that would help an agent reason about invocation strategy.

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

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

The description is well-structured with clear Args and Returns sections. Given the complete lack of parameter descriptions in the schema, the length is justified and necessary. The opening sentence efficiently establishes scope and scale. No redundant information is present, though the formatting is more verbose than a pure narrative description.

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 7 parameters with zero schema coverage, the description adequately compensates by documenting all parameters and their semantics. It also describes the return value structure sufficiently. The combination of scope metrics (540+ projects), parameter documentation, and return format provides adequate context for tool selection and 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?

With 0% schema description coverage, the description fully compensates by documenting all 7 parameters in the Args section, including critical constraints like date format (YYYY-MM-DD), valid status enum values (planned, under_construction, completed, all), and pagination limits (max 100). This manual documentation effectively substitutes for the 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?

The description clearly states the tool tracks '540+ projects, 369 GW of data center construction pipeline globally' with specific coverage of planned, under construction, and completed projects. It uses specific verbs and quantifies scope, distinguishing it from sibling tools like get_facility or search_facilities which focus on existing infrastructure rather than 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?

While the description lists available filters and return format, it provides no explicit guidance on when to use get_pipeline versus sibling tools like get_facility, search_facilities, or get_market_intel. No prerequisites, exclusions, or decision criteria are mentioned.

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

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

While annotations declare readOnly/idempotent/safety properties, the description adds valuable behavioral context: it specifies 'utility-scale' scope (filtering out residential), notes proximity search capability for data center siting, and documents the JSON return structure ('installations, capacity, and location data'). No contradictions with annotations exist.

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

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

The description uses a standard docstring format (summary, use cases, Args, Returns) that efficiently organizes information. Each sentence serves a distinct purpose: scope definition, contextual application, parameter documentation, and output contract. The structure is appropriate for a 4-parameter tool with zero schema descriptions.

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 summarizes return values without redundant detail. It covers all parameters (necessary due to lack of schema descriptions) and explains the domain context (data center proximity). Could optionally note that all parameters are optional, but otherwise 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?

With 0% schema description coverage, the description fully compensates by documenting all four parameters in the Args section: energy_type enumerates valid values (solar/wind/combined), state specifies format (US abbreviation), and lat/lon clarify purpose (proximity search). This effectively bridges the schema documentation 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 opens with a specific verb-resource combination ('Get renewable energy capacity data') and explicitly enumerates covered asset types (solar, wind, combined). It further distinguishes from siblings like get_energy_prices or get_grid_data by specifying 'utility-scale renewable installations near potential data center sites,' clearly scoping the tool to capacity planning rather than pricing or interconnection.

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 usage context through specific use cases ('sustainability planning, PPA sourcing, and carbon footprint analysis'), helping agents select this tool for procurement and environmental analysis. However, it lacks explicit when-not-to-use guidance or named sibling alternatives (e.g., contrasting with get_energy_prices for market rates).

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 annotations (readOnlyHint, openWorldHint), description enumerates specific incentive types returned (credits, abatements, exemptions, zones) and outlines the JSON structure (programs, criteria, savings). 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?

Well-structured with front-loaded purpose statement followed by Args/Returns sections. Zero redundant text; every sentence conveys specific constraints or return format details. Docstring-style formatting is slightly formal but 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?

Appropriately complete for a single-parameter lookup tool. With output schema present, description provides sufficient narrative summary of return content without replicating full 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?

Excellent compensation for 0% schema coverage. Description specifies parameter format ('US state abbreviation'), concrete examples ('VA', 'TX', 'OH'), and default behavior when empty—fully documenting semantics the schema omits.

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') + specific resource ('data center tax incentives') + scope ('by US state'). Distinguishes from siblings like get_energy_prices or get_facility by focusing specifically on tax policy 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 parameter guidance ('Leave empty for all states summary') and explains the input format with examples. However, lacks explicit comparison against siblings (e.g., when to use get_market_intel 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 establish readOnly and openWorld safety hints; the description adds valuable behavioral context by disclosing the data source ('USGS water stress data') and the nature of the recommendations returned ('actionable cooling recommendations'), which helps the agent understand the external dependency and output utility.

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?

Docstring structure is tight and purposeful: opening sentence establishes scope, second sentence provides usage context, Args/Returns sections document inputs/outputs. No redundant fluff; every line advances agent 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?

Appropriately complete for a read-only lookup tool with 3 parameters. Mentions domain (data centers), data provenance (USGS), use case (cooling decisions), and return format. Output schema exists per context signals, so brief JSON summary is sufficient. Could note that coordinates are optional given defaults exist.

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 (only titles 'Lat', 'Lon', 'State'). The description compensates effectively by documenting all three parameters with types ('Latitude coordinate', 'Longitude coordinate') and format examples for state ('e.g. 'AZ', 'TX', 'VA''). Missing explicit note that parameters are optional (have defaults), but solid given schema inadequacy.

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 ('Get water stress and drought risk') for a specific resource ('data center location'). The mention of 'cooling system design' effectively distinguishes this from generic environmental tools like analyze_site and energy-focused siblings by anchoring to a specific infrastructure concern.

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 contextual guidance ('Critical for cooling system design — determines whether evaporative, air-cooled, or hybrid cooling is appropriate') establishing exactly when this tool is relevant. Lacks explicit naming of sibling alternatives to use instead for non-cooling queries, but the domain specificity serves as implicit 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?

While annotations cover safety profile (readOnly, destructive, idempotent), the description adds crucial behavioral context: database scale ('$324B+'), return format (JSON array with specific fields), and pagination behavior (offset/limit with max 100). 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?

Docstring format with Args/Returns sections is slightly verbose but highly scannable. Every sentence earns its place: industry scope, data scale, filter categories, parameter details, and return structure. Could be tighter but efficiently organized.

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 10-parameter query tool. Fully documents filtering options and return structure despite zero schema descriptions. The '$324B+' metric signals data completeness. Covers pagination, date formats, and geographic scope comprehensively.

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

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

With 0% schema description coverage (only titles like 'Buyer', 'Limit'), the description fully compensates by documenting all 10 parameters including constraints (max 100/default 25), formats (YYYY-MM-DD), and enumerations (deal types, regions). Adds substantial semantic 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?

States specific verb 'Retrieve' with clear resource 'M&A transactions' and domain scope 'data center industry'. The '$324B+ in deals' adds valuable context that distinguishes this from generic transaction tools and aligns with its unique position among infrastructure-focused siblings.

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 no guidance on when to use this tool versus alternatives (like search_facilities or get_market_intel), no prerequisites for filtering, and no warnings about data availability. Only states what filters are available, not when to apply them.

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

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

Annotations establish read-only/idempotent safety, while the description adds valuable operational context: dataset scope ('20,000+ global'), pagination constraints ('max 100, default 25'), and return structure ('JSON array of facilities with id, name...'). It does not contradict annotations.

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

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

The docstring-style structure (summary, Args, Returns) is appropriate and front-loaded. Length is justified given the need to document 10 parameters with zero schema coverage, though the Args list is necessarily dense.

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

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

Comprehensive for a search tool: annotations cover safety profile, description covers filtering dimensions and pagination, and return format is specified. With 0% schema coverage, the description successfully carries the full documentation burden.

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 example operator names ('Equinix', 'Digital Realty').

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 action ('Search and filter') and resource ('20,000+ global data center facilities'), clearly indicating the tool's scope and scale. The plural noun 'facilities' combined with 'Search' effectively distinguishes it from the sibling tool 'get_facility' (singular).

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 lists available filters comprehensively, it provides no explicit guidance on when to use this tool versus siblings like 'get_facility' (for specific facility lookup) or 'compare_sites'. No prerequisites or exclusions are mentioned.

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