Is this operator in Japan's organic JAS certified list? Hosted; tracks list changes. Relay only.
Scored across 4 tools
The two domain tools split cleanly by intent: organic_jas_lookup answers point-in-time membership while organic_jas_changes answers temporal diffs. The meta tools catalog and get_receipt also have clearly separate purposes (pricing/limits vs. result re-fetch), so misselection risk is low, though lookup and changes both target the same dataset.
The domain tools follow a consistent domain_prefix_action pattern (organic_jas_changes, organic_jas_lookup), but the meta tools break it: catalog is a bare noun and get_receipt is a verb_noun form. Mixed conventions, though each name is still readable.
Four tools is lean but reasonable for a data-lookup service: two domain queries plus two supporting meta tools. It is on the thin side (no aggregation/list endpoint for the data itself), but each tool earns its place.
The lookup/changes pairing plus payment infrastructure covers the core lifecycle for a certified-operator dataset, including historical deltas that MAFF itself does not retain. Minor gaps such as no direct bulk operator listing are workarounds rather than dead ends.
List the tools of this server with prices, data sources, licensing, daily limits and data freshness.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| legal | Yes | |
| terms | Yes | URL of the terms of service. |
| tools | Yes | Every tool of this server with its price. |
| paused | Yes | Operator pause flags (true = paused). |
| server | Yes | |
| payment | Yes | |
| provenance | No | Freshness receipts for every upstream source used. |
| daily_limits | Yes | Daily limits of paid calls (calls, usd, timezone) or a misconfiguration notice. |
| fetch_status_values | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so safety is covered. The description adds the content categories returned (prices, licensing, limits, freshness), which is useful context, but an output schema exists and would surface the same structure, so the incremental disclosure is modest.
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?
A single front-loaded sentence with no filler; every clause enumerates distinct payload content, so nothing is wasted.
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 parameters, a read-only annotation, and an output schema present, the description need not explain return values or safety. It is nearly complete for this simple tool; only a hint about when to reach for it is absent.
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 there is nothing for the description to disambiguate. Baseline 4 applies under the '0 params' rule.
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?
Clear verb ("List") plus resource ("the tools of this server") and an enumeration of the payload contents (prices, data sources, licensing, daily limits, freshness). It is plainly distinguishable from siblings like get_receipt or drone_flight_check, though it does not explicitly name or contrast them.
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?
No explicit when-to-use or when-not-to-use guidance is given; usage is only implied by the discovery framing ("the tools of this server"). An agent can infer this is the entry point for learning available tools and pricing, but nothing states that intent directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Re-fetch the stored result of a settled paid call by its receipt_id, for when the response was lost after payment. Free. Unknown or unsettled receipt ids return RECEIPT_NOT_FOUND. Results are kept for 90 days after settlement.
| Name | Required | Description | Default |
|---|---|---|---|
| receipt_id | Yes | The receipt_id returned with a paid result ("rcpt_" + 64 hex characters). |
| Name | Required | Description |
|---|---|---|
| tool | Yes | Name of the paid tool that produced the result. |
| terms | Yes | URL of the terms of service. |
| result | Yes | The stored result, exactly as returned by the paid call. |
| payment | Yes | |
| provenance | Yes | Freshness receipts for every upstream source used. |
| receipt_id | Yes | Receipt id of the settled paid call ("rcpt_" + 64 hex). Use with get_receipt. |
| settled_at | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well past readOnlyHint=true by disclosing cost ('Free'), the failure mode and error code (RECEIPT_NOT_FOUND for unknown/unsettled ids), and the retention window (90 days after settlement). These are exactly the runtime traits an agent needs before calling.
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 short sentences, front-loaded with the action and the receipt_id, followed by behavioral facts. No filler, no 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?
An output schema exists, so return values need no explanation, and the description still covers cost, error behavior, and retention limits. Nothing an agent needs to call this correctly is missing.
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 100% and the schema already specifies the receipt_id format ('rcpt_' + 64 hex characters, maxLength 80). The description only names the identifier without adding format or constraint detail, so the schema does the real work.
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 ('re-fetch'), specific resource ('stored result of a settled paid call'), and the keying mechanism ('by its receipt_id'). The 're-fetch ... for when the response was lost' framing clearly separates it from the unrelated sibling tools.
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 triggering scenario: use it when a paid call's response was lost after payment. It also implies the boundary condition (unknown or unsettled ids are not valid targets), but does not name an alternative tool or state a when-not clause for other lookup paths.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Which organic JAS listings were added to, changed in, dropped from or returned to MAFF's official lists since a date? From this service's own record of list versions (MAFF keeps no old files). Each change has the listing id, observed_at, last_seen_at, changed fields and before/after; personal-looking names are withheld and the reason for a drop is not published or inferred. History starts at tracking_since. Free window: last 30 days.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of changes, 1-500 (default 100) | |
| since | Yes | ISO 8601 date or date-time with time zone, e.g. 2026-10-01 or 2026-10-01T00:00:00Z | |
| country | No | Optional filter: country code (CN), English name or Japanese name. JP = the domestic list | |
| change_type | No | Optional filter: added, modified, dropped_from_list or reappeared |
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| terms | Yes | URL of the terms of service. |
| changes | Yes | Changes observed by this service between list versions, oldest first. |
| coverage | Yes | |
| truncated | Yes | |
| provenance | Yes | Freshness receipts for every upstream source used. |
| answered_at | Yes | |
| attribution | Yes | |
| history_note | Yes | |
| legal_notice | Yes | |
| history_window | Yes | Free history window applied to this answer. |
| official_check | Yes | Read first: confirm with the certification body or on the official MAFF page listed here before relying on this answer. |
| tracking_since | Yes | When this service first loaded the lists. Nothing before it was observed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint and openWorldHint already given, the description goes well beyond the annotations: it discloses the data provenance (the service's own record of list versions, since MAFF keeps no old files), what each change record contains, deliberate withholding of personal-looking names, that drop reasons are neither published nor inferred, the history start point, and the 30-day free window.
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 core question is front-loaded in the first sentence, followed by provenance, record contents and constraints. It is dense but every clause carries information; slightly longer than ideal but no 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?
An output schema exists so return values need no explanation, yet the description still summarizes the record fields, and it covers provenance, retention limits and the free window. Nothing an agent needs to call this tool correctly is missing.
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 100%, so limit, since, country and change_type are already fully documented in the schema, and the description's enumeration of change types merely mirrors the enum. It adds only light framing (since relates to tracking_since), which is not enough to lift it above the baseline.
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 resource (organic JAS listing changes) with a clear verb (which listings were added/changed/dropped/returned) and a scope constraint (since a date). It implicitly distinguishes itself from the sibling organic_jas_lookup by framing the tool as a change log rather than a point-in-time lookup, but it never names that alternative explicitly.
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?
Usage is implied through constraints like 'since a date', 'History starts at tracking_since' and 'Free window: last 30 days', which tell an agent when the tool is applicable. However, there is no explicit when-to-use versus organic_jas_lookup or catalog, and no guidance on choosing change_type filters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Is this operator in Japan's official MAFF list of organic JAS certified operators (domestic or foreign)? Look up by certification number, operator name (2+ chars, organizations only), country, prefecture, category or certifier. Returns found, no_longer_listed (reason not published or inferred), no_match_in_checked_list (does not mean not organic) or unknown, with certifier, category, municipality or country, certified_on, first/last seen. Confirm with the certification body.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of listings, 1-100 (default 20) | |
| country | No | Country: ISO code (CN), English name (China) or Japanese name (中国). JP = the domestic list | |
| certifier | No | Part of the registered certification body's name, e.g. Ecocert or アファス | |
| prefecture | No | Japanese prefecture (Tokyo or 東京都), JIS code (13) or local government code (130001); domestic listings only | |
| operator_name | No | Part of the operator name in Japanese or Latin letters, at least 2 characters (organization names only) | |
| product_category | No | Product category: agricultural_products, processed_foods, feeds, livestock_products, algae (or the Japanese name, e.g. 有機加工食品) | |
| certification_number | No | Certification number as published by the certification body, e.g. 060420-001 (numbers can repeat across bodies; add certifier to narrow) |
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| terms | Yes | URL of the terms of service. |
| total | Yes | |
| status | Yes | found = in the current official list; no_longer_listed = seen by this service before but not in the current list (reason not published, not inferred); no_match_in_checked_list = not in the list versions checked and not seen since tracking_since (does not mean not organic); unknown = list not loaded yet or stale. Never 'expired'. |
| listings | Yes | |
| name_note | Yes | |
| truncated | Yes | |
| provenance | Yes | Freshness receipts for every upstream source used. |
| answered_at | Yes | |
| attribution | Yes | |
| status_note | Yes | |
| legal_notice | Yes | |
| list_version | Yes | |
| official_check | Yes | Read first: confirm with the certification body or on the official MAFF page listed here before relying on this answer. |
| registry_status | Yes | The common registry status section shared across this operator's servers (listed / not_found_in_checked_records / no_longer_listed_since / unknown; expired is never used here). Null for list queries that do not identify an operator (country, prefecture, category or certifier only). |
| no_longer_listed | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuinely useful semantics beyond that: it enumerates the outcome states and critically warns that no_match_in_checked_list 'does not mean not organic' and that no_longer_listed reasons may be unpublished or inferred, plus an authoritative-source caveat. These interpretive notes go well past the structured fields.
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 core question, then the lookup keys, then the return semantics and caveat. Dense and mostly waste-free, though the enumerated status list is slightly long given an output schema exists. Every sentence still carries decision-relevant information.
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, open-world lookup with a 100%-covered schema and an existing output schema, this is complete: purpose, accepted filter dimensions, return-state interpretation, and an authoritative-source warning are all present. An agent has everything needed to call it and interpret results 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?
Schema description coverage is 100%, so the schema already documents every parameter's format, codes, and constraints. The description restates the filter dimensions (cert number, name with 2+ char/organization-only rule, country, prefecture, category, certifier) but adds no syntax or format detail beyond what the schema provides. Baseline 3 applies.
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 (look up) and resource (Japan's official MAFF list of organic JAS certified operators), plus scope (domestic or foreign). An agent immediately understands this is a membership/verification lookup against a government registry, distinct from a changes feed like organic_jas_changes. Framing it as a yes/no question makes the intent unmistakable.
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 'Is this operator...?' framing implies the verification use case, and the closing 'Confirm with the certification body' caveat signals this is not the authoritative source. However, it never states when to reach for this versus a sibling like organic_jas_changes, nor any exclusions. Usage is implied rather than explicit.
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.
catalogget_receiptorganic_jas_changesorganic_jas_lookupIs this Japanese SSW support organization in ISA's list? Hosted; tracks list changes. Relay only.
Is this name on Japan's MOF asset-freeze list? Hosted, list-change history kept. Reference only.
USDA NOP organic compliance checks — operation websites vs live OID certificate data.
Is a food, country or company in Japan MHLW imported food inspection orders? Rows as published.
Add one secure layer between your agents and this server.