termdat-mcp

Overview Schema Source Related Servers Discussions Admin

check_terms

Read-only

Check terms against validated TERMDAT designations for Swiss authorities, departments, and abbreviations, returning validated, unvalidated, or not_found status to ensure communication accuracy.

Instructions

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.

Input Schema

TableJSON Schema

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

Output Schema

TableJSON Schema

Name	Required	Description	Default
`caveat`	No		TERMDAT covers federal and cantonal administrative nomenclature — authority names, official titles of legal acts, abbreviations. Domain vocabulary (e.g. pedagogy) is largely absent. And the public API deliberately serves only a subset of TERMDAT, selected for the needs of the federal administration's translators (Federal Chancellery, 2026-08-21), so 'not_found' means 'not in the public API' — never 'not in TERMDAT' and never 'incorrect'. Check www.termdat.ch for the difference.
`source`	No		Data: TERMDAT, terminology database of the Swiss Federal Administration, Swiss Federal Chancellery (BK), via api.termdat.bk.admin.ch. Terms of use (Terminology Section, Federal Chancellery, 2026-08-21): reuse and republication are permitted only if the source www.termdat.ch is named, and the Terminology Section must be informed of the purpose and manner beforehand (terminologie@bk.admin.ch).
`checked`	Yes
`results`	Yes
`language`	Yes
`not_found`	Yes
`validated`	Yes
`provenance`	Yes
`retrieved_at`	Yes	ISO-8601 UTC timestamp

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.2.0Sep 23, 2026

changedOutput schema / properties / caveat / default

Previous value: -"TERMDAT covers federal and cantonal administrative nomenclature — authority names, official titles of legal acts, abbreviations. Domain vocabulary (e.g. pedagogy) is largely absent, so 'not_found' means 'not in TERMDAT', not 'incorrect'."New value: +"TERMDAT covers federal and cantonal administrative nomenclature — authority names, official titles of legal acts, abbreviations. Domain vocabulary (e.g. pedagogy) is largely absent. And the public API deliberately serves only a subset of TERMDAT, selected for the needs of the federal administration's translators (Federal Chancellery, 2026-08-21), so 'not_found' means 'not in the public API' — never 'not in TERMDAT' and never 'incorrect'. Check www.termdat.ch for the difference."

changedOutput schema / properties / source / default

Previous value: -"Data: TERMDAT, terminology database of the Swiss Federal Administration, Swiss Federal Chancellery (BK), via api.termdat.bk.admin.ch. The I14Y catalogue record carries no explicit licence statement — clarify terms with the Federal Chancellery before republishing."New value: +"Data: TERMDAT, terminology database of the Swiss Federal Administration, Swiss Federal Chancellery (BK), via api.termdat.bk.admin.ch. Terms of use (Terminology Section, Federal Chancellery, 2026-08-21): reuse and republication are permitted only if the source www.termdat.ch is named, and the Terminology Section must be informed of the purpose and manner beforehand (terminologie@bk.admin.ch)."

First observedv0.1.0Jul 26, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and destructiveHint, so the safety profile is clear. The description adds useful behavior beyond structured data: each term is reported as one of three statuses, and lookups run concurrently. It does not mention authentication or rate limits, but the read-only annotation lowers the bar.

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?

Three sentences with no fluff: purpose first, then context, then behavioral details and limits. Every sentence adds information an agent needs.

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 simple 2-parameter schema, output schema presence, and read-only annotations, the description is nearly complete. The main missing piece is language parameter semantics, and explicit alternative routing would help, but these are not fatal for a basic check 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?

With 0% schema description coverage, the description must compensate for parameter meaning. It clarifies that 'terms' are a list and repeats the 25-term cap from the schema, but it does not explain the 'language' parameter, its accepted values, or how it affects the check. This is a clear gap.

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 action ('Check a list of terms against validated TERMDAT designations') and clarifies the exact QA use case. It is clearly distinct from siblings like search_terms, but it does not explicitly differentiate itself by naming any sibling tool.

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 strong when-to-use guidance: 'Intended for communication QA' and lists example content (authority names, department titles, abbreviations). It does not mention when not to use it or point to an alternative, so it stops short of full exclusion guidance.

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

Deploy Server