Japan Finance Reference Checks

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.

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

Beyond the readOnly/idempotent/openWorld annotations, the description discloses the exact published row fields (date, action type, legal basis, business type, lifted flag), the returned provenance (list version, SHA-256, scope of what was checked), and the two edge-case behaviors: zero rows becomes not_found_in_checked_records with that scope, and a date after the as-of date is unknown. This is unusually thorough behavioral disclosure for a read tool.

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 front-loads the core query in question form before covering scope, output fields, and edge cases, so no sentence is filler. It is dense and the parenthetical qualifiers ('by the FSA and Local Finance Bureaus, fiscal 2002 to the list's as-of date') slow parsing slightly, but the structure is sound.

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?

Because an output schema exists, the description need not restate return shapes, and it covers scope, provenance, and the not_found/unknown edge cases well. The only gap is routing guidance against the sibling lookup tools, which would make an agent's tool choice unambiguous.

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 already 100%, so the baseline is 3, but the description adds genuine meaning: it clarifies that 'since' can overshoot the list's as-of date and then yields unknown, and reinforces that corporate_number is a verified 13-digit houjin bangou. These constraints go beyond the schema text.

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 precise verb+resource: returning rows of the Japan FSA adverse administrative action case list that match a given 13-digit corporate number, with a defined scope (FSA and Local Finance Bureaus, fiscal 2002 to as-of date). It also contrasts itself with name-based lookups via 'No name search', which separates it from siblings like jp_fsa_registry_lookup.

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 rather than spelled out: the agent can infer this is the tool for checking whether a specific corporate number appears in FSA enforcement actions. The description sets boundaries (no name search, date-scoped, zero rows means not_found_in_checked_records) but never names the sibling to prefer for registry or name-based queries, so the when-to-use-vs-alternative guidance is only 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 only cover readOnlyHint and openWorldHint. The description adds substantive traits the agent could not otherwise know: data provenance (own version record rather than upstream history), that reasons are neither published nor inferred, that history begins at tracking_since, and that only the last 30 days are free.

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 front-loaded with the question the tool answers, then layers provenance, payload shape, and constraints. Every clause carries information, though the field enumeration and caveats in the tail make it denser than strictly necessary.

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?

Output schema exists, so return values need not be explained; the description nevertheless summarizes the payload and adds the limits an agent needs (tracking_since floor, 30-day free window, no inferred reasons). Nothing needed to call it 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 coverage is 100%, so the baseline is 3. The description nonetheless adds meaning beyond the schema by paraphrasing the change_type space ('added to, dropped from, changed in or returned to') and by disclosing that personal names are withheld and each change carries before/after fields, an observed_at and a list as-of date.

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 opening question names a specific verb set (added/dropped/changed/relisted) and a concrete resource (Japan FSA registers and warning lists), scoped by a date. Nothing among the siblings is a delta feed, so an agent can distinguish it from jp_fsa_registry_lookup or the customs tools 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?

It states the governing context clearly: 'From this service's own record of list versions (the FSA publishes only current lists)', which tells the agent this is the way to obtain historical deltas the FSA itself doesn't publish. It also names the free window (last 30 days). It stops short of naming an alternative tool or an explicit 'do not use for current-state lookups' exclusion.

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?

Beyond readOnlyHint=true, the description discloses pricing ('Free'), error behavior for unknown/unsettled ids (RECEIPT_NOT_FOUND), and a retention window (30 days after settlement). These are substantive operational facts an agent cannot get from the annotations or 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 short sentences, front-loaded with the purpose, followed by cost, error case, and retention. No sentence is redundant and nothing is buried.

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 an output schema present, return values need no explanation, and the annotations cover safety. The description still covers cost, failure mode, and data lifetime, leaving no material gap for an agent calling this single-param read 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% and the schema already documents the 'rcpt_' + 64 hex format, so the baseline is 3. The description adds semantic constraint by implying the id must belong to a settled paid call, which goes slightly beyond the schema's format-only documentation.

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 opens with a specific verb+resource: 'Re-fetch the stored result of a settled paid call by its receipt_id.' This is unambiguous and an agent can immediately tell what the tool returns and what it operates on, even though the sibling tools are unrelated.

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 the triggering condition clearly ('for when the response was lost after payment'), which is exactly the scenario that should select this tool. It also implicitly scopes usage to settled calls via the RECEIPT_NOT_FOUND note, though it names no alternative tools for other recovery paths.

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 cover safety (readOnlyHint, openWorldHint), and the description adds genuinely behavioral context: historical coverage start date, the tri-state status (valid/invalid/unknown), the inclusive effective period, and base-unit normalization (1 or 100) that affects interpretation. Combined with source URL and hash disclosure this exceeds what annotations provide, though it remains silent on rate limits or caching.

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 definition is front-loaded with the core question, then input, then return shape, then caveats, so an agent can stop reading at any line and still act. It is dense and every clause carries information, though the enumeration of retrieval/verification timestamps and SHA-256 hashes is more output detail than the caller strictly needs given an output schema exists.

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 two-parameter read-only lookup with an output schema present, the description covers the key gaps an agent needs: the date floor, the unknown-result semantics, and the non-authoritative nature of the rate. Return-field detail duplicates the output schema, but nothing essential to correct invocation 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 coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema by specifying the inputs as an ISO 4217 code plus a YYYY-MM-DD Japan-calendar date and, via the earlier revision note, normalizing lowercase input to uppercase. That normalization behavior is not expressed in the schema properties themselves, which justifies a step above 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 opening question states a precise verb and resource: retrieve the JPY rate Japan Customs published for a given currency and date. It also scopes the value ('Reference for customs and bookkeeping only; not a market or remittance rate'), which distinguishes it from generic FX tools. However, it never differentiates itself from the sibling 'jp_customs_fx_batch', which an agent could easily confuse for bulk lookups.

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 context is clear: it states the two required inputs, that coverage begins 2021-08-15, and that unpublished periods or unlisted currencies return 'unknown' rather than an error. The exclusion of tax calculation and market/remittance use further bounds scope. It stops short of naming the batch sibling as the alternative for multiple lookups, so routing guidance is incomplete.

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 only mark it read-only/open-world; the description adds substantial behavioral context beyond that: it is paid, it is not charged when no item can be answered, results come from a single dataset snapshot, and unpublished ranges resolve to unknown rather than an error. Those billing and failure-mode details are exactly what 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?

Front-loads the core question and the 1-50 pair scope, then layers constraints. It is dense and the single long final sentence packs several clauses, but each clause carries distinct information with little waste.

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 an output schema present, return structure need not be explained, yet the description still summarizes per-item status, effective periods, rates with base units, source URLs, timestamps, and hashes. Combined with the billing and unknown-handling rules, an agent has everything needed to invoke it 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 coverage is 100% and the nested item shape is documented in-schema, so the baseline is 3. The description does add the 2021-08-15 lower date bound and the base-unit (1 or 100) convention, but does not elaborate currency/date formatting beyond what the schema already states.

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: return Japan Customs' published JPY rates for a batch of 1-50 currency/date pairs. The batch scope, paid nature, and per-item ordered response distinguish it from the singular jp_customs_fx sibling without needing to open 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?

Gives real boundary conditions: valid dates from 2021-08-15, unpublished periods and unlisted currencies return unknown, and it explicitly rules out date selection, tax calculation, market/remittance rates, and forecasts. It does not, however, name an alternative tool for single-pair lookups or other rate sources.

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?

Beyond the readOnly/openWorld annotations, the description discloses match semantics (exact match, optional domain), a critical trust caveat ('entity tie (domain alone: unverified)'), the shape of the result (registration type, name candidates, as-of dates), and an explicit scope disclaimer plus 'No advice'. These are behavioral traits annotations cannot convey.

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 compact and front-loaded, leading with the core question and then the mechanism, result shape, and caveats. Some density (register list, result fields, disclaimers packed into two paragraphs) makes it slightly heavy, but 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?

With annotations covering the safety profile and an output schema covering return values, the description supplies exactly the missing pieces: accepted identifiers, exact-match behavior, domain-tie verification caveat, and scope limitations. An agent has everything needed to decide and invoke 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 baseline would be 3. The description adds meaning beyond the schema by clarifying that name/registration/corporate number all feed an exact-match lookup and that domain input is optional and yields only an unverified entity tie — a reliability nuance not present in the schema text.

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 opens with a precise question form that names the verb (lookup/check), the resource (Japan FSA registers and warning lists), and the accepted identifiers (name, registration number, 13-digit corporate number). It enumerates the covered register categories (financial instruments, crypto-asset exchange, electronic payment instruments, funds transfer, money lending), which clearly separates it from siblings like fsa_register_changes or fsa_enforcement_by_corporate_number.

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 context is clear: this is the tool for checking whether a named business appears on an FSA register or warning list, and it explicitly states the scope limit ('Stated scope only; no warning match is not proof none exists'). However, it never names an alternative tool or states when a sibling (e.g. fsa_enforcement_by_corporate_number) would be preferred over this one, so the routing is left implicit.

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