i14y-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| HOST | No | Bind address for HTTP transports | 127.0.0.1 |
| PORT | No | Port for HTTP transports | 8000 |
| I14Y_MCP_TRANSPORT | No | Transport protocol: stdio, sse, or streamable-http | stdio |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_catalogA | Search Switzerland's national metadata catalogue for data resources. The primary entry point: use this to find out who publishes data on a topic before looking for a specific dataset. Returns titles, publishers, themes and portal permalinks. Known limitation (verified live 2026-07-21): the upstream search index
covers Datasets only. Filtering by Args: query: Free-text search term, e.g. "Sonderpaedagogik" or "Bildung". An empty string returns the full index (over 1000 records) and is not recommended. language: Language for titles and descriptions. types: Restrict to resource types. Effectively only "Dataset" works. themes: Filter by theme identifiers. publishers: Filter by publisher identifiers. limit: Maximum records to return (1-200). Upstream ignores paging, so capping happens in this server. |
| list_datasetsA | List registered datasets, optionally filtered by publisher. Unlike Args:
publisher_identifier: Publisher identifier from |
| get_datasetA | Retrieve the full, aggregated metadata record for one dataset. This is the aggregated detail tool: a single call returns the contact
point, temporal and spatial coverage, documentation links and every
distribution with its licence — so Args:
dataset_id: UUID from |
| get_dataset_distributionsA | Get the downloadable files and access URLs for a dataset. This is the «where do I actually get the data» tool. Each distribution
carries its own format, licence and download URL — licences differ between
distributions of the same dataset, so always read the Args:
dataset_id: UUID from |
| list_data_servicesA | List machine interfaces (APIs) registered by Swiss public bodies. The strategic payload of this server: the national register of official APIs, with endpoint URLs and OpenAPI specification links where the publisher supplied them. Use this to discover whether an interface already exists before building a scraper. Args:
publisher_identifier: Publisher identifier from |
| get_data_serviceA | Retrieve the full record for one registered API, including endpoints. Args:
data_service_id: UUID from |
| list_public_servicesA | List registered public services (administrative offerings for citizens). Args:
publisher_identifier: Publisher identifier from |
| list_conceptsA | List harmonised concepts and code lists of the Swiss administration. Concepts are the semantic backbone of interoperability: shared definitions
and code lists that different bodies agree to use. Note that these are not
reachable through Args:
publisher_identifier: Publisher identifier from |
| get_conceptA | Retrieve one concept definition, including its value type and version. Args:
concept_id: UUID from |
| search_codelist_entriesA | List the individual codes of a code-list concept. Use this to resolve official code values — for example the canonical list
of a classification used across several federal datasets. Only concepts
with Args:
concept_id: UUID of a code-list concept from |
| list_publishersA | List the public bodies that publish into I14Y. Returns publisher identifiers needed by the other tools, plus the Swiss UID
where available — the UID is the join key to Args: identifier: Filter by exact publisher identifier. uid: Filter by Swiss UID, e.g. "CHE-123.456.789". language: Language for names. page: 1-based page number. page_size: Records per page (1-100). |
| list_catalogsA | List the catalogues that feed into I14Y. Each catalogue represents one contributing organisation's data collection. Args: language: Language for titles. page: 1-based page number. page_size: Records per page (1-100). |
| api_statusA | Check whether the I14Y API is reachable and which endpoints respond. Always returns an evaluable status rather than an empty result, so an agent can distinguish «no data matched» from «the source is down». |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 13 tools
Each tool targets a distinct resource or action: listing vs. fetching individual entities, plus search, status, and code-list lookup. Even the overlapping get_dataset and get_dataset_distributions are clearly differentiated by the description noting get_dataset returns distributions alongside the full record, making get_dataset_distributions a focused convenience tool. No two tools appear to do the same thing.
Tool names follow a consistent verb_noun pattern: list_* for collections, get_* for single entities, search_* for search operations, and api_status for health. The pattern is uniform across all 13 tools with no mixed conventions or vague verbs.
13 tools is well within the ideal 3-15 range for a domain-specific server. Each tool covers a distinct aspect of the I14Y metadata catalog (datasets, data services, public services, concepts, publishers, catalogs, status), and none feel redundant or superfluous.
The tool surface covers the core read-only workflows for a catalog: listing and retrieving datasets, data services, concepts, and code-list entries, plus search, publishers, catalogs, and status. Minor gaps exist—there is no get_public_service or get_catalog, so those entities can only be listed, not fetched individually. This is a minor gap that agents can work around, but it does not break the primary use cases.