補助・助成.jp

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

With readOnlyHint=true and openWorldHint=true already declared, the description adds substantial behavioral context: it returns evidence citations, missing information, and cost estimates; guideline availability and PDF candidates; and it warns that viewpoints are not pass/fail and must be reported as unconfirmed if not verifiable. This goes well beyond annotations.

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

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

The description is front-loaded with the core purpose, then adds only operationally necessary details about plan fallback, return contents, guideline availability, and the unconfirmed-reporting rule. Every sentence earns its place.

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

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

Given the tool's complexity, the existing output schema, and the read-only/open-world annotations, the description covers the critical agent-facing details: what the verdict means, where subsidy_id comes from, what happens when plan is omitted, and how to handle unavailable guidelines. Nothing important 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 low for the top-level parameters, and the description adds meaning for subsidy_id (recommend_subsidies id) and plan (omitted uses profile plan). However, it does not explain the InvestmentPlan fields or expected formats, so it only partially compensates for the schema 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 states a specific verb and resource: it judges whether the user's company is likely eligible for one subsidy, item by item, and returns one of three statuses. It also ties subsidy_id to recommend_subsidies, making its role distinct from sibling tools in the recommendation workflow.

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 explains that subsidy_id comes from recommend_subsidies and that omitting plan falls back to the profile plan. It also gives a clear conditional action when guideline.available is false. It does not explicitly say when not to use this tool or name a direct alternative, so it falls short of a 5.

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

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

Annotations declare readOnlyHint=false, which the description justifies by disclosing that the call mutates per-user state (既読 / seen marking) and that mark_seen=false suppresses it. It further discloses first-call baseline behavior (new is empty, counts reported as baseline), per-source caps (国12件・J-Net21 8件・自治体8件), and that omitted items reappear next run because they are not marked seen — all beyond what annotations provide.

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

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

The purpose is front-loaded and each line carries operational information, but the seen-state rule is restated three times (omitted items, filtered items, mark_seen), which adds length for a description already dense with caps and edge cases.

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 statefulness and an existing output schema, the description covers everything needed to call it correctly: baseline semantics on first use, cap counts, filtering behavior, and the seen-state side effect. Return-value shape is left to the schema, which is appropriate.

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

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

Schema coverage is 0%, so the description must carry the load. It richly explains mark_seen's state effect and the non-obvious 'purposes filtering does not mark filtered-out candidates as seen' interaction, but deadline_within_days is never explained beyond the implicit notion of 'closing soon' and its default.

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 two concrete result sets (new candidates since the last call, and closing_soon candidates), and explicitly contrasts itself with recommend_subsidies for the full candidate list. An agent can distinguish this from siblings like search_subsidies or get_subsidy without opening any schema.

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

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

It states the intended usage pattern (定期チェック用 / periodic check) and explicitly names the alternative for adjacent needs: 'いまの候補の一覧は recommend_subsidies で見る'. It also warns that 'no new items' does not mean 'no usable subsidies', which prevents a specific misreading.

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?

readOnlyHint と openWorldHint は構造化フィールドが既にカバーしているが、検索が候補地×キーワード×2地域で最大120回という計算量制約と、超える場合はキーワードを絞るという対処を明示している点は注釈を超えた付加情報。これによりエージェントは呼び出し前にコストを見積もれる。

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?

冒頭で目的を述べ、続けて locations の形式・上限、検索回数制約、purposes の挙動、返り値の内容と、要点が先頭から順に並んでいる。冗長な前置きはなく、各文が実用的な情報を担っている。

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?

出力スキーマが存在するため返り値の詳細説明は不要であり、説明は返す local_programs の内容（対象規模・業種・概要つき）に軽く触れる程度で適切。入力制約・検索制約・出力概要が揃っており、この複雑度のツールとしては過不足が少ない。

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 が0%のため説明が意味を補う必要がある。locations については都道府県始まりの形式と例、上限5か所を明記し、purposes については渡した目的の制度のみで比較する挙動を説明しており、実質的に大部分のパラメータを補完している。keywords は「絞る」という言及に留まるが概ね足りている。

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?

明確な動詞（比較する）と対象（本店所在地を変えたときの候補地）を示しており、何をするツールかは一目で分かる。ただし recommend_subsidies や search_subsidies など近接する兄弟ツールとの違いには触れておらず、差別化は読み手の推測に委ねられている。

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?

「本店所在地だけを変えた場合」というシナリオから用途は暗黙に示されるが、いつ使うべきか・使うべきでないか、代替ツールとの使い分けは明示されていない。5か所まで／検索120回までといった運用制約は書かれているが、これは利用ガイドというより制限の説明である。

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 annotations, the description discloses important behavior: coordinates are in pt with top-left origin, deletion of fields containing values is rejected, and fitting failures reject only the affected field rather than the whole batch. This adds meaningful operational context for a destructive editing tool.

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

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

The description is terse and front-loaded: operations and batch size come first, followed by coordinate rules, positioning modes, and rejection behavior. Every sentence carries useful information.

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

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

Given the destructive annotations and the presence of an output schema, the description covers the essential behavior an agent needs: operations, coordinate system, positioning strategies, and partial rejection. It is not exhaustive about every nested field property, but it is complete enough for correct tool selection and invocation.

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

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

The description adds substantial meaning beyond the schema by explaining box, at, and anchor positioning modes, the coordinate system, and that value can be filled after positioning. It still leaves some FieldEdit properties such as kind, align, wrap, label, and valign unexplained, but the key spatial semantics are covered.

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

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

The description uses specific verbs and a clear resource: adding, moving, restyling, and deleting PDF fields. It also states the batch range (1–100), which distinguishes this layout-editing tool from fill-oriented siblings.

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 implies when the tool applies by listing the operations it performs and their limits, but it does not explicitly say when to use this instead of siblings such as fill_form or fill_forms. The usage context is present but not fully routed.

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=false, destructiveHint=false, openWorldHint=false, so the safety profile is partly covered. The description adds useful behavior beyond annotations: it preserves the original format and returns URLs (plus a ZIP for multiple forms), and it explains that submission happens outside the tool. It does not explain why the operation is not read-only or any auth/size caveats.

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

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

Two sentences, front-loaded with the action and output, followed by the user-facing workflow note. No filler, though the second sentence is a bit tangential to selecting/invoking the tool.

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

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

An output schema exists, so return-value explanation is not strictly required, and the safety profile is covered by annotations. The description adequately frames the export workflow but leaves both parameters entirely undocumented, which is the main completeness gap for a 2-param tool.

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

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

Schema description coverage is 0% and there are two parameters (case_id required, form_ids optional array) that the description never mentions. With no schema text and a purely non-compensating description, an agent gets no meaning for either parameter.

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

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

The description states a specific verb (出力/export) and resource (記入済みの様式, the completed forms) and even describes the output (download URL, ZIP when multiple). An agent can tell it produces downloadable artifacts. It stops short of differentiating itself from the close sibling validate_and_export_application.

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 gives post-invocation workflow guidance (show the URL, tell the user to verify formatting/missing entries/attachments before submitting, submission is the user's job), which implies the tool is a final-step export. However, it never states when to choose this over validate_and_export_application or validate_application, so the alternative-routing guidance is absent.

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 destructiveHint=true and readOnlyHint=false, so the overwrite nature is partly covered; the description reinforces it with '（置き換え）' and adds real context beyond annotations – clear semantics, from_profile batch behavior, and the meaning of rejected (not saved) vs warnings (saved). It stops short of describing return structure or permission requirements.

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

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

Front-loads the core save/overwrite semantics before the conditional details, and nearly every line carries distinct information. The telegraphic fragment style is dense but efficient; minor readability cost, no filler sentences.

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

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

An output schema exists, so return-value detail is not required, and the description still explains the response concepts rejected/warnings/progress enough to act on them. Combined with the per-format key guidance and the sibling pointer, an agent has what it needs to call this correctly for a 5-param mutation tool.

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

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

Schema coverage is 0%, so the description carries the burden, and it does: it explains values as field-ID→string, clear as cancellation, sheet as the Excel sheet selector, and from_profile's batch behavior. form_id is left implicit but is obvious from the name; nested-object key syntax for Excel/PDF is spelled out, which is 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?

States a specific verb+resource: save field-ID→string pairs into a form, with overwrite semantics ('保存（置き換え）'). It explicitly routes the multi-form case to the sibling fill_forms, so an agent can distinguish it from that tool without opening either schema.

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

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

Gives explicit conditional usage: from_profile=true fills all blank profile-candidate fields at once, and '複数様式は fill_forms を使う' names the alternative for multiple forms. It also clarifies the field-ID format per document type (Excel sheet/address, PDF p1.f12), removing ambiguity about when each form applies.

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

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

Annotations only say it is a destructive write; the description goes well beyond by disclosing merge semantics (same form merged in array order and saved once), partial-failure semantics (per-field 'rejected' = unsaved, 'warnings' = saved), and sequential saving with guidance to check save status on communication failure. This is exactly the behavioral context an agent needs for a mutating batch 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?

Front-loads the purpose and batch limit, then adds merge, argument, and failure-handling detail, with no filler sentences. Dense but every line earns its place.

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

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

An output schema exists so return values need not be described, and the description covers batch behavior, merge rules, and failure handling. The remaining gap is the unexplained per-item field structure, which it defers to fill_form.

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% and the single 'changes' parameter wraps a nested FormChange object with five undocumented properties (form_id, clear, sheet, values, from_profile). The description only says each item uses 'the same arguments as fill_form', a cross-reference rather than an explanation, so the field-level meaning is not supplied 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?

States a specific verb+resource ('複数様式を1回で記入する') and immediately scopes it (1〜50件), making it unambiguously the batch counterpart of the sibling fill_form. An agent can distinguish it from fill_form without opening either schema.

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

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

Gives clear context: it is for filling multiple forms at once (1-50) and each item uses the same arguments as fill_form, which implicitly routes single-form use to that sibling. No explicit when-not or exclusion statement is present, so it stops short of a full routing rule.

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

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

The annotations already declare readOnlyHint=true and openWorldHint=false, so the agent knows this is a safe, non-open-world read. The description adds little beyond that: it does not mention what happens if no profile is saved, whether authentication is required, or any other runtime behavior.

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

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

The description is a single, front-loaded sentence with no wasted words. It states the resource and operation immediately and efficiently.

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

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

With an output schema present, the description need not explain return values, and the annotations already cover the safety profile. The low complexity and zero-parameter schema mean the definition is nearly complete, though it could briefly mention how it relates to storing or looking up company data.

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

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

The tool takes zero parameters, so the baseline is 4. There is nothing for the description to clarify beyond the already complete empty 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 clear verb ('返す') and resource ('保存済みの会社プロフィール'), making the core operation identifiable. However, it does not explicitly distinguish itself from the sibling 'lookup_company' or 'save_company_profile', so sibling differentiation is left implicit.

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 guidance on when to use this tool versus alternatives such as 'lookup_company' or 'save_company_profile'. The only implied usage is retrieving previously saved data, with no exclusions or prerequisites stated.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the read-only nature is established. The description adds beyond that: pages are 1-indexed, the entire page text is returned, and multi-document sources are disambiguated via the document parameter with a pointer to get_subsidy attachments.

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

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

Two tight sentences: the first front-loads what the tool returns and the indexing convention, the second handles the multi-document case. No filler, and the most important information leads.

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

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

An output schema exists, so return values need no explanation, and annotations cover the safety profile. The description fills the remaining gaps (indexing, document selection, sibling relationship), though it omits error behavior such as an out-of-range page.

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%, so the description must carry the load, and it does for two of three params: pages is clarified as 1-indexed, and document is explained as the filename to set when multiple documents exist, with the source of that list. It leaves the pages array shape and subsidy_id semantics unexplained, but the latter is self-evident.

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

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

States a specific verb and resource — returns the full text of a specified guideline page — and pins the scope with '1始まり' indexing. It explicitly distinguishes itself from siblings by positioning itself as the read step that follows search_guideline and by pointing to get_subsidy for the document list.

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?

Explicitly says to use it when reading pages before/after those found by search_guideline, which gives the agent a clear trigger and a named alternative for the discovery step. It does not state exclusions (e.g., when search_guideline alone suffices), so it falls short of a full 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?

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuine value by scoping the payload (summary only, body excluded), but it says nothing about the caching semantics implied by the refresh parameter, nor about rate limits or staleness — a notable omission for an open-world read tool.

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

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

A single front-loaded sentence that lists the returned fields, followed by a short exclusion clause. No filler, no repetition of the title, and the most important scoping fact is stated up front.

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

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

An output schema exists, so return-shape detail is largely redundant, and the description is complete about what is and is not returned. But for a two-parameter tool with 0% schema coverage, the unexplained refresh flag and the absence of any usage or prerequisite context leave 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 0%, so the description carries the full burden for two parameters, and it explains neither. subsidy_id is only inferable from context, and refresh — a boolean that clearly controls cache bypass — is completely undocumented in both schema and description.

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

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

States a specific verb (返す) and resource (補助金の概要) and enumerates exactly which fields are returned (公募回次・対象地域・締切・上限額・補助率・添付文書名とページ数). The negative clause 本文は返さない separates it from body-text retrieval tools like get_guideline_pages, though no sibling is named explicitly.

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

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

The exclusion 本文は返さない implicitly tells the agent when to look elsewhere for full text, and the 'detail for a given subsidy' framing implies use after a search. However there is no explicit when-to-use statement, no prerequisite (e.g., needing a subsidy_id from search_subsidies), and no named alternative tool.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true. The description goes beyond them by disclosing that the form is added to the user's case (a mutation), the exact URL provenance validation, allowed extensions, and the failure/fallback behavior. It stops short of stating auth or permission requirements.

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 dense lines, each carrying distinct information: action, input constraint, file types, downstream usage, and failure fallback. No filler and the core action is front-loaded.

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

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

An output schema exists, so return values need not be described, yet the description usefully points to the returned forms' form_id as the handoff to inspect_form/fill_form. The only real gap is that program_id's meaning is never explained.

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 carries the burden. It richly constrains url (provenance and file extensions) but never explains program_id, leaving half the parameters undocumented.

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

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

States a specific verb+resource+scope: import exactly one municipal official form and attach it to the user's application case. It also names the upstream source (start_application's official_forms) and downstream siblings (inspect_form/fill_form), so an agent can place it in the workflow without opening any schema.

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

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

Gives explicit trigger (when the user asks), an input restriction (url must come from start_application's official_forms; anything else is rejected), accepted file types, and an explicit fallback path (guide the user to upload_url when import fails). This is when/when-not/alternative guidance in full.

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

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

Annotations already declare readOnlyHint and openWorldHint, yet the description adds substantial behavioral context beyond them: xlsm macros are preserved but never executed, pagination must reuse the same retrieval conditions via next_cursor/next_offset, max_bytes is a UTF-8 JSON budget with format-dependent defaults, and how_to/profile_candidates appear only on the first call. This is exactly the extra context the annotations do not cover.

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

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

Front-loads purpose in the first fragment and organizes the rest by format, exclusivity, pagination, and budget, so it is easy to scan. It is dense and telegraphic, and the max_bytes/MCP-wrapper caveats add length that only marginally serves tool selection.

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 12-parameter, multi-format tool whose output schema already documents return values, the description still covers format behavior, exclusivity, pagination chaining, and empty-vs-mandatory semantics — enough to call it correctly. The only noticeable gap is the unexplained limit/include_formulas parameters.

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 carries the full burden, and it explains most parameters well (page is 1-based, table is 0-based, targets take 'sheet!address' IDs, only_empty means unfilled candidates not mandatory-field detection, max_bytes range 4096–262144). It leaves limit and include_formulas unexplained, so it compensates but not completely.

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?

Opens with a specific verb+resource ('欄の一覧' — list the fields of a form) and then distinguishes itself from the sibling view_form ('欄は空いた場所の候補で、view_form で画像を確かめる'). An agent can tell it reads field structure rather than filling or validating without opening the schema.

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

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

Gives explicit mode-selection rules per format (Excel=outline/sheet/sheets, PDF=per-page vs page, Word/RTF=body and table, PowerPoint=targets), states the exclusivity constraint (sheet・sheets・targets・table は排他), and routes to view_form for image confirmation. When-to-use and when-to-use-an-alternative are both covered.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered and the bar is lower. The description still adds meaningful context beyond the structured fields: the list is restricted to unfinished applications (not submitted/exported ones) and includes per-form completion counts, which tells the agent what a resumed session looks like.

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

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

A single front-loaded sentence carrying the return content first and the usage condition second in a parenthetical. No filler, no restatement of the title beyond what adds scope information.

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

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

For a zero-parameter read tool with an output schema and read-only annotations, the description supplies what the structured fields do not: the draft-only scope and the resume use case. Return-shape details are legitimately omitted since the output schema covers them; only minor things like ordering or result limits are unaddressed.

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

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

The tool takes zero parameters, so the baseline is 4. There is nothing for the description to clarify about inputs, and schema description coverage is 100%.

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

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

States a specific verb (返す/returns) plus a precise resource scope: in-progress application cases (作成中の申請案件) and per-form filled-field counts. That scope distinguishes it from siblings such as start_application, fill_form, export_application and validate_application without the agent needing to open any schema.

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

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

The parenthetical explicitly names the triggering situation: resuming a previous session (前回の続きから再開するときに使う). This gives clear when-to-use context, though it names no alternative tool and states no when-not-to-use condition.

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 set readOnlyHint=false, destructiveHint=false, openWorldHint=false. The description earns credit by explaining why the tool is not read-only: acknowledge_changes=true performs a state mutation that persists across calls ('next time they won't appear in changes'). It also documents what the listing returns, which the sparse annotations do not cover.

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

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

Front-loaded with what the tool returns, followed by the flag's side effect; both sentences earn their place. The indented line-break formatting is slightly awkward but does not hurt 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?

For a simple one-optional-parameter listing tool with an output schema, the description covers purpose, returned content, and the mutation side effect. Nothing essential for correct invocation is missing, though the relationship to check_new_subsidies remains unaddressed.

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 has 0% description coverage for its single parameter, so the description must carry the burden — and it does, explaining both the effect of acknowledge_changes=true and its persistence semantics. No format/type detail is added, but for a boolean flag that 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+resource (list watched subsidies) and enumerates the returned fields — deadline, remaining days, status, and changes since last check. It is clearly distinguishable from watch_subsidy/unwatch_subsidy, though it never explicitly contrasts itself with the nearby sibling check_new_subsidies.

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: it tells the agent that acknowledge_changes=true marks displayed changes as acknowledged so they stop appearing in future results, which is genuine usage guidance for the flag. However, there is no explicit when-to-use-this-vs-alternatives framing against check_new_subsidies or the other listing tools.

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

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

Annotations cover readOnlyHint and openWorldHint, and the description reinforces 'does not save' while adding far more: the meaning of proposed/differences/unknown/warnings, the rule not to overwrite existing values until the user chooses, the caution that missing past_subsidies records don't mean 'not received', and the mandatory attribution requirement.

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?

Purpose and the no-save guarantee are front-loaded, and the sentences are dense and information-bearing. It is long, but the length is mostly justified by the two-step workflow and output-field semantics; a little output-field detail could be trimmed given an output schema exists.

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

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

For a complex read tool with 0% schema coverage and an output schema present, the description supplies the workflow, return-field semantics, scope limits, and attribution needs that the structured fields do not. Nothing essential to correct invocation is missing.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning, and it largely does: name returns a candidate list and can be narrowed by prefecture, and corporate_number is a 13-digit ID used after confirmation. prefecture gets only a brief mention, leaving a small 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?

States a specific verb+resource: reads company info from gBizINFO (METI's corporate info site) by corporate number or company name. It explicitly distinguishes its two modes and separates itself from siblings like save_company_profile and get_company_profile. An agent can identify exactly what it does without opening the schema.

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

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

Gives an explicit workflow: use before asking the user about company info, call with name to get candidates, confirm the company with the user, then call with corporate_number. It names the downstream siblings (get_company_profile, save_company_profile) and states an exclusion (sole proprietors without a corporate number are out of scope).

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 declare readOnlyHint and openWorldHint, but the description goes well beyond: it discloses a multi-stage filter pipeline, a latency warning (数十秒), the status enum values, the null-deadline caveat when acceptance_phase is unknown, and the free-plan behavior (list only, no guideline reading). This is rich behavioral context an agent could not infer from the annotations.

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

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

It is dense and multi-clause, but the highest-value fact (use this first) is front-loaded and every sentence conveys distinct operational detail (latency, enum meanings, plan gating). Some clauses about return fields could be tighter, but none is pure 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 4-parameter, no-required-arg recommendation tool with an output schema, the description covers the calling convention, all filtering paths, edge cases (null deadline), and plan-dependent behavior. The only omission is limit, which is minor given the tool works well with defaults.

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%, so the description carries the load. It thoroughly documents keywords (2+ chars, up to 40 words of 30 chars), detail_top_n (max 10), and purposes (with an example mapping), but never explains limit, whose meaning and default of 20 remain opaque. Three of four parameters are well covered.

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 ('自社に合う補助金候補を探し、判定済みの一覧を返す') and explicitly positions itself as the entry point with 【最初に使う】. It is clearly distinguishable from siblings like search_subsidies and check_eligibility, which do narrower searching or eligibility checking.

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 says when to call it plainly ('通常は引数なしで呼ぶ'), when to use each optional argument (keywords overrides profile, purposes filters by classified purpose), and describes the free-plan alternative path. The example ('IT導入の支援を探して' → ['IT・DX']) shows exactly how to route intent to the purposes argument.

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?

アノテーションの destructiveHint=true と整合する「上書き」を明示し、さらに確認なし保存の禁止、推測で order_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?

冒頭で保存・上書き・後続判定への影響を述べ、以後は箇条書き的に必要情報を並べており front-loaded である。ただし複数段落で長く、やや密なため 4。

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?

ネストした大きな CompanyProfile と plan を持つ複雑なツールに対し、保存条件、欠損時の扱い、確認、非保存設定、後続判定への影響まで説明している。出力スキーマがあるため戻り値説明は不要で、呼び出しに必要な文脈はほぼ揃う。

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?

search_keywords の文字数・個数・例、purposes の由来と引き継ぎ、plan の order_status 等を利用者が言ったときだけ入れる条件、company_name 等の申請書類用途を説明し、スキーマ以上の意味を追加している。ただし「必須の項目はない」とスキーマの company 必須の関係がやや不明瞭で、全パラメータを網羅しないため 4。

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?

「保存する（上書き）」という具体的な動詞と対象「会社プロフィール」を明示し、以降のツールがこのプロフィールで判定することまで述べている。get_company_profile との関係も示され、兄弟ツールとの区別が容易。

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?

既存プロフィールへの追加時は get_company_profile の内容に足すこと、不明項目は省略すること、様式で null の候補が出たら利用者に聞くことなど、具体的な使用条件を列挙している。保存前の確認や「サーバーに保存しない」設定時の非保存も明記されている。

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds that excerpts are page-numbered and that the query is an OR search, which is useful behavioral context, but says nothing about result volume, limits, or the effect of max_hits/context_chars.

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

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

Two short sentences, front-loaded with purpose and followed by query syntax. No filler, though the brevity borders on under-specification rather than tightness given the undocumented parameters.

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

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

An output schema exists so return values need not be explained, and annotations cover the safety profile. Still, the missing parameter semantics (especially subsidy_id scoping and the two integer knobs) and the absence of sibling differentiation leave gaps for a 4-parameter search tool.

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

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

Schema description coverage is 0%, so the description must carry the load. It explains the most important parameter well (query is space-separated OR search, with two examples), but leaves subsidy_id, max_hits, and context_chars entirely undocumented, including their non-obvious 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 names a specific verb+resource (公募要領の本文を検索) and states what is returned (ページ番号付きの抜粋), so an agent understands the operation. It does not, however, differentiate itself from the sibling get_guideline_pages, which is its nearest competitor.

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 gives one concrete use case – verifying the basis of concerns items (concerns の項目の根拠確認に使う). That is genuine guidance, but there are no exclusions or explicit alternatives (e.g. get_guideline_pages) to route the agent when this tool is the wrong choice.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuine behavioral detail beyond that: prefecture filtering excludes nationwide systems (requiring prefecture="全国"), and purposes collapses certain categories. It omits behavior of accepting_only (default true) and limit, which are meaningful filtering defaults.

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

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

Front-loads the core purpose and the preferred alternative before detailing parameter quirks. Dense but each sentence adds operational value; 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?

With an output schema present, return values need not be described, and the key scoping quirks are covered. The main gap is unstated behavior for accepting_only (default true) and limit, which can affect result sets.

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% across 5 parameters, so the description carries the burden. It explains prefecture and purposes semantics well and implies keyword is a single term, but limit and accepting_only are left entirely undocumented in both schema and description.

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

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

States a specific verb (raw keyword search) and resource (J-Grants subsidies), and explicitly distinguishes itself from recommend_subsidies by noting it does not judge by company conditions. An agent can tell what it does and how it differs from the sibling without opening either schema.

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

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

Explicitly names the preferred alternative ('通常は recommend_subsidies を使う') and the condition that separates them (raw keyword search vs. company-condition judgement). Clear routing context, though it never states an explicit when-not/exclusion beyond the alternative pointer.

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=false, destructiveHint=false and openWorldHint=true. Beyond that, the description adds genuine behavioral context: case_id=null signals a missing template or fetch failure, the same request should not be repeated, and failure paths route to original_url. It still doesn't describe the side effect of 'starting' a case (draft creation, state change).

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?

Purpose is front-loaded in the first clause, and the remaining sentences each carry a distinct rule (writable routing, null case, retry guidance, preparation, original_url fallback). Dense but no filler.

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

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

For a workflow-start tool with an output schema, the description appropriately focuses on interpreting results (case_id, reason, next_steps, forms.writable, preparation) rather than re-documenting the return shape. The only gap is the tool's own mutation semantics, which no field 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 coverage is 0% for the single required parameter, so the description must compensate. It identifies subsidy_id as the 制度ID (subsidy/program identifier) being acted on, but adds no format, lookup source, or validation detail beyond that.

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

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

States a specific verb and resource ('制度IDから案件を開始・再開する' – start/resume a case from a subsidy ID), which is clear and distinct from siblings like get_subsidy or list_applications. It does not, however, explicitly contrast itself with those siblings, so it stops short of a 5.

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 is rich in downstream routing (writable=true → inspect_form→fill_form; writable=false → original_url; import_official_form when the user asks), which implies the workflow context. But it never states the condition for invoking start_application itself versus alternatives, so usage is implied rather than explicit.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds modest value by scoping the destruction as 'removing from the watchlist' rather than deleting the subsidy itself, which matters alongside a sibling like delete_my_data. It says nothing about idempotency or behavior when the subsidy is not currently watched.

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

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

A single short sentence with the action front-loaded and zero filler. It is efficiently terse, though brevity here borders on under-specification rather than deliberate concision.

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

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

For a one-parameter toggle with annotations covering the safety profile and an output schema covering the return value, the description is close to sufficient. It nonetheless omits any linkage to watch_subsidy/list_watchlist, which is the one thing an agent would need to place this tool in a workflow.

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%, but there is only one parameter and its name (subsidy_id) maps directly onto 補助金 in the description, so its meaning is inferable. The description adds no format, ID-source, or validity detail beyond that.

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

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

States a specific verb (外す = remove) and resource (補助金 from ウォッチリスト), so the agent can tell it is the inverse of watch_subsidy. It does not, however, explicitly name watch_subsidy or otherwise differentiate itself textually from its siblings.

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 when-to-use guidance, no mention of prerequisites, and no reference to the obvious counterpart watch_subsidy or to list_watchlist for verifying state. Usage must be inferred purely from the tool name.

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 declare a non-read-only, non-destructive, closed-world write, and the description adds meaningful behavior beyond them: fail means no export at all, warnings/unknown block export unless allow_warnings=true after user confirmation, and validation explicitly does NOT cover required fields, subsidy-amount correctness, or formatting (check the real file before submission). These are exactly the operational caveats an agent needs for a write 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?

Front-loads the pass/fail export rule in the first line, then layers the warning gate, the expected reference, and the validation-limit caveat in short clauses. Very little waste, though the four-line layout is slightly terse in places.

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

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

With an output schema present, return values need no explanation, and annotations cover the safety profile. The description adequately supplies the conditional-export logic, the confirmation prerequisite, and the validation boundaries; only the meaning of case_id and the exact failure response remain unstated.

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?

Top-level schema description coverage is 0%, so the description must carry the load. It clarifies allow_warnings semantics and instructs that table amounts need the original value plus row/column headers (mapping to the nested value/row/column fields), and points expected at validate_application's contract. But case_id is never explained and the expected entries' shape is only deferred, not described.

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

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

States a specific compound action — validate the same entered content and export only on pass — and explicitly ties the 'expected' input to validate_application, so the agent can distinguish it from validate_application (no export) and export_application (no validation). Clear verb+resource, though the export mechanism itself is only implied.

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

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

Gives conditional guidance for the allow_warnings path (warnings/unknown require confirming the issues with the user first), which is real routing advice. However it never states when to prefer this combined tool over calling validate_application then export_application separately, leaving the primary tool-selection decision to inference.

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

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

Annotations already declare readOnlyHint=true/openWorldHint=false, so safety is covered, but the description adds real behavioral context: the four possible status values (fail/warning/unknown/pass), what IS checked (input rules, formula references), and explicitly what is NOT verified (required fields, supplementary amount calculations). This scope-boundary disclosure is valuable and goes beyond the annotations; it only lacks any note on cost/pagination behavior.

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

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

Front-loaded with the nature of the operation ('読み取り検査'), then scope, then routing. Every sentence carries information (status values, check coverage, alternatives) with no filler. Dense but not wasteful.

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

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

An output schema exists, so return format need not be re-explained, and the description covers the remaining essentials: status semantics, validation coverage limits, and how to inspect findings or combine with export. Adequate for the tool's complexity, with only minor room for detail on case_id or unsaved/missing-field outcomes.

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?

Top-level schema description coverage is 0%, so the description must carry the load for `expected` – which it does, explaining that the caller passes what was entered and that the server matches it against field headers and stored values, and that monetary amounts must always be supplied. `case_id` is left unexplained but is self-evident from the required-parameter name.

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

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

States a specific verb and resource ('読み取り検査' read-only inspection that validates entered content), plus the mechanism (`expected` compares original values/row-column headers against saved values). It differentiates itself from both inspect_form (findings) and validate_and_export_application (combined validate+output), so an agent can pick it without opening the schema.

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

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

Names two alternatives with the conditions that select them: use inspect_form(targets=[欄ID]) to see flagged fields, and validate_and_export_application when inspection and output should be combined. It also gives a hard usage rule ('amounts in tables must always be passed'), leaving nothing to inference.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely non-obvious behavior: the color coding of the overlay (red=unfilled, green=filled), that field numbers are f-numbers, and that the inspection step records this visual confirmation.

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 resource is stated first, then each flag is introduced with its effect and intent, and there is little wasted text. The multi-line formatting is dense but front-loaded and each sentence carries information.

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

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

With no output schema, the description does convey that the return is a page image, and readOnlyHint covers safety. But for a 6-parameter tool with 0% schema coverage, leaving page, form_id, and values undocumented and offering no differentiation from inspect_form makes it only 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 description coverage is 0%, so the description must carry the load, and it does for three of six parameters: boxes (overlay semantics and colors), region (format [left,top,right,bottom] in pt and the zoom purpose), and grid (50pt spacing and why). It leaves page, form_id, and values completely unexplained, so it only partly 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 names a specific verb+resource: it renders the page image of a PDF form, with optional overlays. It is clear what the tool returns, but it makes no attempt to distinguish itself from the sibling inspect_form, which an agent would plausibly confuse it with.

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 gives useful mode-level guidance (use boxes=true to see field frames and numbers, grid=true when correcting positions, boxes=false after filling to verify against the submission). However, it never says when to use view_form versus inspect_form or the other form siblings, so the routing decision is left implicit.

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 write/non-destructive/closed-world; the description adds real behavioral context beyond that by disclosing that a snapshot of deadline, subsidy cap, rate, and target region is captured at registration time to detect later changes. It omits error behavior for invalid subsidy_id and any auth notes.

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

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

Front-loaded with the core action and the upsert caveat, which is good. But the full status enum listing duplicates the schema's enum verbatim and consumes roughly a third of the text without adding information for the agent.

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

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

An output schema exists, so return values need no explanation, and for a 3-parameter upsert the definition covers the main behavior (create-or-update, snapshotting for change detection). Gaps are minor: no failure modes, no note constraints, no guidance on obtaining a valid subsidy_id.

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%, so the description must carry the burden. It clarifies that status is a workflow state and that note is a memo field updated on re-registration, but it mostly restates the enum values already in the schema and says nothing about note format/limits or what subsidy_id should reference.

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

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

States a specific verb+resource (register a subsidy in the watchlist) and adds the crucial upsert nuance: if already registered, status and note are updated. That distinguishes it from list_watchlist and unwatch_subsidy by implication, though no sibling is named explicitly.

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

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

The upsert clause tells the agent this tool also serves as the update path, which is useful implied guidance. However, there is no explicit 'use this when…' / 'use X instead' routing, and no prerequisites (e.g., subsidy must exist, must be obtained via search_subsidies first).

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