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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety and repeatability profile is covered. The description adds that output is JSON metadata rather than article text, which is useful, but with an output schema present the enumerated return fields add little beyond structured data.

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 the action and output shape, followed by the usage context. Nothing is redundant, though the second sentence is fairly generic guidance.

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, rich annotations, and fully documented parameters, the description only needs to frame purpose and usage, which it does. It could be stronger by distinguishing itself from the many sibling retrieval tools, but 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 100%, and both parameters (law_name, article_number) are documented in the schema with format examples. The description contributes no additional parameter meaning, so the baseline 3 applies.

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

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

States a specific verb and resource: it analyzes the structure of a legal article and returns metadata (paragraph counts, item counts, reference statistics, preview). This clearly differs from siblings that fetch raw text (get_law, search_articles), though the description never names those siblings 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?

It gives an implied usage context — 'use as source material when an AI generates summaries or explanations' — which tells the agent this is a pre-processing step rather than a text-fetching tool. However, it names no alternatives and gives no when-not-to-use condition, so the routing signal remains inferential.

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, idempotentHint=true, openWorldHint=true, destructiveHint=false, so the safety profile is covered. The description adds that the check is performed against the external e-Gov API, but it does not disclose rate limits, error behavior, or what output is produced.

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 with the core purpose front-loaded and the mode distinctions following. No filler, though it is very terse for a four-parameter 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?

With no output schema, the description should ideally hint at the return shape (e.g., what a '改正あり' result contains), but it does not. Annotations cover the safety profile and the schema covers parameters, leaving output format as the notable gap.

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 all four parameters (group, since, law_name, show_history) are already documented in the schema. The description restates the law_name/group/show_history usage but adds no syntax, format, or constraint detail beyond the schema.

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

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

States a specific verb (確認する) and resource (法令の改正状況), plus the mechanism (e-Gov API). It is clearly distinguishable from read-oriented siblings like get_law or search_law, though it does not explicitly name how it differs from the amendment-related sibling get_kokuji_amendments.

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 maps the three parameters to three usage modes (law_name=単体チェック, group=バッチチェック, show_history=履歴表示), which is useful implied guidance. However, it offers no explicit when-to-use versus siblings or any when-not/exclusion criteria.

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, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds that the entire law text is returned rather than a subset, which is useful return-scope context, but it says nothing about pagination/truncation behavior (covered only in the schema) or any rate/permission constraints.

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 with zero waste; the core action is front-loaded and the scope clarification follows immediately. 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?

For a read-only, idempotent retrieval tool with full schema coverage and no output schema, the description is largely sufficient: it states what is returned and at what granularity. It stops short of describing the offset-based continuation flow, but that is adequately handled by the schema.

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

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

Schema description coverage is 100%, so law_name, offset, and max_chars are fully documented in the schema. The description adds no parameter-level meaning beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource ('法令の全文を取得する') and clarifies scope ('条番号を指定せず法令全体のテキストを返す'), which implicitly separates it from article-level siblings. However, it never names or contrasts with the closely related 'get_law' sibling, so an agent cannot fully disambiguate between the two from the description alone.

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 '条番号を指定せず' implies this tool is for whole-law retrieval as opposed to article-specific tools, but no alternative (e.g., get_law, search_articles) is named and no explicit when-to-use condition is given. Usage is inferable rather than 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 readOnly/idempotent/openWorld/non-destructive, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the primary data source (MLIT PDF database), the e-Gov fallback, and the explicit not-found message when a number is absent from the MLIT DB.

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

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

Three sentences, front-loaded with purpose and input format, then source and fallback. Slightly redundant in restating the not-found behavior that the kokuji_name schema field already carries, but otherwise tight.

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-value explanation is unnecessary, and the description covers source, fallback, and error case adequately. Pagination via offset/max_chars is left to the schema, which is acceptable given full coverage.

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 the schema already documents offset, max_chars and kokuji_name with the same examples used in the description. The description adds no new parameter meaning (syntax, formatting, constraints) beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (全文を取得) and resource (建築基準法が技術基準を委任している告示), and names the input forms precisely. It is clearly distinguishable from siblings like get_law, get_full_law and search_law, which operate on laws rather than delegated technical notifications.

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 a clear context for use (retrieving full text of delegated technical standards) plus accepted input formats and a documented fallback path (e-Gov API when not found by name). It does not explicitly state when to prefer get_law or search_law over this tool, so it stops short of full routing guidance.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds genuinely useful scope information the annotations cannot convey: results are limited to amendments published on/after 2018-01-01 and only those listed on the MLIT (国交省) amendment pages. Pagination/return behavior is left to the output schema.

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

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

Four short sentences, front-loaded with the core action, then the sibling comparison, then the data-scope caveat, then the parameter rule. No filler; every 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 annotations covering safety and an output schema covering return shape, the description supplies exactly the remaining pieces an agent needs: what is returned, the data coverage window, the source, and the parameter selection rule.

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

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

Schema coverage is 100% and both params are optional, but the description adds a constraint the schema cannot express: exactly one of the two identifiers must be supplied. That mutual-exclusivity rule is real added meaning beyond the structured fields.

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 ('改正一覧だけを取得する') and immediately distinguishes itself from the sibling get_kokuji by noting it is the lighter-weight option that omits the body text. An agent can tell the two apart 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?

Names the alternative (get_kokuji) and the trade-off (lighter, no body text), and states the selection constraint that exactly one of kokuji_number / kokuji_name must be given. It does not spell out an explicit 'when not to use' case beyond the sibling contrast, so a 4 rather than 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 cover the safety profile (readOnly, idempotent, openWorld, non-destructive). The description adds genuinely useful behavior: the ~50,000-character cap on the whole response including structuredContent, the structured JSON hierarchy, and the find/matches continuation pattern. It does not describe auth or rate limits, but adds real context beyond the annotations.

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

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

Four dense sentences, purpose front-loaded, each carrying distinct information (scope, format options, size limit, find/offset rule). No filler, though the limit sentence is a bit convoluted.

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 explanation is unnecessary and the description rightly focuses on format choice, size cap, and pagination via find/offset. Covers what an agent needs to call it correctly, with the only gap being tool-level alternatives.

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 the per-parameter descriptions are already rich (find semantics, offset, max_chars range, enum for format). The description restates format=text vs structured and the find/offset workflow but adds little syntax or meaning beyond the schema. Baseline 3 is correct.

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?

Specific verb+resource: retrieve a law's provisions by article number, with explicit coverage of 附則・別表 and acceptance of abbreviations or official names. This implicitly separates it from get_full_law (whole law) by keying on a single article, but 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?

It gives good intra-tool guidance (use find for paragraphs/table rows in long articles, don't guess offset; format=structured for hierarchical JSON), but there is no statement of when to choose this tool over search_articles, search_law, or get_full_law. Usage across siblings is left 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 readOnly/idempotent/openWorld and non-destructive, so the safety profile is covered. The description adds real value beyond them: the 20-item batch cap, the ~50,000-character whole-response ceiling tied to structuredContent, and per-article e-Gov retrieval. It does not describe pagination or partial-failure behavior across the batch.

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 compact sentences with the purpose front-loaded, followed by limits and the alternative routing. Dense but every sentence carries information; 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?

An output schema exists, so return values need not be explained. The description covers scope, batch cap, character constraints, and the alternative for oversized items, which is sufficient for a batch-read tool; only cross-batch error/partial-result semantics 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?

Schema description coverage is 100%, so the baseline is 3, but the description adds rationale beyond the schema by explaining that the char limit exists to keep the whole response (including structuredContent) under ~50,000 characters. Minor tension between the stated ~50k total and the schema's 24,000 max_total_chars is not resolved.

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 (複数の法令・条文を一括取得) and clarifies the retrieval mechanism (each article fetched individually from e-Gov per article). It names the sibling get_law for the long-article case, letting an agent distinguish batch vs. single-article retrieval 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 a clear batch context plus an explicit routing rule: long articles (with a concrete example, 建築基準法施行規則 第1条の3) should use get_law instead. It does not address when to prefer this over get_full_law or search_articles, so no explicit exclusions for other siblings.

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, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds value by naming the metric categories returned, but says nothing about freshness, aggregation window, or scoping. With annotations carrying the safety burden, a 3 is appropriate.

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

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

A single front-loaded sentence with the resource first and the payload enumerated in parentheses. Every element earns its place and nothing is padded.

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 structure need not be described, and the description still previews the metric categories. Annotations cover the safety profile. The only gap is the absence of any usage context, which is minor for a zero-parameter read tool.

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

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

The tool takes zero parameters, which is the baseline-4 case. The description correctly implies no input is needed, and there is nothing further to document.

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?

Specific verb (返す) plus resource (使用量メトリクス), with an explicit enumeration of what is returned (tool call counts, API requests, cache hit rate, uptime). It is unmistakably distinct from the law-lookup siblings, though it never names or contrasts them, so it falls 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?

There is no when-to-use guidance, no mention of prerequisites or timing (e.g. for monitoring or diagnostics), and no reference to any alternative tool. The agent must infer the use case entirely from the 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 already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds genuinely useful behavioral detail: AND/OR/NOT are treated as literal search terms, wildcards are supported, full-width spaces are normalized, and results contain only section names and excerpts. That last point about missing article numbers is exactly the kind of non-obvious behavior an agent needs.

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, followed by query syntax and then the key caveat about missing article numbers. It is dense and mostly earns its sentences, though the syntax rules restate what the schema already says.

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, yet the description still usefully warns that results lack article numbers and points to get_law. Coverage of syntax, filtering, and the key limitation is sufficient for correct invocation.

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

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

Schema description coverage is 100%, so all four parameters are documented in the schema. The description's syntax notes (space-delimited AND, wildcard support) duplicate the keyword parameter's schema description verbatim and add no new semantics, so the baseline 3 applies.

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

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

The description names a specific verb and resource ('条文本文をキーワードで検索する') and clarifies the scope of results (節名と抜粋のみ, no article numbers). It distinguishes itself from get_law for accurate article text, but never contrasts with the sibling search_law, so the differentiation is only partial.

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

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

It explicitly routes the agent to get_law when exact article text is needed, since search results omit article numbers, and it explains the accepted query syntax. It gives no guidance on when to prefer search_law or suggest_related, so the routing is clear but not exhaustive.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld). The description adds genuinely useful context beyond them: the search spans both locally registered aliases and an external e-Gov API, which implies a network dependency and possible variability in results. It stops short of describing latency, rate limits, or result count 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?

Three short sentences, front-loaded with the core action followed by source coverage and then the caveat/alternative. Every sentence carries distinct information with no repetition of the tool name or 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 single-parameter read tool with annotations covering safety and openWorld, the description covers purpose, scope, and the sibling routing decision. The only omission is what the result looks like (law titles/IDs to feed into get_law), which matters mildly for chaining but is not required to invoke correctly.

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

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

Schema coverage is 100%, so the parameter itself is documented. The description nonetheless adds a semantic constraint the schema does not encode: the keyword is matched against law titles, not article text, which materially shapes what strings are worth passing. That is real value over the schema.

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

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

States a specific verb and resource ('キーワードで建築関連法令を横断検索する') and immediately names the scope (law titles only) plus the source coverage (registered aliases and the e-Gov API). It clearly distinguishes itself from search_articles, which operates on article bodies.

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 states the exclusion ('検索対象は法令名（タイトル）のみ') and routes the agent to the correct sibling for the other case ('条文本文のキーワード検索には search_articles を使用してください'). The when/when-not decision is fully specified.

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, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds only that references are derived automatically rather than looked up, which is mild context; it says nothing about coverage limits, confidence, or what a suggestion contains.

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

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

A single tight sentence with the action front-loaded and zero filler. It is appropriately sized for the tool's scope, though it is so terse that it leaves useful context unstated.

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 analysis tool with no output schema, the description should hint at the shape of the suggestions (e.g. related law names with the referencing provision). Annotations cover safety, but the agent still cannot anticipate the return payload.

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 both parameters carry their own descriptions with format examples (正式名称または略称, 第20条/20). The description adds no syntax or format meaning beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (自動抽出して提案) and a specific resource set: 関連法令・委任先・同法令内参照, scoped to a given 条文. An agent can distinguish this from get_law or search_articles, though it never names a sibling to sharpen the contrast.

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?

No when-to-use or when-not-to-use guidance is given. With siblings like verify_citation and analyze_article in the same family, the description should say when suggestion of related provisions is preferable to citation verification or article analysis, but it offers nothing.

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, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context beyond that: the batch ceiling of 10 items and the fact that accuracy checking is done via text matching (as opposed to mere existence lookup). It does not discuss failure behavior for unverifiable citations, which keeps it from a 5.

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

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

Three short clauses, no filler, and the core action is front-loaded before the capability details and the limit. Every sentence carries information an agent needs.

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 needn't explain return values, and it covers purpose, both verification modes, and the batch limit for a single-parameter tool. Slightly incomplete on what happens when a citation cannot be verified, but nothing critical 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 100% for the single 'citations' parameter, including per-field descriptions and the omission semantics of claimed_text, so the baseline is 3. The description's only added datum is the repeated 10-item limit, which the schema already enforces via maxItems.

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

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

The description names a specific verb and resource (verify legal citations contained in AI answers) and enumerates the two verification modes: existence confirmation and text-matching accuracy. This clearly separates it from siblings like get_law or search_articles, which retrieve rather than verify. It falls short of 5 only because it never names an alternative sibling to route against.

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 is implied by the phrase 'AIの回答に含まれる法令引用' — the tool is for checking citations produced by a model — but there is no explicit when-to-use/when-not guidance and no named alternative for adjacent tasks. An agent can infer the context but must guess at the boundary with analyze_article or get_law.

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