Skip to main content
Glama

China Medical Device Lookup

get_udi_device

Read-onlyIdempotent

Look up medical-device records when a UDI identifier is known. Inputs: udi. Returns paginated structured records with source_class, provenance, snapshot, pagination and limits. Recorded facts only; this query performs no new inference or aggregation. Coverage is limited to the available snapshot. No match returns an empty data array. Required: udi. Missing required or invalid input produces an argument error.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
udiYesRecorded UDI identifier; retain leading zeros. Exact match. Non-empty string, at most 256 characters; control characters are not accepted. Required.
limitNoMaximum number of records returned. Integer 1–100; default 20. A page may contain fewer records.
offsetNoZero-based pagination offset. Integer 0–999; default 0. Offsets of 1000 or greater are rejected. Use the returned next_offset when present.
snapshotNoOptional expected snapshot.version, not a historical-version selector. If omitted, the current dataset snapshot is used. For continued pagination reuse the previous response snapshot.version; a mismatch is rejected.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / limit / description
      Added value: +"Maximum number of records returned. Integer 1–100; default 20. A page may contain fewer records."
    • addedInput schema / properties / offset / description
      Added value: +"Zero-based pagination offset. Integer 0–999; default 0. Offsets of 1000 or greater are rejected. Use the returned next_offset when present."
    • addedInput schema / properties / snapshot / description
      Added value: +"Optional expected snapshot.version, not a historical-version selector. If omitted, the current dataset snapshot is used. For continued pagination reuse the previous response snapshot.version; a mismatch is rejected."
    • addedInput schema / properties / udi / description
      Added value: +"Recorded UDI identifier; retain leading zeros. Exact match. Non-empty string, at most 256 characters; control characters are not accepted. Required."
  2. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Beyond the annotations (read-only, idempotent, non-destructive), the description discloses that the query performs no inference or aggregation, is limited to the available snapshot, returns an empty array on no match, and raises argument errors on invalid input. These are substantive behavioral details not present in 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded with the primary purpose, followed by inputs, returns, and behavior. A small amount of redundancy ('Inputs: udi' and 'Required: udi') and the error sentence could be trimmed, but overall every sentence earns its place.

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?

With no output schema, the description appropriately summarizes the return shape (paginated records, source_class, provenance, snapshot, pagination, limits) and covers no-match and error behavior. It relies on the thorough input schema for pagination defaults and next_offset semantics, which is acceptable.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline applies. The description only restates that udi is required and does not add parameter-level details about limit, offset, or snapshot; it does clarify error behavior for missing required input, which is mild added value.

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?

States a specific verb and resource: 'Look up medical-device records when a UDI identifier is known.' This clearly identifies the exact-match lookup purpose, and the mention of a known UDI implies a distinction from search-based siblings, though no sibling is named explicitly.

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 a clear usage condition ('when a UDI identifier is known'), and notes that no match or invalid input yields specific results. It does not name alternative tools or state when-not-to-use in relation to siblings, so it stops short of explicit routing.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources