補助金AI

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

The annotations already mark the tool as read-only, idempotent, and non-destructive; the description adds meaningful behavior beyond that: inputs and results are not saved, English status is internal-only, user-facing output must use statusLabel/summary/professionalConsultation, and unverifiable facts must not be guessed. No contradiction with 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 dense but every sentence carries distinct operational value: purpose, input sourcing, confirmation rules, output language, and non-retention. It is front-loaded with the core purpose and contains no filler.

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

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

For a tool with a complex nested schema and no output schema, the description covers the essential invocation details: provenance, output field usage, and privacy behavior. It omits a concrete output example or possible status values, but these are largely inferable from the schema and context.

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 only 33%, so the description compensates by explaining when to populate single_large_owner_percent and related fields (only when the shareholder is confirmed to be a large enterprise under the program) and by forbidding guesses for taxable income and officer overlap. It does not detail every nested field, but it covers the most error-prone semantics.

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 names a specific verb and resource: it cross-checks the official treatment of 'deemed large enterprises' against EDINET-verified capital relationships, and distinguishes allowed, excluded, and conditional cases. It does not explicitly name sibling tools, so differentiation is implicit rather than 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?

It clearly states that the tool applies to candidate subsidies and gives strong input-provenance guidance: program_rule must come from the latest official guidelines/FAQ, with source_url and checked_at. It does not list exclusion conditions or alternative tools, but the context is clear enough for correct selection.

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 discloses important behavioral traits beyond annotations: it may overwrite existing estimates for a specified public recruitment round, and it stops calculation under certain eligibility statuses. The annotations already indicate destructiveHint=true, and the description adds specific context about what gets overwritten and when. It could further clarify the exact nature of the overwrite (e.g., irreversible) but the current disclosure is solid.

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 dense paragraph in Japanese, covering purpose, exclusions, stopping conditions, input constraints, and side effects. It is information-dense but not structured with separators or bullet points. Every sentence earns its place, but the lack of structural breaks makes it harder to parse quickly. Slightly above average due to high information density.

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 complexity (7 params, destructive side effect, no output schema), the description covers the key decision points: when to stop, what inputs are safe, and how to avoid overwriting. However, it does not describe the output format or methodology version details, and the meaning of several parameters remains implicit. The absence of an output schema increases the burden, but the description still provides enough for an agent to call it correctly in most cases.

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 only 14%, so the description must compensate for undocumented parameters. The description explains the role of target_jgrants_subsidy_id (save to D1 and overwrite) and mentions budget/scope changes as inputs, but it does not explain program_series_key, eligibility_status, program_continuity, target_scope_change, budget_change_percent, or maximum_grant_change_percent in detail. The enum values for eligibility_status are self-explanatory, but the numeric parameters lack context. This is a partial compensation, not full.

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: it estimates the overall program selection outlook using up to 3 past official selection results from the same program series, using explainable rules. It also explicitly distinguishes itself from individual company selection probability. However, it does not explicitly differentiate from sibling tools like evaluate_subsidy_fit, though the unique focus on program-level outlook and saving to D1 provides some distinction.

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 explicit usage conditions: it must stop calculation if eligibility is uncertain/conditional/likely ineligible, and it instructs to only input budget/scope changes when verifiable from official materials. It also gives clear guidance on when to omit target_jgrants_subsidy_id to avoid overwriting existing estimates. This is strong when-to-use and when-not-to-use 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?

The description adds genuine value beyond the annotations: it discloses that assessment.status is internal-only, that English codes must be translated into statusLabel/summary/professionalConsultation for users, and that the tool must not definitively assert eligibility/selection. This aligns with openWorldHint=true via the 'unconfirmed items' notion and responseGuidance follow-through. No contradiction with annotations (readOnlyHint=false is consistent with an evaluative, non-read-only tool).

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

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

The core purpose is front-loaded in the first sentence, followed by essential output-formatting rules. It is dense — a single long paragraph — but every clause earns its place given the complex output requirements (internal vs user-facing fields, category separation, follow-up behavior). Slightly long, yet justified.

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

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

With no output schema, the description responsibly carries the burden of explaining the return contract: it names the key output fields (statusLabel, summary, professionalConsultation), the internal status, the evaluation categories, and directives about responseGuidance and re-confirming prerequisites. What's missing is differentiation from the near-duplicate sibling and clarification of company_profile semantics, leaving modest but real gaps.

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 50%: subsidy_id is well documented in the schema ('search_subsidies returned J-Grants subsidy ID'), but company_profile has no top-level description and its five nested fields carry only constraints, no meaning. The description maps generally to both params ('J-Grants details' and 'company profile') but does not elaborate on how fields like capital_yen, employee_count, or business_plans influence the evaluation, so it only partially compensates for the coverage gap.

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+resource: it matches a specified subsidy's J-Grants details against a company profile and returns explicit matches, non-matches, and unconfirmed items separately. The purpose is unambiguous. However, it does not differentiate from the near-identically named sibling evaluate_subsidy_fit_for_company, leaving an agent to guess how the two evaluate-subsidy tools differ.

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?

There is no explicit statement of when to use this tool versus an alternative. Notably, the sibling list includes evaluate_subsidy_fit_for_company and estimate_program_selection_outlook, yet the description never routes the agent between them. The only guidance is a negative constraint — 'not a tool that asserts eligibility or selection' — which clarifies what it cannot do but not when to select it.

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 discloses key behaviors beyond annotations: it supplements outdated public info with user input and returns sources/discrepancies, handles verification steps, instructs not to assert eligibility, and details how to format user-facing responses (e.g., not showing English codes). No contradiction with annotations (readOnlyHint=false, openWorldHint=true).

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 long but densely packed with actionable instructions, structured logically from core function to specific handling and output rules. Every sentence contributes to correct usage, though a slightly tighter wording could improve readability without losing content.

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 description is comprehensive: it covers data retrieval, supplementation, verification steps, output formatting, internal vs. user-facing fields, and response guidance. It also anticipates common pitfalls (e.g., not excluding based on capital relations alone) and directs to sibling tools, leaving no critical gap for an agent to call it correctly.

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

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

The input schema already covers 100% of parameters with descriptions. The description adds extra meaning by clarifying that user-specified values override public data (e.g., '指定時は公開法人情報より優先'), and explains the role of corporate_number. It does not deeply explain business_plans or edge cases, but the added context is valuable, so above baseline.

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

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

The description states a specific verb (retrieve and match) and resource (gBizINFO corporate profile against J-Grants subsidy conditions), clearly distinguishing it from siblings like get_company_profile or search_companies. It also names the input (corporate number and subsidy ID) and the action of evaluation.

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

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

It explicitly states when to use this tool (when you have a corporate number and subsidy ID) and gives conditional guidance: for SME requirements, use verify_corporate_relationship and assess_deemed_large_enterprise_eligibility for specific sub-steps. It also instructs on how to present results and follow responseGuidance, making the selection and invocation context clear.

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 read-only, idempotent, and non-destructive. The description adds valuable behavioral nuance: activityCount from name search is an aggregate, not type-specific; results separate type counts, acquisition failures, and discrepancies from the search API's reported counts. This prevents agent misinterpretation beyond what annotations convey.

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

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

The description is front-loaded with the primary purpose and maintains a logical progression: purpose, user-facing naming guidance, category list, and count caveats. It is appropriately dense, though the user-facing response instruction is a slight tangent from tool invocation.

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 moderate-complexity, read-only lookup tool with an output schema absent, the description covers the main return categories and the important count interpretation issue. It does not describe exact response structure or pagination, but the schema fills parameter behavior, leaving only minor gaps.

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 parameters are already well documented. The description reinforces the meaning of activity types and the aggregate count caveat, but it does not materially extend the schema's parameter explanations.

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 the action ('法人番号から...活動情報を取得します') and resource (gBizINFO activity information), then lists the eight activity categories. It is distinct from siblings like get_company_profile and search_subsidies in content, but it never explicitly names or contrasts the closest sibling alternatives.

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

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

Usage context is implied by 'corporate numberから...取得します' and the activity category list, but there is no explicit statement of when to prefer this tool over get_company_profile, search_companies, or subsidy-specific tools. No exclusions or alternative conditions are given.

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

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

Beyond the readOnly/openWorld/idempotent annotations, it discloses that activity information is deliberately returned as not_fetched due to completeness concerns, that unregistered fields must be null or empty arrays, and that statusAvailability=not_provided must not be used to assert corporate status.

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

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

The description is dense but every sentence earns its place: retrieval source, user-facing naming, returned fields, activity-data exclusion, sibling routing, and null/status handling. It is front-loaded with the primary action and then layers crucial caveats.

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

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

For a read-only profile tool with no output schema, the description covers the essential operational details: what is returned, what is explicitly not returned, when to delegate to a sibling, and how to handle missing or uncertain data. No critical calling behavior appears missing.

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

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

Schema description coverage is 100%, so the schema already documents corporate_number and activity_limit well. The description reinforces that activity_limit is deprecated and irrelevant, but does not add substantial new parameter semantics 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 states a specific verb and resource: retrieving public corporate basic information from METI's gBizINFO database using a corporate number. It explicitly distinguishes this tool from get_company_activities by stating which data belongs to each tool.

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 explicit routing guidance: activity-related data such as certifications, patents, and subsidies should use get_company_activities. It also clarifies that the activity_limit parameter exists only for backward compatibility and is not used here.

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, openWorldHint, idempotentHint, and destructiveHint=false. The description adds value beyond these by naming the data source (NTA), specifying the exact information retrieved, and disclosing the open-world caveat about closure data. It does not contradict annotations; it reinforces the openWorldHint with a concrete interpretation.

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

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

Three short sentences with no filler. The primary retrieval purpose is front-loaded, followed by the critical caveat, then the routing to get_company_profile. Every sentence earns its place and the structure aids quick comprehension.

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 no output schema, the description compensates by enumerating the returned data fields (formal name, location, closure info, exclusion info) and the required notice source and disclaimer. It also provides the key behavioral caveat and the relevant sibling alternative. For a one-parameter read-only tool, nothing essential is missing.

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

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

Schema description coverage is 0%, so the description bears the burden. It does add some meaning by connecting the parameter to the NTA corporate number inquiry, implying corporate_number is the 13-digit corporate identifier. However, it does not explicitly describe the parameter's format or semantics; the schema's pattern and parameter name already convey most of this. For a single self-explanatory parameter, this is minimally acceptable but not a strong contribution.

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 names a specific verb ('取得します' / retrieves), a concrete resource (国税庁の法人番号照会 / NTA corporate number inquiry), and the exact fields returned: latest official name, location, closure information, and search exclusion information. It also differentiates itself from get_company_profile by explicitly excluding capital and employee data, making sibling discrimination clear.

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 gives an explicit routing rule: for capital and employee counts, use get_company_profile instead. It also provides a critical usage instruction: absence of closure information must not be interpreted as the company being operational, and the notice's source and non-guarantee disclaimer must be shown to the user. This is actionable when-to-use and how-to-use 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 cover readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable behavior beyond those: officialRate may be null, the agent must not infer a rate from missing data, and user-facing labels must emphasize 'past official selection rate' rather than individual probability. This is meaningful context that prevents misuse.

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 main purpose is front-loaded in the first sentence, and the two following sentences each add an essential constraint about handling null rates and user-facing terminology. There is no fluff or repetition, and the structure is easy for an agent to parse.

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

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

For a read-only lookup with one parameter, the description covers the returned content (counts, selection count, official rate, supporting basis), the possibility of officialRate being null, and presentation rules. It does not specify the exact response shape or behavior when no record exists, but it is complete enough for correct invocation and basic interpretation.

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 0%, but the single parameter jgrants_subsidy_id is directly explained in the description as 'Jグランツ補助金ID', making its meaning clear. The description also clarifies that the data is stored and keyed by that ID. Format details are minimal, but with one required self-descriptive parameter this is sufficient.

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

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

The description states a specific verb ('返します') and a precise resource ('公募回別の公式申請件数・採択件数・公式採択率と根拠') scoped to a JGRANTS subsidy ID. Its read/statistics semantics clearly distinguish it from siblings like record_official_selection_statistics and estimate_program_selection_outlook without needing to name them.

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

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

The description gives clear behavioral constraints for presenting results ('officialRateがnullの場合は割合を推測しない', '個別企業の採択確率とは説明しない'), which guides correct use. However, it never explicitly states when to prefer this tool over alternatives such as estimate_program_selection_outlook, so tool-selection 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 provide safety hints (readOnlyHint, destructiveHint), and the description adds value beyond them by disclosing output boundaries: it returns per-round periods and document metadata but explicitly not Base64 document bodies. It also instructs checking official materials for rates and exceptions before estimation, adding workflow behavior not present in 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?

Three sentences front-load the core action and output scoping, with no redundant phrasing. The third sentence is dense but contains a useful verification instruction, so no sentence is wasted.

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

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

With one required parameter and no output schema, the description covers what is returned and the key non-return of Base64 documents, which is enough for correct invocation. It could be more specific about the response structure, but the low complexity and pipeline guidance make the definition adequately 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?

Schema coverage is 100% and describes the subsidy_id format, so the schema does most of the work. The description contributes the key source relationship: the ID must come from search_subsidies, which is meaningful beyond the format constraints.

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

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

The description states a specific verb and resource: it fetches the J-Grants detail API V2 using a subsidy ID returned by search_subsidies. It also distinguishes itself by naming what it returns (application periods, document metadata) and what it does not return (Base64 document bodies), separating it from sibling tools.

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

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

The description gives clear workflow context: use it after search_subsidies, with the ID that tool produced, and before estimating amounts. It does not explicitly list exclusions or alternative tools, but the intended position in the pipeline is evident.

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

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

Beyond the readOnly/idempotent annotations, the description adds substantial behavioral context: results are not saved or sent, missing company name/business summary/deadline must be omitted rather than guessed, and the output must include nextAction and readyToSendMessage rather than a vague 'consult an expert' summary. This gives the agent important operational expectations.

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

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

The description is dense but front-loaded with the trigger conditions and then moves to output and safety constraints. It is longer than strictly necessary, especially the list of private-document examples, but every sentence adds useful operational guidance rather than 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 read-only message-generation tool with no output schema, the description covers the output shape, safety behavior, and constraints well. The main remaining gaps are the slight ambiguity around consult_by and the lack of explicit mention of the issue topic enum, both of which the schema partially covers.

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 only 25%, but the description compensates by mapping most parameters: subsidy_name ('制度名'), source_url ('公式URL'), confirmed_facts ('確認済みの公開事実'), issues ('未確認論点'), company_name, public_business_summary, and application_deadline. It also adds what should not be placed in parameters. However, consult_by and the issue.topic enum are not explained in the description, so it is not fully complete.

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

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

The description states a specific verb and deliverable: it creates a copyable consultation message for a professional advisor, with nextAction and readyToSendMessage. It also names the trigger conditions (user wants to consider subsidy candidates, consult an expert, or ask what to do next) and clearly distinguishes this from sibling analysis/search tools by emphasizing message composition rather than eligibility assessment.

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 explicitly says when to use the tool and notes it can build on information from web search or other tools. It also gives constraints on what not to do (don't guess missing fields, don't include non-public data). It does not name sibling alternatives or state when not to use it, so it stops 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?

Beyond the destructiveHint annotation, the description explains it may overwrite existing records, verifies official URLs before saving, calculates the ratio internally, and uses evidence_text only for hashing without storing it. These are useful behavioral details not conveyed by annotations alone.

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 dense single paragraph with no filler; every sentence adds an important instruction or constraint. It is front-loaded with the primary action and then provides critical behavioral details.

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 nested objects and 6 required parameters, the description covers many edge cases: overwriting behavior, ratio calculation, comparability handling, evidence_text handling, and input restrictions. It is fairly comprehensive, though it does not describe every field in detail.

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 description clarifies semantics for comparability, applications_count, and evidence_text, but does not address other parameters like program, round, or source fields. Given the schema description coverage is 0%, it partially compensates but not fully for all 7 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 saves official application and selection counts for a given recruitment round to D1 with source and calculation basis. It uses a specific verb (保存) and resource, and distinguishes itself from sibling tools like get_official_selection_statistics (retrieval) and estimate_program_selection_outlook (estimation).

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?

Provides explicit guidance on when to avoid certain actions: do not input ratios, do not guess applications_count when only a selected list exists, and set comparability to not_confirmed/not_comparable when the same round/scope cannot be confirmed. It does not explicitly name alternative tools, but the instructions make usage context clear.

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 the tool as read-only and idempotent, but the description adds essential behavioral details beyond those: do not automatically decide among same-name candidates, disclose when only the first page is returned, avoid asserting registration status when statusAvailability is not_provided, and use specific user-facing terminology for the data source. These are non-obvious behaviors an agent would otherwise miss.

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

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

The core function is front-loaded in the first sentence, and the remaining sentences each carry a distinct, valuable usage or handling rule. The length is justified by the number of important caveats, and there is no wasted text.

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?

Despite the absence of an output schema, the description covers what the tool returns, how to handle multiple candidates, pagination disclosure, status uncertainty, and the next tool to invoke. This is sufficiently complete for a read-only search tool with strong 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 schema describes name, city, and prefecture with examples, while page and limit lack descriptions, giving about 60% schema coverage. The description does not add much parameter-specific meaning, although it reinforces formal name usage and mentions pagination-related output via mayHaveMore. It does not clarify page or limit semantics beyond the schema defaults.

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 a specific verb and resource: it searches for company names in the METI gBizINFO database and returns candidates with corporate number and address. It also distinguishes itself from the follow-up tool get_company_profile by stating that the profile tool should be used after candidate confirmation.

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 gives clear context for when to use this tool: when searching for a company by name and needing candidate identification. It also provides explicit handling rules for ambiguous candidates, pagination, and status uncertainty, and directs to get_company_profile after confirmation. It does not explicitly contrast with search_corporate_identities, so the alternative selection guidance is not fully complete.

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 the tool as read-only, idempotent, open-world, and non-destructive. The description meaningfully adds behavior context: closed corporations are included, multiple hits require address-based confirmation, pagination is driven by mayHaveMore, and users must see the notice source and non-guarantee. No contradiction with annotations exists.

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?

Four short sentences each carry distinct, decision-relevant information: result fields, closed-entity inclusion, disambiguation rule, pagination behavior, and notice handling. The operational claim is front-loaded and no sentence is wasted.

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

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

For a search tool with no output schema, the description covers the essential result fields, pagination, disambiguation, and user-facing notice requirements. It would be more complete with an explicit statement about result count or output shape, but the provided information is sufficient for a competent agent to invoke and handle the tool correctly.

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

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

Schema description coverage is only 33%, so the description must compensate. It indirectly explains the name parameter through '法人名検索' and gives page semantics via the mayHaveMore instruction, but it does not mention the address_code parameter, which is left to the schema. The added pagination guidance provides some value beyond the schema, but coverage remains incomplete.

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 operation: search the NTA corporate registry for official name, corporate number, address, and closure status, including closed entities. It goes beyond the tool name by specifying the data source and result fields, but it does not explicitly contrast itself with sibling tools such as search_companies or get_corporate_identity.

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 provides concrete usage guidance: do not automatically resolve same-name companies, confirm by address, advance the page when mayHaveMore is true, and present the notice's source and disclaimer to users. However, it does not state when to prefer this tool over sibling alternatives or when not to use it.

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 provide openWorldHint=true and readOnlyHint=false, but the description goes far beyond by specifying how to interpret results ('0件を制度不存在とせず'), how to handle specific use cases (employment/training), and that the response contains guidance to follow. It also warns against concluding eligibility solely from search results. These are critical behavioral details that are not in the annotations, adding substantial value.

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, dense paragraph that leads with the core purpose and scope, then layers operational instructions. Every sentence carries essential information – there is no fluff or repetition. The structure flows logically from what the tool does to how to use it correctly, making it easy for an agent to parse.

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 9 parameters, no output schema, and a complex operational context, the description covers all critical aspects: scope, handling of zero results, follow-up actions (get_subsidy_detail), and external supplementation. It even references response guidance, acknowledging that the output will contain instructions. An agent has enough to invoke and interpret results correctly.

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

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

The schema covers 67% of parameters with descriptions, and the description adds semantic context for at least one parameter: '所在地が指定された場合は全国対象制度も含めます' clarifies the behavior of the target_area parameter. It also implies that employee_count is used for post-API filtering, though that is already in the schema. The description does not explicitly describe sort, limit, or order, but those are straightforward. Overall, it enhances parameter understanding 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 states the specific verb ('検索' – search), the resource ('Jグランツの公開API' – J-Grants public API), and the subject ('補助金候補' – subsidy candidates). It explicitly scopes the search to J-Grants, which distinguishes it from sibling tools like get_subsidy_detail (which fetches details) and search_companies (which searches companies). The purpose is unambiguous and well-differentiated.

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 gives explicit operational guidance: follow the returned searchGuidance and responseGuidance, do not treat zero results as non-existence, supplement with standard web search for employment/training using MHLW official information, include nationwide programs when a location is specified, and use get_subsidy_detail after candidate selection. It also implicitly tells when not to use this tool (not for final eligibility determination). This is exemplary guidance for an agent.

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 goes well beyond the annotations: it discloses possible overwrite of existing records under D1 settings, explains that absence from documents does not imply no capital relationship (aligned with openWorldHint), and flags internal fields such as relationId as not user-facing. None of this contradicts the annotations; it enriches them meaningfully.

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

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

The description is dense but every sentence carries a distinct fact: core action, overwrite side effect, non-inference limitation, open-world caveat, output presentation, and downstream workflow. The most important information is front-loaded, and there is no redundant 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 destructive, open-world tool with no output schema and six parameters, the description covers critical side effects, result interpretation, internal-vs-user-facing output, and the correct next step. The only minor gap is that it never states the exact return shape (e.g., confirmed/not-confirmed structure), though it references internal fields that will appear, so an agent can still act reasonably.

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?

All six input parameters already have individual descriptions in the schema, and schema coverage is 100%, so the baseline is 3. The description adds useful high-level behavioral context, but it does not add parameter-specific meaning beyond what the schema already provides. There is no need for the description to compensate here.

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

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

The description opens with a specific verb and resource: verifying a user-declared parent-company candidate against the latest EDINET securities reports. It also explicitly scopes itself negatively ('not a tool for inferring a parent from zero'), which differentiates it from search/company-profile siblings. This makes the tool's unique role very clear.

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 states when to use the tool: when a user has declared a parent candidate to be verified, and it explicitly warns against using it for guessing from scratch. It also gives downstream guidance to check program guidelines and use assess_deemed_large_enterprise_eligibility. However, it does not name a direct alternative for the same verification-style task among siblings, so it is not a perfect 5.

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