Luminus
Server Quality Checklist
Latest release: v0.6.1
- Disambiguation3/5
Many tools have distinct data sources and regions, but the cluster of grid connection tools (e.g., get_grid_connection_queue, get_grid_connection_intelligence, get_nged_connection_signal, get_site_connection_report) overlap in purpose and could confuse an agent. Descriptions are detailed, but boundaries are still fuzzy.
Naming Consistency4/5Most tools follow a consistent get_<domain>_<detail> pattern in snake_case. A few exceptions (screen_site, compare_sites, verify_gis_sources, luminus_status, luminus_discover) deviate slightly, but the overall pattern is predictable and readable.
Tool Count2/5With 44 tools, the server is significantly over the typical 3-15 range for coherent tool sets. The high count makes the tool surface hard to navigate and increases the chance of mis-selection, even if each tool individually earns its place.
Completeness4/5The server covers a broad range of energy data and site-screening needs for GB and EU, including market prices, grid connection, land constraints, and weather. Minor gaps exist (e.g., no explicit GB day-ahead price tool), but core workflows for solar/BESS siting and energy analysis are well supported.
Average 3.8/5 across 44 of 44 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 2 of 2 community issues answered or closed in the last 6 months
- 6 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
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, but it only adds domain context about forced outages and capacity reductions. It does not mention pagination, default limits, filtering behavior, output format, or any access requirements, leaving significant behavioral aspects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short sentences with no redundant content. However, the first sentence is more like a title or label than a functional description, which slightly reduces its effectiveness as a standalone explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters and no output schema, the description gives only minimal context about the data domain. It explains what data is covered but omits information about how results are returned, how to refine queries effectively, or any constraints. The schema fills some gaps, but the overall description underdelivers for a moderately complex energy data source.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter having a description, so the baseline is 3. The description reinforces the meaning of message_type by mentioning 'forced outages' and 'capacity reductions,' but it adds no additional detail about limit, country, or fuel_type beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource (ACER REMIT) and the specific data types (UMMs and outage events), which clearly distinguishes this tool from the broad set of sibling energy data tools. It lacks an explicit verb like 'retrieves' or 'lists,' but the tool name 'get_acer_remit' provides that context, making the purpose clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as get_entsog_data or get_smard_data. There are no exclusions, prerequisites, or contextual recommendations, leaving the agent without decision criteria for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the data types and 'real-time' nature, and notes no API key is required, but does not mention read-only behavior, response format, rate limits, historical depth, or units. For a data retrieval tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with a clear structure, front-loading the key data types. It wastes no words, but could be slightly more informative without becoming verbose. The length is appropriate for the schema richness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should compensate by explaining return values. It does not mention that the tool likely returns time-series data, nor does it clarify the role of the optional 'date' parameter. For a data-fetching tool with 2 parameters, the description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with detailed descriptions for both parameters, including enum explanations for 'dataset' and the date format for 'date'. The description repeats the dataset enum values ('generation, consumption, exchanges, outages') but adds no new meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the tool's purpose: retrieving French electricity data from RTE (eco2mix), naming the key data types (generation, consumption, exchanges, outages). It distinguishes from sibling tools by explicitly naming the French/ RTE source and the data scope, even though it does not name an alternative tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool vs alternatives. The description implies it is for French electricity data but does not mention that other national data sources exist, nor when not to use it. The 'No API key' note is a convenience but not a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It fails to mention limitations, units, time horizons, or data source specifics. The only added context is input flexibility, which is already captured in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two short sentences and front-loaded with the core output. Every sentence contributes essential information, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema or annotations, the description is too sparse to fully prepare an agent. It omits forecast duration, update frequency, units, and response structure, which are critical for correctly invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description's phrase 'Accepts country code or lat/lon' adds no new meaning beyond the schema property descriptions, which already explain the override behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a weather forecast with hourly temperature, wind speed, and solar radiation. This is a specific verb+resource combination, but it does not explicitly differentiate from sibling tools like get_era5_weather.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_era5_weather or get_solar_irradiance. The description only mentions input methods, not selection criteria or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only names the data content and source but does not mention any behavioral traits such as data granularity, time zone, units, availability limitations, or response format. The claim 'Primary BESS revenue data source' hints at relevance but lacks operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short, information-dense sentences. It front-loads the source name and data type, then adds the BESS revenue context. Every word contributes value, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only two parameters and no output schema, the description should provide more context about return values, units, time periods, or data aggregation. It only states 'prices and volumes' without specifying units (e.g., €/MW, MWh) or temporal coverage. For a data source critical to BESS revenue modeling, this is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for both parameters: 'date' has format and default, and 'product' has an enum with detailed definitions for FCR, aFRR, and mFRR. The description adds no extra parameter semantics beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides FCR/aFRR/mFRR reserve tender prices and volumes from Regelleistung.net, naming the specific data domain. It distinguishes itself from sibling energy data tools by specifying the exact reserve products and the primary use case, though it lacks an explicit verb like 'retrieve' or 'fetch'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It mentions 'Primary BESS revenue data source,' which implies the tool is for battery energy storage system revenue analysis, offering some usage context. However, it does not explicitly state when to use this tool versus alternatives like get_flexibility_market or get_auction_results, nor does it provide any exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that no API key is needed and lists the key return types, which is useful. However, it does not mention geographical coverage, limitations, error handling, or output structure, leaving gaps for a data-retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of three short clauses in two sentences. Every word adds value: the source (PVGIS), the outputs, and the no-API-key ease-of-use note. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (3 parameters, no output schema) and lack of annotations, the description is fairly complete. It identifies the data source and key output types. However, it would benefit from a note about when to use this over similar data sources (e.g., ERA5 weather) and any geographical limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does not add parameter-specific information beyond the schema; it mentions outputs like 'monthly kWh/m2' and 'optimal angle' but does not explain how they relate to the lat/lon/year inputs. The schema already handles parameter semantics adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the resource (PVGIS) and the outputs (solar irradiance, PV yield, monthly kWh/m2, optimal angle, annual yield), which differentiates it from sibling tools. It lacks an explicit imperative verb, but the tool name 'get_solar_irradiance' and the accompanying noun phrase make the purpose clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No mention of alternatives, exclusions, or use-case context. The only practical note is 'No API key', which hints at ease of use but does not guide tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden of behavioral disclosure. It does disclose the output content (registered tools, active profile, API keys) which suggests a read-only, status-related operation. However, it does not mention potential side effects, authentication requirements (especially concerning API key exposure), or return format. The description is not misleading but is minimal in behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence: 'Server status: registered tools, active profile, configured API keys'. It is front-loaded with the main concept ('Server status') and every word adds value. There is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (0 params, no output schema, no annotations). The description covers the core purpose and key output fields, but it lacks usage context (e.g., when to call this vs. other server-related tools like luminus_discover) and does not describe the structure of the returned data. For a status tool, this is minimally adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty. Per the baseline, a 0-parameter tool earns a 4. The description does not need to add parameter semantics since there are none. It correctly implies that no input is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: it provides server status including registered tools, active profile, and configured API keys. This distinguishes it from sibling data-retrieval tools (e.g., get_power_plants) which focus on external data, while luminus_status is about the server itself. The use of 'status' implies a read-only introspection operation, though it lacks an explicit verb like 'get' or 'retrieve'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives, nor does it specify any prerequisites or exclusions. It simply lists what the tool reveals. With many sibling tools, an agent could mistakenly use this for data retrieval if not careful. No alternatives are mentioned, and no context is provided for when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions 'No API key' as a behavioral trait, but does not disclose rate limits, data lag, return format, or integration requirements. Minimal behavioral context beyond authentication.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two succinct sentences. The first front-loads the purpose, and the second delivers a key practical note (no API key). Every word earns its place with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple data retrieval tool, the description covers source and data types but omits any indication of output format or return structure. Since there is no output schema, the description could have provided more context, though the detailed schema parameter descriptions partially compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all parameters with detailed enum explanations, so the baseline is 3. The description adds no parameter-specific details beyond listing the data types, which is redundant with the dataset enum descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing Danish electricity data from Energi Data Service, listing specific data categories (CO2 emissions, production, spot prices, balance). This distinguishes it from sibling tools by its Danish focus and the named source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Danish electricity' phrasing implies when to use the tool, and 'No API key' gives a practical prerequisite. However, it offers no explicit comparison to alternatives or exclusion criteria, so usage guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavioral traits. It mentions the data source and units but does not discuss authentication, rate limits, update frequency, or any operational nuances. For a read operation, this is a minimal disclosure that leaves the agent guessing about access and reliability.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core resource, units, source, and scope. Every word earns its place, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, and the description is brief. It covers the general purpose and modes but does not elaborate on return structures, potential limitations, or usage caveats. For a two-parameter tool with a clear enum, it is minimally adequate but leaves gaps for an agent expecting a fully specified contract.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters and the action enum. The description adds marginal context by mentioning 'national, regional, or historical' and 'generation mix', but it does not provide any semantics beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves GB carbon intensity in gCO2/kWh and generation mix from National Grid ESO, and specifies the available scopes (national, regional, historical). This is specific and distinguishes it from sibling tools like get_gb_grid_demand, which focuses on demand.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by outlining the three modes (national, regional, historical), but it does not explicitly state when to use this tool over alternatives or include any exclusions. The enum in the schema covers the selection between actions, but no guidance is given on tool selection among similar data services.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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 API key requirement and the composite read nature, but it does not explain response format, pagination, error behavior, or default data scope when no spatial filter is provided. This is a significant gap for a data-aggregation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-load the core purpose, enumerate key data components, and mention spatial filtering and authentication. Every sentence is informative with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description conveys what data is combined but does not describe the output structure, use cases, or potential limitations. Given the moderate complexity and absence of an output schema, a bit more context about the returned data would be helpful but is not critically missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter described, so the description does not need to repeat parameter details. The description only mentions spatial filtering, which adds no new meaning over the schema's lat/lon/radius descriptions. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a UKPN composite grid overview combining GSP capacity, HV flexibility zones, and live network faults. This specific verb-resource pairing distinguishes it from sibling grid tools like get_distribution_headroom or get_gb_grid_demand.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies spatial filtering use case and notes the API key requirement, but it does not explicitly state when to use this tool over alternatives or mention scenarios where it should not be used. This is adequate context but lacks exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden and adds useful context: no API key required and coverage of all EU TSOs. However, it does not disclose rate limits, data freshness, pagination, or behavior for invalid dates/country codes, so transparency is partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that lists core datasets and key access facts, with no filler or repetition of schema details. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only data retrieval tool with 3 params and no output schema, the description plus rich schema covers dataset selection, date, and country filters. It lacks return format and limitations, but the tool complexity is low and 'No API key' plus 'All EU TSOs' provides enough operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the dataset enum has thorough per-value explanations (e.g., physical_flows = actual flows in GWh/d). The description adds the unit GWh/d and EU-wide TSO coverage but doesn't need to compensate since the schema already documents parameters well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description identifies the resource (ENTSOG gas pipeline data) and enumerates specific datasets (physical flows, nominations, interruptions, capacities), which clearly distinguishes it from sibling energy tools. It lacks an explicit verb like 'returns' but the tool name and data listing make the purpose clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when EU gas pipeline flow, nomination, interruption, or capacity data is needed. It does not explicitly state alternatives or exclusions, such as using get_eu_gas_price for price data, but the ENTSOG gas specificity is an implicit usage signal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It adds useful behavioral facts: data source (OSM Overpass) and no API key required, plus hints at output fields (distance, voltage, operator). But it omits whether the result is a single nearest item or a list, and gives no information about rate limits or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It front-loads the purpose and then adds source and authentication context. Every phrase earns its place, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no annotations, and no output schema, the description is somewhat thin on result shape and edge cases. It explains the source and key requirement but leaves 'nearest' ambiguous (singular vs. list) and does not describe the return format. However, parameter coverage is strong, so it is not severely incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-specific semantics beyond the schema; the mention of 'distance, voltage, operator' appears to describe output features rather than parameter usage. The schema already documents latitude, longitude, radius, and voltage minimum adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('get') and resource ('nearest grid infrastructure' including substations and HV lines within a radius). The 'nearest' and 'within a radius' qualifiers distinguish it from broader grid tools like get_transmission_lines, giving it a clear, scoped purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied: use this when you need grid infrastructure near a point. However, there is no explicit guidance on when to prefer this over siblings such as get_grid_connection_queue or get_transmission_lines, nor any exclusions or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It discloses the data source, variables, countries, and the fact that no API key is needed, but lacks details on units, update frequency, or data latency. Calling it a 'proxy' is a useful caveat, but more behavioral context would be expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the main purpose and key details (source, variables, countries, no API key). Every word earns its place; there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only two well-documented parameters, the description is adequate. It tells the agent what the tool does and its scope. However, without an output schema or any note on return format, the agent must guess what the response looks like, which is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage of both parameters with descriptions, so the baseline is 3. The description adds extra context about countries and variables, but does not add meaning beyond what the schema already explains, such as how the period values affect the output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: provides a hydro inflow proxy using specific ERA5-Land variables for a set of countries. It distinguishes itself from generic weather tools like get_era5_weather by focusing on a derived proxy and naming the exact geographical scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the phrase 'Hydro inflow proxy' and the listed countries, but there is no explicit guidance on when to choose this over alternatives, nor any exclusions. The 'No API key' note is helpful but not enough to fully direct an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses useful behavioral traits: data sources differ by country (Natural England vs EEA Natura 2000), it's a 'hard exclusion check', and 'No API key' is required. However, it does not describe return format, error behavior, or whether any special permissions are needed, leaving significant gaps for a screening tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, each adding value: purpose, geographic/dataset specificity, and a practical detail (no API key). No fluff or redundancy, and the main purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should explain what the tool returns, but it only says 'screening' without detailing output structure or criteria. It does cover purpose, geographic scope, data sources, and the no-API-key aspect, but the missing return semantics and error handling make it incomplete for a screening tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all four parameters. The description adds that 'country' determines which data source is used (GB vs EU), but this is also implied in the schema's country description. No new syntax or additional meaning beyond the schema is provided, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs 'land-constraint screening within a radius' and specifies 'hard exclusion check for PV/BESS siting', distinguishing it from sibling tools like get_land_cover or get_agricultural_land. The verb 'screening' plus the resource 'land constraints' and radius scope make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for PV/BESS site screening via 'hard exclusion check', and clarifies geographic coverage (GB vs EU). However, it does not explicitly state when to use this tool over alternatives like get_land_cover, get_flood_risk, or screen_site, nor does it provide any when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It discloses the data source (SMARD/BNetzA), the data granularity (hourly), and the authentication requirement (no API key). However, it does not mention response format, rate limits, supported time ranges, or any operational limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the key facts (German, SMARD, hourly data types, no API key). No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema), and the description covers the data domains. However, it lacks context about the output structure, time range of data returned, or whether data is real-time/historical. Given the simplicity, it is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter coverage, including a description for the 'dataset' enum. The tool description adds no extra parameter-level semantics beyond what the schema already provides. Baseline 3 is appropriate given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource+scope: "German electricity from SMARD (BNetzA): hourly generation, consumption, market data." It clearly distinguishes this tool from sibling tools like get_gb_grid_demand (UK) and get_eu_gas_price (EU) by explicitly naming the German source and data categories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for German electricity data but does not explicitly state when to use this tool versus alternatives. It notes "No API key" as a practical prerequisite, but there is no mention of exclusions or alternative tools for other regions or data types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It lists data categories and zones, but does not mention units, response format, pagination, or any access constraints. Since this is a read-only data retrieval tool, the risk is low, but the absence of either annotations or explicit behavioral details keeps this at a neutral 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the tool's purpose ('Italian electricity from Terna'), followed by a list of data types and zones. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters, one required, and no output schema. The description gives a valuable overview but does not specify return structure, units, or formatting. Since the data types are listed but not explained in detail, completeness is only moderate for an agent need to understand what exactly will be returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage with descriptions for all three parameters. The description adds minor context by listing zone names and data categories, which loosely maps to the parameters but does not go beyond the schema in any significant way. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as Italian electricity data from Terna, listing specific data types (generation, demand, exchanges, zonal prices) and zones. This distinguishes it from sibling tools like get_rte_france or get_smard_data, though it lacks an explicit verb like 'retrieves' or 'provides'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: this tool is for Italian electricity data from Terna. It implies when to use it (if you need Italian grid data) without needing to reference alternatives. However, it does not explicitly state when not to use it or mention similar tools, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that results are from OSM and that the endpoint is rate-limited. It also notes the default voltage floor. But it omits response format, geometry details, pagination behavior, and error semantics, which are critical for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one telegraphic sentence, front-loaded with the resource name. Every clause—source, attributes, filter mechanism, default, and rate limit—adds value without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must explain behavior and return values. It lists returned attributes and key filters, but doesn't specify the response structure (e.g., GeoJSON, array shape) or pagination/limit semantics beyond a bare rate-limit warning. This is adequate for selection but incomplete for full invocation confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all 7 parameters (100% coverage), so the baseline is 3. The description's 'Filter by country/bbox' and '220kV+ default' merely restate schema property descriptions without adding new meaning. No additional parameter context is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'HV transmission lines from OSM', clearly identifying the resource and source. It enumerates returned attributes (voltage, operator, cables, coordinates) and mentions filtering, distinguishing it from sibling tools like get_power_plants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates filtering by country/bbox and a default 220kV+ threshold, implying use cases for high-voltage network queries. However, it does not explicitly state when to prefer this tool over siblings or provide usage exclusions, leaving the agent to infer from resource naming.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does state the core read-only behavior ('List'). However, it does not disclose additional behavioral traits such as output format, pagination, or what exactly 'profiles' means, which limits transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is appropriately concise for a tool with a simple purpose and two optional parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 optional params, no output schema, no annotations), the description is adequate but not fully complete. It does not explain what a 'profile' is, what the output looks like, or how to interpret the list, which would help an agent use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters with descriptions (100% coverage), so the schema already provides the needed semantics. The description adds no additional parameter meaning beyond what is already structured.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a clear resource ('available Luminus tools and profiles'), which distinctly separates this tool from the many data-retrieval siblings that fetch specific datasets. It clearly indicates a discovery/metadata operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for discovering available tools and profiles, but does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. The context is clear but not fully guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It focuses on return content rather than behavior, omitting details such as data history, availability, rate limits, or whether results are limited to published auctions. There is no mention of access constraints or 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the source, data granularity, and key fields without any filler. Every word earns its place, making it highly efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only 2 parameters and no output schema, so the description is the primary source for return values. It communicates the main fields (allocated MW, price, offered capacity) and source adequately. However, it could be more explicit about the result structure (e.g., grouped by corridor) or any limitations, but given the low complexity, this is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides full descriptions for both date (format) and corridor (examples and available list). The description's mention of 'per corridor' and price units adds minimal context beyond the schema. With 100% schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the specific resource: cross-border capacity auction results from JAO. It lists the key data fields (allocated MW, price in EUR/MW, offered capacity) and the per-corridor scope, which distinguishes it from sibling tools like get_transmission_lines or get_nordpool_prices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this tool to obtain cross-border capacity auction results from JAO, with details per corridor. It does not explicitly mention alternatives or exclusions, but no sibling tool covers this exact data, so the usage context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses useful behavioral traits: no API key required and return scope (latest, 5-day history, stats). However, it does not explain what 'stats' means, specify output format, or explicitly state read-only behavior, leaving some gaps for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with three concise clauses: what it returns, the time/history scope, and the auth requirement. Every phrase adds value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description covers the essential context: exact commodities, time range, and authentication. It lacks details on output structure and the meaning of 'stats', but overall it is sufficiently complete for straightforward price retrieval, especially given the schema's richness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each enum value well-described. The description adds minimal additional parameter meaning beyond listing commodity types, but since the schema already handles semantics fully, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning EU commodity prices with specific commodities (EUA carbon, Brent crude, TTF gas) and a defined scope (latest + 5-day history + stats). This is a specific verb+resource+scope that effectively distinguishes it from most sibling tools by naming exact instruments, though overlap with get_eu_gas_price is not addressed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool by stating it provides EU commodity prices, but it offers no explicit guidance on when to use it versus alternatives like get_eu_gas_price or get_smard_data. No exclusions or alternative tool names are mentioned, so usage context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that UKPN supports spatial matching while SPEN returns results alphabetically without coordinates, and that an API key is required for both operators. This is meaningful behavioral context, though it does not cover rate limits or 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, each providing distinct value: purpose, operator-specific behavior, and authentication requirement. It is front-loaded with the core function and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich schema, the description covers the main functionality, operator differences, and API key requirement. However, it omits ENWL and the 'all' operator option from the description, and is missing guidance on output/pagination, preventing a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes all 7 parameters with 100% coverage, so the baseline is 3. The description adds operator-specific context (e.g., SPEN has no coordinates, affecting radius_km), but does not provide significant additional parameter semantics beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the UKPN and SPEN Embedded Capacity Register, showing connected/accepted generation and storage near a location with energy source, capacity, and connection status. However, it only names UKPN and SPEN while the schema also supports ENWL and 'all', which is a slight omission that affects full clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for getting embedded capacity data from UKPN/SPEN near a location, and mentions operator-specific behavior (spatial vs alphabetical). However, it does not explicitly state when to use this tool over sibling tools or when to avoid it, so guidance is present but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses useful traits: no API key, hourly resolution, time range, and variable categories. However, it omits return format, units, rate limits, or error behavior, leaving significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, compact sentence that front-loads the core purpose ('ERA5 weather reanalysis via Open-Meteo') and packs essential details (variables, time range, no API key) without any redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should clarify return values. It conveys the data source, variables, and time range effectively, but does not specify output format, units, or aggregation. However, the tool is relatively simple and the schema covers parameter semantics, so the missing bits are minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description mentions variables and time range but does not add substantial meaning beyond the already-detailed schema descriptions (e.g., latitude/longitude ranges, variable definitions, date formats).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a specific resource (ERA5 weather reanalysis via Open-Meteo) and scope (hourly wind, solar, temperature; 1940 to ~5 days ago). It distinguishes itself from siblings like get_weather_forecast by explicitly stating 'reanalysis' rather than forecast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The time range '1940 to ~5 days ago' implies historical use, and 'reanalysis' suggests not for real-time forecasts. However, there is no explicit when-to-use guidance, exclusions, or mention of alternatives like get_weather_forecast or get_solar_irradiance, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does disclose the data source (Environment Agency), the coverage limitation (England only), and that no API key is required, which is useful. However, it lacks details on return format, error behavior, or update frequency, which are important for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: it opens with the tool's purpose, then details the checks performed, and finishes with key constraints. Every sentence adds essential information with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's moderate complexity and lack of an output schema, the description only vaguely says it 'summarises planning risk' without specifying the output structure, risk categories, or any additional data. This leaves significant gaps for an agent trying to interpret the tool's results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all three parameters, so the baseline is 3. The description adds meaningful context beyond the schema by stating 'England coverage only,' which clarifies that only lat/lon coordinates within England are valid despite the country code 'GB' being accepted. This refines the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's specific function: it checks Environment Agency Flood Zone 2, Flood Zone 3, and flood storage areas, and summarises planning risk. This distinguishes it from sibling tools like get_terrain_analysis or get_agricultural_land, which address different site constraints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for flood planning on English sites, and notes limitations (GB input, England coverage only), but it does not explicitly state when to use this tool over alternatives or when not to use it. No alternative tools are referenced, so usage guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool provides both actual and forecast demand, and mentions frequency deviations indirectly via the schema. However, it does not state that this is a safe read-only operation, whether any authentication is needed, or return format details beyond units. This is adequate for a simple data retrieval tool but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the key data types and source. Every word contributes value, with no filler or repetition of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers the essential information: data type, units, and source. The schema explains the parameter choices. Without an output schema, the description does not detail response structure, but the provided units and data types give sufficient context for the agent to understand what will be returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema provides detailed descriptions for the 'action' parameter including the distinction between 'demand' and 'frequency' and what each returns. The tool description adds no additional parameter meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the resource (GB demand and grid frequency), includes units (MW, Hz), and identifies the source (National Grid ESO). It distinguishes from sibling tools like get_eu_frequency by explicitly scoping to Great Britain, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied through the data description ('GB demand', 'grid frequency') but there is no explicit guidance on when to choose this tool over alternatives such as get_elexon_bmrs or get_smard_data. No alternative tools are named, so the agent must infer suitability from domain knowledge.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It adds useful specifics: the 15-minute resolution and the no-API-key requirement. However, it does not mention output format, error behavior, rate limits, or whether it is purely read-only. This is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that packs in the source (Nordpool), product (day-ahead prices), resolution (15-min), geographic scope (Nordic/Baltic, detailed areas), and a key access trait (no API key). Every word earns its place, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should inform the agent what the return data looks like. It only says 'prices' without specifying the structure, units, or whether timestamps and area labels are included. While the tool is simple and the parameters are well documented, the lack of output expectations leaves a notable gap for an agent to fully anticipate the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides complete descriptions for all three parameters, including examples and an enum for currency. The description's mention of areas ('SE1-4, NO1-5, DK1-2, FI') is redundant with the schema's detailed list. With 100% schema description coverage, the description adds minimal value beyond what the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves Nordic/Baltic day-ahead prices from Nordpool, with a 15-minute resolution and specific area coverage. This distinguishes it from siblings like get_smard_data (German market) or get_rte_france (French market), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use this tool: when Nordic/Baltic day-ahead prices are needed. The note 'No API key' hints at lower friction compared to other tools, but it does not explicitly name alternatives or exclusions. Still, the geographic scope is a strong usage indicator.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the underlying Open-Meteo API and the lack of an API key, which is useful. However, it omits response format, error behavior, and 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the tool's purpose and outputs, followed by relevant data-source and authentication details. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with no output schema, the description covers the essential context: what it computes, its data source, and auth requirements. It lists the output metrics, partially filling the gap left by the missing output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents lat and lon with ranges and WGS84 datum, and coverage is 100%. The description adds no extra parameter meaning beyond labeling them as a location.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as performing terrain analysis for a location, listing specific outputs (elevation, slope, aspect, flatness score). This distinguishes it from sibling tools focused on weather, grid, or land-use data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose implies use when terrain metrics are needed, but no explicit guidance contrasts it with alternatives like get_land_constraints or get_flood_risk. There are no when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It discloses key logic: NESO boundary matching, fallback to nearest GSP, and conditional addition of SSEN/NGED data. It also includes a critical disclaimer ('Not a connection offer or capacity guarantee'). It could mention return format or rate limits, but for a read-only aggregation tool, this is strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence that front-loads the tool's purpose and efficiently packs multiple clauses about data sources and conditions. While it could benefit from bullet points, it contains no filler and earns its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex aggregation tool with no output schema. The description explains the resolution logic, fallback behavior, data sources, and limitations, providing substantial context. It doesn't describe the return structure or possible empty results, but overall it covers key aspects adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all four parameters. The description adds no extra parameter-level detail beyond the schema. Baseline 3 applies because the schema already handles parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: it resolves a GSP region, falls back to the nearest GSP, and aggregates grid connection context (TEC register, substations, SSEN headroom, NGED queue). This is a specific verb+resource description that distinguishes it from sibling tools specializing in individual data sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies usage for GB grid connection assessment with 'GB grid connection intelligence' and conditional data coverage. However, it doesn't explicitly state when to use this tool vs alternatives, nor does it provide exclusions or reference the sibling tools that offer more focused data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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 reveals that the tool prefers post-1988 Natural England surveys, falls back to provisional ALC, and flags BMV risk. It also mentions 'No API key' and geographic coverage, providing useful context about data sourcing and access requirements. It does not describe the exact return format, but the behavioral traits are well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-structured sentence that front-loads the core purpose, then adds essential details about data sources, fallback behavior, geographic limitation, and authentication requirements. Every clause adds value, with no redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a relatively simple lookup tool with three well-defined parameters and no output schema, the description is largely complete. It covers what the tool does, how it prioritizes data, fallback behavior, geographic scope, and authentication needs. It leaves out the response structure, but given the lack of an output schema, the description still provides a robust contextual picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for all three parameters, including types and descriptions. The description adds minimal parameter-specific detail, only reinforcing that the country must be GB and coverage is England-only. This does not exceed the baseline for tools with full schema_description_coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: providing Agricultural Land Classification for an English site. It goes beyond the name by specifying the classification system, the geographic scope (England only), and unique features like flagging Best and Most Versatile land risk. This distinguishes it from sibling tools such as get_land_constraints or get_land_cover.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for agricultural land classification in England, noting 'GB input, England coverage only' which tells the user not to use it for other countries. However, it does not explicitly mention when to prefer this tool over alternatives or provide exclusions relative to sibling tools. The guidance is mostly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses a key prerequisite ('Requires API key') and hints at output content (duration and energy lost), but it does not mention pagination, rate limits, data latency, or other behavioral traits. The statement is helpful but not rich enough to score higher.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loaded with the core purpose, followed by the use case and a requirement. Every sentence contributes value: what it is, what it shows, why it matters, and what is needed to use it. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description adequately communicates the data returned (history, duration, energy lost), the use case for BESS siting, and the API key requirement. It could be more complete by mentioning parameter defaults or response shape, but the schema covers parameters and the description covers the essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all four parameters with descriptions, providing 100% coverage. The description adds no parameter-specific guidance beyond what the schema already offers, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as 'UKPN grid constraint breach history' and specifies it 'Shows where and when network constraints triggered DER curtailment, with duration and energy lost.' This is a specific verb+resource+scope and is well differentiated from siblings like get_ukpn_grid_overview or get_flexibility_market by focusing on constraint breaches and curtailment events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context via 'Direct signal for BESS siting — frequent breaches indicate flex revenue opportunity.' This tells the agent when the tool is useful, though it does not explicitly state when not to use it or name alternatives, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses 'No API key,' which is a useful access requirement, and implies a read-only operation through the 'get' verb. However, it does not mention rate limits, response format, or other operational behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence with no filler. It front-loads the main purpose and ends with a critical access note, every element earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the tool's scope and datasets, but without an output schema it leaves the return structure implied. The sibling tool context is not directly addressed, though the unique data source and dataset list help the agent distinguish it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all parameters with 100% coverage, including the enum values and the date format. The description's list of data types echoes but does not add new semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's scope: 'GB balancing mechanism from Elexon BMRS' and enumerates the available datasets (cashout prices, generation by fuel, bids/offers, system warnings, interconnectors), clearly distinguishing it from sibling tools by naming the specific data source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context on what data this tool serves, but does not explicitly state when to use it over alternatives or list exclusions. The mention of 'Elexon BMRS' and the dataset list effectively guide selection among similar GB energy tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It adds useful behavioral context: no API key required, faster performance than ENTSO-E, and geographic coverage (EU excluding GB). It stops short of disclosing response format or potential rate limits, but the provided traits are relevant and beyond what the schema offers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that front-loads the provider and key data types, then covers scope and performance advantages. Every word adds value, and it avoids repetition of schema content. It is an efficient and well-structured summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a well-documented schema and no output schema, the description covers the core context: data source, data types, geographical scope, and access requirements. It does not mention the return format (e.g., JSON data vs chart images) nor the additional dataset types not listed in the description (demand, signal, installed_capacity), but those are available in the schema. Overall, it gives enough context for an informed choice, though a little more clarity on return type would make it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers 100% of parameter descriptions, so the baseline is 3. The description mentions 'prices (15-min)' which mirrors the schema's dataset description for 'prices', thus adding no new parameter-specific meaning. It does not clarify zone code conventions or date handling beyond what the schema lists, so it neither improves nor harms the parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description specifically identifies the provider (Fraunhofer ISE) and the data types provided (prices, generation by fuel, cross-border flows) with a resolution detail (15-min). This clearly communicates what the tool does and distinguishes it from sibling tools like get_nordpool_prices or get_smard_data by naming a unique data source and scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool via 'Faster than ENTSO-E' and notes the exclusion of GB ('All EU except GB'), which gives some context. However, it does not explicitly name alternative tools for GB data or for other scenarios, nor does it state when not to use this tool beyond the GB exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the API key requirement and indicates a read-only operation ('Shows historical flex activations'). However, it does not describe rate limits, pagination, error behavior, or what happens without a valid API key, leaving significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, front-loaded with the core purpose. It avoids redundant phrasing and clearly conveys the tool's function, use case, and authentication requirement without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a data retrieval tool with no output schema, the description provides useful context: the data source (UKPN/SPEN), the type of data (historical flexibility dispatches with pricing, zones, providers, tech types), the intended use case, and the API key requirement. It does not explain return formats or pagination, but the combination of schema and description is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter (days, zone, limit, operator) is fully documented in the schema. The description adds no extra parameter-level detail beyond what the schema already provides. It mentions output attributes (pricing, zones, providers) but not parameters, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool fetches UKPN and SPEN flexibility market dispatches, specifically historical flex activations with pricing, zones, providers, and technology types. This is a specific verb+resource combination that distinguishes it from sibling tools like get_gb_grid_demand or get_weather_forecast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states a use case: 'Use to assess flex revenue potential for BESS sites.' This provides clear context for when to use the tool. However, it does not mention alternatives or exclusions (e.g., other flexibility market tools), so it's not a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It adds useful context like 'No API key' and that it draws from a public register, while noting the output is an aggregate signal, not a guarantee. However, it does not disclose rate limits, data freshness, pagination behavior, or explicitly state read-only semantics, leaving notable gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core resource, followed by usage and exclusions. Every sentence adds value with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 optional parameters and no output schema, the description gives a solid overview: data source, filterable fields, output shape (projects + aggregated MW), exclusions, and auth requirement. It lacks some details like result limits or update frequency, but the shape and scope are clear enough for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description mentions the searchable fields (connection site, project, host TO, technology, status, agreement type) and explains that results include aggregated MW by site, but it does not add per-parameter meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as 'GB transmission connection-register signal from NESO's public TEC register' and the action as searching and retrieving matched projects plus aggregated MW. It also distinguishes itself by explicitly stating it is 'not a DNO headroom map or a guaranteed connection offer', which separates it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-not-to-use guidance via the exclusions ('not a DNO headroom map or a guaranteed connection offer'), which helps an agent avoid misusing it for DNO headroom or guarantee checks. It lacks explicit named alternatives, but the search fields and intended use case are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It does reveal the data source (OPSD) and return fields (name, capacity, fuel, location, year), which is useful. Yet it omits details on pagination, rate limits, or how multiple filters interact, leaving moderate transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences with no filler. It front-loads the tool's identity and scope, and each sentence contributes essential information about the registry, its fields, and filtering options.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with three optional parameters and no output schema, the description adequately covers the data source, returned fields, and filter options. The schema fills in parameter specifics, so the description is nearly complete. Minor additions like result limits or data update frequency could improve it but are not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter already well described (e.g., ISO country code, case-insensitive partial match, default min capacity). The description's 'Filter by country/fuel/capacity' simply lists the same parameter names without adding syntax or format details, providing no additional value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a 'European power plant registry from OPSD' and lists the fields (name, capacity, fuel, location, year) and filter options. This specificity distinguishes it from sibling tools like get_transmission_lines or get_gb_grid_demand.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clarifies that the tool is for European power plant data and mentions filtering by country, fuel, and capacity, implying when to use it. However, it does not explicitly state when not to use it or name alternative tools, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explains the output (structured memo with traffic lights driven by published upstream signals) and clearly states what the tool does not provide. However, it does not explicitly mention read-only behavior, data freshness, or potential operational delays, which are minor gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three well-structured sentences: scope ('GB-only per-site'), content ('Aggregates...'), and limitations ('Not a...'). Every sentence adds value and information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's scope, aggregation logic, and key caveats despite lacking an output schema. It could be more explicit about the output format or data source timeliness, but it is sufficiently complete for an agent to understand what the tool offers.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents each parameter (lat, lon, radius_km, project_name, capacity_kind). The description adds no additional parameter-level meaning beyond stating the report is per-site, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it aggregates existing Luminus tools into a structured memo with traffic lights, distinguishing it from sibling tools by naming those components. It also explicitly disclaims being a connection offer, capacity guarantee, or Gate 2 decision, leaving no ambiguity about its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for a comprehensive per-site connection context, but does not explicitly name alternatives such as using individual tools (e.g., get_flood_risk alone). The 'Not a...' clauses provide exclusions but no direct 'when not to use' guidance compared to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses the API key requirement and the three data sources combined, which is useful. However, it lacks details about output format, data freshness, or limitations, leaving some behavioral aspects opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four short, focused sentences: purpose, data components, filtering, and authentication. It is front-loaded with the essential information and contains no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with no output schema, the description adequately explains what the tool does and its main filter. It would benefit from explaining the acronym SPD and describing the result structure, but it provides sufficient context for a competent agent to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described, so the baseline is 3. The description adds no new parameter meaning beyond the schema, only restating the GSP filter. It doesn't mention the days parameter or clarify any format expectations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides SP Energy Networks composite grid intelligence, enumerating the specific data components (GSP queue positions, DG connections network capacity, curtailment events). It identifies a unique resource (SPEN) and differentiates from sibling tools focused on other networks or single data types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete usage context: it's for SPEN grid intelligence, with filtering by GSP name and an API key requirement. It does not explicitly mention alternative tools or when not to use it, but the SPEN scope and composite nature make the use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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 internal execution ('Runs screen_site on each point'), the ranking methodology, the transparent heuristic reasoning output, and the 'No API key' authentication requirement. This adds meaningful behavioral context beyond the schema, though it could mention potential latency, error conditions, or exact output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with precise information: action, input range, method, criteria, output, supported regions, and authentication. No filler or redundancy. The most important info (comparison/ranking) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given moderate complexity and no output schema, the description adequately covers purpose, process, and output nature. It could improve by specifying the structure of the ranking result or notable side effects, but overall it's sufficiently complete for an agent to decide invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage of all four parameters with detailed descriptions. The tool description adds the constraint '2-10' (also present in schema) and mentions ranking criteria, but it doesn't deepen parameter understanding beyond schema. The high schema coverage makes a baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Compare and rank') and a clear resource ('2-10 candidate PV/BESS sites'), then details the ranking criteria (verdict, solar resource, grid proximity, terrain). It distinguishes itself from sibling tools by explicitly noting it 'Runs screen_site on each point,' establishing itself as a multi-site aggregation tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear context is provided: use for 2-10 candidate sites, supported regions (GB and EU member states), and no API key required. It also implies a multi-site comparison use case by referencing screen_site as a sub-step, but it does not explicitly state when not to use it or name alternative tools (e.g., screen_site for single-site screening).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses that this is a public lookup, finds specific data, and explicitly states what it is not ('Not a connection offer or firm capacity right'). It does not explicitly state whether it is read-only or mention rate limits, but the nature of the operation is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four concise sentences, front-loaded with the primary verb and resource, and each sentence adds distinct value (scope, data types, limitations). No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description adequately communicates the tool's purpose, the DNO scope, the output content (sites, headroom, constraints, reinforcement timing), and a key caveat. It could specify response format or that results are estimates, but overall it is complete enough for a lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage of parameters, so the description does not need to add much. It does reinforce the operator list and adds the 'key' qualifier for some DNOs, but the schema already explains lat/lon, limit, radius_km, and operator values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('lookup', 'Finds') and identifies the exact resource (DNO headroom for five named GB operators). It distinguishes from siblings by specifying the data types (GSP/BSP/primary sites, generation and demand headroom, constraints, reinforcement timing) and adds a limitation disclaimer ('Not a connection offer').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states which operators are covered and that it uses public data, giving clear context for when this tool is relevant. It does not explicitly name alternative tools or exclusions (e.g., 'use get_grid_connection_queue for queue data'), so it lacks explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
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 real-time nature and the interpretive meaning of deviations, but does not mention data source, update frequency, or coverage specifics. Some behavioral context is added, but limitations remain unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the measurement units, status, and domain meaning, with no redundant or filler content. Front-loaded with the primary output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter read tool, the description covers what data is returned (frequency, deviation, status) and adds interpretive value about deviations. It could specify the data source or whether the value is a European aggregate, but it is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is 100% trivially. The description does not need to explain parameters, and the baseline for zero-parameter tools is appropriately 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides real-time EU grid frequency with specific measurements (Hz, mHz) and status, making the resource and scope explicit. It is easily distinguished from sibling tools, none of which cover grid frequency.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving EU frequency data, and the context note about deviations signaling imbalance suggests when it is relevant. However, it does not explicitly state alternatives or exclusions, though no sibling covers frequency.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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 transparently states that no API key is needed (auth), specifies units (EUR/MWh) and hubs (TTF/NBP), and indicates the data range (latest + daily history). It does not detail rate limits, response format, or error behavior, but for a read-only data retrieval tool, the key behavioral aspects are sufficiently disclosed. The 'Spark spread, gas-power switching' line is a minor ambiguity but does not contradict the core behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: it starts with the core purpose ('EU gas prices'), then gives essential details in short, scannable phrases (hubs, history, no API key, spark spread). Every sentence contributes useful information, and there is no fluff or repetition of the tool name. It earns a perfect score for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, enums, full schema coverage) and the absence of an output schema, the description does a good job of covering the key context: what data is available, the units, hubs, and the convenience of no API key. It mentions 'spark spread' and 'gas-power switching' which hints at additional derived data, though not fully elaborated. For a focused data-retrieval tool, this is reasonably complete, but could benefit from a bit more detail on the response structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters (hub and period) with exhaustive descriptions, including enum values and units. Schema description coverage is 100%, so the baseline is 3. The tool description adds some context like 'EUR/MWh' and 'European benchmark' for TTF, but these are already implied in the schema for hub. No additional parameter semantics are provided beyond the schema, so a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: retrieving EU gas prices for TTF or NBP hubs. It specifies the resource (gas prices) and distinct hubs, which differentiates it from sibling tools focused on power grids, weather, or other energy data. The verb 'get' is implicit in the name, and the description enhances it with specific units and data granularity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use the tool: for EU gas prices, with specific hubs (TTF/NBP) and time periods (latest/history). It also notes that no API key is required, which is a practical usage hint. However, it does not explicitly mention alternative tools or exclusion criteria, so it stops short of full guidance. The 'gas-power switching' mention implies a use case but not an explicit alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the rule-based nature, the possible result values (pass/warn/fail/not_applicable), the inclusion of reference URLs, and the explicit limitation that it is not a prediction of Gate 2 outcome. This is strong behavioral disclosure beyond simple read/write status.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with no padding. The first sentence immediately identifies the tool's purpose, and each subsequent sentence adds essential value (evaluation method, output format, caveat).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description adequately explains what the tool returns (per-rule pass/warn/fail/not_applicable with reference URLs). It covers the main behavioral and output aspects, though it could theoretically mention how to interpret a final outcome, but the 'not a prediction' caveat covers the key interpretive risk.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 9 parameters thoroughly. The description adds no additional parameter-level detail beyond referring to 'project inputs', which is adequate but does not go beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a rules-based Gate 2 readiness checklist, evaluating project inputs against NESO entry criteria and returning per-rule results. This is a specific verb+resource that distinguishes it from sibling data-retrieval tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is for project inputs and assesses Gate 2 readiness. It does not explicitly state when to use it over alternatives, but no sibling tool performs this function, so the usage context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the output structure (3-digit CLC code, label, group, exclusion flag) and the auth requirement ('No API key'), though it does not describe error handling or behavior for out-of-coverage points.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
All five sentences serve a distinct purpose: purpose, returns, coverage, exclusion, auth. No filler or redundancy; the core purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple point-lookup tool, the description explains return values and limitations sufficiently. The absence of an output schema is compensated by the explicit list of return fields, though it could mention how to interpret the planning-exclusion flag.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no parameter syntax details beyond the schema; it does reinforce the country restriction, but that is already in the schema's country description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Land-cover classification for a point using CORINE Land Cover 2018.' It clearly distinguishes from sibling tools by naming the data source and return fields, including the planning-exclusion flag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear geographic context with 'EU27 + EEA/EFTA only' and explicitly excludes Great Britain, indicating when the tool is not applicable. However, it does not name an alternative tool within the description itself; the alternative is only present in the input schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and explains the two-step process: resolving the site to a GSP and returning records where covered. It also clarifies the interpretation of results ('Not headroom, a connection offer, or a firm capacity right'). It omits details like pagination, error cases, and response format, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences. The first front-loads the purpose and process, the second provides a clear disclaimer. Every word earns its place, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no output schema, and no annotations, the description covers purpose, scope, and caveats well. It conveys what the tool does and what it does not guarantee, but lacks explicit response structure or edge-case behavior (e.g., when GSP is not covered). Overall, it is sufficient for selection but not fully complete for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the 5 parameters, so baseline is 3. The description adds little beyond the schema—it contextualizes lat/lon/country as a 'GB site' but does not explain parameters further or add syntax/format details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it resolves a GB site to its NESO GSP and returns NGED's per-GSP connection queue and TD-limit records. It also distinguishes itself from related concepts by explicitly stating 'Not headroom, a connection offer, or a firm capacity right,' which helps differentiate it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys when to use this tool by emphasizing 'NGED-only' and stating what it is not (headroom, connection offer, firm capacity right). However, it does not explicitly name sibling tools like get_distribution_headroom or get_grid_connection_queue, so it lacks explicit when-not-to-use alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It transparently describes the operation (pings endpoints), the outputs (status, response time, source metadata), and lists all sources covered. It could mention potential slowness or error handling, but the core behavior is well disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the main purpose, followed by a valuable list of sources and a usage directive. Every sentence earns its place without filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, sources, output content, and usage timing. Since there is no output schema, it effectively tells the agent what to expect. It is slightly ambiguous whether results are aggregated, but it is adequate for a health-check tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameter descriptions, including the optional source_id, an example value, and behavior when omitted. The description text adds no additional parameter semantics beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a health check for GIS data sources, listing the specific providers and endpoints it covers. The verb 'verify' and the explicit actions ('pings', 'reports status, response time, and source metadata') distinguish it from sibling data retrieval tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: 'Use before relying on GIS tool results.' This clearly signals when to invoke the tool. However, it does not explicitly mention alternatives or when not to use it, which would earn a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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 reveals the return format (pass/warn/fail with layers_available/layers_unavailable) and notes the lack of API key requirement. It does not mention rate limits, error behavior, or side effects, but for a read-only screening tool this is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: two sentences that front-load the purpose, itemize the scope, and state the output. Every word earns its place with no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and lack of output schema, the description covers the essential points: what it does, where it applies, what layers are used, and what it returns. It doesn't explain how verdicts are computed, but that is not required for selection and invocation. Minor gaps like exact EU country support are handled in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for all four parameters, giving a baseline of 3. The description adds meaning by explaining how the 'country' parameter influences the analysis (GB-specific layers vs EU-specific layers including Natura 2000 and CORINE), which goes beyond the schema's generic ISO code note.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Composite PV/BESS site screening') and clearly defines the resource and scope: GB and EU locations. It enumerates the factors included (terrain, grid, solar, land constraints, etc.), which distinguishes it from sibling tools that focus on individual layers or data sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description establishes clear context: this is a composite screening tool for PV/BESS across GB and EU, returning a verdict. It implicitly signals when to use it (for an integrated multi-criteria assessment) but does not explicitly state when to prefer alternative sibling tools or provide exclusions. The 'No API key' note adds practical usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/kitfunso/luminus'
If you have feedback or need assistance with the MCP directory API, please join our Discord server