Loading ToolBench
MCP server for TERMDAT — the terminology database of the Swiss Federal Administration
termdat-mcp demonstrates solid definition quality with comprehensive parameter schemas, detailed descriptions, and clear tool naming. All 7 tools follow verb_noun conventions (search_terms, get_entries, check_terms, translate_terms, list_classifications, list_collections, server_status). Descriptions are substantive (200-800 chars), explaining WHAT, WHEN, and caveats. Input schemas are complete with types, descriptions, and constraints (minLength, maxLength, minimum, maximum, enums via defaults). However, output schemas are not explicitly documented in the visible code, the response structure must be inferred from model definitions. Error handling guidance is minimal; tools lack recovery hints for common failure modes. Tool composition is excellent: each tool has a single responsibility, and search_terms output (entry_id) chains to get_entries input. Parameter naming is precise (search_term, in_language, out_language, classification_ids). Defaults are safe (detail=true, max_results=25). The server correctly omits Prompts and Resources, using only Tools, appropriate for a query-only API.
Check the official status of terms in TERMDAT. Use this to validate whether a term or abbreviation is officially registered in TERMDAT, and if so, retrieve its status, language, and any associated metadata.
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.
List all subject classifications in TERMDAT. Use this to discover the available subject classifications (Sachgebiete) that can be used to filter searches. Returns the complete taxonomy with IDs and multilingual names.
List all collections in TERMDAT. Use this to discover the available collections (Sammlungen) that can be used to filter searches. Returns the complete list with IDs and multilingual names.
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. **Leave `detail` at True unless you want a bare hit list.** With `detail=False` the API omits `languageDetails`, and every entry comes back with an empty `variants` — id, url, status and classification, but not a single designation. That is a hit you cannot read a term from, from a tool whose purpose is terms. Use it to count or to filter by classification, never to answer «what is this called». `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. Coverage caveat: the public API serves a subset of what termdat.bk.admin.ch shows, and the Federal Chancellery confirmed on 2026-08-21 that this is deliberate — the selection follows the needs of the federal administration's translators, and no fuller coverage is planned. Entries the website lists can be missing from the API entirely: not hidden by a filter, simply not served, so no query reaches them. So «not found here» means «not in the API», never «not in TERMDAT»: say which one you mean, and point at www.termdat.ch for the difference.
Output schemas not documented in visible code. Response structure must be inferred from model imports (SearchResult, TermEntry, etc.), not from explicit tool output declarations. LLMs cannot plan downstream operations without knowing what fields to expect.
Error handling lacks recovery guidance. Tools do not document what errors are retryable, what the LLM should do on 404 (term not found), or how to disambiguate between 'term absent from API' vs 'term absent from TERMDAT'. The search_terms description warns about this distinction but tools do not return actionable error messages.
check_terms and translate_terms accept arrays of terms (minLength=1, maxLength=25) but do not document per-item success/failure. If 1 of 25 terms fails, does the tool return partial results or a blanket error? This forces agents to retry all 25 or guess.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 71 | <=2025-11-25 | v2 |
Check the operational status of the TERMDAT API. Use this to verify that the TERMDAT API is reachable and operational before attempting searches or other operations.
Translate terms between official languages in TERMDAT. Use this to find the official designation of a term in another national language (German, French, Italian, or English). Returns all registered variants and their status in the target language.
search_terms max_results defaults to 25 and caps at 100, but no pagination mechanism (cursor, offset, next_page) is visible. Large result sets may be truncated silently. Pagination guidance should be explicit in the description.
server_status description is generic ('Check the operational status of the TERMDAT API') and does not explain what the response contains or when to call it. Is it a health check? Does it return latency, uptime, or just a boolean? Vague descriptions reduce LLM confidence in tool selection.