What can you do with this server?

This server provides read-only access to TERMDAT, the official terminology database of the Swiss Federal Administration, enabling AI agents to look up, translate, and validate official administrative designations in German, French, Italian, and English. * Search terms: Query using Lucene syntax with filters for language, field (Terminus, Name, Abbreviation), collection, and classification. * Translate terms: Get official equivalents in another national language, including preferred and variant designations. * Check terms: Validate up to 25 terms at once, returning status as validated, found unvalidated, or not found. * Get entries: Retrieve full details for up to 100 entries by numeric ID. * List collections: Browse ~140 terminology collections for filtering. * List classifications: Browse 23 subject classifications (e.g., BILD for education). * Check API status: Verify TERMDAT API availability. This covers administrative nomenclature only (authorities, official titles, abbreviations), not general vocabulary. All tools are read-only and require no authentication. Results include validation status and licence information.

How do I use termdat-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@termdat-mcp What is the French term for 'Bundesamt für Gesundheit'?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

termdat-mcp

by malkreide

Overview Schema Related Servers Score Discussions

Python

Remote

🇨🇭 Part of the Swiss Public Data MCP Portfolio — open-source MCP servers connecting AI agents to Swiss public and open data. This is a private project. It is independent of any employer or institutional affiliation.

🏷️ termdat-mcp

Version License: MIT Python 3.10+ MCP Auth: none Portfolio

Official, validated Swiss administrative designations across DE / FR / IT / EN — with source references and validation status.

🇩🇪 Deutsche Version

Overview

MCP server for TERMDAT, the terminology database of the Swiss Federal Administration, maintained by the Federal Chancellery. It gives an AI agent the officially validated designations of Swiss authorities, departments and legal acts across DE / FR / IT / EN — with source references and validation status.

Discovered through i14y-mcp, which catalogues TERMDAT as data service ff0c37eb-2f7c-4ff6-996e-d22b77bf52fc.

What this is — and what it is not. TERMDAT is not a subject dictionary. It is a certified name-plate archive: it will not tell you what «Sonderpädagogik» means, but it will tell you the official name of the authority responsible for it, and what that authority is called in French.

Measured coverage (live, 2026-07-19, German search over the Terminus field):

Search term	Hits
Departement	20
Bildung	13
Verordnung	8
Schule	5
Behörde	4
Sonderpädagogik	3
Volksschule · Lehrperson · Schulleitung · Unterricht · Kindergarten	0

The thirteen «Bildung» hits are organisational names — Bildungsdirektion, Erziehungsdepartement, Departement für Volkswirtschaft und Bildung — not pedagogical concepts. Plan accordingly: this server is strong for authority naming, official titles and abbreviations, and largely silent on domain vocabulary.

Related MCP server: swiss-ip-mcp

Features

Seven read-only tools over the official TERMDAT public v2 API.
Official designations across DE / FR / IT / EN, with source reference and validation status on every response.
Communication QA: check up to 25 terms in one call against validated designations.
Vocabulary cache (24 h TTL) for the 140 collections and 23 classifications, with stale-serve fallback.
Retry with exponential backoff (2/4/8 s); explicit MaxEntryCount to avoid silent truncation.
Dual transport: stdio (local) and SSE (cloud).
No authentication required — public, unauthenticated API (No-Auth-First).

🎯 Anchor demo query

«What are the official French and Italian names of the education directorates of the German-speaking cantons?»

Resolved with list_classifications → search_terms → translate_term.

Demo

Demo: Claude using search_terms and translate_term

Prerequisites

Python 3.10+
uv / uvx (recommended) or pip
Network access to api.termdat.bk.admin.ch — no API key needed

Installation

uvx termdat-mcp

Claude Desktop (claude_desktop_config.json):

{
  "mcpServers": {
    "termdat": {
      "command": "uvx",
      "args": ["termdat-mcp"]
    }
  }
}

Quickstart

# Run locally over stdio (default transport)
uvx termdat-mcp

# From a checkout, without installing
PYTHONPATH=src python -m termdat_mcp

Configuration

All configuration is via environment variables. Defaults are safe for local use.

Variable	Default	Purpose
`TERMDAT_MCP_TRANSPORT`	`stdio`	Transport: `stdio` (local) or `sse` / `streamable-http` / `http` (cloud)
`HOST`	`127.0.0.1`	Bind host (SSE transport only). Loopback by default; set `HOST=0.0.0.0` only inside a container
`PORT`	`8000`	Bind port (SSE transport only)
`TERMDAT_MCP_CORS_ORIGINS`	`[]`	SSE only: explicit allowed browser origins (default-deny; never a wildcard in production)
`TERMDAT_MCP_LOG_LEVEL`	`INFO`	structlog level (JSON to stderr)
`TERMDAT_MCP_VOCAB_TTL`	`86400`	Vocabulary cache TTL in seconds

Configuration is loaded once into a typed Settings object (pydantic-settings).

Cloud (Render / Railway):

TERMDAT_MCP_TRANSPORT=sse PORT=8000 termdat-mcp   # exposes /sse

Available Tools

Tool	Purpose
`search_terms`	Search TERMDAT with field flags, collection and classification filters
`translate_term`	Official equivalent of an administrative term in another national language
`check_terms`	Communication QA: check up to 25 terms against validated designations
`get_entries`	Fetch known entries by numeric ID
`list_collections`	The ~140 terminology collections (filter values)
`list_classifications`	The 23 subject classifications, e.g. `BILD` = education
`api_status`	Availability; never returns silently empty

All tools are annotated readOnlyHint: true, destructiveHint: false.

MCP primitives. This server uses only the Tools primitive. TERMDAT answers are live queries with no stable resource hierarchy to expose as Resources, and there are no server-authored Prompts. The seven tools are small and closely related, so they live in a single server.py rather than a tools/ package.

Architecture

┌─────────────────┐   stdio / SSE    ┌──────────────────────────┐
│  MCP host       │ ───────────────► │  termdat-mcp             │
│  (Claude, IDE)  │ ◄─────────────── │                          │
└─────────────────┘                  │  vocabulary cache (24 h) │
                                     │  140 collections         │
                                     │   23 classifications     │
                                     └────────────┬─────────────┘
                                                  │ httpx + retry (2/4/8 s)
                                                  ▼
                              https://api.termdat.bk.admin.ch/v2
                              ├── /Search          (SearchTerm + InLanguageCode)
                              ├── /Entry           (EntryIds)
                              ├── /Collection      (140 values)
                              └── /Classification  ( 23 values, incl. BILD)

Architecture decision

This server uses Architecture A (live API only), with caching limited to the two controlled vocabularies.

Rationale (verified live on 2026-07-19):

The API publishes a complete OpenAPI 3.0.4 specification at /swagger/v2/swagger.json and declares no security schemes — unauthenticated access, No-Auth-First satisfied.
Server-side search works properly, including 11 field flags and filters by collection and classification. There is no reason to mirror the database locally, and no bulk dump is offered.
/Collection (140 entries) and /Classification (23 entries) change rarely and are needed to make filter arguments legible to an agent, so they are cached with a 24-hour TTL and a stale-serve fallback.

Consequences:

Every search is a live call; provenance is live_api except for vocabulary lookups.
Validation errors arrive as clean RFC 9110 payloads and are surfaced rather than swallowed.

Project Structure

termdat-mcp/
├── src/termdat_mcp/
│   ├── __init__.py
│   ├── __main__.py       # entry point; dual transport (stdio / SSE)
│   ├── client.py         # httpx client, retry, vocabulary cache
│   ├── models.py         # Pydantic models
│   └── server.py         # MCP tool definitions
├── tests/
│   ├── test_client.py    # offline, respx-mocked
│   └── test_live.py       # hits the real TERMDAT API
├── README.md
├── README.de.md
├── CHANGELOG.md
├── LICENSE
└── pyproject.toml

Safety & Limits

Read-only. Every tool is annotated readOnlyHint: true, destructiveHint: false; the server never writes to TERMDAT.
No credentials handled. The API is unauthenticated; the server stores and forwards no secrets.
No silent empties. api_status and error paths surface failures instead of returning an empty result that looks complete.
Truncation is explicit. MaxEntryCount is always sent and truncated is reported (see Known Limitations).
Terms of use are stated, not guessed. Every response repeats them in source: reuse and republication require the source www.termdat.ch to be named, and the Federal Chancellery's Terminology Section to be informed of purpose and manner beforehand (statement of 2026-08-21).
Egress allow-list. Requests can only reach api.termdat.bk.admin.ch (HTTPS), enforced before every call by a frozen ALLOWED_HOSTS set — no user input can redirect egress. See docs/network-egress.md.
Loopback by default. SSE binds to 127.0.0.1; 0.0.0.0 is an explicit container opt-in that warns on stderr. SSE also sets default-deny CORS, exposing only Mcp-Session-Id.
Errors are masked. Upstream/internal error detail is logged to stderr (structlog JSON) and never returned to the model.
Accepted risks (ADRs): DNS pinning (ADR 0001) and stateful load balancing (ADR 0002) are deliberately deferred — low risk for a single-instance, single-host, no-auth server.
Container. A hardened, non-root Dockerfile is provided for SSE deployments.

Known Limitations

Administrative scope only. See the coverage table above. check_terms returns not_found, never «incorrect», precisely because absence from TERMDAT is not evidence of error.
MaxEntryCount has a silent default of ~25. Omitting it looks like a complete result set. This server always sends the parameter explicitly and reports truncated.
CollectionIds / ClassificationIds have a silent default of VARIA. An ID-less /v2/Search covers one of 23 subject areas — the residual one — and reports the truncated result as a normal empty answer. This server sends the full classification set unless you narrow it explicitly. See issue #11.
SearchTerm is Lucene, and matching is on whole words. «Quellensteuer» does not match «Quellensteuerverordnung»; «Quellensteuer*» does. *, ? and ~ are available — on an empty result, retry with a wildcard before concluding the term is absent.
Field.* flags default to true where unsent. Terminus, Name, Abbreviation and Phraseology are on unless explicitly disabled, so a partial flag set can only widen a search. This server sends all eleven flags explicitly, which is what makes fields able to narrow.
Multilingual variants are opt-in. Without OutLanguageCode, entries return German designations only. translate_term sets it for you.
The public API exposes less than the website — deliberately. Not a scope setting, and not a defect: asked directly, the Federal Chancellery's Terminology Section confirmed on 2026-08-21 that the API covers only part of the TERMDAT records, that the selection follows the needs of the federal administration's translators, and that no fuller coverage is planned. Measured beforehand: for «Quellensteuer» the website lists 12 distinct entries and the API returns 7 at maximum recall (every language, all 11 fields, infix wildcard, all classifications and collections); the overlap is one entry, 447912. Fetching the missing IDs directly via /v2/Entry returns HTTP 200 with an empty body — they are not served at all, so no query can reach them. Consequence: absence from this server means absence from the API, not from TERMDAT, and there is nothing to work around. Verified 2026-07-30 with the entry IDs supplied by @dfch in issue #11.
The I14Y catalogue record carries license: null — the terms are elsewhere. Reuse and republication of TERMDAT content are permitted only with the source www.termdat.ch named, and the Terminology Section of the Federal Chancellery informed of purpose and manner beforehand (terminologie@bk.admin.ch; statement of 2026-08-21). Running this server is covered by the enquiry that produced that statement; your own downstream republication needs its own notice. Every response repeats the terms in source.
Entry-level language coverage varies. Not every entry exists in all four languages; translate_term omits entries without a target-language variant rather than inventing one.

Live probe findings (2026-07-19)

Endpoint	HTTP	Status	Note
`/swagger/v2/swagger.json`	200	✅	OpenAPI 3.0.4, 132 KB, `securitySchemes: []`
`/v2/Search`	200	✅	requires `SearchTerm`, `InLanguageCode`, `ReturnType`
`/v2/Entry`	200	✅	requires `EntryIds`, `InLanguageCode`
`/v2/Collection`	200	✅	140 values
`/v2/Classification`	200	✅	23 values, incl. `BILD` (education)
`/v2/` (root)	404	❌	no index; the I14Y record points here
`InLanguageCode=deu` / `de-CH`	400	❌	only two-letter ISO codes, case-insensitive

Probe note: a correction worth recording. An earlier probe concluded that OutLanguageCode filters the result set, because adding it appeared to drop all hits. It does not. Two variables had been changed at once — the parameter and the search term — and the term itself («Volksschule») genuinely has zero hits. Verified afterwards across four broad terms: result counts are identical with and without OutLanguageCode; the parameter is purely additive. A regression test (test_out_language_is_additive_not_filtering) now guards this.

Rule of thumb: change one variable per probe call, or the API will confess to a crime it did not commit.

Live probe findings (2026-07-27) — search scope

Reported in issue #11: «Quellensteuer» returned nothing while the TERMDAT website returned twelve hits. Three independent causes, in descending order of effect. Entry counts, InLanguageCode=DE:

Query	ID-less (`=VARIA`)	all 23 classifications	+ free-text fields	+ `*` wildcard
`Quellensteuer`	0	1	3	6
`Pensionskasse`	1	4	22	27

The first column is what this server sent before the fix. The VARIA default is the dominant term: it hid FINANZWESEN, RECHT and twenty other subject areas behind an answer that looked like a confident zero.

Probe note. The failure mode worth recording is not the count — it is that an under-scoped search is indistinguishable from a genuine absence. In the reported session the model read the empty result together with this server's own «absence usually means out of scope» caveat and invented a plausible explanation for a term that was in the database all along. A tool that narrows silently will be believed silently. Hence hint on empty results, and a caveat that now tells the model to retry rather than to conclude.

Project Phase

This server is in Phase 1 (read-only). All tools are annotated readOnlyHint: true / destructiveHint: false and only ever query the public TERMDAT v2 API — there are no write, send, or filesystem capabilities.

Phase	Scope	Status
1 — Read-only	Search, translate and check administrative designations	✅ current
2 — Write-capable	(none planned)	—
3 — Multi-agent	(none planned)	—

A transition to a later phase would require a re-audit and human-in-the-loop controls before any write-capable tool is added.

MCP Protocol Version

This server speaks two protocol eras over the same endpoint. The client's first request on a connection decides which one applies; a later claim from the other era is refused.

Era	Revision	Who reaches it
`initialize` handshake	`2024-11-05` … `2025-11-25`	What today's clients speak. The server answers with the revision asked for, or with the `2025-11-25` ceiling when the request asks for something newer.
Per-request envelope	`2026-07-28`	A request carrying the `2026-07-28` `_meta` envelope opens a modern connection.

Both revisions are pinned in tests/test_protocol_version.py and asserted against the installed SDK, so a Dependabot bump of mcp cannot move either one silently. This server builds no ASGI app to send an initialize through, so the gate asserts the SDK constants rather than a measured response — the weaker form, named rather than left unsaid.

Note that the SDK's LATEST_PROTOCOL_VERSION is an alias for the modern era, not for the handshake era — pinning against it alone would leave the era that current clients actually negotiate free to drift.

Update policy. When the gate fails, do not edit the constant blindly: read the spec changelog between the two revisions, verify the server still behaves, then move the constant, this section, README.de.md and CHANGELOG.md together.

Testing

PYTHONPATH=src pytest tests/ -m "not live"   # offline, respx-mocked
PYTHONPATH=src pytest tests/ -m live         # hits the real API
python scripts/check_ruff_pin.py
ruff check src/ tests/ scripts/
ruff format --check src/ tests/ scripts/
python scripts/check_version_sync.py

Changelog

See CHANGELOG.md.

Contributing

Issues and pull requests are welcome. Please keep tools read-only, run ruff check and the offline test suite before submitting, and add a CHANGELOG.md entry under [Unreleased] for user-facing changes.

Maintainers: see PUBLISHING.md for the step-by-step PyPI release process (Trusted Publishing via GitHub Release).

Security

See SECURITY.md for the security posture, hardening controls, and how to report a vulnerability.

License

MIT for this server — see LICENSE. TERMDAT content remains subject to the Federal Chancellery's terms: name the source www.termdat.ch and inform the Terminology Section beforehand of purpose and manner of any reuse or republication (statement of 2026-08-21).

Author

Hayal Oezkan · github.com/malkreide

Data: TERMDAT, Swiss Federal Chancellery (BK).
Catalogue entry: I14Y data service ff0c37eb…
Discovery server: i14y-mcp
Portfolio index: swiss-public-data-mcp

Available Tools

7 tools

api_statusA

Read-only

Availability of the TERMDAT API. Never returns silently empty.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`source`	No
`message`	Yes
`reachable`	Yes
`provenance`	Yes
`collections`	No
`retrieved_at`	Yes	ISO-8601 UTC timestamp
`classifications`	No

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already mark readOnlyHint=true and destructiveHint=false. The description adds that it never returns silently empty, providing a behavioral guarantee 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 sentences, front-loaded with core purpose. Every word adds value; no redundancy.

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 simplicity (zero parameters, output schema exists), the description fully captures what the tool does and a key behavioral trait. No gaps.

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?

No parameters exist; schema coverage is 100%. Baseline is 4 since the description cannot add value on 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 'Availability of the TERMDAT API' which specifies the resource and action, and distinguishes from sibling tools like search_terms and translate_term. The additional 'Never returns silently empty' clarifies expected behavior.

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 guidance on when to use versus alternatives; the purpose implies using it to check API availability, but no when-not-to or sibling comparisons provided.

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

check_termsA

Read-only

Check a list of terms against validated TERMDAT designations.

Intended for communication QA: verify that authority names, department titles and abbreviations in a draft match the officially validated form. Each term is reported as validated, found_unvalidated or not_found. Up to 25 terms per call; the lookups run concurrently.

ParametersJSON Schema

Name	Required	Description	Default
`terms`	Yes
`language`	No		DE

Output Schema

ParametersJSON Schema

Name	Required	Description
`caveat`	No
`source`	No
`checked`	Yes
`results`	Yes
`language`	Yes
`not_found`	Yes
`validated`	Yes
`provenance`	Yes
`retrieved_at`	Yes	ISO-8601 UTC timestamp

TDQS

A4.1/5.0

Behavior4/5

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

Reports that lookups run concurrently and indicates output categories (validated, found_unvalidated, not_found). Annotations already declare readOnlyHint and no destructive effects, so description adds value without 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?

Two concise sentences front-load the main purpose and usage. Every sentence adds value without 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?

Covers purpose, constraints (max 25 terms), behavior (concurrent lookups), and output categories. Output schema handles return values, so this is sufficient.

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 terms parameter is implicitly described (list of terms), but the language parameter is not explained. With 0% schema description coverage, the description should provide more detail on parameter meaning and constraints.

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?

Clearly states the tool checks a list of terms against TERMDAT designations, specifying it's for communication QA. Distinct from siblings like 'search_terms' or 'translate_term'.

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?

Provides intended use case (communication QA) and a limit of 25 terms per call. Does not explicitly exclude alternatives, but context is clear.

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

get_entriesA

Read-only

Fetch known TERMDAT entries by their numeric IDs, with full language variants.

Use this to re-retrieve an entry you already found via search_terms (its entry_id), e.g. to pull all four national-language designations at once.

ParametersJSON Schema

Name	Required	Default
`entry_ids`	Yes
`in_language`	No	DE
`out_language`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`hint`	No	Set when the search returned nothing; suggests how to widen it
`source`	No
`entries`	Yes
`returned`	Yes
`truncated`	Yes	True if the result hit max_results — narrow the query or raise the limit
`provenance`	Yes
`in_language`	Yes
`search_term`	Yes
`out_language`	No
`retrieved_at`	Yes	ISO-8601 UTC timestamp

TDQS

A4.1/5.0

Behavior3/5

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

Annotations already declare readOnlyHint true, openWorldHint true, and destructiveHint false, so the safety profile is covered. The description adds that it returns 'full language variants,' which is modest extra 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 concise: two sentences that front-load the purpose and then provide usage guidance. No extraneous 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?

Given the tool has an output schema (providing return structure) and annotations cover behavioral traits, the description gives the main use case and mentions language variants. It lacks explanation of the language parameters but is otherwise complete for a read-only retrieval 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%, but the description only explains entry_ids as 'numeric IDs' and implicitly references language variants. It does not clarify the in_language or out_language parameters, leaving a significant semantic gap.

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 fetches known TERMDAT entries by numeric IDs with full language variants, using specific verb and resource. It distinguishes itself from sibling search_terms by specifying it is for re-retrieving known entries.

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 when to use this tool ('re-retrieve an entry you already found via search_terms') and provides a concrete example ('pull all four national-language designations at once'), giving clear usage context.

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

list_classificationsC

Read-only

List the 23 subject classifications (e.g. BILD = education), for classification_ids.

ParametersJSON Schema

Name	Required	Description	Default
`language`	No		DE

Output Schema

ParametersJSON Schema

Name	Required	Description
`kind`	Yes
`count`	Yes
`source`	No
`values`	Yes
`language`	Yes
`provenance`	Yes
`retrieved_at`	Yes	ISO-8601 UTC timestamp

TDQS

C2.7/5.0

Behavior3/5

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

Annotations already declare readOnlyHint and openWorldHint. The description adds that there are exactly 23 classifications and provides an example, but lacks details on language effects or other behavioral traits.

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

Conciseness4/5

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

Single sentence with no wasted words, though it could be more structured by explicitly linking to the parameter.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema, return values are partially covered, but the description omits parameter guidance and usage context, making it incomplete for an agent.

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?

Schema description coverage is 0%, yet the description fails to mention the 'language' parameter or its role, leaving the agent without necessary context.

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 lists 23 subject classifications and gives an example, but does not distinguish it from sibling tools like list_collections.

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; no context on prerequisites or exclusions.

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

list_collectionsA

Read-only

List the ~140 TERMDAT collections, for use as collection_ids filters.

ParametersJSON Schema

Name	Required	Description	Default
`language`	No		DE

Output Schema

ParametersJSON Schema

Name	Required	Description
`kind`	Yes
`count`	Yes
`source`	No
`values`	Yes
`language`	Yes
`provenance`	Yes
`retrieved_at`	Yes	ISO-8601 UTC timestamp

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false. Description adds the approximate count (~140) and usage hint, but no additional behavioral traits beyond what annotations provide. 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?

Single sentence, front-loaded with action and key detail (count and purpose). No wasted words; efficient and clear.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given output schema exists (presumably handling return values) and annotations cover safety, the description is minimally adequate. However, missing parameter explanation and any notes about filtering or edge cases reduce completeness.

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 has one optional parameter 'language' with default 'DE', but description does not explain its purpose or effect. Schema description coverage is 0%, and description offers no clarification, leaving the agent to guess.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool lists approximately 140 TERMDAT collections for use as filters. Distinguishes from siblings like search_terms or get_entries by specifying a precise purpose.

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?

Explicitly says 'for use as collection_ids filters', indicating when to use. However, does not explicitly state when not to use or provide alternative tools. Sibling list is present but no direct comparison.

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

search_termsA

Read-only

Search TERMDAT for official designations of the Swiss Federal Administration.

Use this to look up the officially validated German/French/Italian/English name of an authority, department or legal act — for example to check how a body is named in another national language before citing it.

search_term is Lucene query syntax: * and ? wildcards and the ~ fuzzy operator work. Matching is on whole words, so a compound is not found by its parts — «Quellensteuer» does not match «Quellensteuerverordnung», but «Quellensteuer*» does. Reach for a wildcard before concluding a term is absent.

out_language adds a target language to every entry's variants — it is purely additive and never filters the result set. fields is a comma-separated subset of: Terminus, Name, Abbreviation, Phraseology, Definition, Note, Context, Source, Metadata, Country, Comment; empty means Terminus, Name, Abbreviation, Phraseology, Definition, Note, Source. By default the search spans all 23 subject classifications; pass classification_ids or collection_ids to narrow it (see list_classifications / list_collections).

Scope caveat: TERMDAT holds administrative nomenclature (authority names, titles of legal acts, abbreviations), not domain vocabulary — so a term may genuinely be absent. Establish that with a wildcard retry, not from a single empty result, and never fill the gap with a guessed designation.

ParametersJSON Schema

Name	Required	Default
`detail`	No
`fields`	No
`in_language`	No	DE
`max_results`	No
`search_term`	Yes
`out_language`	No
`collection_ids`	No
`classification_ids`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`hint`	No	Set when the search returned nothing; suggests how to widen it
`source`	No
`entries`	Yes
`returned`	Yes
`truncated`	Yes	True if the result hit max_results — narrow the query or raise the limit
`provenance`	Yes
`in_language`	Yes
`search_term`	Yes
`out_language`	No
`retrieved_at`	Yes	ISO-8601 UTC timestamp

TDQS

A4.9/5.0

Behavior5/5

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

Beyond annotations (readOnlyHint, openWorldHint, destructiveHint), the description explains Lucene query syntax, whole-word matching, additive nature of out_language, default fields, and the concept of absent terms. It advises wildcards to avoid false negatives.

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-structured: purpose sentence, usage guidelines, parameter details, then scope caveat. Every sentence is informative and non-redundant, fitting all necessary information without verbosity.

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's complexity (8 parameters, search semantics) and the presence of an output schema, the description covers essential aspects: purpose, usage, parameter behavior, and limitations. It provides sufficient context for correct invocation.

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?

With 0% schema description coverage, the description explains search_term (Lucene, wildcards), out_language (additive), fields (comma-separated list), and classification/collection_ids (narrowing). However, detail and in_language parameters are not explained beyond defaults.

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 TERMDAT for official designations of Swiss Federal Administration. It specifies the resource and verb, and distinguishes from siblings by explaining the administrative scope and referencing list_classifications/list_collections for narrowing.

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 provides explicit when-to-use guidance (e.g., look up official names before citing), when-not-to (not for domain vocabulary), and alternatives (retry with wildcard, use list_* for classifications). It also cautions against filling gaps with guessed designations.

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

translate_termA

Read-only

Get the official equivalent of an administrative term in another national language.

Returns the preferred designation (sequence 1) plus accepted variants, per matching entry. Use this for authority names, department titles and titles of legal acts.

Matches only against designation fields, so a term merely mentioned in a definition is never reported as an equivalent. term accepts Lucene wildcards; on an empty result retry with term* before concluding there is no equivalent.

ParametersJSON Schema

Name	Required	Default
`term`	Yes
`max_results`	No
`to_language`	No	FR
`from_language`	No	DE

Output Schema

ParametersJSON Schema

Name	Required	Description
`hits`	Yes
`term`	Yes
`source`	No
`provenance`	Yes
`to_language`	Yes
`retrieved_at`	Yes	ISO-8601 UTC timestamp
`from_language`	Yes
`total_entries`	Yes

TDQS

A4.5/5.0

Behavior5/5

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

Beyond annotations (readOnly, openWorld, non-destructive), the description discloses critical behavioral details: matching only designation fields (not definitions), Lucene wildcard support, and the retry strategy. This adds significant value for correct invocation.

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 at 5 sentences, front-loaded with the main purpose, and efficiently conveys all necessary information without redundancy.

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's moderate complexity, annotations, and presence of output schema, the description covers behavioral details, parameter hints, and usage context comprehensively. It leaves no obvious gaps for correct agent invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description must compensate. It explains the 'term' parameter accepts wildcards and suggests retry with 'term*'. However, 'max_results', 'to_language', and 'from_language' are not described beyond defaults in schema. The description adds some value but leaves key parameters underspecified.

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: 'Get the official equivalent of an administrative term in another national language.' It specifies the verb (Get), resource (equivalent), and scope (administrative term). It also distinguishes from siblings by focusing on translation of specific administrative terms.

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 clear usage context: 'Use this for authority names, department titles and titles of legal acts.' It also advises on retry strategy with Lucene wildcards. However, it does not explicitly contrast with sibling tools like search_terms or get_entries, leaving some ambiguity about when to use alternatives.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

2 tool updatesv0.1.1Jul 30, 2026

Changedget_entries1 field changed

addedOutput schema / properties / hint

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Set when the search returned nothing; suggests how to widen it",
+  "title": "Hint"
+}

Changedsearch_terms2 fields changed

changedInput schema / properties / fields / default
```
Previous value: -"Terminus"New value: +""
```

addedOutput schema / properties / hint

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Set when the search returned nothing; suggests how to widen it",
+  "title": "Hint"
+}

7 tool updatesv0.1.0Jul 26, 2026
- First observedapi_status
- First observedcheck_terms
- First observedget_entries
- First observedlist_classifications
- First observedlist_collections
- First observedsearch_terms
- First observedtranslate_term

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: retrieving entries by ID, searching, translating, checking status, validating terms, and listing collections/classifications. No overlap in functionality.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern in snake_case (e.g., get_entries, search_terms, list_collections). No mixing of conventions.

Tool Count5/5

7 tools is well-scoped for a terminology database server—enough to cover key operations without being overwhelming or too sparse.

Completeness4/5

The tool set covers searching, retrieval, translation, validation, and metadata listing. Missing write operations, but these are likely outside the server's intended read-only scope.

Maintenance

ActivityActive

ResponsivenessResponsive

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Opendata Swiss B
io.github.pipeworx-io
opendata.swiss MCP — Switzerland's federal open-data portal (CKAN catalogue).
Government Data Open Data
362
FirstData
io.github.Vist233
Hosted MCP server for finding authoritative primary data sources and official portals.
Search Open Data Government Data
2144
OpenHelvetia Gateway
swiss.openhelvetia
Swiss federal law (Fedlex) and political data (LINDAS) for agents, every answer with sources
1
failmodes A
io.github.elyngved
MCP server for the Fail Modes taxonomy — a knowledge base of AI system failure modes
AI & Machine Learning Knowledge & Memory Testing & QA Tools
42

Related MCP Servers

swiss-food-safety-mcp
Government Data Open Data Research & Data
malkreide
A
license
A
quality
A
maintenance
MCP server connecting AI models to Swiss Federal Food Safety and Veterinary Office open data, enabling queries about food recalls, animal disease surveillance, food control results, and more.
Updated 4 days ago (2026-09-01 22:39 UTC)
11
MIT
swiss-ip-mcp
Government Data Search
malkreide
A
license
A
quality
A
maintenance
MCP server for querying Swiss intellectual property data (trademarks, patents, supplementary protection certificates) from the Swissreg register via natural language.
Updated 5 days ago (2026-09-01 04:57 UTC)
11
MIT
ch-eli-mcp
Legal & Compliance Government Data
matematicsolutions
A
license
A
quality
A
maintenance
MCP server for Swiss federal legislation metadata via Fedlex, enabling search and retrieval of act details with ELI URIs, SR numbers, and multilingual support.
Updated 13 days ago (2026-08-24 13:55 UTC)
3
Apache 2.0
swiss-apis-mcp
Government Data Open Data Travel & Transportation
clement8426
A
license
B
quality
D
maintenance
MCP server exposing all major Swiss official public APIs as native tools for any MCP-compatible AI agent.
Updated 5 months ago (2026-03-30 12:52 UTC)
34
16
MIT

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/termdat-mcp'

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

🏷️ termdat-mcp

Overview

Features

🎯 Anchor demo query

Demo

Prerequisites

Installation

Quickstart

Configuration

Available Tools

Architecture

Architecture decision

Project Structure

Safety & Limits

Known Limitations

Live probe findings (2026-07-19)

Live probe findings (2026-07-27) — search scope

Project Phase

MCP Protocol Version

Testing

Changelog

Contributing

Security

License

Author

Credits & Related Projects

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API