swiss-energy-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.4.1
Disambiguation3/5
Several tools overlap: energy_find_power_plants covers all plant types, while the specific find tools (wind, hydro, PV, biogas) duplicate the same search for a single category. Although descriptions clarify the extra details each specific tool provides, an agent could select the wrong one for a given task. Other tools like energy_solar_potential and energy_check_status are clearly distinct.
Naming Consistency3/5
The energy_find_* tools follow a consistent verb_noun pattern, but energy_solar_potential and energy_location_profile use noun phrases, and energy_search_bfe_datasets uses 'search' instead of 'find'. This mix of conventions is readable but not fully consistent.
Tool Count5/5
With 10 tools, the server is well-scoped within the ideal 3-15 range. Each tool covers a distinct aspect of Swiss energy data queries, and none feel redundant or unnecessary.
Completeness4/5
The server provides comprehensive location-based energy data queries, including a convenient aggregation tool (energy_location_profile). Minor gaps exist: biogas is not explicitly included in the location profile, and there is no direct lookup by plant identifier. Overall, the core domain is well covered.
Average 4.3/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 48 commits in the last 12 weeks
- Last stable release on August 2, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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.json to 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, openWorld, idempotent, and non-destructive behavior. The description adds the data source (ch.bfe.statistik-wasserkraftanlagen) and notes the output fields, but does not disclose behavior like pagination, result limits, ordering, or permission requirements. It provides moderate context beyond annotations, but not rich 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear main sentence followed by structured XML tags for use case, important notes, and an example. It is front-loaded with the core purpose and avoids unnecessary fluff. The example is slightly redundant with the schema descriptions but adds a practical touch.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with three well-documented parameters and an output schema, the description covers the necessary context: purpose, use case, data source, and an example. It implies Swiss scope through the source and coordinate bounds, but does not explicitly state it. Still, the combination of description, schema, and annotations is sufficient for an agent to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool description does not explain individual parameters; however, the input schema extensively describes lat, lon, and radius_m with examples, ranges, and defaults. The example in the description (lat=47.05, lon=8.31, radius_m=30000) provides a concrete usage hint. Since schema coverage is high, a baseline of 3 is appropriate; the description adds only minimal parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action (search for hydro plants around a location) with a specific resource (Wasserkraftwerke, including subtypes Lauf-, Speicher-, Pumpspeicher). It lists key output attributes (Leistung, Fallhöhe, Jahresproduktion), and the tool name itself distinguishes it from sibling tools like wind turbines or PV installations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit use case ('Analyse der regionalen Wasserkraft, Infrastruktur-Recherche'), giving clear context for when to use it. It does not explicitly mention alternatives or when not to use it, but the specificity of hydro plants and the mention of regional analysis make the intended use fairly 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?
The description adds valuable behavioral context beyond annotations: it returns metadata (title, description, formats, link) and not raw data, full-text search is metadata-only, and pagination uses offset. This complements the readOnlyHint and idempotentHint annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a short main sentence, use_case, important_notes, and example. It is slightly longer than the minimal two-sentence ideal but every section adds value and the information is tightly packed without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage context, limitations, and gives an example. Since an output schema exists, return values need not be described. The combination of annotations and description is sufficient for an agent to understand the tool's behavior and constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already contains descriptions for limit, query, and offset. The description adds an example (query='wasserkraft', limit=10, offset=0) and notes that offset is used for pagination, but does not substantially extend parameter meaning beyond the schema. Given the schema description coverage is reported as 0%, the example and pagination note provide partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches the opendata.swiss catalog for datasets from the BFE, a specific verb+resource. It does not explicitly differentiate from siblings like energy_find_power_plants, but the focus on dataset search rather than specific asset types is evident from the description and name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The use_case clarifies when to use it (finding raw data and statistics beyond geo-layers), and important_notes state that it returns metadata only and that full-text search covers metadata, not raw data. This provides clear context for usage, though it does not explicitly name alternatives or when-not-to-use scenarios.
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?
Annotations already indicate read-only, idempotent, and safe behavior. The description adds useful context: it aggregates multiple parallel API calls, typical runtime <5s, and data source (GeoAdmin/BFE), which goes beyond annotation metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a concise opening sentence followed by use_case, important_notes, and example tags. Each element serves a distinct purpose, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's aggregation complexity, the description covers purpose, use cases, performance characteristics, and an example. An output schema exists to document return values, so the description does not need to explain that. It is complete for effective selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention parameters at all. Although the nested schema documents lat/lon/radius_m, the top-level schema coverage is 0% per context signals, and the description fails to compensate by explaining parameter usage or semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a complete energy profile for a location by aggregating five BFE layers. It uses a specific verb ('Erstellt') and resource ('Energieprofil'), and the distinction from sibling tools (which target individual layers) is evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The <use_case> tag explicitly states when to use it (reports, location decisions, demos) and emphasizes a single-call overview, which contrasts with the sibling finder tools. However, it does not name alternative tools explicitly, only implies them.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, establishing a safe read operation. The description adds the data source ('Quelle: ch.bfe.biogasanlagen') but does not disclose additional behavioral traits such as rate limits, pagination, or result ordering. With annotations covering safety, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single primary sentence followed by short, well-structured tags and an example. It is concise, front-loaded, and contains no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple spatial-search tool with a full output schema and safe-read annotations, the description covers the use case, data source, and an example. It provides enough context for an agent to select and invoke the tool correctly without ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema thoroughly documents all three parameters (lat, lon, radius_m) with descriptions and bounds. The tool description adds a concrete example (lat=47.4, lon=8.5, radius_m=25000), which illustrates valid values and usage. This adds value beyond the schema, justifying 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Sucht Biogasanlagen im Umkreis eines Standorts', which identifies a specific verb ('searches'), resource ('biogas plants'), and location scope. This clearly distinguishes it from sibling tools like energy_find_power_plants or energy_find_wind_turbines.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The use_case tag ('Recherche zu Biomasse-Energie, regionale Kreislaufwirtschaft') gives clear context for when to use this tool. However, it does not explicitly state exclusions 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context beyond these: the data source (BFE-Layer ch.bfe.elektrizitaetsproduktionsanlagen), the optional category_filter behavior, and the maximum of 201 results per call. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, using XML-style tags (<use_case>, <important_notes>, <example>) to separate sections. It front-loads the core purpose in a single sentence, then adds essential notes without unnecessary verbosity. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with four parameters and an output schema, the description covers all critical aspects: purpose, use cases, source, optional filter, result limit, and a concrete example. It is complete enough for an agent to select and invoke the tool correctly, even without deep schema exploration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The context signal indicates schema description coverage is 0%, so the description must compensate for missing parameter documentation. The description mentions the category_filter and provides an example with lat, lon, radius_m, and category_filter, but it does not explicitly explain the semantics or bounds of lat/lon/radius_m. The schema does include descriptions for these fields, but from the agent's perspective (with 0% coverage), the description only partially fills the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with the verb 'Sucht' (searches) and the resource 'Elektrizitätsproduktionsanlagen aller Typen' (electricity production plants of all types), listing specific types. It distinguishes from sibling tools by emphasizing 'aller Typen' and listing the categories, making it clear this is the general-purpose finder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases (Standortanalysen, Recherche, Schulprojekte) and an example invocation. However, it does not explicitly contrast with sibling tools (e.g., telling the agent to use energy_find_wind_turbines for wind-only queries). The sibling names and the 'aller Typen' phrasing imply the differentiation but do not explicitly state when 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?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable context by stating that two lightweight test requests are executed, which informs the agent about the tool's internal behavior beyond the basic safety annotations. This goes beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with only two short sentences and well-structured semantic tags. It is front-loaded with the main purpose, followed by use case and important notes. Every sentence contributes, with no redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, read-only, clear purpose), the description fully covers the human intent needed for an agent. The annotations and output schema handle safety and return structure, while the description adds use cases and implementation details, making it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter structure to explain. The description adds clarity by stating what the tool checks and its overall behavior, which is appropriate for a no-parameter tool. A baseline of 4 applies here since there are no params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Prüft die Verfügbarkeit') and resource ('GeoAdmin- und opendata.swiss-APIs'), making it obvious that this is a health/status check tool. It is distinctly different from the sibling tools, which all perform search/find operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The explicit use_case tag ('Diagnose bei unerwartetem Verhalten, Monitoring') provides clear guidance on when to invoke this tool. However, it does not explicitly mention alternatives or exclusion criteria, which would warrant 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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds the data source (ch.bfe.energiestaedte) and the requirement that exactly one of name or location be used. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and immediately understandable. The use of structured tags (use_case, important_notes, example) adds value without redundancy, and every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only search tool with a rich schema and clear annotations, the description covers the core purpose, use context, critical constraint, and example. The output schema presumably documents return values, so no further explanation is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides detailed descriptions for all parameters. The description goes beyond by reinforcing the mutual exclusivity of name vs. lat/lon and offers a concrete example with sample values, which helps the agent construct valid invocations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Sucht' (searches) and a clear resource: municipalities with the 'Energiestadt' label. It distinguishes itself from sibling tools by targeting municipalities rather than power plants or wind turbines.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a concrete use case (comparing municipal energy policy) and an important constraint (either name or lat/lon must be provided). It does not explicitly mention alternatives among the sibling tools, but the use case and condition make appropriate usage 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?
The annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds valuable context beyond these: the data source ('Quelle: ch.bfe.photovoltaik-grossanlagen') and the scope limitation (only large-scale systems are included). However, it does not disclose additional traits such as pagination, ordering, or behavior when no results are found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured using XML-style elements (use_case, important_notes, example). It front-loads the primary purpose, followed by contextual guidance and a concrete example. Every sentence contributes meaningful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the purpose, use case, important scope notes, a parameter example, and the source of data. It also mentions output fields (Leistung, Jahres- und Winterproduktion, Projektstatus). With an output schema present, the description is sufficiently complete for an agent to understand what the tool does and when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain each parameter, but the example 'lat=46.2, lon=7.5, radius_m=40000' provides a concrete usage pattern. The input schema itself contains detailed descriptions for lat, lon, and radius_m, including bounds and defaults, so the example supplements the schema without repetition. Given schema_description_coverage is 0%, the description only partially compensates with the example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb+resource: 'Sucht Photovoltaik-Grossanlagen' (finds PV large-scale systems). It also lists key output fields (Leistung, Jahres- und Winterproduktion, Projektstatus) and explicitly distinguishes from sibling tools via the important_notes, noting that individual PV installations are found in energy_find_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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The use_case element gives clear context for when to use the tool ('Recherche zu PV-Grossprojekten, Energieplanung'). The important_notes explicitly states a limitation and an alternative: 'Erfasst nur Grossanlagen — Einzel-PV erscheint in energy_find_power_plants', providing a when-not-to-use condition and naming the alternative tool.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context beyond this by naming the data source (ch.bfe.windenergieanlagen), noting the regional concentration of wind turbines, and mentioning the result fields — useful behavioral details without contradicting the safe-read annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with XML tags for use_case, important_notes, and example, each earning its place. The main sentence is front-loaded and direct, followed by brief, valuable notes. Slightly longer than the minimal two-sentence style, but every part adds meaningful guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple spatial-search tool with three parameters and an output schema available. The description covers the purpose, use case, relevant background (Swiss regions), and a concrete example, making it complete for an agent to select and invoke correctly. The output schema handles return value documentation, so the description does not need to explain that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explicitly define parameters, but the example (lat=47.22, lon=7.05, radius_m=30000) demonstrates usage, and the important notes clarify the radius_m maximum. The input schema itself provides per-parameter descriptions, so the description adds complementary illustrative context rather than leaving the agent without guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses 'Sucht Windenergieanlagen im Umkreis eines Standorts' (searches for wind turbines in the vicinity of a location), which clearly specifies the action and resource. It also lists the data points returned (operator, manufacturer, model, hub height, power), distinguishing it from sibling tools that focus on other energy types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit use case ('Recherche zu Windkraft-Standorten, regionale Energieplanung') and important notes about Swiss wind farm distribution and radius recommendations, guiding when and how to use the tool effectively. It does not explicitly name alternatives, but the sibling tool list makes the specialization obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds critical behavioral details: the internal radius is raised to at least 2000m, small radii may yield no results, and suitability classes are numbered 1-5. These go beyond annotation metadata and clarify real-world 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core statement. The use of structured tags for use_case, important_notes, and example makes it highly scannable. Every sentence contributes unique value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, use case, data source, radius behavior, and suitability classes. Since an output schema exists, the description does not need to explain return values. It is fully adequate for a spatial query tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents lat, lon, and radius_m with ranges and defaults. The description adds a concrete example (lat=47.37, lon=8.54, radius_m=3000) and a note about the radius being internally raised to 2000m, enhancing the semantic understanding of the parameters beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries the solar suitability of roofs for a location ('Fragt die Solareignung von Dächern für einen Standort ab'). It is specific with verb and resource, and the use case distinguishes it from sibling tools about power plants, wind turbines, and other energy infrastructure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The use_case explicitly describes when to use this tool (deciding on PV systems on school/public buildings, solar potential analyses). It does not name alternative tools or exclusion criteria, but the provided context is sufficient for basic usage decisions.
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:

[![swiss-energy-mcp MCP server](https://glama.ai/mcp/servers/malkreide/swiss-energy-mcp/badges/card.svg)](https://glama.ai/mcp/servers/malkreide/swiss-energy-mcp)

Score Badge

Copy to your README.md:

[![swiss-energy-mcp MCP server](https://glama.ai/mcp/servers/malkreide/swiss-energy-mcp/badges/score.svg)](https://glama.ai/mcp/servers/malkreide/swiss-energy-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/malkreide/swiss-energy-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server