bakom-mcp

Server Quality Checklist

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

Latest release: v3.0.0
Disambiguation4/5
Most tools have clearly distinct purposes (coverage vs. antennas vs. media stats vs. dataset discovery). A slight overlap exists between 'bakom_aktuell' and 'bakom_telekomstatistik_uebersicht'—both search opendata.swiss for BAKOM datasets—but parameter differences and detailed descriptions reduce confusion.
Naming Consistency4/5
All tools follow a 'bakom_' prefix with snake_case noun phrases. However, language is mixed: 'bakom_broadband_coverage' (English) vs. 'bakom_mobilfunk_abdeckung' (German), and 'bakom_multi_standort_konnektivitaet' mixes both. Overall pattern is consistent, so minor deduction.
Tool Count5/5
12 tools cover a diverse but focused domain (telecom coverage, antennas, media stats, dataset catalogs). Each tool has a clear niche and no tool feels extraneous. The count is well-scoped for the server's stated purpose.
Completeness4/5
Core workflows are covered: fixed/mobile coverage, fiber, antenna search, media statistics, and dataset discovery. Minor gaps exist (e.g., no per-operator mobile details, no spectrum license query), but the descriptions explicitly limit scope, so agents can work around missing features.
Average 4/5 across 12 of 12 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 49 commits in the last 12 weeks
- Last stable release on August 14, 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 declare the tool as read-only, idempotent, and non-destructive. The description adds context about using the BAKOM layer via geo.admin.ch, which is useful for understanding data source, but does not disclose other behavioral traits like rate limits or data freshness. The description does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, starting with a clear purpose, followed by data source, then clearly labeled Args and Returns sections, and an inline output schema. It is slightly verbose with some redundancy (e.g., 'Zeigt...' similar to first sentence), but overall efficient and front-loaded with key information.
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 read-only query tool with good annotations and an output schema, the description provides sufficient context: what it returns (frequencies, type, operator), the input (coordinates + format), and data source. It does not cover edge cases or empty results, but with the output schema and annotations, the agent has enough to use the tool correctly.
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 provides detailed descriptions for latitude, longitude, and response_format, including examples and bounds. The description only mentions 'Standortkoordinaten WGS84 + Format' at a high level. Since schema_description_coverage is effectively high (the schema gives rich parameter info), the baseline is 3, and the description does not add significant value beyond that.
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 queries UKW radio and TV transmission sites for a specific location, using a specific verb ('abfragen') and resource ('Sendeanlagen'). It distinguishes itself by focusing on location-based frequency data, but does not explicitly differentiate from sibling tools like bakom_sendeanlagen_suche or bakom_rtv_suche.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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. The description only states what the tool does without any when-to-use, when-not-to-use, or prerequisite information, leaving the agent to infer usage context from the tool name and 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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the description's burden is lower. The description adds that the tool queries the opendata.swiss CKAN API and returns overviews with download links, which is useful context. However, it does not significantly expand on behavioral traits beyond the annotations, so 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with an Args/Returns/Schema section, and the purpose is front-loaded. It is not overly long, and each section adds information. The inclusion of a sample output schema is helpful. Minor redundancy: the 'Schema' section repeats some structure already in the input schema, but it is still clear.
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 the return value (a string with download links) and provides a sample JSON schema of the data structure. However, there is a slight inconsistency: it says 'Returns: str' but then shows a JSON object schema. This could confuse an agent. Given the complexity and the presence of annotations and output schema, the description is mostly complete but has this minor flaw.
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?
Schema description coverage is 0%, meaning the tool description must compensate for parameter understanding. The description lists example thema values ('breitband', 'mobilfunk', etc.) and mentions format, but the input schema itself has a very detailed description of the 'thema' parameter (about search behavior and effective keywords). The tool description's parameter section is a simplified summary that lacks the nuanced search behavior, and it does not explain the 'response_format' enum. Thus it adds limited value beyond the schema.
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 retrieves overviews of Swiss telecommunications statistics from BAKOM datasets, with specific domains (Festnetz, Mobilfunk, etc.). It uses a specific verb ('abrufen') and resource. However, it does not explicitly differentiate from sibling tools like bakom_broadband_coverage or bakom_breitbandatlas_datensaetze, which might also provide statistics, so it's not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions use cases ('Marktanalysen, politische Berichte, KI-Fachgruppe-Demos'), giving context for when to use the tool. But it provides no explicit guidance on when not to use it or which sibling tool to choose instead, so the guidance 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety and idempotency are clear. The description adds that the tool returns structured data from reports and metadata but does not disclose further behavioral traits like response limits or authentication. The added value is minor, earning a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a docstring including Args, Returns, and a Schema example, but it is somewhat verbose. The schema example partly duplicates information already in the input schema and output description. It could be more concise to improve readability, giving a score of 3.
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 the tool's purpose, usage context, parameter guidance (though slightly off), and includes an output schema example. For a tool with one nested parameter, good annotations, and an output schema implied, the description is largely complete. Minor improvements could align parameter guidance more closely with the schema, earning a 4.
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's Args section lists specific thema values ('radio', 'tv', 'online', 'print', 'medien'), which adds some meaning beyond the top-level param lacking description. However, the actual nested schema is more detailed (default 'breitband', many valid search terms), and the description's list is oversimplified and slightly inconsistent. With 0% top-level schema coverage, the description partially compensates but with some inaccuracy, scoring 3.
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 returns structured information about the Swiss media landscape based on BAKOM reports and opendata.swiss metadata, specifically listing media sectors (Radio, TV, Online, Print). This verb+resource combination is specific and distinct from siblings like broadband or mobile coverage tools, earning a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the tool is 'ideal for media education and strategic analyses', which implies a usage context but does not specify when not to use it or compare with alternatives such as 'bakom_medien_statistik'. No exclusions or alternative tool references are provided, so the guidance is only implicitly stated, scoring 3.
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 provide readOnlyHint=true and idempotentHint=true. The description adds valuable behavioral context: uses geo.admin.ch API with 250×250m raster, returns coverage percentage and technologies, and includes the output schema. Does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: purpose sentence, API source, parameter list, and return schema. Front-loaded with the core action. Slight redundancy in Args section but overall efficient.
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 moderate complexity (4 parameters, nested input) and presence of output schema, the description explains geographical bounds, speed options, technologies, and data source. Lacks error handling or example usage but is sufficiently complete for a straightforward query tool.
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 provides comprehensive descriptions for all parameters, including ranges and enum values. The description's Args section repeats this info, adding little extra beyond what the schema already offers. Baseline 3 is appropriate given high schema coverage.
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 fixed-network broadband coverage for a location in Switzerland, using specific verb 'abfragen' and resource 'Breitbandversorgung'. It distinguishes from siblings like mobilfunk_abdeckung (mobile) and glasfaser_verfuegbarkeit (glass fiber) by specifying 'Festnetz' and the BAKOM source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. Sibling tools exist for mobile coverage and glass fiber, but the description does not mention exclusions or comparative context. Implied usage only from the tool name and subject.
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 indicate readOnly, idempotent, openWorld. The description adds behavioral details: resolution (100x100m), outdoor-only coverage, and that it returns provider count. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections and front-loaded purpose, but includes an inline schema that could be omitted for brevity. Still, every sentence adds value.
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 output schema is present, the description adequately explains return values and coverage details. It covers all necessary context for a read-only query tool.
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 summarizes parameters as 'coordinates WGS84, generation, format' but adds little beyond the input schema, which already provides detailed descriptions for each field (latitude, longitude, generation, response_format). Schema coverage is high, so baseline 3 is appropriate.
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: query mobile network coverage (5G/4G/3G) for a Swiss location and show how many providers cover it outdoors. It distinguishes itself from sibling tools like bakom_broadband_coverage or bakom_frequenzdaten.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The sibling tools are listed but there is no contrast or explicit conditions for selection.
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 the tool as read-only, idempotent, and non-destructive. The description adds behavioral context by stating it returns a list of installations with operator and type, and includes a return schema example. This supplements annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-line purpose, use cases, args/returns/schema blocks. It front-loads the key verb and resource. However, the inclusion of a 'Schema' block in the description (though helpful) slightly lengthens it; still appropriately sized.
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 has a small parameter set and an output schema (which the description includes), the description covers what the tool does, when to use it, and what it returns. It lacks explicit details about coordinate system or response format options, but overall is sufficient for an agent to use correctly.
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 only briefly mentions parameters as 'Koordianten WGS84, Suchradius, Format' without detailing each. With schema description coverage reported as 0%, the description does little to compensate. The input schema itself has descriptions, but the description adds minimal value beyond that.
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 starts with a clear verb and resource: 'Mobilfunkanlagen und Sendeanlagen in einem Umkreis suchen.' It specifies the tool finds antenna sites (mobile and broadcast) within a radius. Use cases (schools, media planning, infrastructure analysis) differentiate it from sibling tools like coverage or frequency tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides example use cases (schools, media planning) which imply when to use, but it does not explicitly state when not to use or compare to alternatives like coverage tools. No exclusionary guidance is given, so the agent may not know to avoid this for coverage queries.
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, destructiveHint=false, and idempotentHint=true. The description adds valuable behavioral context (data source: BAKOM Breitbandatlas via geo.admin.ch with 250×250m resolution), enhancing transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences plus a schema block. It is well-structured, front-loads the purpose, and every element adds value 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?
For a simple query tool, the description covers key aspects: data source, resolution, output schema (provided in description), and technology details. It lacks explicit handling of missing data but the output schema indicates nullable fields, so it's adequate.
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 provides descriptions for latitude, longitude, and response_format. The description restates 'Standortkoordinaten WGS84 + Ausgabeformat' without adding new meaning. Given that schema description coverage is reported as 0% (likely a metric limitation), but actual schema descriptions are present, a score of 3 is appropriate.
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 checks Glasfaserverfügbarkeit (FTTB/FTTH) for a Swiss location, using specific technology terms and distinguishing it from siblings like bakom_mobilfunk_abdeckung or bakom_broadband_coverage.
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 specifies the tool's purpose and context (Swiss location, BAKOM data), providing clear usage guidance. It does not explicitly mention when not to use it or alternatives, but the context is sufficient.
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 readOnlyHint=true and destructiveHint=false. The description adds substantial behavioral context: sorting by metadata_modified descending, no news fetching (with reason), full-text search limitations (no topic facet, unknown topics return empty list with hint), and the implication that results are date-ordered not relevance-ordered. This goes well beyond the annotation hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: a clear one-sentence purpose, followed by important caveats in bullet points. Every sentence adds value (e.g., sorting behavior, no news, search limitations, relevance warning). It is front-loaded with the main purpose and uses appropriate German terminology without fluff.
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 simplicity (1 parameter with nested sub-params) and the presence of annotations and an explicit output schema, the description covers the key behavioral aspects: data source, sorting, search behavior, empty results handling, and the exclusion of news. It does not explain the output schema structure in words (but the embedded Schema block suffices). Minor gap: no mention of the openWorldHint annotation's implications, but overall quite complete.
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?
Schema description coverage is 0% for the top-level 'params' parameter, though nested fields have rich descriptions. The description adds meaningful context for 'thema' (explaining it's a full-text search without topic facet, and that unknown topics return empty results). It does not describe 'response_format' beyond what the schema already provides. Overall, the description partially compensates for the top-level coverage 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 'Zuletzt aktualisierte BAKOM-Datensätze auf opendata.swiss zu einem Thema', providing a specific verb (abfragen von aktualisierten Datensätzen) and resource (BAKOM-Datensätze auf opendata.swiss). It distinguishes itself from sibling tools like bakom_broadband_coverage or bakom_medien_statistik by focusing on recently updated datasets across any topic, not a specific domain.
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 explains when to use this tool (to see what BAKOM recently worked on) and explicitly states what not to expect: 'Keine Medienmitteilungen.' It warns about the sorting by date reducing relevance ('ein Treffer kann das Suchwort nur am Rand berühren') and advises where to find news instead. However, it does not directly compare with sibling tools or specify conditions that would make this tool preferable over others.
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, destructiveHint=false, idempotentHint=true, so the tool's safety profile is clear. The description adds behavioral context: it queries 5G and glass fiber status per location, returns a comparison table, and limits to 20 locations. This goes beyond the annotations. However, it does not mention error handling or data freshness, which would improve 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a clear first sentence for purpose, then use cases, followed by structured 'Args' and 'Returns' sections with an output schema. Every sentence adds value without redundancy. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of comparing multiple locations and the presence of an output schema in the description, the tool is fairly complete. It covers what it does, how many locations, what data it returns, and use cases. It could mention error handling or data freshness, but overall it provides sufficient context for an agent to invoke it correctly.
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 has only one parameter with 0% description coverage per the given context, so the description carries the burden. It explains the substructure of 'locations' (name, latitude, longitude) and mentions the optional response_format. This adds meaning beyond the schema's minimal descriptions. However, the schema's location items have 'additionalProperties: true', and the description's fields (lat, lon) align with the example in the schema description, adding clarity.
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 compares broadband and mobile coverage for multiple locations simultaneously ('Breitband- und Mobilfunkversorgung für mehrere Standorte gleichzeitig vergleichen'). This distinguishes it from sibling tools like bakom_mobilfunk_abdeckung (single location) and bakom_broadband_coverage (single location). The use cases further reinforce the multi-location comparison purpose.
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 (Schulhausvergleiche, Standortentscheide, Digitale-Chancengleichheit-Analysen) which guide when to use this multi-location tool. However, it does not explicitly state when not to use it or name alternative tools for single-location queries, which would strengthen guidance. The context from sibling tools implies single-location alternatives, but a clear reference would be better.
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 read-only, idempotent, and non-destructive behavior. The description adds significant behavioral context: it clarifies that the search is full-text based, not faceted, that the catalog has no facets for media_type and kanton, and that it returns datasets from the catalog, not individual stations. It also mentions output format options. The 'Returns: str' line is slightly ambiguous but resolved by the output schema and format parameter.
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 reasonably concise (around 150 words) and well-structured. It starts with the purpose, then explains what it returns and what it does not, followed by parameter behavior notes, and ends with a structured Args/Returns/Schema section. Every sentence contributes value, though the 'Returns: str' section could be slightly clearer.
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 moderate complexity (one parameter object with multiple sub-parameters, output schema, annotations), the description is comprehensive. It covers the search scope, limitations (non-exact filtering, alternative source), output format, and provides an example output schema. The description, combined with annotations and input schema, gives the agent everything needed to use the tool correctly.
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?
Schema description coverage is 0%, meaning the description must add meaning beyond the schema. The description compensates well by explaining that media_type and kanton are full-text search terms that weight results, not exact filters, and that the catalog has no faceted filtering for these. This adds crucial usage semantics not fully captured by the schema descriptions 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's purpose: searching BAKOM datasets on opendata.swiss for radio and television. It explicitly distinguishes itself from sibling tools by noting it returns catalog datasets, not individual stations, and points to an alternative source for concessionaire details. This is specific and helps differentiate from other BAKOM 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it explains that the tool searches the BAKOM catalog, not individual stations, and that for specific concessionaire info one should use the RTV-Datenbank web interface. It also explains that media_type and kanton are not exact filters but full-text search terms. However, it does not explicitly compare with all sibling tools or list when to prefer this tool over others.
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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value by specifying that the response is a catalog with titel, layer_id, url, and kategorie fields, and that the tool returns a full overview of datasets covering fixed network, mobile, fiber, and speed levels.
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 clear one-line summary, a brief elaboration, a documented Args/Returns/Schema section, and all sentences add value without redundancy. Appropriate length for the tool's complexity.
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 has a low parameter count (1), comprehensive parameter description, clear annotations, and an output schema, the description fully covers the tool's usage, behavior, and output structure—leaving no gaps for a typical agent.
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?
Schema description coverage is 0%, but the description details the parameter (Thema and Format) and gives specific search examples for Thema such as 'medien', '5g', 'festnetz', etc., adding significant practical guidance beyond the schema's minimal description.
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 lists all available BAKOM Breitbandatlas datasets from opendata.swiss. It explicitly mentions the resource (datasets), the action (list), and differentiates from siblings by focusing on the catalog overview rather than specific coverage or search.
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 explains the tool is useful for data selection before download or API query, providing clear context for use. However, it does not explicitly state when not to use this tool or name specific sibling 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, openWorldHint, idempotentHint, and non-destructiveHint, so the description doesn't need to restate these. The description adds valuable behavioral context about data source limitations (only examined programs, aggregate vs. sender, naming variations), which annotations don't cover. It doesn't discuss rate limits or detailed authorization, but for this stateless query tool the provided context is sufficient.
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: a clear purpose statement, usage guidance, key behavioral quirks listed concisely, and a summary of input/output schema. Every sentence adds value, with no redundancy or filler. The format is front-loaded with the most critical information (what the tool does) followed by usage tips.
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 complexity (multiple cubes, dimensions, and data sources), the description is remarkably complete. It covers purpose, usage workflow, data caveats, parameter roles, and provides a full output schema. The sibling context and annotations further support correct selection and invocation. There are no obvious gaps in understanding what the tool does or how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does thoroughly. It explains that `thema` without value lists all available evaluations and describes the matching behavior (substring match on titles). It also mentions year and limit parameters with context, and the output schema is provided, so return value semantics are clear. The description adds meaning well beyond the bare 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 the tool provides Swiss radio and TV market statistics from BAKOM cubes on LINDAS, listing specific data types like market shares, reach, and program structure. It distinguishes itself from siblings by its unique focus on media statistics, while sibling names (e.g., bakom_mobilfunk_abdeckung, bakom_sendeanlagen_suche) suggest they cover different domains.
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 explicitly advises starting without `thema` to list available evaluations when unsure, providing a clear workflow. It also notes three data quirks (covered vs. actual programs, 'Durchschnitt' as aggregate, naming inconsistencies), helping the agent avoid common misinterpretations and use the tool correctly.
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:

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

Score Badge

Copy to your README.md:

[![bakom-mcp MCP server](https://glama.ai/mcp/servers/malkreide/bakom-mcp/badges/score.svg)](https://glama.ai/mcp/servers/malkreide/bakom-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/bakom-mcp'

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