Server Quality Checklist

Tool Scores

• get_municipality_grantsB
  3.4/5.0
  Behavior3/5

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

  No annotations are present, so the description carries the full burden. It indicates a read operation ('List') and adds 'Free' and coverage context, but it does not disclose output format, pagination behavior, error handling, or rate limits. The coverage claim adds some value but lacks operational detail.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

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

  The description is two sentences with the core purpose front-loaded in the first sentence. The second sentence adds the J-Grants differentiator and 'Free', which are somewhat extraneous but still concise. It earns a high score for efficiency, though the source comparison is not strictly necessary for tool selection.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter list tool with no output schema and no annotations, the description provides the essential municipality code semantics and coverage notes. Yet it omits limit behavior, return structure, and usage guidance relative to sibling tools, leaving the context incomplete for an agent deciding among multiple list/search tools.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description explains municipality_code with a format example and JIS standard, adding meaning beyond the schema regex. However, the optional limit parameter is not mentioned, and schema coverage is only 50%, so the description only partially compensates. The agent can infer limit from its name and constraints, but the description adds nothing about its use.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('List all subsidies') and resource ('for a specific municipality') with a precise JIS X 0402 6-digit code example. It is specific enough to distinguish from get_subsidy_detail, though it does not explicitly reference sibling tools. The J-Grants differentiator adds extra context but is not about sibling distinction.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The use case is implied: use when you need all subsidies for a specific municipality. However, the description does not provide explicit when/when-not guidance or mention alternatives like search_subsidies or compare_municipal_subsidies. The J-Grants comparison is about data source coverage, not usage conditions.

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

• search_auctionsB
  3.4/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It does mention 'Free' and lists return fields (case_id, court, address, etc.), adding some transparency. However, it does not state whether the operation is read-only, describe pagination behavior, or disclose any limitations like data freshness or rate limits.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

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

  The description is a single well-organized block that front-loads the purpose, then lists filters and return fields. It contains no filler or repetition, and efficiently packs useful information into a compact structure.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  There is no output schema, so the description appropriately lists return fields. However, it fails to explain important aspects like default sorting, pagination, meaning of court_code, and how status affects results. With 11 parameters and no required fields, the description is adequate but not complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description adds meaning for several parameters: prefecture (with example 東京都), property_type (with enum values), price range, and bid_period_only. However, it omits other parameters like status, keyword, sort, limit, and offset. Since schema coverage is only 36% and the description does not fully compensate, the parameter semantics are partially helpful but incomplete.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool searches Japanese court real-estate auctions using BIT data, with a specific verb and resource. It explicitly distinguishes itself from the subsidies module, but does not differentiate from sibling auction tools like get_auction_detail or list_upcoming_sales, so it falls short of a perfect score.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides one explicit exclusion ('Distinct from the subsidies module above'), but does not offer guidance on when to use this tool versus other auction-related siblings such as get_auction_detail or list_upcoming_sales. The usage context is implied rather than fully spelled out.

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

• search_subsidiesA
  3.5/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the burden. It adds valuable traits such as being a free tool and the default limit behavior, but it omits other behavioral details like sorting behavior, pagination via offset, or the open_only filter. This is moderate disclosure, not comprehensive.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  Two sentences, front-loaded with the primary action, and every phrase adds information (scope, filters, limit, free). No redundant or filler content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 9-parameter tool with no annotations and no output schema, the description is adequate but not complete. It explains the core search behavior and main filters, but it does not address result ordering, pagination, or how to handle no filters. Sibling differentiation is also missing, which is important given the large toolset.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is only 44%, so the description must compensate. It names four key filters (keyword, prefecture, category, minimum amount) and clarifies the limit default, adding meaning beyond the schema. However, it leaves several parameters like sort, offset, and municipality_code unexplained, so it only partially bridges the low coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool searches Japanese central and municipal subsidies with a specific verb and resource. It distinguishes the general search scope but does not explicitly differentiate it from sibling tools like get_municipality_grants or find_supplementary_grants, so it misses the top score.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives useful usage context—filters can be combined, and results are capped by the limit parameter with a default. However, it does not provide explicit guidance on when to choose this tool over alternatives or any exclusions, so it falls short of strong usage guidance.

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

• subscribe_changesA
  3.8/5.0
  Behavior4/5

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

  No annotations are present, so the description carries the full burden. It goes beyond basic operation by disclosing the $0.20 USDC cost, x402 payment method, and the structured 402 response on payment failure or missing capability. This is valuable behavioral context, though it omits subscription management and event payload details.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  The description is concise, with two sentences that front-load the core action and then add cost and error handling details. Every sentence earns its place without unnecessary fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a subscription tool with no output schema, the description lacks return value info, cancellation instructions, and event payload format. It does address cost and error handling, but important operational aspects are missing, making it incomplete for a medium-complexity tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is only 50%, with 'filter' and 'ttl_days' lacking schema descriptions. The description mentions 'matching a filter' but does not elaborate on filter fields or explain 'ttl_days', thus failing to compensate for the low coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'Create a webhook subscription that pushes grant-change events matching a filter.' It uses a specific verb and resource, and distinctly differentiates from sibling read/search tools by introducing a subscription mechanism.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for receiving push notifications of grant changes, but it does not explicitly state when to use it over alternatives or when not to use it. No exclusions or comparisons to sibling tools are provided.

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

• find_practitionerA
  3.9/5.0
  Behavior4/5

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

  No annotations are provided, so the description must carry the full burden. It discloses the output (association registry URLs and a LocalGov.jp referral landing URL) and includes a BETA note about vetted profiles, which adds context about maturity. It does not describe any side effects, but as a recommendation tool, the behavior is sufficiently transparent.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  The description is three concise sentences, front-loaded with the main action (Recommend 3 practitioners), followed by output details and a BETA caveat. Every sentence adds value with no redundancy or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description helpfully states exactly what is returned (registry URLs and landing URL). It covers the tool's core purpose and output for a simple 2-parameter tool. It lacks explicit guidance on how or when to use it relative to sibling tools, but the BETA note adds useful context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is only 50% (grant_id lacks a description, industry_hint has one). The description does not explain grant_id format or provide examples, and it omits industry_hint entirely. It mentions 'grant's category and amount tier' which hints at grant_id's role but does not add substantive parameter-level meaning.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Recommend' and identifies the target resource: 3 Japanese licensed practitioners (行政書士, 税理士, 中小企業診断士, 社会保険労務士). It also states the matching criteria (grant's category and amount tier), which distinguishes it from sibling tool find_practitioner_for_auction that targets auctions.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies this tool is for grants via 'matched to the grant's category and amount tier', but it does not explicitly state when to use it over alternatives like find_practitioner_for_auction. No exclusions or alternative references are provided, leaving usage context somewhat implicit.

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

• find_supplementary_grantsA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of behavioral disclosure. It provides useful details: 'Heuristic: matches base title tokens', 'Returns up to 30', and 'Free'. However, it does not state whether it's read-only, how data is sourced, or what the response structure looks like, leaving some gaps.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  The description is extremely concise: three short sentences plus 'Free'. It front-loads the primary purpose, then adds heuristic and output limit details. Every word contributes value, with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given its simplicity (3 params, no output schema) and no annotations, the description covers the essential context: purpose, matching logic, and result limit. It lacks explicit output format and error conditions, but for a straightforward search tool, this is nearly complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 67% (central_grant_id and prefecture have descriptions; limit does not). The description adds an example for central_grant_id and the 'Returns up to 30' note relates to limit behavior. Yet it does not systematically explain parameters beyond the schema, so it meets the baseline but adds little extra.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'search for municipal grants that supplement [a central J-Grants subsidy id]'. The verb 'search' and the specific resource (supplementary municipal grants) distinguish it from sibling tools like get_municipality_grants or search_subsidies. The example with national and city-level program names further clarifies the intent.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  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 have a central grant id and want municipal supplements. The 'Heuristic' note signals approximate matching, setting expectations. However, it does not explicitly mention alternatives or exclusions, 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.

• get_subsidy_detailA
  4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the transparency burden. It discloses return contents (title, summary, eligibility, etc.), distinguishes source_url vs. _source, instructs the agent to cite _source, and notes the tool is 'Free.' This adds meaningful behavioral context beyond a simple fetch, though it does not discuss error handling or rate limits.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  The description is two sentences with no wasted words. It front-loads the action, lists the returned fields efficiently, and includes the citation and cost note in a compact second sentence.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (one parameter, no output schema, no annotations), the description is reasonably complete. It specifies the resource type, id format is covered by the schema, and it enumerates the returned fields so the agent knows what to expect. Minor gaps include no mention of error behavior or output structure, but the description suffices for this straightforward fetch.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides 100% coverage of the single 'id' parameter, including examples and format. The description adds no additional parameter-specific meaning beyond referencing 'by id', so it does not exceed the baseline of 3 where the schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific verb ('Fetch') and resource ('full record for a single subsidy by id'), immediately distinguishing it from sibling tools like search_subsidies or get_municipality_grants. The action is unambiguous and the scope (single record) is explicit.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The usage is implied: you need an id to fetch a detail, and the description lists return fields, suggesting this tool provides full detail. However, there is no explicit guidance on when to use this versus search_subsidies or other siblings, nor any exclusions or prerequisites mentioned.

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

• list_upcoming_salesA
  4/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden. It discloses the time window (default 14, max 90), sorted ascending order, and forward-looking scope. It does not mention response format or pagination, but the core behavior is transparent enough for a read-only list tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  Two sentences, front-loaded with the verb 'List', includes essential details (time window, sorting, use cases). No filler or redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  No output schema exists, so the description must explain what the returned list contains. It only mentions sorting and time window, omitting response fields, pagination behavior, or any filtering side effects. This is inadequate for a tool with no structured output definition.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema descriptions cover both parameters (limit, days_ahead) with defaults and constraints at 100% coverage. The description only repeats days_ahead defaults and max, adding no additional meaning beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description clearly states the tool lists auctions whose opening_date falls within the next N days, with a specific verb and resource. It distinguishes from sibling search_auctions by focusing on upcoming sales and mentions sorting and default/max values.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides clear context for when to use the tool (investment screening, calendar exports) but does not explicitly exclude alternatives or name sibling tools. The use-case hints are sufficient for a basic list operation.

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

• compare_municipal_subsidiesA
  4.2/5.0
  Behavior4/5

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

  No annotations are present, so the description carries the full burden. It adds useful behavioral details: returns 5-10 nearby municipalities, currently same-prefecture, and is free. It does not disclose the output structure or error behavior, but for a read-only comparison tool, this is adequate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  Two sentences, front-loaded with the main purpose, and all information is relevant. No waste.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema and no annotations, the description covers the main purpose, the required parameter, and key constraints (same-prefecture, free). It does not mention optional parameters except implicitly, but the schema covers those. Overall, it's reasonably complete for an agent to invoke.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is only 33% (only category has a description). The description adds that an anchor municipality_code is required and that categories are what get compared, but it does not explain max_municipalities at all. The stated '5-10' range also conflicts with the schema's max of 20, so it adds limited value.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb+resource: 'Compare same-category subsidies across nearby municipalities.' It clearly distinguishes this from sibling tools like search_subsidies by focusing on same-category comparisons across nearby places rather than general search.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description notes it is 'useful for relocation / siting decisions,' providing a concrete context. However, it doesn't explicitly state when not to use it or mention alternatives like get_subsidy_detail, so it lacks exclusions.

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

• get_court_directoryA
  4.2/5.0
  Behavior4/5

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

  Without annotations, the description carries the burden of disclosing behavior. It does so by specifying the exact output fields: name, prefecture, parent court, inquiry phone, and BIT search URL. It also discloses a constraint: brand isolation, i.e., the tool is isolated and should not be mixed with subsidies. For a simple lookup tool, this is adequate transparency about what the agent can expect.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  The description is two concise sentences: the first states the purpose in Japanese, the second in English, followed by return details and a brief isolation warning. Every sentence adds value, and there is no redundant or filler content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a one-param lookup tool with no output schema, the description covers the purpose, parameter type (via schema), output fields, and an important usage constraint. It does not explain error behavior or exhaustive edge cases, but that is not necessary for a straightforward directory lookup. It is complete enough for an agent to invoke confidently.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides full coverage (100%) for the single parameter, including examples of both accepted formats (slug and BIT ID). The description's mention of 'by code' adds no new semantics beyond the schema. Per the rubric, baseline is 3 when schema coverage is high, and the description does not need to compensate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: looking up a Japanese district court by code and returning contact/jurisdiction information. It enumerates specific return fields (name, prefecture, parent court, phone, BIT URL), and it is distinct from all sibling tools, which are subsidies, auctions, and practitioner lookups. The verb 'look up' plus the resource 'Japanese district court' gives a precise purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description does not explicitly enumerate alternative tools, but it gives a clear when-not-to-use signal with 'Brand-isolated; do not mix with the subsidies module.' Since no sibling tool performs court lookups, this warning effectively tells the agent that this tool is exclusively for court directory data and not to be confused with the subsidy-related tools. This is sufficient guidance for selection.

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

• get_auction_detailA
  4.3/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It discloses that the tool is free, returns a specific set of fields, includes a computed field (bid_floor_jpy = base × 80%), and provides _canonical for citation. It does not cover error behavior or rate limits, but gives solid behavioral context for a simple fetch operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  The description is compact and information-dense, with a list of return fields and important notes (free, brand isolation). The bilingual content is slight redundancy, but every sentence and clause carries value; there is no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given a single parameter and no output schema, the description fully explains what will be returned, including field names, a computed field, a citation instruction, and the tool's scope. It is sufficient for an agent to invoke the tool and interpret the result, with no major missing details.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% (the schema already describes case_id with an example). The description adds the same example and clarifies the usage context, but does not add meaningful new semantics beyond what the schema provides, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool fetches one auction by case_id, with a concrete example ('bit_00000078922') and a list of returned fields. It distinguishes itself from siblings like search_auctions and get_subsidy_detail by specifying 'one auction' and 'Brand-isolated from the subsidies module'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It implies usage for retrieving details of a single known auction by case_id, and notes it is free and independent of the subsidies module. However, it does not explicitly mention that search_auctions should be used to find case_ids or state when not to use this tool, leaving a small gap.

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

• find_practitioner_for_auctionA
  4.6/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden and does well: it discloses the return cardinality ('2-3 practitioner federation directories'), the information-only nature, the default stage, and stage-specific legal context such as 司法書士 being almost legally required. It falls short of describing the exact result structure or edge cases like no results found.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

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

  The description is dense but efficient: it front-loads the purpose, packs the stage list with meanings, and adds a crucial sibling-disambiguation warning in a single compact paragraph. Slightly verbose due to bilingual repetition, but every sentence contributes useful information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given no output schema and no annotations, the description compensates by explaining return count, stage contexts, legal implications, and the distinction from a related tool. It does not clarify the exact output fields or how the optional prefecture parameter affects results, which leaves minor ambiguity for the agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Although the schema already covers all three parameters, the description adds substantial meaning to the 'stage' enum by explaining each value in domain terms (e.g., post_acquisition means ownership transfer registration, eviction means 明渡し・強制執行). It also clarifies the default behavior, going well beyond the raw schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns practitioner federation directories for auction-related stages and lists the specific professions (司法書士, 弁護士, 不動産鑑定士, 土地家屋調査士). It distinguishes from the sibling 'find_practitioner' by its auction context and explicitly warns against combining outputs.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly enumerates the four stages and their use cases, provides a default stage, and gives a clear when-not instruction ('Do not combine the result of this tool with output from find_practitioner'). It also clarifies the tool is information-only, not a paid intermediary, which helps the agent set expectations.

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

• verify_receiptA
  4.6/5.0
  Behavior5/5

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

  With no annotations provided, the description carries full burden and does an excellent job: it discloses local crypto, no network, the signature verification against LocalGov.jp pubkey, expiration check, and the live pubkey fetch fallback. This goes well beyond the schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  Two sentences, front-loaded with purpose, no filler. Every detail (crypto type, network behavior, pubkey fallback) earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is thorough for a verification tool, but because no output schema exists, it should mention the return value or failure behavior. Otherwise the tool's result is left ambiguous.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, but the description adds meaning by explaining the 'pubkey' omission triggers a live fetch, and by contextualizing the receipt as an Ed25519-signed envelope.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool verifies an Ed25519-signed citation receipt from a specific API endpoint. It also specifies the two checks (signature and expiration), making the purpose unambiguous and distinct from all unrelated sibling tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for verifying receipts previously issued by /api/cite/:grant_id and explains the optional pubkey behavior. It lacks explicit when-not guidance or alternatives, but the sibling context makes confusion unlikely.

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