swiss-apis-mcp

Server Quality Checklist

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

Latest release: v1.0.1
Disambiguation4/5
Most tools have distinct domains (transport, geo, health, company, parliament) which make them easy to distinguish. However, there is meaningful overlap between swiss_health_search_datasets, swiss_opendata_search_datasets, and swiss_statistics_search — all search government open data catalogs and could confuse an agent about which to pick for a data search, though domain prefixes help. Similarly swiss_energy_search_datasets versus swiss_grid_energy_data have related but distinct purposes.
Naming Consistency4/5
The naming pattern is consistent with the swiss_ prefix and mostly follows verb_noun (search_x, get_x, identify_x) conventions. Minor deviations include swiss_postal_data, swiss_migration_statistics, and swiss_avalanche_data which drop a verb, and swiss_grid_energy_data which lacks a verb. Overall the pattern is readable and predictable enough for an agent.
Tool Count3/5
34 tools is on the heavy side, exceeding the typical 3-15 well-scoped range. However, the server deliberately aggregates many distinct Swiss APIs (transport, geo, health, parliament, law, company, energy, weather, food, statistics), each domain having a legitimate subset of tools, so the count is defensible but borders on overwhelming.
Completeness3/5
The surface is broad, covering many Swiss data domains, but individual domains are inconsistently deep — transport has search/stationboard/connections/gtfs (deep), while weather only has a search tool with actual queries 'planned for Q2 2026' (a dead end), and avalanche/hydro have single tools. Within domains there's no clear operation lifecycle (create/update/delete) since these are mostly read-only, which fits the data-sourcing purpose, but several tools (weather, grid) note future/limited data access.
Average 3.2/5 across 34 of 34 tools scored. Lowest: 2.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states what data source it draws from but gives no behavioral detail: no mention of rate limits, data recency, whether it requires API keys (notable since a sibling 'swiss_set_api_key' exists), output format, or pagination. For a data retrieval tool with zero annotation coverage, this is a significant transparency gap.
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 one concise sentence with no wasted words. However, this length reflects under-specification rather than deliberate economy; it's short because it lacks substance, not because it's efficiently complete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 1 parameter, no annotations, no output schema, and 33 siblings to disambiguate against, the description is far too thin. It provides no details about what data is actually returned, how queries work, whether an API key is needed, or how it relates to the similar search tools in the sibling list.
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?
There is one parameter (query) with 0% schema description coverage, so the description must compensate. It provides zero explanation of what the 'query' should contain, what a good query looks like, or how it shapes the results. The default value 'migration asylum population' hints at usage but the description itself adds nothing about the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it gets 'Swiss migration and population data' from SEM, naming the source. However, the verb 'Get' is generic and doesn't specify what form this takes (a search? a stat download?). The tool name suggests statistics but the description reads like a generic data retrieval tool without specific output characteristics, and it doesn't distinguish itself from the many other swiss_* data tools.
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, which is a real concern given 33 sibling tools including swiss_statistics_search, swiss_opendata_search_datasets, and swiss_health_search_datasets. The description gives no context about when migration data should come from SEM specifically versus the general Swiss statistics/opendata tools, nor any exclusions or prerequisites.
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 full responsibility for behavioral disclosure. It only mentions 'parliamentary activity' without explaining what data is returned, whether results are paginated, what 'activity' includes, or how 'parliament' param affects results. A read tool with zero disclosure about return format or behavior is a 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core purpose. No wasted words. It could arguably benefit from slightly more detail, but it is appropriately brief for a list-retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 2 params, no annotations, no output schema, and a sibling 'swiss_parliament_search' that may overlap, the description should clarify scope, differentiation, and expected output. It only provides a one-line purpose with no pagination, filtering, or output structure details, leaving the agent to guess behavior.
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 50%, covering 'parliament' (Parliament code) but not 'limit' (no description in schema). The description adds no parameter detail—it doesn't explain what 'Parliament code' values are valid (ch vs other codes) or what 'limit' controls beyond the default. Half the parameters are undocumented and the description doesn't compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get Swiss parliament members (councillors, deputies) with their parliamentary activity.' It uses a clear verb (Get) and resource (Swiss parliament members) with parenthetical clarification. However, it doesn't differentiate from the sibling tool 'swiss_parliament_search', which could overlap in purpose, so it doesn't fully distinguish itself.
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 when-to-use guidance is provided. The description doesn't explain how this tool differs from 'swiss_parliament_search' or when an agent should prefer one over the other. Without exclusions or alternative naming, the agent has no situational guidance.
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 doesn't mention whether this is a read-only operation, what the result shape is, pagination/limits, or whether the rows parameter controls result count limits. It doesn't describe rate limits or result format, leaving significant behavioral unknowns.
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?
Single sentence, front-loaded with the verb and resource, with a domain list appended. No wasted words. However, it's compact to the point of omitting useful behavioral and usage details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no annotations and no output schema, the description should clarify return value structure and how rows/query behave. It provides neither. It also doesn't help an agent disambiguate from numerous sibling search tools. The description is minimal and leaves too much unspecified for effective tool selection and invocation.
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 coverage is 50%: the query parameter has a description with examples ('population', 'unemployment', 'GDP', 'immigration'), which the description partially reinforces. However, the rows parameter (integer, default 10) has no description in either schema or tool description, and the description doesn't explain how the query maps to results or how rows interacts with the search.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it searches Swiss Federal Statistical Office datasets with a domain list (population, economy, education, society). It's clear what resource it targets, but it doesn't specify what the search returns (datasets? records? metadata?) or how it differs from siblings like swiss_health_search_datasets, swiss_energy_search_datasets or swiss_opendata_search_datasets, which appear to be similar 'search datasets' tools.
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?
The description gives a broad topic hint ('Statistical topic') but provides no guidance on when to use this vs alternatives. With many sibling 'search' tools, there's no distinction offered between BFS statistics and, say, opendata or health/energy datasets. No exclusions or alternative tool references.
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 full burden. It discloses that this is a dataset search (not live API queries yet) and that individual API queries are planned for Q2 2026, which is useful context. However, it does not describe the return format, pagination, rate limits, or whether results are just metadata/dataset listings versus actual data values. For a search tool with zero annotations, more behavioral disclosure is needed.
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?
Two short sentences with no waste. The temporal context (May 2025 opening, Q2 2026 plans) is efficiently conveyed. Could arguably be more informative while staying concise, but the structure is appropriate for the content provided.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a search tool with a 2-parameter schema, no output schema, and no annotations. The description partially explains the data source and its temporal limitation but fails to describe what results look like (dataset metadata vs actual weather data), how to interpret responses, or any caveats about the search functionality. Given zero annotations and no output schema, the description should do significantly more work.
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 coverage is 50%, and the description adds no parameter semantics beyond what the schema provides. The schema documents the 'query' parameter with examples, and 'rows' with a default of 10. The description does not elaborate on what querying returns, how rows behaves, or whether there are pagination nuances. The description adds no value over the schema here.
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 verb (search), resource (MeteoSwiss open datasets), and identifies MeteoSwiss as official Swiss meteorology. It distinguishes from siblings by the specific data source (MeteoSwiss OGD, opened May 2025). However, there is no explicit differentiation from similar search tools like swiss_health_search_datasets, swiss_energy_search_datasets, or swiss_statistics_search beyond the meteorology context.
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?
The description mentions the data was opened since May 2025 and notes individual API queries are planned for Q2 2026, which hints at limitations but does not provide explicit when-to-use or when-not-to-use guidance. No alternative sibling tools are named. The agent gets no clear direction on when to choose this over the many other Swiss data search tools.
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 full behavioral disclosure burden. It describes what data is searched but doesn't state what the return format looks like, whether it returns metadata versus actual values, pagination or limit behavior, or the relationship between the 'rows' parameter and result count. For a search tool with zero annotations, this is a meaningful transparency 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single efficient sentence that packs topic scope and agency attribution. No wasted words. Could potentially add an example invocation pattern, but the current length is appropriate for the information conveyed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and only 50% schema coverage, the description should compensate more. It doesn't explain the return value format, whether this returns raw data or dataset metadata, or any rate/pagination constraints. For a tool that actually retrieves data, the lack of behavioral clarity is a notable gap.
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 coverage is 50% (query has a description with examples; rows has only default=10 with no description). The description reinforces what types of queries work ('electricity', 'solar', etc. from the query param examples) but doesn't explain what 'rows' controls (max results? page size?). Baseline 3 is appropriate since the query param is well-documented in schema and partially reinforced in description.
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 uses a specific verb ('Search') with a clear resource scope ('Swiss energy data from SFOE') and lists content areas (electricity production, renewables, consumption, EV charging stations). It distinguishes from siblings by naming the specific agency (SFOE) and topic domains, though it doesn't explicitly name alternative tools among the many Swiss-data siblings.
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?
There's no guidance on when to use this tool versus alternatives. Given the large sibling set (swiss_grid_energy_data, swiss_hydro_data, swiss_health_search_datasets), it would be valuable to note that this is the general SFOE dataset search while swiss_grid_energy_data and swiss_hydro_data are more specialized. No exclusions or contextual pointers provided.
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 full burden of behavioral disclosure. It does not state whether boundary lookups are approximate, what happens for points near borders or outside Swiss territory, whether it handles lakes/exclaves, or what the output format looks like. Given geo boundary identification has edge cases, this is a notable 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single efficient sentence that communicates the core purpose with no waste. It could be structured to include more behavioral detail, but for pure conciseness it's appropriately brief and front-loaded with the verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a geo-lookup tool with no annotations and no output schema, the description is thin. It doesn't cover boundary edge cases, out-of-Switzerland behavior, return format, or the relationship to the sibling municipality-identification tool. Given the tool's moderate complexity (coordinate-to-administrative-unit mapping), more context would be valuable.
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 100%, with both lat and lng documented. The description doesn't add parameter detail beyond the schema (e.g., valid ranges for Swiss coordinates, whether lat/lng order matters), but the schema already covers the basics, so baseline 3 is appropriate.
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 verb (identify), resource (canton), and target (a coordinate). It distinguishes from siblings like swiss_geo_identify_municipality, which identifies a different administrative unit. However, it doesn't explicitly differentiate from other geo-lookup tools in the group, making the distinction implicit rather than explicit.
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 such as swiss_geo_identify_municipality or swiss_geo_search_location. The description doesn't state prerequisites (e.g., coordinate format, required projection) or exclusions. The usage context is implied by the name and description but not explicitly stated.
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 doesn't mention what data freshness/recentness is, whether a setup/api key is required (sibling swiss_set_api_key and swiss_check_setup exist, suggesting auth may be needed), data granularity, or response structure. For a data-fetching tool with zero annotation coverage, this is a notable 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that packs in the data source, the specific data types, and scope. No wasted words. Could be front-loaded with the differentiation from siblings, but the length is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-param tool with 100% schema coverage and no output schema, the description provides a reasonable understanding of what data is retrievable. However, given the title is null and no annotations exist, it could strengthen by noting data time-window, refresh cadence, or required setup steps (given sibling setup tools exist). It's adequate but leaves room for improvement.
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 100%, so the schema already documents the 'query' parameter. The description adds context about what data types the query can fetch (consumption, production mix, cross-border flows), which is a mild enhancement over the bare 'Search query' schema description. Baseline 3 is appropriate since the schema handles documentation and the description adds only marginal value.
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 states a specific verb ('Get') and resource ('Swiss energy grid data from Swissgrid') with concrete data types (actual electricity consumption, production mix, cross-border flows). It distinguishes itself well from siblings like swiss_snb_financial_data or swiss_energy_search_datasets, though it doesn't explicitly draw that contrast.
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 vs alternatives. There's a sibling swiss_energy_search_datasets (likely for searching energy datasets) and this tool could be confused with it, but the description doesn't clarify the distinction or when to prefer one over the other. Usage context is entirely implied by the name/description.
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 full burden of behavioral disclosure. It does not reveal what happens with a vague query like 'monetary policy' vs a specific one, whether results return raw data or processed numbers, whether an API key is required, or how results are structured. The description makes a broad promise ('financial and monetary data') without disclosing query limitations or edge cases.
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?
Single sentence, front-loaded with the tool's purpose and immediately lists data categories. Zero waste. Slightly generic wording ('financial and monetary data') could be tightened, but structurally it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter with full schema coverage and no output schema, the description covers the essentials (what data categories are available). However, for a natural-language free-text query tool it lacks guidance on query phrasing, expectations for result scope, or any limitation note. Adequate for a simple single-param tool but leaves room for the agent to guess about query behavior.
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 coverage is 100% and the single 'query' parameter has a helpful example set ('exchange rates EUR/CHF', 'interest rates', 'inflation', 'monetary policy') embedded in its schema description. The tool description also enumerates categories which aligns with the query parameter. However, the description does not explain how the query maps to SNB datasets — e.g., whether queries are free-text matched or must match specific SNB dataset names — which is the key meaning gap for a natural-language query parameter.
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 uses a specific verb ('Get') with a clear resource ('Swiss National Bank (SNB) financial and monetary data') and lists concrete data categories (exchange rates, interest rates, balance sheets). It distinguishes itself from sibling Swiss tools by its domain focus, though the sibling tools are clearly different domains so differentiation is easy. A solid clear purpose statement.
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?
The description does not provide any when-to-use guidance, exclusions, or alternatives. With a large sibling set of 36 Swiss data tools, there is no hint about when to choose this over related financial tools (e.g., swiss_energy_data, swiss_grid_energy_data). No context about prerequisites like API key setup (which appears to exist via swiss_set_api_key), leaving uncertainty about whether setup is needed.
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 behavior disclosure. The description notes the API key requirement, which is useful, but doesn't disclose what happens without the key, the return format (GTFS-RT protobuf vs JSON), whether data is limited to Switzerland, or any latency/staleness characteristics of the real-time feed. For a real-time data tool with zero annotation coverage, behavioral expectations are under-specified.
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 a single efficient sentence that conveys the data source and the key prerequisite. There is no waste or redundancy, though it could be slightly improved with a brief note about feed types or output format without bloating.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a single-parameter, no-output-schema, no-annotation tool that deals with real-time GTFS data. The description leaves significant gaps: no output format explanation (GTFS-RT feeds are typically protobuf binary, which agents may need to know), no authentication failure behavior, no refresh rate or data scope details. For a data-fetching tool, agents would benefit from knowing what to expect when invoking 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?
Schema description coverage is 100% and the single feed_type parameter is well-defined with an enum of three clear options (trip_updates, vehicle_positions, alerts). The description doesn't add semantic meaning beyond the schema, but each enum value is self-explanatory, so the baseline 3 is appropriate. No additional context about typical usage of each feed is provided.
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 states the specific verb ('get') and resource ('real-time GTFS data from opentransportdata.swiss'), providing clear purpose. It distinguishes from sibling transport tools (station_search, stationboard, connections) which focus on static/near-time data, though it could more explicitly differentiate real-time feeds vs those alternatives.
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?
The description mentions a prerequisite (OTD_API_KEY env variable) but gives no when-to-use guidance or alternatives. It doesn't explain when to choose this tool over swiss_transport_stationboard, connections, or station_search, nor does it describe which feed_type to select for which scenario. The tool requires the API key setup but no exclusion criteria or comparison guidance is given.
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 mentions 'No API key needed,' which is useful, but it doesn't disclose what the response looks like, whether results are real-time or scheduled, pagination behavior, or how it resolves station name variants. For a tool that could return many data points, this is a meaningful transparency 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero waste. The 'No API key needed' note is genuinely useful information for an agent deciding whether to use this tool. Concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a data-retrieval tool with a clear station parameter and useful filters (limit, transportations) in the schema. Given no annotations and no output schema, the description should explain more about the return data and behavior (real-time vs scheduled, time horizon, station name matching). It's minimally viable but leaves the agent guessing about output format and semantics.
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 coverage is 100%, with all 3 parameters documented. The description adds the 'No API key needed' note but otherwise doesn't add meaning beyond the schema. Since the baseline is 3 for high schema coverage and the description adds marginal value (no custom formats or interaction notes), a 3 is appropriate.
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?
Clear verb+resource: 'Get next departures from a Swiss public transport station.' It distinguishes from siblings like swiss_transport_connections (which does routes) and swiss_transport_station_search (which finds stations). The scope is specific to departures from a single station.
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?
The description gives no guidance on when to use this vs alternatives. It doesn't mention that swiss_transport_station_search should be used to find station names first, nor distinguish it from swiss_transport_connections (journey planning) or swiss_transport_gtfs_realtime. No exclusions or context provided.
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. The description reveals nothing about return format, whether results are paginated, how the limit parameter behaves, error behaviors for invalid layer IDs, or any rate limits or setup requirements (notably there's a sibling swiss_set_api_key suggesting an API key may be required, but this isn't mentioned). For a tool with zero annotation coverage, this is a notable 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that efficiently captures the tool's purpose. It's appropriately minimal with no wasted words. The only slight gap is that it could mention the requirement of required parameters or point to setup requirements, but for length versus information, it's well-balanced.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a search tool with 4 parameters and no output schema, the description should explain what kind of results are returned and how to use the parameters effectively. The description provides none of this. There is no mention of result format, the relationship between search_text and search_field, how limit affects output, or what constitutes a valid layer ID beyond the two examples given. The presence of a sibling swiss_set_api_key suggests setup is needed but this isn't communicated.
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 75%, with three of four parameters having descriptions (layer, search_text, search_field). The description adds the context that layer IDs are swisstopo layer identifiers with examples, which adds some value. However, the 'limit' parameter lacks a schema description and the tool description doesn't clarify its semantics (default, max, behavior). The description doesn't significantly enhance understanding 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (search features) and the resource (swisstopo map layer) with explicit examples of content types (streets, buildings, stations). It distinguishes reasonably from sibling geo tools which cover search_location, elevation, canton/municipality identification, and coordinate conversion. However, it doesn't explicitly differentiate from the more general swiss_geo_search_location or the swisstopo-specific siblings, so it falls short of 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 implies the tool is used for text-based feature search within specific map layer IDs, which is clear enough context. However, it provides no explicit 'when to use vs when not to use' guidance or alternatives. The examples of layer IDs in the schema help establish usage context, but there's no direct guidance about when alternative tools like swiss_geo_search_location might be preferable.
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 doesn't mention that this generates a URL for use in map libraries (e.g., Leaflet), no mention of coordinate system/projection assumptions (e.g., which grid the x/y tiles assume), rate limits, or whether the URL requires an API key. Given the tool generates an external service URL with several implicit dependencies, this is a notable transparency 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single well-formed sentence that conveys the tool's purpose efficiently. No wasted words, though the sentence is a bit generic since it adds little beyond the tool name itself.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool generates an external tile URL with implicit dependencies (WMTS base URL, tile grid/CRS convention, layer parameter nuances, potential API key requirement—note a sibling 'swiss_set_api_key' exists). No output schema means the description should clarify the URL format/template this returns. For a tool that depends on external service configuration, the description lacks essential operational context.
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 coverage is 75% (3 of 4 params documented: x, y, z described as 'Tile X', 'Tile Y', 'Zoom level'; only 'layer' gains meaningful enum context). However, the description adds no parameter semantics beyond what the schema provides. The x/y tile coordinates have subtle WMTS conventions (which zoom origin/CRS, e.g., Web Mercator vs LV95) that go unexplained. Baseline 3 is appropriate given decent schema coverage.
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 states a specific verb+resource: 'Generate a swisstopo WMTS tile URL for map display', clearly identifying it as the official Swiss national map tool among many swiss_geo siblings. It doesn't explicitly name sibling alternatives, but the 'official Swiss national map' scoping helps distinguish from location search, elevation, canton identification, etc.
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 gives 'map display' as purpose context but provides no explicit when-to-use vs alternatives or exclusions. Among the geo tools (search location, elevation, identify canton/municipality, convert coordinates), the WMTS tile URL function's distinct purpose is implied by the 'map display' phrase, but no alternatives are named or contrasted.
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 full burden for behavioral disclosure. It states the tool fetches hydrological data but does not disclose whether it requires setup/api key, rate limits, whether any station_id is required (0 required parameters), what happens with no station_id, or what the return payload looks like. For a data-fetching tool with zero annotation coverage, this is a notable gap.
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?
A single clean sentence that names the tool's purpose, the specific data categories, and the data source institution. Zero waste — every word earns its place while remaining informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there's no output schema, no annotations, and no behavioral caveats, the description is thin on what the agent can expect. The tool is a single-purpose data fetcher, which reduces complexity, but the absence of any return format hints, error conditions, or setup requirements makes it underspecified relative to its informational burden. The 100% schema coverage and single optional parameter mitigate this somewhat, but the description should convey more about behavior for a no-annotation tool.
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 coverage is 100% with a single parameter (station_id) that has a clear description including an example ('2104' with the Rhône at Gletsch station). With an optional parameter (0 required), the description's mixed data types help convey breadth. The schema already does the heavy lifting for this parameter, and the description's general scope adds appropriate context without redundancy.
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 states a specific verb+resource — 'Get hydrological data' — and enumerates the specific data types: river levels, flow rates, flood forecasts. It clearly identifies the source as BAFU. However, it doesn't distinguish itself from sibling tools (e.g. swiss_weather_search_meteoswiss, swiss_avalanche_data) beyond the general hydrological scope, though the BAFU attribution provides reasonable differentiation.
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?
The description provides no explicit when-to-use or when-not-to-use guidance, no discussion of alternatives, and no prerequisites (e.g., need for an API key via swiss_set_api_key). The context of 'hydrological data from BAFU' is clear but there is no guidance on distinguishing this from weather or avalanche data siblings, nor any mention of required setup.
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 mentions 'No API key needed,' which is useful but insufficient. It doesn't describe what the response contains, how connections are ordered (by departure time?), whether results are limited by the 'limit' parameter, or any rate-limit or error behaviors. The 'via' and 'datetime' parameter behaviors are not disclosed at all.
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 a single concise sentence that immediately conveys the core purpose ('Find train/bus connections between two Swiss locations') and the key operational detail ('No API key needed'). It's efficient with no filler, though it could add a bit more behavioral context without becoming bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a moderately complex multi-parameter tool (5 params, 2 required) with no annotations and no output schema. The description provides only the basic purpose. Given the sibling swiss_set_api_key tool and the mention of 'No API key needed', the description partially positions this against tools that DO require keys, but it lacks essential context: result ordering, pagination, error handling for invalid location names, and how 'via' affects routing. For a tool of this complexity with zero annotation coverage, more detail is needed.
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 80%, with most parameters (from, to, via) having descriptions in the schema. The description adds no parameter-level detail beyond what the schema already provides. The 'limit' parameter has schema constraints but the description doesn't clarify whether the default of 3 connections is reasonable or how limit interacts with via routing. At 80% coverage, the baseline 3 is appropriate.
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 states 'Find train/bus connections between two Swiss locations' — a specific verb+resource+geographic scope. It clearly distinguishes from sibling tools like swiss_transport_station_search (station lookup) and swiss_transport_stationboard (departures from a single station) but does not explicitly name these alternatives.
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 implies usage for point-to-point journey planning between two Swiss locations, which distinguishes it from stationboard (single-station departures) and station_search (station lookup). However, there are no explicit when-to-use vs when-not-to-use statements or named sibling alternatives, and no guidance about whether 'locations' must be station names, addresses, or both.
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 full burden for behavioral disclosure. It doesn't state whether results are sorted by relevance vs distance, what happens with empty results, whether coordinate mode returns nearest station and how many, or whether 'name' matching is fuzzy/partial. For a search tool with no annotation coverage, this is a notable 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence that efficiently states purpose and scope. Could add a usage hint about mode selection, but for its length it is well-structured and front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter tool with no output schema and no annotations, the description is thin. It doesn't clarify return structure (does it return station codes, names, coordinates?), the meaning of 'nearby', limits, or how it relates to the stationboard/connections siblings. Schema covers 75% of params but the operational semantics remain underspecified.
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 coverage is 75%, so the schema documents query, lat, and lon but not limit. The description adds the two-mode distinction (name vs coordinates) which goes slightly beyond the schema, but doesn't explain the limit default behavior or clarify the interaction between query and coordinates. Description adds marginal value over 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?
Clear verb+resource ('Search for Swiss public transport stations') with two modes (by name or coordinates), distinguishing it from the sibling stationboard and connections tools. However, it doesn't explicitly note its distinction from sibling swiss_geo_search_location or clarify search scope beyond 'Swiss'.
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 implies two usage modes (name query vs lat/lon coordinates) and the schema reinforces this with separate fields. However, it doesn't state when to prefer this over swiss_geo_search_location or swiss_transport_stationboard, nor clarify whether query and coordinates are mutually exclusive or combinable.
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. The description states it returns 'nutritional values' but doesn't describe response format, whether it requires an API key (note sibling swiss_set_api_key and swiss_check_setup exist), pagination/limits, or query language specifics (e.g., does it need exact names, does it handle partial matches). For a search tool with zero annotation coverage, this is a notable 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that conveys the key purpose without waste. It's front-loaded with the primary action ('Search') and identifies the authoritative source (FSVO). Appropriate length for a single-parameter search tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/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 one well-documented parameter and no output schema, the description is mostly adequate. However, given that sibling tools include swiss_set_api_key and swiss_check_setup, it would be helpful to note whether authentication is required. The description is complete for the core search function but lacks operational context that would help the agent use it 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?
Schema description coverage is 100%, and the single param 'query' has a description with examples ('gruyère', 'fondue', 'rösti'). The baseline 3 is appropriate since the parameter is well documented in the schema and the description adds minimal additional semantics beyond noting it searches Swiss food items.
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 verb ('Search'), the resource ('Swiss Food Composition Database (FSVO)'), and the scope ('official nutritional values of foods available in Switzerland'). This clearly distinguishes it from siblings like Swiss food_search_products which likely searches marketplace products rather than official nutritional databases.
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 implies it's for looking up nutritional values of Swiss foods, but doesn't explicitly state when to use this vs swiss_food_search_products or provide exclusions (e.g., not for packaged products, only for composition values). The distinction from sibling food tools is only implied, not stated.
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 full burden of behavioral disclosure. It doesn't mention that this is a read-only search, what the tool returns (list of datasets vs. data records), whether results are truncated, or any authentication requirements. For a search tool the safety profile is fairly safe, but the return format and pagination/limited-results behavior are 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose. The topic list is concise and useful. No filler or redundant text. Efficient and appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no output schema, the description should clarify what the search returns, but it doesn't specify return format or whether it overlaps with the sibling swiss_health_get_dataset. The topic coverage is useful, but the tool would benefit from stating it returns dataset metadata (titles, descriptions) that can then be fetched by the sibling tool. Adequate but with a notable gap.
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 coverage is 50%, with only 1 of 2 params documented in the schema. The description doesn't add parameter detail beyond the schema. The 'rows' parameter's meaning (number of results) is implicit but not explained. Query examples are provided in the schema, not the description, so the description adds marginal value over 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 specifies a clear verb+resource: 'Search BAG datasets on opendata.swiss' and lists covered topics (infectious diseases, hospitalizations, mortality, vaccination rates). It differentiates from siblings reasonably well—there are similar search tools like swiss_opendata_search_datasets, swiss_energy_search_datasets, and swiss_statistics_search—but the BAG scoping does distinguish it. However, it doesn't explicitly contrast with sibling search 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 implies usage context (searching Swiss health-related open data) but provides no explicit when/when-not guidance or named alternatives. The sibling tool swiss_health_get_dataset appears related (probably fetching a specific dataset after search), but no relationship is explained. Context is inferred rather than stated.
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 mentions 'free, no auth' (useful access info) but doesn't disclose any limits (rate limits, pagination, response format, or whether it returns all three data types together or separately based on filters). With zero annotations and no output schema, this is a notable 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tight sentence plus a two-word clause, making it concise and front-loaded. It efficiently states the resource and the access requirement without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a lookup tool with 100% schema coverage and zero required parameters, the description covers the essentials: what it fetches and access requirements. However, with no output schema and no annotations, it doesn't clarify whether output is a list or single object, how filters combine (AND vs OR), or whether partial matches are returned. Adequate but with room for improvement given the absence of structured metadata.
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 100%, meaning all three parameters (canton, postal_code, municipality) are described in the input schema with examples. The description itself adds no parameter-level detail beyond 'get Swiss postal codes, street names, and administrative divisions,' which loosely maps to the three filters. Baseline of 3 is appropriate since the schema handles the heavy lifting.
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 what the tool does: get Swiss postal codes, street names, and administrative divisions via the OpenPLZ API. It identifies the resource (Swiss postal data) and the API source. However, it doesn't explicitly differentiate from siblings like swiss_geo_identify_canton or swiss_transport_station_search, though the purpose is distinct enough.
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 notes 'free, no auth,' which sets expectations about access. However, it doesn't specify when to use this tool vs. alternatives like swiss_geo_identify_canton or swiss_geo_identify_municipality, which could also resolve location information. No explicit exclusions or alternative references are provided.
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 mentions it searches via Fedlex but doesn't describe pagination, result count, language matching behavior, or whether partial/fuzzy matches are supported. For a search tool with zero annotation coverage, more behavioral context is needed.
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, compact sentence with zero wasted words. It conveys the platform and domain efficiently. This is appropriately concise for a tool with a single parameter and full schema coverage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter search tool, the description is mostly adequate. It identifies the platform (Fedlex) and domain. However, it doesn't clarify what output the user should expect (list of citations? full text? official bulletin?), and with no output schema and no annotations, some return-format guidance would improve completeness.
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 coverage is 100%, so the schema already documents the single 'query' parameter. The description adds the language constraint (FR/DE/IT/EN) which is meaningfully echoed in the schema description. With full schema coverage, baseline 3 is appropriate; the description contributes only marginal 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 states a specific verb+resource ('Search Swiss federal legislation via Fedlex') and names the platform, which makes the purpose reasonably clear. It doesn't explicitly distinguish from siblings, but sibling tools are mostly clearly different domains (transport, geo, weather), so ambiguity with siblings is low. It could be stronger by noting what kind of results are returned.
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 implies this is for finding Swiss federal law text but provides no explicit when-to-use guidance, what types of queries work best, or exclusions (e.g., cantonal law). Given the large sibling set of swiss_* tools, it's implied this handles legislation, but there's no guidance on when not to use it or alternatives.
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 full burden of behavioral disclosure. It mentions the API key requirement, which is useful. However, it does not disclose the return format, pagination behavior (despite a page parameter existing), rate limiting, whether results are capped, or whether partial matches vs exact matches are returned. For a search tool with zero annotation coverage, this is a meaningful gap.
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?
Two sentences: one states the purpose/resource, the second flag the API key requirement. Zero wasted words, front-loaded with the core purpose. Every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a search tool with 3 parameters (0 required), no output schema, no annotations. The description covers the domain and API key prerequisite but does not explain the results format, pagination semantics, or how search interacts with barcode lookup. For a search tool where agents may iterate on queries, missing pagination and result-format guidance represents a moderate completeness gap. Adequate for basic use but not rich.
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 67% - query and barcode have descriptions, page does not. The description adds the API key dependency context but does not add meaning beyond the schema for the query/barcode parameters. Since page is undocumented in the schema (counting as 33% missing) and the description neither confirms nor explains its semantics (pagination control), the description does not fully compensate for that gap. Baseline 3 is appropriate.
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 'Search Swiss food products in FoodRepo (EPFL open database of barcoded Swiss food products)' with a specific verb (search), specific resource (Swiss food products in FoodRepo), and even identifies the source database. It distinguishes this from siblings like swiss_food_nutrition_database which covers nutritional data rather than barcoded product search. Does not fully articulate what types of search fields it supports beyond the schema.
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 indicates the context (Swiss food products in a barcoded database) and mentions the API key requirement ('Requires FOODREPO_API_KEY'), which helps the agent know prerequisites. However, it does not explicitly state when to use this vs alternative tools like swiss_food_nutrition_database, nor does it mention pagination or how search results would flow into other tools. Usage context is implied 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description states what it searches but doesn't reveal any behavioral traits: no mention of whether results are scored/ranked, how many results are returned by default, whether it supports fuzzy matching, or whether it requires an API key. It's a fair baseline but omits behavioral details an agent would find useful. No contradiction with annotations since none exist.
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 a single efficient sentence that front-loads the core purpose. Zero wasted words. However, given the ambiguity around the 'types' parameter and the lack of usage guidance, a bit more content would have improved value without bloating it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no output schema, no annotations, and 50% schema description coverage, the description is thin for the tool's actual complexity. The tool offers spatial references (sr), type filtering (types), and limits — none of which are explained in the description. Given the moderate parameter count and absence of output schema, the description should provide more context about how types and sr affect behavior.
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 50% (query and sr are documented in the schema). The description adds no additional parameter semantics beyond re-stating that it searches locations; it doesn't clarify the 'types' parameter (locations vs featuresearch) or how 'sr' affects output. The query examples in the schema ('Lausanne', 'Rue de Rive Genève', '1201') already cover query format. With 50% coverage, the description could compensate but doesn't add any param details, so baseline 3 is appropriate.
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 verb ('Search') and resource ('Swiss location'), enumerating the types of locations covered: cities, addresses, communes, postal codes, points of interest. It's specific about scope (Switzerland) but doesn't explicitly distinguish from sibling geo tools like swiss_geo_identify_canton or swiss_geo_find_layer_features, though the search functionality is fairly distinct from those.
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 implies general search usage ('Search for any Swiss location') but provides no explicit when-to-use vs when-not-to-use guidance. It doesn't mention alternatives like swiss_geo_identify_canton or swiss_postal_data, nor does it describe exclusions or prerequisites (e.g., needing an API key set via swiss_set_api_key). Usage context is implied but not explicitly guided.
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 behavioral disclosure burden. The description states this is read-oriented (gets publications, shows history), which conveys a non-destructive operation. However, it doesn't disclose whether the UID maps to Swiss company registry data, whether results vary by canton, pagination/limits, or what happens when no publications exist. For a retrieval tool with zero annotation coverage, more transparency 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the purpose and adds a clarifying example of content type ('registration history, mergers'). No wasted words. It's appropriately sized for a single-parameter read tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a single required parameter, 100% schema coverage, no output schema, and no annotations, the tool is relatively simple. The description adequately conveys the tool's core function. However, lacking any note about output format/return structure (the 'etc.' is vague) and no mention of what types of data might be returned, the description stops short of being fully 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?
The single parameter 'uid' has 100% schema description coverage ('Company UID'), so the schema already documents it adequately. The description implies the UID is a company identifier by saying publications are 'for a company', but adds no format detail (e.g., should it be CH- prefixed, 9 digits, etc.). Since the schema covers the parameter fully, baseline 3 is appropriate.
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 uses a specific verb+resource ('Get SOGC publications for a company') and names the source (Swiss Official Gazette). It clarifies scope with 'registration history, mergers, etc.' While it doesn't explicitly distinguish from siblings, the sibling list includes swiss_company_by_uid and swiss_company_search which are clearly different operations (company lookup vs. publication history), so the purpose is reasonably 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving publication/registration history tied to a company UID, which creates enough context against sibling company tools. However, it provides no explicit when-to-use/when-not-to-use guidance, no mention of alternatives, and no indication of when this tool is preferred over swiss_company_by_uid. Usage context is implied 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?
No annotations are provided, so the description carries the full burden. It's a read-only lookup operation and the description implies this by describing an 'identify' action, but it doesn't state behavioral details like what coordinate system is expected (LV03/LV95 vs WGS84), what precision or boundary tolerance applies near municipal borders, or whether the input needs to be within Switzerland's bounds. For a geo lookup, coordinate system specification is a critical behavioral detail that's omitted.
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 a single, clear sentence with no wasted words. It's front-loaded with the primary action ('Identify which Swiss municipality'). One could argue it's slightly under-specified for a geo tool, but for what it contains, it's efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a fairly simple tool: 2 parameters, no output schema, no nested objects. The description gives the core purpose. However, key context is missing: the expected coordinate system (critical for Swiss geo tools where LV95 differs from WGS84), behavior for out-of-country coordinates, and boundary handling. Given the tool's relative simplicity, the description is adequate but leaves important geo-specific gaps unfilled.
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%, so the description must compensate for the two parameters (lat, lng). The description mentions 'coordinate' which implies lat/lng are the input coordinate components, giving them some context. However, it doesn't specify the coordinate reference system (WGS84 vs Swiss LV95), which is a substantive semantic gap for geo tools. The baseline of 3 applies given the 0% coverage but the description adds only minimal parameter meaning.
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 has a specific verb+resource structure: 'Identify which Swiss municipality (commune) a coordinate belongs to.' It clearly states what the tool does (reverse geocoding a lat/lng coordinate to a municipality). It distinguishes from siblings like swiss_geo_identify_canton (which returns a canton, a different administrative level) and swiss_geo_search_location (which searches by name rather than coordinates), though it doesn't explicitly name these distinctions.
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 implies usage context (given a coordinate, find its municipality) and the sibling set shows related geo tools exist. However, there's no explicit when-to-use vs when-not-to-use guidance, no mention of how it differs from identify_canton or search_location, and no note about coordinate format requirements (e.g., WGS84 or LV95). The clear intent is somewhat implied by ambiguity with the coordinate system issue.
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's a read-type operation, but the description doesn't state this, doesn't mention whether an API key is needed (note sibling swiss_set_api_key exists), whether network/rate limits apply, or what happens on invalid/unknown slugs. For a data-fetching tool with zero annotation coverage, this is a gap.
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?
Single sentence, zero filler, states purpose and key qualifier (by slug) efficiently. Nothing wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter retrieval tool, the description is fairly complete, but given the absence of annotations and output schema, it could add context about the return format (structure of download URLs and metadata), authorization requirements, or error behavior on unknown slugs. The sibling tool list reveals this is part of a broader Swiss data suite where setup/API-key tooling exists, suggesting auth context could matter.
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 100%, and the single parameter dataset_slug is clearly described with a concrete example ('covid-19-schweiz'). The description reinforces that it's the slug from opendata.swiss. With only one well-documented parameter, the schema already does heavy lifting, so baseline 3 is appropriate; the explicit example in schema bumps it slightly.
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?
Description states a specific verb+resource combination: 'Get direct download URLs and metadata for a specific BAG health dataset by its slug.' It clearly identifies what is retrieved and how the dataset is identified. It doesn't explicitly distinguish itself from sibling swiss_health_search_datasets, but 'by slug' implies searching by slug vs searching generally, providing implicit differentiation.
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 implies usage context: it's for retrieving a specific dataset when you already know its slug, complementing the search tool (swiss_health_search_datasets). However, it does not explicitly state when to use this vs the search variant, nor mention any prerequisite like having the slug from a prior search.
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 describes the data source (BAG + Swiss Health Observatory) which is useful credibility context. It doesn't disclose whether results are read-only (likely implied as a GET), data freshness, language availability, or any rate limits/pagination behavior. For a read operation the transparency is arguably adequate but thin.
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?
One concise sentence plus a source attribution. Every element earns its place: the action, the scope, and the data authority. Zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 1-parameter read tool with full schema coverage, the description is reasonably complete. However, no output schema exists, so the description could help by describing what the response looks like (e.g., data per canton, JSON format). Also, with health data, output format/unit expectations matter. The description doesn't address this gap.
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 coverage is 100% with a single indicator parameter that has a description with examples. The description adds the '100+ indicators by canton' context which helps frame what the parameter means. The description and schema together reasonably convey parameter semantics for a single-parameter tool.
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 states it gets Swiss Health Atlas data covering health indicators by canton with a specific verb+resource. It distinguishes from siblings like swiss_health_search_datasets by focusing on the Versorgungsatlas specifically. However, '100+ health indicators' is a reasonable scope statement, though it doesn't name the specific dataset structure, so it's clear but slightly under-specified for a data retrieval 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this vs alternatives. With siblings like swiss_health_get_dataset and swiss_health_search_datasets, there's no explicit differentiation on which to pick. The description doesn't state whether this is for the Versorgungsatlas specifically vs general Swiss data, so an agent would not know if this or swiss_health_get_dataset is the right call.
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 of behavioral disclosure. The description indicates this is a data retrieval (read) operation, which is implied by 'Get', but it doesn't disclose behavioral traits like whether API key setup (swiss_set_api_key, swiss_check_setup siblings exist) is required, rate limits, or data freshness/update cadence.
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 efficient sentence with zero waste. It states the purpose and data source clearly. This is appropriate conciseness for a simple one-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 1 param, full schema coverage, and no output schema, this is close to adequate. However, the tool touches on avalanche safety data where recency/timeliness matters, and there's no disclosure about data currency or update process. The presence of sibling setup tools (swiss_set_api_key, swiss_check_setup) suggests authentication may be needed, which isn't addressed.
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 100%, meaning the schema documents the single 'query' parameter with its default and description. Since there's only one parameter and it's fully covered by the schema, the description adds minimal value beyond 'Get ... data'. The baseline of 3 applies because the schema handles the documentation burden.
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 verb ('Get') and resource ('avalanche warning and snow data from SLF'). It distinguishes the data source from sibling tools. However, it doesn't quite match the level of specificity shown in top-tier examples — it doesn't clarify what specific data fields or formats are returned.
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 implies usage (avalanche/snow data needs) but provides no explicit when-to-use vs alternatives guidance. Sibling tools like swiss_weather_search_meteoswiss could overlap with weather/snow data, yet no differentiation is offered. No exclusions or context around when this tool is preferred.
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 adds the useful facts that there are 14,000+ datasets and that no auth is required, which is genuinely helpful context. However, it doesn't disclose pagination behavior, result limit behavior, what the response structure looks like, or rate limits. For a search tool with zero annotation coverage, more behavioral disclosure 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, information-dense sentences with zero waste. Every word earns its place — purpose, scope, scale, and auth requirement are all conveyed efficiently. Front-loaded with the core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no output schema and no annotations, the description is somewhat thin. It doesn't explain return format, result ordering, or default behavior of rows. However, search tools are relatively straightforward, and the siblings suggest this is part of a larger family where domain-specific search tools exist. It's adequate but not rich.
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 50% (query and organization have descriptions, rows and format do not). The description itself adds no parameter-specific information beyond what the schema provides. With 50% coverage, the description could compensate for the undocumented rows/format parameters but does not. Baseline 3 is appropriate since half the parameters are documented in 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?
Description clearly states what the tool does: 'Search the opendata.swiss catalog — 14,000+ official Swiss government datasets.' The verb (Search) plus resource (opendata.swiss catalog) is specific and clear. Among siblings there are multiple *_search_datasets tools (health, energy, statistics), so it somewhat differentiates by naming the opendata.swiss catalog explicitly, though it doesn't explicitly distinguish from those sibling search 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?
It states 'No auth required' which is useful setup context and implies it can be used freely without API key preparation. However, it doesn't explicitly say when to use this vs the domain-specific search tools (swiss_health_search_datasets, swiss_energy_search_datasets, swiss_statistics_search) or provide concrete exclusion guidance. Usage context is implied 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?
No annotations are provided, so the description carries the full burden, but no behavioral details are disclosed beyond the basic action. It doesn't warn about network dependency on the REFRAME service, potential latency, error conditions, or whether conversions are reversible/precise. As a read-only conversion tool this is less critical, but there's little added behavioral context beyond stating the service source.
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?
Single clear sentence that efficiently captures the tool's purpose and confirms the official source. No wasted words. Could optionally add usage context, but as a purpose statement it is tight and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a conversion tool with 4 straightforward params, 2 enums, and no output schema, the description is functional but lean. It doesn't explain return format (which coordinate values are returned, order, or units) nor the axis ordering caveat between Swiss northing/easting and WGS84 lat/lng. Given no output schema exists, some note about the response shape would improve completeness. Parameter definitions carry partial meaning via schema descriptions.
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 coverage is 50% — the two system parameters have enums (self-documenting), but coord1 and coord2 have partial descriptions ('lat for WGS84, northing for Swiss'). The description doesn't add meaningful parameter context beyond what the schema provides, such as formatting requirements, decimal precision, or axis ordering. The schema partially documents parameters; description adds minimal extra value.
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?
Description states a specific verb ('Convert') with a clear resource ('coordinates') across three named systems (LV95, LV03, WGS84) and specifies the reference service (swisstopo REFRAME). It clearly distinguishes from sibling geo tools like search_location, get_elevation, and identify_canton, all of which do different things.
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 implies conversion use-cases but doesn't explicitly state when to choose this over alternatives or name specific sibling tools. It mentions the official service as a differentiator, but there are no exclusions or when-not-to-use guidance. No guidance on which input format pairs are valid (e.g., WGS84 requires lat/lng whereas Swiss systems use northing/easting).
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. The description identifies this as a read operation ('Get elevation') and names the official service, giving some credibility context. However, it doesn't disclose behavior around coordinate validity, error handling, or whether it strictly requires Swiss coordinates, which are important behavioral traits for a geo tool.
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 a single, well-structured sentence that front-loads the key information: what it returns (elevation in meters), the input format (WGS84), scope (Switzerland), and source (official swisstopo REFRAME service). Every element earns its place with no filler words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given 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 and no annotations, the description is reasonably complete but could benefit from stating the output format more explicitly and any behavioral constraints (e.g., Swiss coordinate bounds). The core purpose, input, and result unit are all covered, but edge case handling is unaddressed.
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 100%, so the schema already documents both lat and lng parameters with examples. The description adds the coordinate system (WGS84) context, which is valuable and not fully explicit in the schema. However, it doesn't add range validation info or clarifying details beyond what the schema provides, 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?
Description clearly states the verb ('Get elevation'), the exact resource (elevation/altitude in meters), the coordinate system (WGS84), the geographic scope ('anywhere in Switzerland'), and the official service (swisstopo REFRAME). This is a specific, well-scoped purpose that clearly distinguishes it from sibling geo tools like coordinate conversion or location search.
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 implies usage context (retrieving elevation for a lat/lng point in Switzerland) but provides no explicit when-to-use vs alternatives guidance. It doesn't mention limitations like coordinate validity ranges or what happens outside Switzerland. No exclusions or alternative tool references are provided.
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 does disclose the authentication requirement (ZEFIX_USER and ZEFIX_PASS env vars) and the need for a free account, which is valuable operational context. However, it doesn't disclose rate limits, whether this is a cost-bearing operation, or error behavior if credentials are missing. Still, the auth disclosure is genuinely useful beyond 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence that efficiently conveys the source, purpose, and a critical prerequisite. Zero wasted words; every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 4 parameters, no output schema, and no annotations, the description covers the essential prerequisites but misses behavioral details like result ordering, pagination behavior, rate limits, and error handling for missing credentials or no matches. It's adequate for a basic search but lacks depth given the auth complexity and no output schema to fall back on.
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 50% (name and canton have descriptions; active_only and max_results are undocumented in the schema). The description adds the ZEFIX-specific context and auth needs but doesn't explain parameter semantics like what active_only default true means or what max_results caps. With 50% coverage, the description partially compensates but leaves two parameters still under-explained.
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 this searches Swiss companies in the ZEFIX official commercial register, with a specific verb+resource combination. It slightly overlaps with sibling swiss_company_by_uid (which presumably searches by UID), but the description names the ZEFIX source which helps orient the agent. It doesn't explicitly distinguish from swiss_company_by_uid though.
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 ZEFIX as the data source and notes the env var requirement, which implies it's the appropriate tool for commercial register lookups. However, it doesn't explicitly state when to use this vs. swiss_company_by_uid (e.g., name-based search vs. UID-based lookup) or any exclusion criteria. The context of ZEFIX hints at usage but no explicit alternative comparison is made.
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 behavioral burden. It discloses the API source (OpenParlData API) and coverage scope (74+ parliaments), which adds useful context about what data is accessible. For a read/search tool, this is reasonable disclosure, though it doesn't mention pagination, result ordering, or limits on query 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, efficient sentence that captures purpose, content type, scope, and API source with zero padding. Front-loaded with the core function. Every word earns its place.
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 search tool with a basic schema and no output schema, the description covers the essential scope and content. It could add result-format expectations (e.g., what fields are returned), but given the simplicity of the tool and sibling context, it is reasonably complete. Not penalized heavily for missing return details absent an output schema.
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 coverage is 67%, meaning query and parliament have descriptions but limit does not. The description adds the type/scope context but doesn't elaborate on limit semantics or default behavior. Baseline 3 is appropriate given moderate schema coverage; description enhances parliament/query meaning somewhat.
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?
Description states a specific verb+resource ('Search Swiss parliamentary business') and enumerates content types (motions, postulates, votes) and scope (74+ cantonal and national parliaments via OpenParlData API). This distinguishes it from sibling tools like swiss_parliament_persons, which targets persons rather than business. Could name the sibling explicitly for full differentiation, hence 4.
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 implies usage for searching parliamentary business across Switzerland, which is reasonably clear. However, it doesn't explain when to prefer this over swiss_parliament_persons or swiss_federal_law_search, and gives no exclusions or selection criteria among close sibling search tools. 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the disclosure burden. It discloses the authentication requirement (ZEFIX credentials), which is useful behavioral context. However, it doesn't describe the response format, whether failed lookups return errors vs empty results, or any rate limits. For a single-UID read operation, this is adequate 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, focused sentence that conveys purpose and a critical precondition in one line with zero wasted words. The UID format example is a useful concrete detail packed into the sentence efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool, the description is fairly complete. However, the credential requirement is a meaningful operational detail worth expanding — e.g., what happens without ZEFIX credentials, or how setup relates to swiss_check_setup. The output schema is absent, so it does not clarify the return structure, but for a details lookup tool this is partially acceptable.
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 coverage is 100%, with the uid parameter already documented in the schema with format instructions. The description reinforces the format but adds little new semantic meaning beyond what the schema provides. Baseline 3 is appropriate given full 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 verb ('Get') and specific resource ('full details of a Swiss company by its UID'), including a concrete UID format example (CHE-123.456.789). It distinguishes from the sibling swiss_company_search, which presumably searches rather than retrieves by exact identifier.
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 'by its UID' implying the tool is for exact-identifier lookup, which differentiates it from the sibling swiss_company_search. It also states the credential requirement ('Requires ZEFIX credentials'), telling the agent a precondition. However, it doesn't explicitly say 'use this when you have a UID' or contrast with alternatives like swiss_company_search.
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 persistence location (~/.swiss-apis-mcp/keys), immediate-effect behavior, and the optional nature of the key. It doesn't mention whether setting a key overwrites existing values or how to delete/clear a key, but the provided details cover the most important behavioral traits for a credential-storage tool.
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?
Three sentences covering purpose, storage, effect, and user-interaction guidance. Efficient and front-loaded with the primary purpose. No wasted words, though the behavioral detail about storage location could arguably be trimmed. Well-structured for an agent to quickly extract purpose and safety guidance.
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 tool is simple (2 params, no output schema, no nested objects), so the description covers the essentials well: purpose, storage location, immediate effect, and the instruction to ask the user first. The main gap is the lack of guidance on overwriting or managing multiple keys, but given the low complexity of the tool, the description is 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?
With 100% schema description coverage, the baseline is 3. The description adds meaningful context that the key enables 'Swiss API tools that require it', tying parameters to their operational effect. However, the enum values (key names) are not individually explained beyond their names, and the description doesn't add much per-parameter semantic value beyond what the schema's field descriptions already provide.
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 action 'Store an optional API key', the specific resource (Swiss API tools that require it), and the exact storage location. It clearly distinguishes this tool from all sibling tools, which are data-retrieval tools, by being the only configuration/setup tool in the set.
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 instructs 'Ask the user for the value before calling this tool', which is critical safety guidance for an API-key tool. It also clarifies the timing (takes effect immediately, no server restart needed) and implies this is a prerequisite step for other Swiss tools that need the key. The description frames it as a setup action, distinguishing it from the many data query 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?
No annotations are provided, so the description carries the burden. It explains the tool is a read-only configuration check that reveals operational status, which is reasonable behavioral disclosure. However, it doesn't describe the output format, whether it returns a list of configured vs. unconfigured keys, or any caveats about caching or freshness of the key status check.
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?
Two sentences, zero wasted words. The first sentence states the purpose, the second gives imperative usage guidance. It is appropriately sized for a zero-parameter utility tool and fully front-loaded.
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 zero-parameter, no-output-schema utility tool among many data tools, the description is complete: it defines the purpose and gives clear invocation context. It could mention what the output looks like (list of keys), but since there's no output schema and the agent needs to know what to expect, a minor gap exists. Still, it fully serves its purpose for a simple check tool.
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 are no parameter semantics to document. Per the rubric, 0 params earns a baseline of 4. The description correctly communicates this is a no-input introspection call.
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 this tool checks which optional API keys are configured, with a specific verb+resource ('Check which optional API keys are configured'). It establishes itself as a setup/configuration introspection tool, distinct from the many data-returning sibling tools. The 'Call this first' framing gives it a clear, unique role among 30+ siblings.
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 instructs when to call it: 'Call this first to know which Swiss API tools are fully operational and which need a free API key.' This gives explicit usage context and tells the agent to invoke it before other Swiss tools, which is clear action guidance. It differentiates operational vs. non-operational tools.
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-apis-mcp MCP server](https://glama.ai/mcp/servers/clement8426/swiss-apis-mcp/badges/card.svg)](https://glama.ai/mcp/servers/clement8426/swiss-apis-mcp)

Score Badge

Copy to your README.md:

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

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