Skip to main content
Glama

search_terms

Read-only

Look up officially validated German, French, Italian, or English designations of Swiss federal authorities, departments, and legal acts. Use wildcards to catch compound terms before concluding a term is absent.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
detailNo
fieldsNo
in_languageNoDE
max_resultsNo
search_termYes
out_languageNo
collection_idsNo
classification_idsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
hintNoSet when the search returned nothing; suggests how to widen it
sourceNoData: 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).
entriesYes
returnedYes
truncatedYesTrue if the result hit max_results — narrow the query or raise the limit
provenanceYes
in_languageYes
search_termYes
out_languageNo
retrieved_atYesISO-8601 UTC timestamp

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.2.0
    • 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)."
  2. Changed2 schema fields changedv0.1.1
    • 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"
      +}
  3. First observedv0.1.0

TDQS

A5/5.0
Behavior5/5

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

The annotations already declare readOnlyHint and openWorldHint, and the description substantially enriches them with concrete behavioral details: Lucene wildcard/fuzzy syntax, whole-word matching, detail=False returning unusable empty variants, out_language being purely additive, and the API's deliberate deliberate subset limitation confirmed by the Federal Chancellery. This is far more transparent than the annotations alone.

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 longer than average, but every paragraph adds decision-relevant behavior, caveat, or parameter semantics. The core action is front-loaded, and the later sections are thematically grouped rather than rambling.

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 an output schema exists, the description still provides everything else needed for correct invocation: query syntax, filtering behavior, retry policy, scope limitations, and precise open-world semantics. An agent could use this tool correctly and interpret empty results confidently without external help.

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

Parameters5/5

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

Schema description coverage is 0%, so the description carries the full burden. It explains search_term's Lucene syntax, detail's effect on variants, out_language's additive nature, fields' comma-separated allowed values and default, and classification_ids/collection_ids narrowing — none of which is available from the schema itself. Even in_language and max_results need no explanation because their names and schema defaults are self-evident.

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 opens with a specific verb-plus-resource statement: 'Search TERMDAT for official designations of the Swiss Federal Administration.' It then specifies the concrete use case — looking up validated names of authorities, departments, or legal acts — and clarifies the administrative-nomenclature scope, distinguishing it from ordinary vocabulary lookup.

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?

It gives explicit when-to-use guidance ('before citing it') and strong when-not-to-use rules: retry with a wildcard before concluding absence, never invent a guessed designation, and keep detail=True unless you only need counts or classification filtering. It also points to list_classifications/list_collections as the narrowing alternatives and warns that not-found-in-API does not mean not-found-in-TERMDAT.

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