termdat-mcp

Overview Schema Source Related Servers Discussions Admin

get_entries

Read-only

Retrieve complete TERMDAT entries by numeric IDs, with all four national-language designations and source references, for entries previously found via search.

Instructions

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.

Input Schema

TableJSON Schema

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

Output Schema

TableJSON Schema

Name	Required	Description	Default
`hint`	No	Set when the search returned nothing; suggests how to widen it
`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).
`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

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.2.0Sep 23, 2026

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)."

Changed1 schema field changedv0.1.1Jul 30, 2026

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"
+}

First observedv0.1.0Jul 26, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already mark it read-only and non-destructive; the description adds useful behavioral context beyond that: it works on previously discovered entries, returns full language variants, and can surface all four national-language designations. No contradiction with the 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?

Three sentences with no filler. The first sentence states the operation and scope, and the second/third give concrete usage guidance. The most important info is front-loaded.

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?

For a simple ID-based lookup with an output schema and read-only annotations, the happy path is well covered: what to pass and why. The main gap is the optional language parameters, which are not explained and could affect the returned variants.

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%, so the description needed to compensate. It explains entry_ids ('numeric IDs', 'entry_id') and hints at language output, but never explains in_language or out_language, their defaults, or how they interact with the 'full language variants' behavior.

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?

Opens with 'Fetch known TERMDAT entries by their numeric IDs' – a specific verb, resource, and input identifier. The follow-up sentence explicitly positions it as the re-retrieval counterpart to search_terms, making it easy to distinguish from sibling tools.

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 clear use context: call this after search_terms, using the returned entry_id, to get all language designations at once. It does not explicitly state when not to use it or compare with translate_term/check_terms, so it falls short of a fully explicit routing rule.

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

Deploy Server