Loading ToolBench
Strong foundation with 31 well-named, read-only tools covering a comprehensive API surface (datasets, concepts, services, catalogs, mappings, agents). All tools have descriptions (avg 180 chars, within baseline 194). Input schemas present with typed parameters and descriptions. However, output schemas are not documented in the source code, responses are described narratively but lack formal JSON Schema definitions. Error handling is minimal; no recovery guidance or actionable error messages visible. Tool descriptions are good but could be more prescriptive about when to use each variant (e.g., get_dataset vs get_dataset_by_identifier). No tool annotations (readOnlyHint, idempotentHint) despite all being read-only.
Check whether a dataset has a structural model defined on I14Y. Use this before calling get_dataset_structure() to avoid errors on datasets with no model. Useful for filtering a list of datasets to only those with documented schemas.
Get detailed metadata for a specific publishing organisation. Returns full agent record including name, description, contact point, homepage, spatial coverage, and sub-organisations.
Export a catalog from the Swiss I14Y platform in DCAT-AP format. Catalogs aggregate datasets, data services, and other resources published by an organisation. The export is DCAT-AP (EU Application Profile for Data Catalogs) compliant.
Get all catalog records (resource entries) from a specific DCAT catalog. Catalog records link a catalog to the datasets and data services it contains, with provenance metadata (when the record was added, modified, etc.).
Get all themes used within a specific DCAT catalog. Returns the controlled vocabulary themes (from the EU Data Theme vocabulary) assigned to resources in this catalog. Useful for understanding the thematic coverage of a catalog and for RDF/DCAT alignment.
Output schemas not documented. Tool descriptions state what is returned narratively (e.g., 'JSON string with paginated results') but no formal JSON Schema definitions are visible in source code. LLMs cannot reliably parse or chain results without explicit output schemas.
No tool annotations despite all 31 tools being read-only. Missing readOnlyHint annotations prevent clients from optimizing caching, retry logic, and safety guarantees. All tools should declare readOnlyHint=true.
Minimal error handling and recovery guidance. No visible error classification (retryable vs user-fixable vs fatal) or actionable error messages. When a dataset is not found or API fails, LLMs receive no guidance on next steps.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 68 | <=2025-11-25 | v2 |
Get paginated codelist entries with full annotations for a concept. Returns richer data than get_concept_codelist() — includes annotations, descriptions, and hierarchical metadata for each entry. Suitable for browsing large codelists page by page.
Get all child entries of a parent code in a hierarchical codelist. For codelists with a parent-child hierarchy (e.g. NUTS regions, Swiss commune/district/canton hierarchy), this returns all direct children of a given parent code.
Get a single codelist entry by its code value. Use this to look up the label and metadata for a specific code, e.g. find what canton code "1" means in HGDE_KT.
Get detailed metadata for a specific data concept.
Get concept(s) by their human-readable identifier (e.g. "HGDE_KT"). Unlike get_concept() which requires a UUID, this tool accepts the short identifier string visible in the I14Y platform and URLs. Returns all versions of the concept with that identifier.
Export all codelist entries for a concept. Use this tool to retrieve the full set of valid values defined by a codelist concept (e.g. all canton codes, all country codes).
Get detailed metadata for a specific data service by its ID.
Get a data service by its human-readable identifier (not UUID).
Get detailed metadata for a specific dataset by its ID.
Get a dataset by its human-readable identifier (not UUID). Use this when you know the dataset's short identifier (e.g. "px-x-0602010000_109") rather than its UUID. More convenient than list_datasets() with a filter.
Get the structural model of a dataset as a schema graph. Returns the dataset schema in schemaGraph format — a JSON representation of the model as a graph of nodes and edges, suitable for programmatic processing and visualisation. Complements get_dataset_structure() which returns RDF/JSON-LD formats. Only works for datasets that have a structure (use check_dataset_has_structure() to verify first).
Export the structural schema of a dataset.
Fetch and return the content of a DCAT distribution file. Use this after get_dataset() to read the actual data behind a distribution. The distribution's downloadUrl.uri (from the get_dataset response) should be passed directly as download_url. Supports text-based formats: JSON, CSV, XML, RDF/Turtle, GeoJSON, etc. Binary formats (PDF, ZIP, Excel, images) are rejected with an error message. Content is truncated to max_kb kilobytes if the file is larger. Typical workflow: 1. dataset = get_dataset(dataset_id) 2. url = dataset["distributions"][0]["downloadUrl"]["uri"] 3. content = get_distribution_content(url)
Get detailed metadata for a specific mapping table by its ID. Returns the full mapping table record including its name, description, version, publisher, source codelist URI, target codelist URI, registration status, validity period, and responsible persons.
Export all mapping relations (value correspondences) for a mapping table. Each relation pairs a value from the source codelist with its equivalent in the target codelist. Use this to retrieve the complete mapping, e.g. all old code → new code pairs.
Get detailed metadata for a specific public service by its ID.
Get a public service by its human-readable identifier (not UUID).
Get public services related to a given public service. Returns other public services that are semantically linked to this one (e.g. prerequisite services, related administrative procedures).
List all publishing organisations (agents) registered on I14Y. Agents are the federal offices, cantonal bodies, and other organisations that publish resources on the I14Y platform. Use this to discover available publisher identifiers for use in other tools' publisher_identifier filter.
List all DCAT catalogs registered on the I14Y platform. A catalog aggregates datasets, data services, and other resources published by an organisation. Use this to discover available catalogs before exporting one with get_catalog().
List data concepts (codelists, data dictionaries) on the Swiss I14Y platform. Concepts are reusable data definitions that ensure semantic interoperability across Swiss government systems. They include codelists (e.g. country codes, canton codes), date formats, numeric ranges, and string patterns.
List data services (APIs) registered on the Swiss I14Y platform. Data services are electronic interfaces (APIs) that provide access to datasets or functionality published by Swiss federal and cantonal bodies.
List datasets from the Swiss I14Y interoperability platform. Supports filtering by publisher, registration status, publication level, access rights, or a specific dataset identifier.
List mapping tables registered on the Swiss I14Y platform. A mapping table defines a correspondence between two codelists (source → target), enabling semantic alignment across different classification systems. For example, mapping Swiss canton codes to NUTS regional codes, or aligning one version of a codelist to another.
List public services registered on the Swiss I14Y platform. Public services are administrative services offered by Swiss federal, cantonal, or communal bodies to citizens, businesses, or other organisations.
Search for entries within a specific codelist by label or code. Use this to find specific codes within a large codelist without fetching all entries. For example, find the code for "Zurich" in the canton codelist, or search for a specific NOGA sector.
Overlapping tool variants (get_X vs get_X_by_identifier) lack clear guidance on when to use each. Descriptions do not explain the trade-off: get_dataset requires UUID; get_dataset_by_identifier accepts human-readable strings. LLMs may choose inefficiently.
get_distribution_content accepts arbitrary URLs without validation. No visible input sanitization against path traversal or SSRF. Downloading from user-supplied URLs without constraints is a security risk.