Skip to main content
Glama
Gastaan

Swiss Grounding MCP

by Gastaan

Search official Swiss information

search_official_info
Read-onlyIdempotent

Find official Swiss procedures, rules, deadlines, and fees by searching federal, cantonal, and municipal web pages. Restrict results by location and get verbatim excerpts with URLs.

Instructions

Full-text search over official Swiss web pages: ch.ch (all languages), federal offices, the 26 cantons and large cities. Use for procedures, rules, deadlines, fees and "how do I…" questions (permits, moving, taxes, social insurance, driving licences, customs, schools, housing, voting). Give place to restrict results to federal + that canton/municipality. Returns verbatim excerpts with URLs.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
placeNoMunicipality, postcode, address or canton as the user said it, in any language (e.g. 'Lugano', '8003', 'Genf', 'Bahnhofstrasse 1, Zürich').
queryYesKey words of the question, ideally in the language of the source (e.g. 'permis de conduire étranger échanger').
languageNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataNo
statusYes
summaryYes
guidanceNo
citationsNo
missing_contextNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover readOnly/idempotent/destructive safety, and the description adds substantive behavioral context: it scopes place-based filtering ('federal + that canton/municipality') and reveals the output shape ('Returns verbatim excerpts with URLs'). This goes beyond what annotations and schema alone convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact, front-loaded with the core purpose, and each sentence adds useful detail (scope, use cases, place behavior, output format). 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?

With an output schema present and rich annotations, the description covers the main operational points: scope, use cases, place filtering, and output format. It omits details like pagination and rate limits, but for a read-only search tool with output schema, this is near-complete. It could still benefit from an explicit pointer to sibling tools (e.g., swiss_federal_law) for law-specific queries.

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 only 50%, so the description should help clarify parameters. It adds meaning for `place` by explaining its filtering effect. It does not mention `limit` or `language` behavior, and the schema already documents `query`, `place`, and `language`. The description's extra value is moderate.

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 ('Full-text search') and a precise resource ('official Swiss web pages: ch.ch, federal offices, the 26 cantons and large cities'), making the tool's purpose immediately clear. It does not explicitly name sibling tools to distinguish from, so it stops 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Use for procedures, rules, deadlines, fees and "how do I…" questions' and lists concrete example topics. This gives clear context for when the tool is appropriate, though it does not state when not to use it or name alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.