eudamed_referencesFetch reference values by language with optional CODE and ID filtering to resolve classifications and status codes. Join on CODE plus ID, never ID alone.
Fetch reference values by language, optionally filtering CODE and ID together. Local limit only; use CODE + ID as the join key, never ID alone.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | ||
| code | No | ||
| limit | No | ||
| language | No | en |
Changes observed during successful MCP inspections.
v0.1.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare this a safe, idempotent, read-only, open-world operation, so that bar is lower. The description adds behavior that the annotations do not cover: the limit is applied locally rather than server-side, and ID is only meaningful when joined with CODE. Both are non-obvious operational facts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is two sentences with no filler, and the core action comes first, followed by the join-key warning. The trade-off is that the compression goes slightly too far, because 'Local limit only' is terse to the point of ambiguity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description ought to say what comes back: for example, a list of code/ID/label reference pairs. Instead it explains only how to filter, not what the reference values look like or how they relate to the codes found in the sibling tools. Adequate but incomplete for a 4-parameter decode tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description has to carry the burden. It names all four parameters (language, code, id, limit), which is better than nothing, but it does not say that language is a two-letter lowercase code, that code is a string up to 200 characters, or what 'local limit' actually bounds. It covers the parameters without explaining them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it fetches reference values, scoped by language, with optional CODE/ID filtering. That is enough to identify it as the decode/reference lookup. It does not, however, contrast itself with siblings such as eudamed_devices or eudamed_actors, so the agent must infer which tool resolves codes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives real usage guidance on how to combine parameters: filter CODE and ID together, never ID alone. That is a genuine constraint on invocation. However it never says when a caller should reach for this tool instead of a sibling, such as 'use this to resolve codes returned by eudamed_devices,' so the usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.