Find recorded product recalls and public safety notices in China, including affected products, companies and recall details.
Scored across 3 tools
The three tools have clearly distinct purposes: one returns the information-standard document, one retrieves a specific record by ID, and one searches by text. There is no overlap or ambiguity in their roles.
All tool names follow a consistent verb_noun pattern in snake_case: get_information_standard, get_recall_record, search_recalls. The verbs (get/search) and nouns are appropriately descriptive and match the tool's function.
With only three tools, the server is tightly scoped for a read-only recall search/retrieval domain. Each tool covers a distinct essential operation, and there is no redundancy or bloat.
The set covers search and retrieval by ID, plus access to the information standard, which covers the core read-only workflow. Minor gaps exist, such as lacking a way to list all records without a search query or to inspect available snapshots directly, but these are workable.
Retrieve definitions of information formation classes, provenance fields and snapshot/version metadata. Takes no arguments. Returns the information-standard document, not business records or an assessment of facts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds useful context by stating that the tool takes no arguments and returns only the standard document, not records or facts, but it does not describe the document's structure or any pagination/format details.
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?
Two sentences with no wasted words. The core purpose is front-loaded, and the clarifying exclusions ('not business records or an assessment of facts') are valuable for agent decision-making.
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-parameter, read-only, idempotent tool, the description is complete enough. It tells an agent what the tool returns, what it does not return, and that no arguments are needed. The lack of an output schema is offset by the clear high-level description of the document.
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?
There are zero parameters, and the description explicitly confirms 'Takes no arguments,' so there is no ambiguity about invocation. Baseline for zero-parameter tools is 4, and the description removes any doubt about whether arguments are needed.
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 ('Retrieve') and a clear resource ('definitions of information formation classes, provenance fields and snapshot/version metadata'), and further clarifies that it returns the information-standard document rather than business records or factual assessments. It is clear on its own, though it does not explicitly differentiate itself from likely-related siblings such as get_standard_metadata.
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?
The description implies its use case: call this tool when you need the standard definitions/metadata document, and it explicitly says it does not return business records or factual assessments. However, it does not name alternatives or explain when to prefer this over sibling tools like get_standard_metadata or search_standard_metadata.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a recall notice or detail record using an existing search-result identifier. Inputs: record_id. 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: record_id. Missing required or invalid input produces an argument error.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of records returned. Integer 1–100; default 20. A page may contain fewer records. | |
| offset | No | Zero-based pagination offset. Integer 0–999; default 0. Offsets of 1000 or greater are rejected. Use the returned next_offset when present. | |
| snapshot | No | 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. | |
| record_id | Yes | Existing integer recall record identifier returned by search_recalls. Exact match. Non-negative integer within the server integer range. Required. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds crucial behavioral details: it performs no new inference or aggregation, coverage is limited to the available snapshot, returns an empty data array on no match, and produces an argument error on invalid input. These go beyond the annotations and fully disclose behavior.
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 description is a compact paragraph that front-loads the purpose, then covers return format, safety, and error conditions. It is not overly verbose, but the line 'Inputs: record_id' is somewhat redundant given the schema and the later mention of required. Still, it is well-structured and readable.
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?
With no output schema, the description adequately explains the return payload (paginated structured records with specific fields), pagination behavior, snapshot handling, and error cases. It covers all essential aspects an agent needs to call the tool correctly, making it complete for a retrieval 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 coverage is 100% with detailed descriptions for all parameters. The description only repeats that record_id is required, adding no new meaning to limit, offset, or snapshot beyond what the schema already provides. This meets the baseline but adds little value.
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 clearly states the verb 'Retrieve' and the resource 'recall notice or detail record' using an existing search-result identifier. It distinguishes itself from search tools by emphasizing it operates on an existing identifier, and clarifies it returns recorded facts without inference or aggregation, making it unambiguous.
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 the tool retrieves using an existing search-result identifier, which implies prior use of a search tool like search_recalls. It does not explicitly name alternatives or say when not to use, but the context is clear enough for an agent to infer the appropriate usage scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find recall notices and detail records by product, manufacturer or title text. Inputs: query. Returns paginated structured records with source_class, provenance, snapshot, pagination and limits. Recorded notices only; an empty result does not establish absence of recalls. No match returns an empty data array. Required: query. Missing required or invalid input produces an argument error.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of records returned. Integer 1–100; default 20. A page may contain fewer records. | |
| query | Yes | Recorded recall title, product name or manufacturer text. Literal, case-sensitive substring match; no fuzzy search. Non-empty string, at most 256 characters; control characters are not accepted. Required. | |
| offset | No | Zero-based pagination offset. Integer 0–999; default 0. Offsets of 1000 or greater are rejected. Use the returned next_offset when present. | |
| snapshot | No | 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'an empty result does not establish absence of recalls,' which is an open-world claim. The annotations declare openWorldHint=false, meaning closed-world semantics. This directly contradicts the annotation, so the score is 1.
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 description is dense and front-loaded with the purpose. Some redundancy exists ('Inputs: query' and 'Required: query') and the error sentence is slightly redundant with the schema, but overall it is efficient and well-organized.
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?
With no output schema, the description explains the return envelope (source_class, provenance, snapshot, pagination, limits), explicitly describes no-match and error behavior, and relies on the rich parameter schema for invocation details. This is sufficient for an agent to call the tool correctly.
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 schema covers 100% of parameters with detailed descriptions, including literal case-sensitive substring matching, limit/offset constraints, and snapshot semantics. The description adds little beyond redundant mentions of 'query' and 'Required', so baseline 3 is appropriate.
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 action ('Find') on a clear resource ('recall notices and detail records') with search dimensions (product, manufacturer, title text). This distinguishes it from sibling get_recall_record, which implies single-record retrieval, without needing to inspect the 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?
The context is clear: this tool is for text-based searching of recall notices by product, manufacturer, or title. It does not explicitly name alternatives or exclusions, but the use case is evident and no misleading guidance is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_information_standardget_recall_recordsearch_recalls
Add one secure layer between your agents and this server.
