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

Annotations already indicate readOnlyHint=true, so the description does not need to restate safety. It adds useful behavioral context by specifying the output includes a granularity level and confidence score, and that it is Japan-only. It does not disclose error handling or edge cases, but the annotation coverage lowers the bar.

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 single, tightly written sentence that front-loads the verb and essential information. Every word contributes value, with no repetition or 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?

For a simple tool with one parameter and no output schema, the description covers the key aspects: input (Japanese address), output (coordinates, granularity, confidence), and scope (Japan-only). It lacks details on failure behavior or formatting requirements, but these are not critical for a basic geocoding operation.

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 input schema has 100% coverage for the single 'address' parameter, describing it as 'A Japanese address string.' The tool description adds no further parameter-specific meaning beyond the same 'Japanese address' context, so the baseline of 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 clearly states the tool's function with a specific verb ('Geocode'), the target resource ('a Japanese address'), and the output ('WGS84 lat/lng coordinates, with a granularity level and confidence score'). The 'Japan-only' constraint further differentiates it from sibling address tools like address_reverse_geocode or address_normalize.

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 provides clear usage context by stating 'Japan-only', which tells the agent when this tool is applicable. It does not explicitly mention alternatives or when not to use it, but for a straightforward geocoding tool this is sufficient context.

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 readOnlyHint and openWorldHint, and the description adds specific behavioral details: it fixes character width variants and old-form kanji, resolves postal codes, and returns a 0-1 confidence score. This goes beyond the annotations and provides useful expectations about the transformation and output, though it omits any failure 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 two sentences, front-loaded with the primary action and output, and the second sentence states the return value. There is no redundancy or filler; every word adds 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?

Given the tool has one parameter, no output schema, and rich annotations, the description covers the core behavior and return value. It is adequate for a read-only normalization tool, though it could possibly mention what happens on invalid input, but that is not necessary for basic use.

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%: the single parameter 'address' is already described as 'A Japanese address string, any common notation.' The description adds context about normalization (e.g., fixing width) but does not add new parameter-level details, so the baseline of 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 uses a specific verb 'Normalize' with a clear resource ('a Japanese address') and states the output components (prefecture/city/town/chome) and key transformations (fixing fullwidth/halfwidth and old-form kanji, resolving postal code). This distinguishes it from sibling tools like address_parse or address_geocode, which focus on parsing or coordinates.

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 clearly implies the tool is for normalizing Japanese addresses into clean components, which gives context for when to use it. However, it does not explicitly mention alternatives or when not to use this tool, leaving some ambiguity given the many sibling address-related tools.

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 readOnlyHint=true, so the agent knows it is a safe read operation. The description adds that it extracts building name, room number, and addressee, giving insight into the output. However, it does not detail edge cases, error behavior, or how incomplete addresses are handled, leaving gaps.

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 single, front-loaded sentence with no redundant words. It efficiently conveys purpose, input source, and expected components.

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?

Given one parameter, annotations, and no output schema, the description conveys the core purpose and output components. It does not specify the exact return format, but the phrase 'fully structured' plus the listed components give enough context for a parsing 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?

The single parameter 'text' is fully documented in the schema with 'Free-form text containing a Japanese address.' The description reiterates this and adds output details but no new parameter-specific semantics. With 100% schema coverage, the baseline of 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 uses the specific verb 'Extract' and names the resource (structured Japanese address) and source (free-form, OCR, or voice-transcribed text). It clearly distinguishes from sibling tools like address_geocode or address_normalize by focusing on parsing into components like building name, room number, and addressee.

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 identifies appropriate input types (free-form, OCR, voice-transcribed), making it clear when to use this tool over normalized or geocoding variants. It does not explicitly name alternatives or exclusions, but the context is sufficient for a one-parameter address parser.

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 readOnlyHint=true, so the read-only nature is covered. The description adds context about the data source (Japan Post KEN_ALL data) and implies multiple results via 'candidates', but it does not describe edge-case behavior (e.g., missing postal code) or response structure.

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 single, front-loaded sentence that conveys the tool's purpose, scope, and data source without any fluff or repetition. Every word earns its place.

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 simple one-parameter lookup with annotations and full schema coverage, the description is nearly complete. The only minor gap is that 'address candidates' could be more explicit about the return type (likely a list), but the term is reasonably clear.

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 input schema provides a complete description of the zip parameter, including format and example. The description adds no additional parameter detail, so with 100% schema coverage the baseline score of 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 clearly states a specific verb ('Look up') and resource ('Japanese address candidates for a 7-digit postal code'). It explicitly names the postal code format and data source, distinguishing it from sibling tools like address_normalize or address_geocode.

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 purpose implicitly signals when to use the tool (when you have a 7-digit Japanese postal code and need address candidates). However, it does not explicitly contrast with alternatives or state when not to use it, so usage guidance is only implied.

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 readOnlyHint=true and openWorldHint=true, so the description adds value by specifying the geographic scope ('within Japan') and output normalization, without contradicting annotations.

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 conveys the essential purpose and constraints with no wasted words.

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 tool with no output schema, the description is sufficient: it states the geodetic coordinate system, the geographic scope, and the expected output. It lacks return format or error behavior, but these are less critical given the simple nature and annotations.

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 input schema fully describes both parameters with 'Latitude (WGS84)' and 'Longitude (WGS84),' achieving 100% coverage. The description adds no parameter-specific details beyond the schema, so the baseline of 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?

The description uses a specific verb 'Reverse-geocode' with a clear resource ('WGS84 lat/lng coordinates within Japan') and a defined output ('normalized address'). It clearly distinguishes from sibling forward geocoding tools like address_geocode.

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 conveys clear context: use for converting coordinates to addresses within Japan. It does not explicitly mention alternatives or exclusions, but the tool name and sibling list make the use case sufficiently obvious.

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 readOnlyHint=true and openWorldHint=true, so the description does not need to restate safety. It adds value by listing the profile's contents (party, constituency, committees, positions), which sets expectations for the response. There is no contradiction, and the additional detail is useful.

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 single, compact sentence with no filler. It front-loads the key qualifier 'canonical id' and succinctly enumerates the profile contents. Every word earns its place, making it highly efficient.

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 simple one-parameter, read-only lookup tool, the description provides sufficient context: what it returns (profile attributes), how to obtain the required id (via diet_members_search), and its role relative to siblings. Although there is no output schema, the description's content list partially compensates and fully satisfies the tool's simplicity.

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 single parameter 'id' is fully described in the schema as 'Canonical member id (from diet_members_search)', and the description repeats this same reference. With 100% schema description coverage, the tool description adds no additional semantic meaning beyond what the schema already provides, meeting the baseline of 3.

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 identifies the tool as retrieving a full profile of a Japanese National Diet member, enumerating key attributes (party, constituency, committees, positions). This specific resource and scope distinguish it from sibling tools like diet_members_search, making the purpose 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?

The phrase 'by canonical id (from diet_members_search)' establishes a clear prerequisite: the id must come from a prior search. This gives concrete context for when to use the tool. However, it does not explicitly state when not to use it or mention alternatives, so it falls short of a 5.

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?

The description claims to search 'current' members, but the schema includes an active_only parameter that can restrict to currently-serving members, implying that the default search may include non-current members. This is a subtle inconsistency that could mislead an agent. The readOnlyHint and openWorldHint annotations already establish safety, but the description adds no further behavioral context such as pagination limits or default result size.

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 single, well-structured sentence that front-loads the tool's purpose and enumerates the primary criteria. No wasted words or redundant detail.

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 search tool with 6 optional parameters and no output schema, the description is somewhat sparse. It does not explain what the search returns, what happens when no filters are provided (potential broad result set), or how to refine results. The schema covers parameters and annotations cover safety, but the description leaves gaps in expected behavior.

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 provides 100% description coverage for all six parameters, each with clear semantics. The description restates these search fields without adding new meaning or clarifying interactions (e.g., whether filters are combined with AND). Baseline of 3 is appropriate because the schema carries the explanatory weight.

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 uses a specific verb ('Search'), names the exact resource ('current Japanese National Diet members'), and enumerates distinct search criteria (name, party, house, constituency). This clearly differentiates it from the sibling tools like diet_member (singular) and diet_minutes_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?

The description implies usage for searching Diet members but provides no explicit guidance on when to prefer this over diet_member (which likely retrieves a single member) or other search tools. No alternatives or exclusions are mentioned, so it relies on the reader to infer the intended use case.

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 readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds minimal behavioral context beyond the resource name and filterability, which is largely a restatement of schema properties. No contradictions or additional behavioral notes are provided.

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, well-structured sentence that front-loads the core action (full-text search) and resource. Every word earns its place, with no extraneous information or repetition. Extremely concise and clear.

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 search tool with 8 parameters and no output schema, the description is reasonably complete. It indicates the tool returns search results from the proceedings archive and lists key filters. It does not describe the return format or pagination, but the schema covers parameter details, and the readOnlyHint ensures agent knows it's safe. Slight gap around result expectations, but adequate for the complexity.

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 input schema has 100% coverage, with each parameter clearly described. The description only reiterates the filterable dimensions (date, house, committee, speaker) that are already in the schema, adding no extra semantic value. Baseline 3 is appropriate given full schema coverage.

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 tool's function with a specific verb ('search') and resource ('official Japanese Diet proceedings archive'). It differentiates from sibling tools like diet_members_search by focusing on the proceedings archive, making its purpose 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?

The description implies when to use the tool (for searching Diet proceedings) but does not explicitly mention alternatives or exclusions. It does not say 'use diet_members_search for member lookups' or provide guidance on when not to use this tool. Usage context is present but not fully explicit.

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?

The description adds output details (probability and character-type breakdown) beyond the readOnlyHint annotation. It does not contradict annotations and provides useful behavioral context about what the result contains.

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 single, front-loaded sentence that covers the verb, resource, categories, and output components without redundancy.

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 one-parameter tool with no output schema, the description adequately covers the return values (probability and character-type breakdown) and classification categories. It could be more explicit about the breakdown's composition but is sufficiently complete.

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 input schema already fully describes the 'text' parameter, and the description's phrase 'Japanese string' is synonymous with the schema's 'Japanese text to classify.' No additional parameter semantics are provided.

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 uses the specific verb 'classify' with the resource 'Japanese string' and enumerates the classification categories and output components, clearly distinguishing it from sibling tools like furigana_convert or furigana_name_readings.

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 does not explicitly indicate when to use this tool over the sibling furigana tools; however, the 'classify' verb and the listed categories imply its purpose for type classification. No exclusions or alternative guidance is provided.

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 readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds valuable behavioral context by specifying the per-token reading breakdown, which is not present in the schema or annotations. This goes beyond the safe-read annotation and gives the agent a clearer expectation of the tool's output 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 single, front-loaded sentence that clearly states the action, object, and output style without any filler. Every word contributes, and the per-token breakdown is an efficient addition.

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 simple read-only tool with two well-documented parameters and strong annotations, the description covers purpose and output characteristics sufficiently. It lacks some broader context like input prerequisites or nuances of how the breakdown is structured, but the combination of schema, annotations, and description is adequate for correct invocation.

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 is 3. The description does not add extra parameter-level detail beyond what the schema already explains for 'text' and 'to'. It confirms the general target scripts but adds no syntax or formatting guidance beyond 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 uses a specific verb 'convert' with a clear resource ('kanji-mixed Japanese text') and target scripts ('hiragana, katakana, or romaji'), plus a per-token reading breakdown. This distinguishes it from siblings like furigana_classify and furigana_name_readings, which suggest different operations or scopes.

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 states what the tool does but does not provide guidance on when to use it over alternatives such as furigana_classify or furigana_name_readings. There is no explicit when-to-use or when-not-to-use context, leaving the agent to infer applicability from the description alone.

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?

The annotations already indicate read-only and open-world behavior. The description adds meaningful context beyond these by stating the output includes probabilities and that names are ambiguous without context, which explains why the tool returns multiple candidate readings rather than a single result. It does not contradict annotations.

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 single, front-loaded sentence that directly states the action and key qualifiers (probabilities, ambiguity, name types). No unnecessary words or repetition.

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?

The tool is simple with two parameters, and the schema plus annotations cover most essentials. The description provides a hint about the output structure (list of readings with probabilities), but it does not specify details such as ordering, empty results, or probability format. This is a minor gap, so 4 is appropriate.

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%, with both parameters already explained ('A Japanese name' and 'Hint for the kind of name'). The tool description reinforces the name types and notes ambiguity, which slightly augments the schema, but it does not add significant additional meaning about parameter usage or format. Thus a baseline of 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 uses a specific verb ('List') with a clear resource ('possible readings of a Japanese name'). It explicitly mentions the types (person, company, place) and distinguishes the tool by highlighting the probability output and ambiguity, setting it apart from likely siblings such as furigana_convert or furigana_classify.

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 provides clear context for when to use this tool: when a Japanese name is ambiguous and multiple readings are possible with probabilities. It does not explicitly name alternative tools or state when not to use it, but the context is strong enough to guide an agent effectively.

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 provide readOnlyHint and openWorldHint, so the safe read-only nature is disclosed. The description adds critical behavioral context by stating that weekends and public holidays are skipped, and that the holiday calendar is Japanese. This goes beyond the annotations, though it does not cover edge cases like starting date falling on a holiday or timezone handling.

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 single, grammatically complete sentence that front-loads the operation (Add or subtract) and then specifies the subject (Japanese business days) and behavior (skipping weekends and holidays). Every part of the sentence carries meaning, with zero 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 only 2 simple parameters fully described in the schema, the description provides sufficient context for the tool's core purpose and behavior. No output schema exists, but the return value (a shifted date) is easily inferred from the tool name and description. The tool is self-contained and does not require additional explanation.

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%: both parameters have clear descriptions ('Start date, YYYY-MM-DD' and 'Business days to add (-3650 to 3650); negative subtracts'). The tool description adds no additional meaning beyond the schema, so the baseline of 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?

Description clearly states a specific verb+resource: 'Add (or subtract) a number of Japanese business days to a date'. It distinguishes from sibling tools like holiday_business_days_between by focusing on shifting a date rather than counting days between dates. The scope (Japanese business days, skipping weekends/holidays) is explicit.

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 when to use the tool (when you need to shift a date by business days) but does not explicitly mention alternatives or exclusions. Sibling tools exist (e.g., holiday_business_days_between) but are not referenced, leaving the agent to infer the distinction based on the operation described.

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 readOnlyHint=true and openWorldHint=true, so the agent knows it is a safe read operation. The description adds a useful behavioral detail (inclusive of neither endpoint by default), but does not disclose what happens if dates are reversed or whether Japanese holidays/weekends are excluded, though the name implies it.

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 entire description is one sentence, front-loaded with the action and ending with a concise parenthetical about endpoint behavior. Every word earns its place; no fluff or redundancy.

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 simple read-only counting tool, the description captures the essential behavior and default inclusivity. The annotations cover safety, and the schema fully documents parameters. It could be improved by explicitly stating that Japanese holidays and weekends are excluded, but the name and phrase 'Japanese business days' largely carry that meaning.

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%, with both 'from' and 'to' clearly described as YYYY-MM-DD dates. The tool description adds minimal value beyond the schema, only reinforcing that these are the two endpoints, so the baseline of 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?

The description uses a specific verb ('Count') and resource ('Japanese business days between two dates'), making the action unmistakable. It also clarifies the endpoint inclusivity default, which distinguishes it from related holiday tools like holiday_is_holiday or holiday_add_business_days.

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 usage context is implied: the tool is for counting business days between a start and end date. However, it does not explicitly mention when to use it over alternatives, such as holiday_is_holiday for single-day checks or holiday_add_business_days for adding days.

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 readOnlyHint and openWorldHint, so the safety profile is known. The description adds the data source ('official Cabinet Office data'), which is useful context, but it does not describe the return format, error behavior, or timezone assumptions. With annotations covering the main safety traits, this is acceptable but not rich.

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 word contributes: it states the action, the input, the output categories, and the authoritative data source.

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 one-parameter classifier with good annotations and no output schema, the description is mostly complete: it explains what the tool does and its output categories. It could mention edge cases (e.g., holiday substitutions prior to 1973, timezone behavior), but these are not essential for a basic classification 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?

The schema fully describes the 'date' parameter format (YYYY-MM-DD), so baseline is 3. The description adds the meaning 'Japanese calendar date,' which implies the date is interpreted in the Japanese calendar/timezone—a semantic clarification not present in the 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 clearly states a specific action: classify a date. It names the resource (Japanese calendar date) and the output categories (public holiday, weekend, business day). This distinguishes it from sibling tools like holiday_list (which lists holidays) and holiday_add_business_days (which adds days).

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 usage is implied by the description—you use this when you need to classify a single date. However, there is no explicit guidance on when to choose this over related tools like holiday_list or the business-day helpers, nor any mention of alternatives or exclusions.

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 readOnlyHint=true and openWorldHint=true, so the description's 'List' operation is consistent. The description adds the year-scoping constraint, but it does not disclose the return format, ordering, or behavior for invalid years. It adds minimal context beyond 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.

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

The description is a single concise sentence that front-loads the verb and core purpose. Every word contributes to clarity, and there is no filler or redundancy.

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 simple tool with one required parameter and no output schema, the description adequately conveys what the tool does. It could specify the return contents (e.g., holiday names and dates) or mention that it returns only national holidays, but the description is sufficient for a straightforward list operation.

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% for the single parameter 'year' with a description of 'Four-digit year.' The tool description merely reiterates that holidays are listed 'for a given year' without adding new semantic details about the parameter format, range, or examples.

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 'List all Japanese public holidays for a given year' uses a specific verb ('List') and resource ('Japanese public holidays') with a clear scope ('for a given year'), which distinguishes it from sibling tools like holiday_is_holiday (checks a specific date) and holiday_add_business_days (calculates date offsets).

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 that this tool is for retrieving all holidays for a year but does not explicitly state when to use it over alternatives such as holiday_is_holiday or holiday_business_days_between. No exclusions are mentioned, but the usage context is clear from the wording.

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 readOnlyHint=true, so the safety profile is covered. The description adds the data source (National Tax Agency registry) and the 'one' result constraint, which are useful, but it does not mention behavior for missing numbers or output format.

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 single 20-word sentence, front-loaded with the verb 'Look up', and every word is meaningful. It is compact and well-structured.

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 simple single-parameter lookup tool with no output schema, the description is adequate: it states the scope, the data source, and the lookup mechanism. It could benefit from noting not-found behavior or return fields, but these are not critical for the basic use case.

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 input schema already describes the 'number' parameter with 100% coverage as 'A 13-digit Japanese corporate number.' The tool description repeats the same format and adds the Japanese term 法人番号, but provides no additional semantic detail beyond the 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 clearly states the action ('Look up'), the specific resource ('one Japanese corporation'), and the exact lookup key ('13-digit corporate number'). This distinguishes it from sibling tools like houjin_search (likely multi-result search) and houjin_verify (verification).

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 usage context is implied: use this when you have a 13-digit corporate number. However, the description does not explicitly name alternatives or state when not to use it, leaving the agent to infer selection relative to sibling tools.

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 readOnlyHint and openWorldHint, and the description adds valuable context: the $0.25 cost, the composite nature, and the dataset vintage. This goes beyond the annotations without contradicting them, though it doesn't detail error handling or response format.

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 two tight sentences that front-load the core purpose and list contents. Every clause adds value, with no fluff or repetition of structured fields.

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 tool with no output schema, the description does a good job of enumerating the returned data (registry, status, readings, risk flags, summary, vintage), along with inputs and cost. It lacks mention of possible failure modes, but overall it is quite complete for decision-making.

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 each parameter has a clear description in the schema. The tool description only repeats that a number or name is accepted, adding no new semantics beyond what the schema already provides. Baseline of 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 clearly states the tool's function: a one-call KYB report on a Japanese corporation with a specific list of included data (registry, lifecycle, readings, risk flags, summary, vintage). It distinguishes from sibling tools by positioning itself as a composite that replaces 3-4 separate 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?

It explicitly says it accepts a corporate number or company name, and notes it's a premium composite replacing multiple lookups, implying it should be used when a comprehensive report is needed. However, it does not explicitly mention when not to use it or compare to alternative sibling tools.

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 readOnlyHint=true and openWorldHint=true, so the safety profile is known. The description adds a useful behavioral detail about matching both Japanese and registered English names, but does not disclose return format, pagination, or other behavioral traits. It provides moderate value beyond annotations.

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 single, front-loaded sentence that immediately states the tool's purpose. It is concise with no wasted words, and the key information is easily scannable.

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 search tool with good annotations and well-documented schema, the description provides sufficient context. It does not explain what the response looks like (no output schema), but for a search tool the agent can reasonably expect a list of matches. The absence of explicit return details is a minor gap given the tool's simplicity.

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 is 3. The description adds semantic value by explicitly mentioning that name matches Japanese and registered English names, which is not captured in the schema's parameter description for 'name'. This helps the agent understand acceptable inputs for the name parameter.

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 'Search' and the resource 'Japanese corporate registry', and specifies search criteria ('by trade name and/or location'). This distinguishes it from sibling tools like houjin_corporation, which likely retrieves a specific corporation, and houjin_verify, which verifies.

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 provides clear context for when to use this tool: searching by trade name and/or location. It does not explicitly mention alternatives or when not to use it, but the criteria are sufficiently clear. The mention of 'Japanese and registered English names' further guides usage.

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 readOnlyHint and openWorldHint annotations, the description discloses that results are probabilistic ('most likely'), includes a confidence score, and that closed/dissolved companies are reported as not verified. This provides meaningful behavioral context without contradicting 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.

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

The description is two sentences, front-loaded with the core purpose and followed by one important edge-case note. Every word contributes meaning with no redundancy.

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 tool with two simple parameters and good annotations, the description covers the return value (corporate number + confidence) and a key edge case (closed/dissolved). It does not mention behavior when no match is found, but this is a minor gap given the tool's simplicity.

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%, with both 'name' and 'address' already documented, including the fact that address improves matching. The description adds no additional parameter-level detail, so it meets the baseline for fully schema-covered parameters.

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 tool performs name-matching (名寄せ) of a company name and location against the Japanese corporate registry, returning a corporate number and confidence score. It also adds a distinctive caveat about closed/dissolved companies, helping differentiate it from sibling houjin 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?

The description implies a clear use case: verifying a company's identity to obtain its corporate number. It does not explicitly mention when to use this tool instead of alternatives like houjin_search or houjin_corporation, but the focused name-matching context is sufficient for basic guidance.

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 readOnlyHint=true, so the safe-read behavior is known. The description adds value by disclosing that routes are ranked and delay-aware, but it does not explain how rankings are computed, data sources, or response structure. This is comparable to the get_calls example and merits a 3.

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 single, focused sentence that front-loads the action and key qualifiers ('delay-aware,' 'ranked'). Every word contributes meaning without redundancy or fluff.

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 only two required string parameters, high schema coverage, and no output schema, the description provides sufficient context for an agent to invoke the tool. It implies the return is a ranked list of routes, which covers the primary output need, though it omits details on result format or data freshness.

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% with clear definitions for 'from' and 'to' (origin and destination station names). The description does not add additional parameter-level meaning, so the 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?

The description uses a specific verb ('Suggest') with a clear resource ('alternative routes for Japanese train travel') and adds differentiating details like 'delay-aware' and 'ranked routes that avoid currently-disrupted lines.' This clearly distinguishes it from sibling tools such as transit_route_plan, which presumably provides standard route planning.

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 usage context by noting routes avoid 'currently-disrupted lines' and are 'delay-aware,' which signals when this tool is appropriate. However, it does not explicitly mention when not to use it or name alternatives like transit_route_plan, so it falls short of a 5.

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?

The annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the 'current' qualifier, indicating real-time data, but does not disclose details about disruption types, severity, or response structure. With annotations present, this is acceptable but minimal.

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 single concise sentence that directly states the tool's purpose. No filler or redundant 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 one-parameter read-only tool, the description sufficiently conveys the scope (current disruptions on a specific line) and the input domain (Japanese train lines). While there is no output schema, 'current service disruptions' hints at the response content. Slightly more detail about disruption categories or severity would improve completeness, but it is adequate for the tool's simplicity.

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 single parameter 'line' has full schema coverage with an example ('jr-east-yamanote') and reference to transit_lines. The description adds no additional parameter-specific meaning, so the baseline of 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?

The description clearly identifies the tool's function: retrieving current service disruptions for a specific Japanese train line. It distinguishes itself from sibling tools like transit_station_status and transit_alternative_routes by focusing on disruptions, though it lacks an explicit verb like 'list' or 'retrieve'.

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 provides no guidance on when to use this tool versus the many transit siblings (e.g., transit_route_plan, transit_alternative_routes, transit_station_status). No mention of alternatives, prerequisites, or typical use cases.

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 readOnlyHint=true and openWorldHint=true, covering safety and non-exhaustive nature. The description adds 'canonical ids' as useful context, indicating the output is a set of identifiers, but it does not describe the response structure or further limitations beyond what annotations provide.

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 short, front-loaded sentences with no filler. The phrase 'Directory of...' immediately conveys the resource, and the second sentence gives a direct action. Every word earns its place.

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?

Given the tool's simplicity (no parameters, read-only), the description covers the core purpose and usage effectively. Without an output schema, it could mention the response format (e.g., list of lines with IDs), but the current text is adequate for discovering line identifiers.

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 has 0 parameters, so the schema provides no parameter details. According to the baseline for 0-parameter tools, a score of 4 is appropriate; the description does not need to explain parameters.

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 identifies the tool as a directory of Japanese rail operators and lines with canonical IDs, and explicitly states its purpose: to discover valid line identifiers. This distinguishes it from sibling tools like transit_line_disruptions or transit_route_plan, which focus on status or routing.

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 provides a clear usage context ('Use to discover valid line identifiers'), implying this is the reference/lookup tool among transit siblings. However, it does not explicitly mention when not to use it or name alternative tools for related needs, such as station lookup.

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?

With readOnlyHint and openWorldHint annotations, the safety profile is already disclosed. The description adds value by specifying the route includes transfers, duration, and fare. It does not disclose any side effects or limitations, but given the annotation coverage, it adds appropriate context.

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?

One concise sentence that states the action and key outputs without fluff, front-loaded with the verb 'Plan'.

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 simple two-parameter tool with no output schema, the description adequately specifies what the tool returns (transfers, duration, fare) and the input scope (Japanese train stations). However, it doesn't mention error handling for unknown stations or whether the route is optimal, but for a tool of this simplicity, the description is nearly complete.

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 input schema fully documents both parameters with 'Origin station name' and 'Destination station name' (100% coverage). The description adds the stipulation that these are Japanese train stations, providing a small increment of meaning beyond the schema. At baseline 3 due to high schema coverage, the minor addition still merits 3.

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 uses a specific verb 'Plan' and resource 'route between two Japanese train stations', and lists expected outputs (transfers, duration, fare). It clearly distinguishes from sibling tools like transit_station_status and transit_stations_search. However, it does not explicitly differentiate from transit_alternative_routes, which also plans routes.

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 the tool is used to plan a route between two stations, but it provides no guidance on when to prefer this tool over transit_alternative_routes or how to handle station name validation (e.g., using transit_stations_search). No exclusions or alternatives are mentioned.

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 readOnlyHint and openWorldHint, and the description adds behavior beyond that by disclosing fuzzy matching and the acceptance of kanji/kana/romaji. This gives useful context without over-explaining, though it doesn't mention return format or edge cases.

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 single, front-loaded sentence with no filler. It communicates the essential purpose and input constraints efficiently, earning a top score.

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?

Given the tool's simplicity (one required parameter, no output schema, read-only and open-world annotations), the description is fully adequate. It tells the agent what the tool does, what input it accepts, and what to expect in terms of behavior.

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 parameter q has full schema coverage with a baseline description ('Search query, at least 2 characters'). The tool description augments this by clarifying that the query supports kanji, kana, or romaji, which provides deeper meaning than the schema alone.

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 uses a specific verb ('Fuzzy-search') and a well-defined resource ('Japanese train stations by name'), while also specifying accepted input formats (kanji, kana, or romaji). This clearly distinguishes it from sibling tools like transit_station_status or transit_lines by focusing on the search capability.

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 provides clear context for when to use the tool—whenever you need to find a Japanese train station by name with fuzzy matching. It does not explicitly state exclusions or alternatives, but the sibling tools are distinct enough that the intended usage is obvious.

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 indicate read-only and open-world; description adds source (ODPT) and output characteristics (per line, bilingual summary), but doesn't discuss rate limits or error behavior. This aligns with the annotation hints.

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 concise sentences, no filler, all information relevant to the tool's purpose and source.

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 a simple single-parameter input and read-only annotations, the description sufficiently conveys the tool's purpose and output type, though exact response fields are unspecified.

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 fully describes the 'name' parameter (station name in kanji, kana, or romaji), so description adds no additional parameter semantics beyond that coverage.

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?

Description clearly identifies the tool as providing real-time delay and operational status for a station per line, with bilingual summary. It distinguishes itself from sibling tools like transit_line_disruptions by focusing on station-level status rather than line-wide disruptions.

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?

Description gives clear context that this is for querying station status in Japan, but doesn't explicitly mention when to use it over alternatives like transit_line_disruptions or transit_stations_search. No exclusions are provided.

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 readOnlyHint=true and openWorldHint=true, so the safety and open-world behavior are covered. The description adds useful context about the relationship to weather tools and the nature of the data (valid codes and names), which complements the annotations without contradicting them.

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 single, front-loaded sentence that conveys the tool's purpose and scope with no filler. Every word earns its place, and it is appropriately concise for such a simple tool.

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?

Given the tool's simplicity, the lack of parameters, and the presence of annotations, the description fully covers what the agent needs to know: it lists JMA region codes and names that are valid for weather tools. No output schema is needed because the description states the output contents clearly.

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 has zero parameters with an empty input schema, so there is no parameter documentation burden. Per the baseline for zero-parameter tools, a score of 4 is appropriate because there is nothing to explain beyond what the schema already shows.

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 tool's function: listing valid JMA region codes and names used by weather tools. It uses a specific verb ('List') and a concrete resource, and it distinguishes itself from sibling weather tools by being the reference for accepted region identifiers.

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 when to use this tool: before calling weather tools that require JMA region codes. It clearly says the codes are 'accepted by the weather tools,' giving enough context without needing explicit when-not-to-use guidance for such a simple reference tool.

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 mark this as read-only and open-world, so the bar is lower. The description adds behavioral context by disclosing the forecast time horizons (today, near-term, 7-day) and the data source (JMA), which goes beyond the annotation information.

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 single, tightly packed sentence that front-loads the purpose and includes content scope and source. Every element earns its place with no wasted words.

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 simple one-parameter tool with read-only annotations and no output schema, the description is sufficiently complete. It covers what the tool returns and the source, though it does not describe return formatting or possible area input syntax—those are delegated to the schema.

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 input schema already fully describes the 'area' parameter as a JMA office code or Japanese/English region name (100% coverage). The description only repeats 'region' without adding extra meaning, meeting the baseline for high schema coverage.

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 tool provides a Japanese weather forecast for a region, including today's conditions, near-term outlook, and a 7-day forecast. It implicitly distinguishes itself from sibling tools like weather_warnings and weather_areas by focusing on forecast content, though it lacks a direct verb like 'returns' or 'provides'.

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 usage for obtaining weather forecasts but does not explicitly state when to use this tool over alternatives such as weather_warnings or weather_areas. No exclusions or alternative tool references are provided.

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 readOnlyHint=true and openWorldHint=true. The description adds valuable context by specifying data source ('from the JMA') and 'Active' status, clarifying that only currently active warnings are returned. This goes beyond annotation details while not contradicting them.

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 single concise sentence with no redundant words. Every word contributes meaning (active, Japanese, weather warnings/advisories, region, JMA). Front-loaded and efficient.

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 simple one-parameter, read-only tool with no output schema, the description effectively covers purpose and scope. It could mention behavior when no warnings exist or how to interpret the output, but the combination of description and schema is sufficient for basic invocation.

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 provides 100% coverage for the single parameter 'area' with a clear description ('A JMA office code or region name.'). The tool description only mentions 'for a region' which adds no meaning beyond the schema. 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?

The description clearly states it returns active Japanese weather warnings and advisories for a region from the JMA. It uses a specific verb/resource combination and is easily distinguished from sibling tools like weather_forecast and weather_areas.

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 use for checking current warnings/advisories but does not explicitly state when to prefer it over alternatives like weather_forecast, nor does it mention any exclusions or specific conditions. Guidance is only implicit via the term 'warnings and advisories'.

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