Zurich Open Data MCP Server

Server Quality Checklist

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

Latest release: v0.7.0
Disambiguation3/5
The presence of deprecated alias tools (get_beschluesse_by_departement, etc.) alongside the newer zurich_strb_* tools creates direct overlap and ambiguity. While most tools target distinct domains, these redundant entries could cause an agent to select the wrong tool or confuse the two sets.
Naming Consistency4/5
The majority of tools follow a consistent zurich_verb_noun pattern (e.g., zurich_search_datasets, zurich_parking_live). However, the deprecated aliases use a different naming style (get_... instead of zurich_...) and the zurich_strb_* tools use an abbreviated naming that slightly breaks the pattern.
Tool Count5/5
With 26 tools covering diverse domains (air quality, weather, parking, parliament, tourism, geographic data, etc.), the count is well-scoped for a city open data portal. Each tool serves a distinct purpose and earns its place without feeling bloated.
Completeness4/5
The tool surface covers a broad range of Zurich open data topics, including live data, search, geographic features, and parliamentary records. Minor gaps exist (e.g., no update or create operations), but these are acceptable for a read-only API focused on data exploration.
Average 3.8/5 across 26 of 26 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 63 commits in the last 12 weeks
- Last stable release on July 31, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey readOnly, idempotent, non-destructive traits. The description adds no behavioral detail beyond stating it behaves identically to the replacement tool, which does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it is a deprecation notice rather than a functional description. It is concise but fails to inform about the tool's purpose or usage.
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 the tool's complexity (multiple parameters, output schema exists), the description is insufficient. It lacks information on what the tool returns or how to invoke it effectively, despite the existence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not describe any parameters. Despite the input schema having detailed parameter descriptions, the tool's own description provides no parameter semantics, relying entirely on schema, which context signals indicate 0% coverage from the description.
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 only states it is deprecated and an alias for `zurich_strb_search`, but does not explain what the tool does (e.g., search Stadtratsbeschlüsse). The purpose is unclear without knowledge of the replacement tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. It instructs to use the new tool but gives no context on when or why to use this alias versus 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds no behavioral context beyond the deprecation notice, providing no added value.
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 very short and front-loaded with the deprecation warning. It is concise, but could be improved by also stating the tool's purpose.
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?
Despite having annotation coverage and a schema, the description fails to inform the agent about the tool's core functionality. The agent cannot determine what this tool retrieves without inferring from the name or alternative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema includes detailed descriptions for all parameters, so the baseline is 3. The description does not contribute any additional parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only states that the tool is deprecated and an alias for another tool. It does not describe what the tool does, leaving the agent without any understanding of its function.
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 tells the agent not to use this tool and directs them to the new tool 'zurich_strb_by_department'. This is clear guidance for a deprecated tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the tool is known to be safe and read-only. The description adds a return format (Markdown list) but does not disclose any additional behavioral traits beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: four sentences that front-load the core purpose, list supported categories, mention data format, and state the return type. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a straightforward search with clear categories and filters, the description and annotations together provide adequate context. An output schema is indicated as present, and the description notes the return format. Slightly lacking in usage guidance for specific categories, but overall satisfactory.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not elaborate on any of the five parameters (format, category, language, max_results, search_text) beyond what the input schema already provides. Schema descriptions are detailed, but the free-form description adds no extra meaning for parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches (Sucht) for attractions, restaurants, hotels, and events via the Zurich Tourism API. It lists specific categories and uses a German verb that precisely describes the action. Among siblings, it is distinctly about tourism, not other city data.
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 guidance on when to use this tool versus alternatives. It does not mention when not to use it or which sibling tools might be more appropriate for specific tasks (e.g., parking or air quality queries).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnly, idempotent, non-destructive. The description adds return format (Markdown table) and indexing behavior, complementing annotations well.
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 sentences plus a return line, no wasted words. Front-loaded with core action.
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?
Covers purpose, return format, and basic behavior. Minor gaps like pagination details are handled by 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?
Input schema has descriptions for all parameters (high coverage). The description adds no additional parameter details, so baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries tabular data from CKAN DataStore with filtering. It implicitly distinguishes from the SQL sibling but does not explicitly differentiate.
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 like zurich_datastore_sql or search tools. Missing when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds that data is yearly updated, but does not disclose pagination, rate limits, or exact response structure. Some additional context but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two main sentences and a returns line. It is front-loaded with the main purpose. The returns line is somewhat redundant given an output schema exists, but it adds clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description does not need to detail return values. It mentions key aspects (yearly updates, vehicle types). The omission of real-time indicator is acceptable as a static dataset.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the tool description does not compensate for the schema's parameter descriptions. The text only mentions line and stop examples, ignoring limit, query, and format parameters. The schema itself has descriptions, but the tool description adds minimal 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?
The description clearly specifies that the tool retrieves passenger numbers for VBZ lines and stops, including vehicle types and yearly updates. This distinguishes it from unrelated sibling tools like parliament or weather data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. The context implies it is for VBZ passenger data, but alternatives or exclusions are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds value by specifying the data source (UGZ), update frequency (hourly), and that it returns current values per station with units. This provides operational context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: three sentences covering purpose, data source, and return format. Every sentence adds value, and the most important information is 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?
For a simple read-only query tool with well-documented parameters and annotations, the description is adequate. However, it lacks usage guidelines and does not explain the output schema (which exists but is not shown). This leaves minor gaps in 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?
The input schema already provides detailed descriptions for all parameters (limit, format, station, parameter) with enums and defaults. The tool description only lists the parameters generically, adding no extra meaning. Since schema coverage is high, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (liefert), resource (Luftqualitätsmessungen aus Zürich), and update frequency (stündlich). It also lists the measured parameters. This sufficiently distinguishes it from sibling tools which focus on other datasets like parking or weather.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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, or any conditions/precautions. The description does not mention when not to use it or suggest other tools for related queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, non-destructive, and idempotent. The description adds that it returns a GeoJSON FeatureCollection and supports markdown or JSON output, but does not disclose additional behavioral traits like rate limits or authentication needs.
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 two short paragraphs, front-loading the purpose and listing examples. It is concise without redundant information, though the 'Returns' line could be more integrated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple read-only nature, annotations, and output description (GeoJSON FeatureCollection), the description covers the essential context. It does not explain pagination or edge cases, but the tool's scope is narrow and well-covered.
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 descriptions for parameters (layer_id, format, max_features, property_filter) are detailed, so schema_description_coverage is high. The description adds minimal extra beyond mentioning feature types and properties (points, polygons, names, addresses).
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 it fetches geo data from the Zurich WFS Geoportal as GeoJSON. It lists example features (schools, districts, playgrounds) and differentiates from sibling tools which focus on other city data like parliamentary records or weather.
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 examples of use cases (schools, playgrounds, etc.) but does not explicitly state when to use this tool versus alternatives like zurich_geo_layers or other data tools. The usage context is implied but not clearly scoped.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds that it returns a markdown-formatted list (or JSON) and mentions the format parameter, but does not disclose further behavioral traits beyond what annotations cover.
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 four sentences, clearly front-loaded with the main purpose. It is well-structured and free of fluff, though it could be slightly more concise by merging the second and third sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with an output schema (present but not shown), the description covers purpose, linkage to a sibling tool, and output formats. It is complete enough for an agent to understand how to 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 coverage is 0% (context signal), so the description must compensate. It mentions 'format' can be 'markdown' or 'json' and 'Markdown-formatierte Liste... (oder JSON bei format='json')'. This adds meaning but is minimal; the schema itself also has a description for format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all available WFS layers of Zurich's geoportal, specifying the information shown (Layer-ID, WFS service name, typename, description). It also notes that the IDs can be used with zurich_geo_features, distinguishing it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: to get available layers before using zurich_geo_features. However, it does not explicitly state when to use this tool versus alternatives, nor does it list exclusions or when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds that it behaves identically to `zurich_strb_detail`, which is useful but does not go beyond the annotations (readOnlyHint, idempotentHint, destructiveHint) that already indicate a safe, idempotent read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two sentences) and front-loads the critical deprecation information, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is deprecated and the description redirects to the new tool, it is contextually complete for its primary intention. The output schema exists but is not described; however, for a deprecated tool, that is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no parameter information. While the input schema itself describes the single parameter with format and examples, the description does not compensate for the low coverage, which is expected for a deprecated alias but still leaves the agent with minimal guidance.
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 it is a deprecated alias for `zurich_strb_detail`, which tells the agent the tool's purpose (retrieve a single city council decision) indirectly through the sibling name. The title also adds clarity.
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 tells the agent not to use this tool and to use `zurich_strb_detail` instead, providing clear when-not-to-use and an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive behavior. The description adds that only SELECT queries are allowed and returns JSON results, which aligns with annotations and provides useful behavioral context beyond what annotations offer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, front-loads the purpose, and avoids unnecessary details. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (SQL queries) and the presence of an output schema (context indicates it exists), the description covers input, constraints, and output format. It could mention error handling or performance but is adequate for agent selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already includes a description with an example. The tool description adds constraints (only SELECT) and capability (complex queries) that are not in the schema, providing some added value, but does not elaborate on parameter format or validation.
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 it executes SQL queries on the CKAN DataStore, specifying it supports complex queries like JOINs and GROUP BY, and only SELECT is allowed. This differentiates it from sibling tools like zurich_datastore_query.
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 explicit guidance on when to use this tool versus alternatives such as zurich_datastore_query. It only implicitly suggests it's for complex SQL queries but lacks when-not-to-use or alternative comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds that the tool returns a list of tags, which is consistent with read-only behavior. No additional behavioral traits (e.g., rate limits, auth needs) are disclosed, but the annotations cover the core safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a single sentence stating the purpose, a brief explanatory line, and an example. It is front-loaded with the core action. No unnecessary words.
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 has an output schema (not shown) and clear annotations. The description states it returns a list of tags, which is sufficient for a simple search tool. It could mention that tags are returned in order of relevance or that pagination may apply, but overall it is complete for the task.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides clear descriptions for both parameters ('limit' with min/max and default, 'query' with example). The tool description does not add any further semantic meaning beyond what the schema already offers. Baseline score of 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches available tags in the open data catalog, with a specific verb 'Durchsucht' and resource 'Tags'. Examples like 'volksschule' and 'kindergarten' make the purpose concrete. Sibling tools cover distinct data types, so the distinction is 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 mentions that tags help find thematically related datasets, which implies usage when searching for tags. However, no explicit guidance is given on when to use this tool versus alternatives or when not to use it. The context is adequate but lacks formal usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, indicating safe, read-only behavior. The description adds that the tool returns a Markdown list and uses the 'Paris API', but does not elaborate on search scope (only titles, as noted in schema) or limitations. With strong annotation coverage, the description adds moderate value.
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 extremely concise: two sentences plus a one-line return type. It front-loads the core purpose and key differentiators (school relevance). Every sentence serves a purpose without extraneous language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity of a search tool and the presence of an output schema (not shown), the description adequately covers the tool's behavior. It specifies the return format (Markdown) and the type of results. However, it omits details like pagination or result limits (though max_results in schema covers that). Slight room for improvement in describing the search scope (only title vs. full text).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides detailed descriptions for all parameters (e.g., query with examples, format enum, year range filters, department filter), so schema coverage is high. The tool description does not repeat or add to these parameter-level details, but the schema itself is sufficient. Thus, the description adds minimal additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches 'Geschäfte des Gemeinderats' (city council business) and lists specific types (Interpellationen, Motionen, Postulate, Anfragen). It distinguishes from sibling tools (e.g., search_stadtratsbeschluesse for executive decisions) by targeting parliamentary motions. The connection to school topics via SSD provides additional context.
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 usefulness for school topics because many items relate to the Schul- und Sportdepartement, which helps agents decide when to use it. However, it does not explicitly state when not to use it or compare with alternatives like search_stadtratsbeschluesse, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only and open-world hints. The description adds behavioral context: data source, measurement details (direction, weather), and ordering (newest first). It does not contradict annotations and provides useful transparency beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two short paragraphs, four sentences. It front-loads the core purpose, includes data source and method, and uses a 'Returns' section. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers data source, measurement, and ordering. However, it omits explicit mention of the 'limit' parameter and pagination behavior. Given the presence of an output schema (not shown), the tool is mostly complete but could benefit from parameter 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?
The description does not mention parameters, but the input schema includes descriptions for 'limit' and 'format' with defaults and constraints. Since the schema covers these details, the description adds no extra semantic value; baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool delivers hourly pedestrian frequencies at Zurich's Bahnhofstrasse, specifies data source (hystreet.com sensors at 3 locations), and mentions measured data (number of pedestrians per hour including direction and weather). This distinguishes it from other Zurich 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?
The description provides no guidance on when to use this tool versus sibling tools (e.g., zurich_air_quality, zurich_vbz_passengers). No context about prerequisites or alternatives is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context about the Markdown return format and error cases (not found or before Feb 2025), which helps with behavioral expectations beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary, argument details, and return description. It is concise but covers essential information without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the explanation of the Markdown return format and error handling is sufficient. The tool is simple with one parameter, and the description provides adequate completeness for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite the schema description coverage being 0% per context, the description provides the format and an example for the parameter, and adds context about where the number appears. This adds value beyond the schema's pattern and length constraints.
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 it returns metadata of a single council decision (Stadtratsbeschluss) by number, listing the specific fields (title, date, department, link). It does not explicitly differentiate from the sibling tool 'get_stadtratsbeschluss_detail', which may appear similar, but the purpose is 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 when one has a Beschlussnummer and wants details, but it does not provide guidance on when to avoid this tool or suggest alternatives like search or filtering tools among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds value by specifying the real-time nature, 10-minute interval, and station-specific measurements. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core purpose, then details stations, interval, and measurements. There is minor redundancy with a 'Returns' line that repeats content. Overall efficient but could be slightly tighter.
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 with 3 parameters, annotations cover read-only safety, and there is an output schema. The description provides sufficient context for a real-time data retrieval tool, including what data is returned. No major gaps given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% according to context, meaning the description does not add meaningful information about parameters beyond what is in the schema. The tool description mentions measurements but does not explain parameters like limit, format, or station. Given low schema coverage, the description should compensate but does not.
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 it provides real-time weather data from the Zurich water police, specifying stations (Tiefenbrunnen, Mythenquai), interval (10 minutes), and measurements (water/air temperature, wind, water level, precipitation, etc.). It distinguishes itself from siblings like zurich_weather_live by focusing on water-specific weather.
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 water-related weather data but does not explicitly state when to use this tool over alternatives like zurich_weather_live. No exclusions or when-not-to-use guidance is provided. Usage is implied but not instructed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, open-world, idempotent, and non-destructive behavior. The description adds behavioral context by mentioning it uses a curated combination of search terms and returns a Markdown list, providing value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise paragraphs plus a return type line. Every sentence adds value; no fluff or repetition. Front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single optional parameter and an output schema (not shown), the description covers the main purpose, returns format, and search methodology. Could mention pagination or result limits but is largely complete for a focused search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the tool description does not explain the 'topic' parameter. Although the schema itself describes the parameter with examples, the description fails to compensate for the low coverage, offering no semantic addition for the parameter.
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 it finds datasets relevant to the school board and primary schools. It uses specific examples like school facilities, education data, district school boards, student statistics, school routes, and related topics, differentiating it from general search tools like zurich_search_datasets.
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?
Implies usage for school-related data search but provides no explicit guidance on when not to use it or how it compares to alternatives like the general search tool. Lacks exclusion criteria or context for using this over zurich_search_datasets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds context: returns Markdown list with dataset counts, and that it can list all or show details. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short, front-loaded with the main action, and each sentence provides distinct value. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with one optional parameter and an output schema, the description adequately explains the purpose and return format. Could mention the hierarchical structure if any, but not necessary.
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 schema already describes the group_id parameter with an enum and explanation. The tool description reinforces the behavior: if group_id provided, shows details; if empty, lists all. This adds practical usage context 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?
Description clearly states it lists all categories or shows details of a specific category. It uses specific verb (listet/zeigt) and resource (Datenkategorien). However, it does not explicitly differentiate from similar sibling tools like zurich_list_tags, though the context suggests different purposes.
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 when to use: when you need to see categories. It explains behavior based on whether group_id is provided. However, no explicit guidance on when not to use or comparison with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare it read-only, idempotent, and non-destructive. The description adds that it shows current mandates and functions and returns a Markdown list, providing additional useful behavior context.
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?
Extremely concise: three sentences plus a return note, front-loaded with the main purpose, no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With annotations, schema, and output schema present, the description covers the tool's purpose and return format. Lacks mention of optional parameters (format, active_only, max_results) but schema compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions three of the six parameters (name, party, commission) but does not explain format, active_only, max_results. However, the input schema provides detailed parameter descriptions, so the overall parameter understanding is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for members of the city council of Zurich, and specifies searchable fields (name, party, commission). It distinguishes itself from sibling 'zurich_parliament_search' which likely focuses on documents.
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?
Usage is implied by stating the search capabilities, but no explicit guidance on when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it's a safe read operation. The description adds context about using Solr for full-text search and the return format, but does not detail any limitations or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two short sentences that front-load the action, then explain the search engine and return format. Every sentence is meaningful with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters well-documented in schema) and presence of an output schema, the description adequately explains the search mechanism and result usage. It could mention sorting/filtering capabilities, but the schema covers those details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not add meaning beyond what the input schema provides. Since the schema already documents all parameters with descriptions and examples (e.g., query, rows, sort), the description adds no extra value for parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Durchsucht den Open-Data-Katalog der Stadt Zürich nach Datensätzen', specifying the verb (search) and resource (open data catalog). It distinguishes from siblings by mentioning the return format and chaining with zurich_get_dataset.
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 general dataset search but does not explicitly state when to use this tool over siblings or when not to use it. No exclusions or alternative suggestions 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?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by specifying the data source (UGZ), update frequency (hourly), and list of stations, which provides behavioral context beyond annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: three sentences covering purpose, data source, stations, and return values. It is front-loaded with the main action and efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema (context indicates yes) and annotations covering safety, the description is complete enough. It mentions return values (temperature, humidity, etc.) and station list, adequately complementing the 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?
The input schema has descriptions for each parameter (limit, format, station, parameter), achieving high schema description coverage. The description does not add further parameter details, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'liefert stündlich aktualisierte Wetterdaten der UGZ-Messstationen Zürich', specifying the verb 'delivers', resource (weather data), and scope (hourly, from specific stations). It distinguishes itself from siblings like zurich_air_quality and zurich_water_weather by focusing on live weather data from UGZ stations.
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 for live weather data but does not explicitly compare with sibling tools or provide when-not-to-use guidance. Given the existence of weather-related siblings (e.g., zurich_air_quality, zurich_water_weather), more explicit distinction would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering safety. The description adds behavioral context about combining search with analysis and returning structured results plus Markdown report, which is consistent and adds value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two paragraphs and a clear 'Returns:' section. It is front-loaded with purpose. Minor redundancy between first sentence and subsequent explanation, but overall well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description need not detail return values. It adequately covers purpose, what the tool does, and the nature of output. It could mention that query is required, but the schema covers this. Annotations add openWorldHint. Overall complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has detailed descriptions for all parameters (e.g., query, max_datasets, include_freshness, include_structure), so the description adds little beyond referencing update frequency and field schemas. With high schema coverage, baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes datasets comprehensively, focusing on relevance, actuality, and data structure. It combines search with analysis, distinguishing it from sibling tools like zurich_search_datasets (search only) and zurich_get_dataset (single dataset retrieval).
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 notes it is useful for finding available data and assessing its timeliness/completeness, providing clear usage context. It does not explicitly state when not to use or list alternatives, but the context of siblings implies differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds context beyond annotations by specifying the data source (ParkenDD API), number of parking garages, and output format options (Markdown table or JSON). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is presented in both German and English, which adds redundancy and length. While it is not overly long, it could be more concise by using a single language or combining the two.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, read-only), the description covers essentials: real-time data, 36 locations, output format, and data source. It could mention limitations or update frequency, but is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema description coverage is indicated as 0%, the schema actually contains a description for the `format` parameter. The description further clarifies by mentioning 'Markdown-Tabelle mit aktuellen Parkhaus-Belegungen (oder JSON bei format='json')', adding value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves real-time parking occupancy data for Zurich, specifying the resource (36 parking garages) and output details. It distinguishes itself from sibling tools which are mostly about city council, air quality, or datasets, as this is the only parking-specific tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates usage for real-time parking data, but does not explicitly state when to use this tool vs alternatives. However, given the unique nature of this tool among siblings, the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, non-destructive behavior. The description adds context about the return format (list with specific fields) and parameter behavior, going beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a clear purpose, usage example, Args section, and Returns section. Every sentence adds value and is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters and no output schema provided, the description covers all necessary aspects: input parameters, return structure, and safety (via annotations). It is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description explains all parameters in detail, including examples for `departement` and valid formats. This compensates fully for the lack of schema descriptions.
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 it returns city council decisions by department with an example. However, it does not distinguish itself from the sibling tool `get_beschluesse_by_departement`, which appears to have a similar purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a specific use case (institutional analysis) but does not mention when not to use this tool or suggest alternative tools for different contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is read-only, idempotent, and non-destructive. The description adds value by detailing the kind of statistical information returned (counts, distributions), beyond what annotations provide. No contradictions detected.
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 extremely concise: two short sentences plus a return note. It front-loads purpose immediately and uses bullet-like clarity without superfluous words. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, simple output, and annotations covering safety and openness, the description sufficiently explains what the tool does and returns. The presence of an output schema further reduces the need for detail.
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 no parameters, and the input schema coverage is 100%. The description does not need to explain parameters, and the baseline score of 4 is appropriate as it adds no unnecessary information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides an overview of the entire Zurich open data catalog, specifying that it shows total number of datasets, category distribution, and common formats and tags. This uniquely distinguishes it from sibling tools that focus on specific datasets, searches, or other domains.
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 obtaining aggregate catalog statistics but does not explicitly state when to use this tool versus alternatives like search or specific dataset tools. There is no guidance on when not to use it or mention of prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, indicating safe, non-destructive behavior. The description adds value by specifying the return format (structured JSON plus markdown) and chaining opportunity, but does not disclose any additional behavioral traits like rate limits or permissions.
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 brief (two sentences plus a returns line), front-loaded with the main purpose, and efficiently conveys key details without extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-parameter input, rich annotations, and presence of an output schema, the description sufficiently covers what the tool does, what it returns, and how it connects to other tools, making it complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a clear description for the single parameter dataset_id, including examples. The tool description does not add further semantic detail, so it meets the baseline for a well-documented schema parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves complete metadata and resources of a dataset, listing specific fields returned (title, description, author, etc.). It distinguishes from siblings like zurich_datastore_query (query data) and zurich_search_datasets (search), making the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a usage pattern by mentioning the result can be chained with zurich_datastore_query, providing context for when to use this tool. However, it lacks explicit when-not or alternative recommendations, which is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, idempotentHint, destructiveHint) are aligned. The description adds value by disclosing the backend endpoint, search method (ILIKE), and details on return format. It also mentions data availability and license, providing complete behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized: purpose, technical details, data availability, license, then Args/Returns. It is front-loaded with the main action and every sentence adds value without redundancy. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (as indicated in context), the description still provides a useful summary of return fields. It covers everything an agent needs: search functionality, parameter details, output format, data source, and limitations (public resolutions from Feb 2025). Complete and actionable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains all parameters (query, departement, datum_von, datum_bis, limit, format) with examples, complementing the input schema which already has descriptions. It provides a quick reference for usage. The 0% schema description coverage in context seems inconsistent, but the description adequately covers parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: full-text search of public city council resolutions (STRB) using CKAN Datastore SQL endpoint. It specifies the exact resource (Stadtratsbeschlüsse) and action (Volltextsuche), distinguishing it from siblings like get_beschluesse_by_departement and search_stadtratsbeschluesse.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use the tool (full-text search with optional filters) and includes data availability and license. However, it does not explicitly state when not to use it or compare it to sibling tools like search_stadtratsbeschluesse, which might have similar functionality.
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:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/malkreide/zurich-opendata-mcp'

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