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

With no annotations, the description carries the behavioral disclosure burden. It discloses that the tool uses the e-Gov法令API v2, supports abbreviated law names, and performs retrieval. These are useful behavioral details beyond the schema, though it does not mention potential API errors, rate limits, or authorization 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?

The description is two sentences with no wasted words. The main function is front-loaded, followed by the API source and abbreviation behavior, both of which are essential and non-redundant with the schema.

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 retrieval tool with a fully documented 5-parameter schema, the description is largely complete. It explains the tool's scope and API source. It stops short of describing error behavior or expected response structure, but the format parameter already covers the markdown/toc output distinction.

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 all parameters at 100%, so the baseline is 3. The description adds meaningful parameter-level context by explicitly stating that abbreviations are supported and giving concrete mapping examples, which expands the law_name semantics beyond the schema examples.

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

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

The description clearly specifies the action (取得する), the resource (法令の特定条文), and the domain (企業主導型保育に関連する法令). It also distinguishes this tool from the sibling search tools by emphasizing direct retrieval of a specific article rather than search.

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

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

The description implies usage: use this tool when you need a specific article from a known law, especially via e-Gov or with abbreviations. However, it does not explicitly state when not to use it or when to prefer search_law or other sibling search tools, leaving routing largely 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?

With no annotations provided, the description carries the burden of behavioral disclosure. It makes clear the tool performs a keyword search over official Q&A, which implies read-only behavior, but it does not mention result format, ranking, pagination, or access limits. This is adequate for a simple search tool but not deeply transparent.

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

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

The description is two short sentences with no wasted words. The first sentence states the operation and target, and the second adds valuable scope information. It avoids repeating schema 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 straightforward three-parameter search tool with full schema descriptions, the description and schema together give enough information for an agent to invoke it correctly. The lack of an output schema and explicit return-value documentation is a minor gap given the tool's simplicity.

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

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

Schema description coverage is 100%, so the schema already documents keyword, limit, and category with examples. The description adds no additional parameter-level meaning beyond restating the broad content areas. Per the baseline for fully covered schemas, a score of 3 is appropriate.

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

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

The description states a specific verb ('キーワード検索する'), a clear resource ('企業主導型保育事業のFAQ'), and the content scope ('制度・申請・共同利用・公金管理システム'). This makes the tool clearly distinguishable from sibling law/standard search tools by targeting official Q&A content.

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

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

The description implies this tool is for FAQ keyword searches and lists relevant domains, giving useful context. However, it does not explicitly name alternatives or state when to prefer search_faq over sibling tools such as search_law or search_kantoku_kijun. Usage guidance 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?

No annotations are present, so the description carries the full burden. It discloses the useful default behavior that omitting doc_type searches all 7 documents, but does not describe result format, matching behavior, or any other operational traits beyond the search operation itself.

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 compact sentences contain the essential information: purpose, use cases, and default filter behavior. There is no filler or redundancy, and the most important scoping detail 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?

For a simple search tool, the description is nearly complete: it defines the document domain, use scenarios, and default cross-document behavior, while schema covers keyword, limit, and doc_type enum. It does not explicitly describe the return payload, but that is reasonably implied by the search operation and the absence of an output schema.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by clarifying that doc_type defaults to a cross-search of all 7 documents and by naming the document categories. The limit parameter is left to the schema, which already documents it fully.

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: keyword search over audit-related documents for employer-led childcare businesses, and enumerates the document categories (指導・監査評価基準, 専門的財務監査基準, 専門的労務監査基準等). This scope is specific enough to distinguish it from siblings like search_law, search_faq, and search_tsuuchi.

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 clear use context: '監査準備、自主点検、帳簿・書類の確認等に使用' tells an agent when this tool is appropriate. It does not explicitly name alternatives or exclusion conditions, but the context is concrete and sufficient.

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?

No annotations are provided, so the description carries the full behavioral burden. It discloses that this is a keyword search over a specific legal standard and adds useful scope context, but it does not describe result behavior, output format, or any limitations such as exact-match vs. fuzzy matching. For a non-mutating search tool this is adequate but not rich.

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

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

Three sentences, each earning its place: the first declares the core search action, the second lists the relevant standard topics, and the third clarifies a key application context. No filler or repetition.

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

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

Given the simple two-parameter schema and no annotations, the description is largely complete: it tells the agent what document to search, what topics are covered, and which facility types are included. The lack of an output schema and explicit return-value description is a minor gap for such a straightforward 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 coverage is 100%, so the baseline is 3. The description adds value beyond the schema by enumerating the content areas covered (qualifications, equipment, childcare content, meals, health management) and by identifying 企業主導型保育 as within scope, which helps the agent choose effective 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?

The description states a specific verb (キーワード検索する) and a specific resource (認可外保育施設指導監督基準), and clarifies that this is the legal minimum standard for all unlicensed childcare facilities. It clearly distinguishes itself from sibling law-related search tools by naming the exact document and domain.

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: searching minimum standards for qualifications/staffing, equipment, childcare content, meals, and health management. It also explicitly notes that 企業主導型保育 falls under this standard. However, it does not explicitly name sibling tools or state when not to use this 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?

No annotations are provided, so the description must carry the behavioral burden itself. It does disclose that this tool uses the e-Gov law API v2, which is useful context about an external dependency. However, it does not mention read-only behavior, response format, rate limits, or potential errors, leaving some behavioral ambiguity.

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 three short sentences, each earning its place: what the tool does, when to use it, and what external API it relies on. 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?

The description covers purpose, usage condition, and external API dependency, which is solid for a simple search tool. However, there is no output schema and no mention of what the returned results look like, error behavior, or network-side expectations, so the agent still has some unknowns.

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 parameters are already well-documented with examples and enum meanings. The description adds no additional parameter-level semantics beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description states a specific verb and resource: searching laws related to employer-led childcare by keyword. It also explicitly notes this is for when the law name is unknown, which distinguishes it from lookup tools like get_law.

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

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

The phrase '法令名が分からない場合に使用' (use when the law name is unknown) gives a clear context for when this tool should be selected. It does not explicitly name alternatives or exclusion conditions, but the usage condition is enough to guide 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?

With no annotations, the description carries the full burden, and it does disclose important behavioral nuances: particular besshi values return non-structured text, besshi="1" returns both base and add-on prices, and teiin_kubun="19" auto-resolves to a 13-19 person category. It does not explicitly state read-only behavior, empty-result behavior, or authorization requirements, but the search-oriented wording makes mutation unlikely and the key behavioral exceptions are covered.

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 longer than average, but every line earns its place: it is front-loaded with a one-sentence summary, then organized into clear besshi, legacy type, and filter sections. The bullet structure makes the many mode-specific behaviors easy to scan, and there is no filler or tautology.

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 7 parameters, no annotations, and no output schema, the description is remarkably complete. It covers the purpose, parameter semantics, special-case behaviors, and filter interpretation. The only missing details are minor (e.g., exact return-field structure, pagination behavior), and the schema already documents limit 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?

Although schema description coverage is 100%, the description adds substantial meaning beyond the schema: it maps every meaningful besshi value to the actual data returned, explains the legacy type fallback, gives concrete examples for chiiki_kubun and nenrei_kubun, and clarifies that kasan_keyword only applies with type="kasan". This is far beyond the baseline for fully covered schemas.

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

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

The opening sentence identifies a specific retrieval operation: searching operating-cost unit prices for corporate-led childcare services from structured data parsed from forms 1-13. The domain and resource are unique enough to distinguish this tool from siblings like search_law or search_kantoku_kijun, even without an explicit sibling comparison.

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: when to use besshi vs. the legacy type parameter, which besshi values return structured data vs. raw text, and when kasan_keyword applies. It clearly states exclusions, such as besshi="3","6","8","11","12" returning full text rather than structured tables, so an agent can select the correct mode without guesswork.

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?

No annotations are provided, so the description carries the full burden. The verb 検索する conveys a non-mutating read operation and the domain scope is explicit, but behavior beyond that — result ordering, no-results handling, which fields are matched, pagination semantics — is undisclosed. Adequate for a simple search tool, but thin relative to the no-annotation context.

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

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

Two compact sentences, front-loaded with verb and resource, and the second sentence earns its place by listing searchable content types that aid relevance judgment. There is minor redundancy — 通知を検索できる restates the operation already named in sentence one — which prevents a 5.

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 3-parameter search tool with full schema coverage, the callable surface is fully explainable and the purpose is clear. However, there is no output schema and no description of what results contain (titles, dates, links, snippets), and the potential overlap with siblings covering audit/seminar topics is never resolved. Adequate, but with clear 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%, and each parameter already carries a meaningful description: limit's default and maximum, keyword's space-separated AND-search semantics with examples, and category's partial-match behavior with examples. Per the rubric, the baseline is 3; the tool description itself adds no parameter-level meaning beyond what the schema already provides.

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

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

The description states a specific verb and resource — キーワード検索する over 企業主導型保育事業の通知・お知らせ一覧 — and enriches it with concrete content examples (助成決定、指導監査、セミナー、システム更新). This notice/announcement domain implicitly separates it from sibling tools that search laws, guidelines, unit prices, audit standards, and FAQ, though no sibling is named explicitly, 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 scope statement implies when to use the tool — searching notices whose topics match the listed areas — but there is no explicit when-to-use vs. alternatives guidance or exclusionary language. With 7 sibling search tools, including search_kansa which could plausibly cover 監査-related content, the routing burden is left entirely 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?

With no annotations, the description carries the behavioral burden. It discloses important behavioral traits: keyword search only may not reach specific data in large tables, section filtering is needed, max_chars can be increased, and the 別紙１ section is a giant section. It does not specify exact pagination or ordering behavior, but the practical constraints are well covered.

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 it earns its length by providing a critical workflow and a comprehensive mapping of 別紙 sections. It is well-structured with headers and lists. Minor redundancy exists in repeatedly explaining search_tanka usage, but the organization makes the information easy to scan and act on.

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 and no annotations, the description is thorough: it clarifies the document being searched, the relationship to sibling tools, the section list, the workflow for large tables, and the max_chars limits. It could mention what the output actually looks like, but that gap is minor given the detailed guidance provided.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful usage semantics: empty keyword with section returns full section, max_chars 5000-10000 for big tables, keyword examples like 'その他地域 51人' for regional/capacity filtering. This goes beyond the schema descriptions and materially helps the agent.

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 explicitly states the tool searches the 企業主導型保育事業費補助金実施要綱 by keyword, and clearly distinguishes it from the related 認可外保育施設指導監督基準 which is served by search_kantoku_kijun. It names the resource, the action, and the boundaries of what is in scope.

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, actionable instructions for when to use this tool vs search_tanka: use search_tanka for 単価の金額, and use search_youkou for 要件・留意事項等のテキスト情報. It also provides a multi-step workflow for retrieving large 単価表 sections with section and max_chars, which is concrete and useful.

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