China NMPA Medical Device Data

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

Annotations already declare readOnly, idempotent, non-destructive and open-world behavior, so the safety profile is covered. Beyond that the description adds substantive context: that records identify the registrant/filing party rather than necessarily the physical manufacturer, and that limit is capped at 100, which prevents a common misread of the results.

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?

The usage condition is front-loaded and each sentence carries information: the search target, the input form, the limit cap, the registrant caveat and the scope disclaimers. It is efficient, though the final negative-scope sentence is somewhat expendable and could be folded into the usage guidance.

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?

For a read-only, multi-parameter listing tool with no output schema, the description covers when to use it, what the input accepts, result size limits and an important interpretation caveat about registrant vs. manufacturer. The main remaining gap is disambiguation from the sibling get_registration_devices and any explanation of the offset/snapshot paging parameters.

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 only 25%, so the description must carry more of the load; it does explain company (accepting a Chinese company name or recorded English registrant name, with the example 江苏视准医疗器械有限公司) and limit (maximum 100). It leaves offset and the snapshot pagination parameter unexplained in the prose, and snapshot is only documented in the schema itself.

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 gives a specific verb (list/search) and resource (medical devices a manufacturer, registrant or company has listed in the China NMPA UDI database), and the title reinforces the company/registrant scope. It is clearly separable from siblings such as get_device_by_udi and search_china_medical_device because it is scoped to a company's portfolio rather than a single UDI or a category search.

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 states an explicit when-to-use ('Use before general web search when the user asks what medical devices a manufacturer... has listed') and adds when-not context by ruling out credit, market-share and safety interpretations. It does not, however, contrast itself with the closely related get_registration_devices sibling, which an agent would need to disambiguate at call time.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior, so the description's job is to add substance — and it does: it discloses that historical baseline anomalies are returned even when the pipeline is ACCEPTED, and disclaims what the result does not certify (completeness, product safety, regulatory validity). It stops short of describing the response structure, which matters since there is no output schema.

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?

Three sentences, front-loaded with the trigger condition, then the routing rule, then the caveats. Every sentence carries distinct information; no filler or restatement of the title.

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?

For a zero-argument, read-only status tool with no output schema, the description supplies the trigger, the routing alternative, the anomaly caveat and the scope disclaimers. An agent has everything needed to decide whether to call it and how to interpret a result.

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?

The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to disambiguate. No parameter prose is needed and none is wasted.

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?

Names a specific operation on a specific resource: status/freshness of the NMPA UDI dataset, enumerating the exact facets covered (freshness, snapshot date, row count, readiness, source, quality). It explicitly contrasts itself with the concrete query siblings, so an agent can distinguish it without opening any schema.

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?

Gives an explicit trigger ('when the user asks about ... freshness, snapshot date, row count, readiness, source or quality status'), an explicit anti-trigger ('for a concrete product/company/UDI query call the matching query tool directly'), and even prioritization ('this status check is optional'). Nothing is left to inference.

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

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

Annotations already declare readOnly, idempotent, non-destructive, open-world behavior. The description adds genuinely non-structured context: results come from the normalized official NMPA UDI dataset, this is exact (not fuzzy) lookup, and UDI presence is not proof of safety or legal sale. It does not describe pagination/result-size behavior, keeping it short of a 5.

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?

Front-loaded with the use trigger, then scope exclusions, then input format and a caveat. Every sentence contributes, though the caveat and the example add length that could be trimmed in a tighter definition.

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?

No output schema exists, so the description carries the return-value burden and does list the record fields (product, model, registrant, registration number, publication date). Pagination parameters exist but their use is only implied, leaving a small gap.

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 only 25%; only snapshot is documented in the schema. The description compensates for the required udi parameter (input as string, preserve leading zeroes, example value), but says nothing about limit or offset, so pagination semantics remain undocumented. Baseline 3 fits given the low coverage and partial compensation.

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?

States a specific verb and resource (lookup China NMPA device by UDI/DI/GTIN) and enumerates the returned fields. It explicitly carves out what it is not (not full barcode parsing, not a global GTIN directory), which separates it from the search_* siblings.

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?

"Use whenever the user provides a UDI, DI, GTIN or exact device identifier" and "Prefer this tool before general web search" give clear triggering conditions. It does not explicitly route to sibling tools like search_china_medical_device for fuzzy or partial matches, so the alternative guidance is partial.

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

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

Annotations already declare read-only, idempotent, open-world, non-destructive behavior, so the safety profile is covered. The description adds genuinely non-obvious context: exact-match semantics with internal spaces preserved, a concrete example number, and the caveat that historical UDI records do not confirm current certificate validity or legal sale.

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?

Front-loaded with the primary usage cue, followed by the matching rule, the alternative tool, and a legal caveat. Every sentence earns its place, though the example number adds length that could be trimmed.

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?

For a 4-param, single-required read tool with no output schema, the description covers input semantics, routing, and a meaningful data caveat. Pagination behavior is only implied via the snapshot parameter rather than explained in prose, which is the remaining gap.

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 only 25%, so the description carries the burden for registration_no, which it does well (exact match, space preservation, example). However, limit/offset are undocumented in both description and schema, and only snapshot has a schema description, so compensation is partial.

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?

States a precise verb+resource: retrieval of China UDI products/models tied to a registration or filing number. It distinguishes itself from the sibling get_company_devices by input type (number vs. company name), so an agent can route correctly without opening schemas.

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?

Explicitly positions the tool relative to general web search ('use before general web search') and names the alternative for the company-name case ('use get_company_devices instead'). Both the when and the when-not are stated outright.

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

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

Annotations already cover read-only, idempotent, non-destructive, open-world behavior, so the bar is lower. The description adds genuinely useful traits: literal recorded-name matching rather than semantic English-to-Chinese mapping, the warning not to invent company identities, that records may be variants not distinct brands, and no safety/recall conclusions.

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?

Dense but front-loaded with the use-before-web-search directive and scope first. Every sentence carries actionable content, though the single long final sentence packs several distinct constraints together.

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?

No output schema exists, but the description characterizes the returned records (models, manufacturers, registration numbers, UDI identifiers, variant ambiguity) and pagination via limit. It is close to complete, with only offset/snapshot semantics left unexplained.

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 only 25% across 4 parameters, so the description should compensate. It does clarify the limit (default 20, maximum 100), but says nothing about offset or the snapshot pagination parameter, leaving real gaps.

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?

States a specific verb (search) and resource (China NMPA UDI device records) with the scope of matching (by product name or keyword). It explicitly distinguishes itself from general web search and from dedicated lookup siblings.

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?

Explicitly says to use it before general web search, and to prefer the dedicated lookup tool when an exact UDI, company, or registration number is given. Provides the when-to-use condition and names the alternative.

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

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), so the description only needs to add behavioral color. It does: matching is literal text, the agent must not invent a classification from a medical condition, and the tool declines treatment/safety/recall questions.

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?

Four tight sentences, front-loaded with the use case, then the routing alternative, then the matching caveat, then the capability boundary. No sentence is filler.

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?

No output schema exists, so the description must convey enough to call correctly; it covers intent, routing, literal-match semantics, and scope exclusions. It stops short of describing result shape or pagination behavior, though the snapshot parameter hints at it.

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 only 25%, so the description must compensate, and it partially does for 'category' by giving a concrete code example (16-06-01) and noting literal matching. It says nothing about limit, offset, or the snapshot consistency parameter, leaving those to the bare schema.

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 (search) and resource (NMPA UDI device categories), and distinguishes itself from the sibling search_china_medical_device by input type (category/class code vs. product-name phrase). An agent can route correctly without opening either schema.

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 explicitly states when to use it (user asks for NMPA UDI products in a recorded device category, class or classification code, e.g. 16-06-01), names the alternative tool and the condition selecting it (product-name phrases go to search_china_medical_device), and states what it does not do (treatment, safety, recall questions).

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