legal-research

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

Annotations already indicate readOnlyHint=true, and the description adds context about full_text_available flag and how to obtain full text via get_material_body_text. No contradictions. However, it does not mention pagination or ordering, but overall sufficiently transparent.

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

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

Description is concise, well-structured, front-loaded with the main purpose, then details, and ends with usage alternatives. Every sentence adds value.

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 simplicity (2 params, no output schema), the description is complete: it explains what it does, what it returns (listing fields), and how to use the output (via get_material_body_text for full text). It also provides alternatives for related tools.

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%, both parameters have descriptions. The description does not add significant new meaning beyond what the schema provides, only reinforcing that they identify an article. Baseline 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 clearly states that the tool returns a list of administrative materials indexed to a specific article, specifying the required parameters (law_id and article_num) and the returned fields (title, source URL, type, date). It also distinguishes from sibling tools like research_revision_primary_sources and search_diet_records.

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 provides usage guidance: to trace primary sources use research_revision_primary_sources, for diet records use search_diet_records, implying this tool is for administrative materials. This helps the agent decide when to use this tool vs. alternatives.

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

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

The description discloses several behaviors beyond the readOnlyHint annotation: results include target/related_targets for chaining, citation rules for outputs, and conditions for including user context. It also explains the format of the target parameter and that include_user_context requires user permission. No destructive actions are indicated, consistent with the annotation.

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 lengthy and begins with a block of citation rules before stating the tool's main purpose. While it contains valuable information, it could be more structured and concise. The important points are present but buried in verbosity.

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 (17 parameters, no required, output schema present), the description covers the main aspects: the bundled result types, chaining capability, citation rules, and user context conditions. It does not detail error handling or edge cases, but the basic usage and output are well explained. The output schema covers return structure, so completeness is adequate.

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 baseline is 3. The description adds meaningful context beyond the schema by explaining the relationship between include_user_context and include_private_sources, providing examples for the target parameter, and specifying when to set include_official_verification_url. This extra detail justifies a score of 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?

The description clearly states that the tool retrieves a comprehensive bundle of information around a legal article, including the article text, delegations, referenced articles, judicial cases, administrative materials, and user context. It distinguishes itself from siblings like get_law, get_judicial_cases, and get_administrative_materials by aggregating multiple sources into one response.

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 rules for citing outputs (preferred_citation vs official_verification_url) and explains when to use parameters like include_user_context and include_private_sources. However, it does not explicitly compare to sibling tools for when to choose this tool over a more specific one, though the purpose implies it's for comprehensive context.

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 tool has readOnlyHint=true via annotations, which the description does not contradict. However, the description adds only minimal behavioral context (e.g., that URLs are usable as citations), beyond what annotations provide. This is adequate but not enhanced.

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 overly verbose, with a lengthy preamble about general citation rules that applies to multiple tools. The core purpose is buried in the latter half, reducing conciseness. It could be significantly shortened.

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 that an output schema exists (context signals indicate it), the description adequately covers the tool's main behavior: retrieving a list of delegated regulations and noting that URLs are directly usable. No major gaps are apparent, though specific output details are left to 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 coverage is 100% (baseline 3). The description adds meaning by explaining that law_id and article_num must be specific and includes usage context for the boolean parameter (including when to set it true). This adds value beyond the schema.

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

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

The description clearly states that the tool retrieves a list of delegated regulations (施行令・施行規則等) for a specified article, which is a specific verb-resource combination. However, the first part contains general citation rules not specific to this tool, slightly reducing clarity.

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

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

The description explicitly states when to use this tool (when law_id and article number are confirmed) and directs users to alternative tools (search_laws, research_law_delegations) for other cases, providing strong usage 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 provide readOnlyHint: true. The description adds extensive behavioral details: disabling local snapshots, treating raw_xml.content plus attachment bytes as source of truth, preserving RemarksLabel and table-cell boundaries, and never replacing Fig with fallback text. It also clarifies the include_official_verification_url parameter's restricted use. No contradictions.

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 verbose, especially the Japanese citation note which, while important, could be more concise. However, the structure is logical: usage note first, then purpose, then detailed output behavior. For the complexity, the length is justified.

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

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

With 11 parameters, full schema coverage, and an output schema, the description provides comprehensive context: purpose, citation rules, when to use, parameter semantics, and output handling. It covers all necessary aspects for correct invocation and use of the 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 100%, so baseline is 3. The description adds significant value beyond the schema, especially for include_official_verification_url (explicit usage restriction), include_display_audit (explanation of audit contents), include_table_row_index (details on row expansion), and include_attachment_manifest (manifest building details). This greatly aids agent understanding.

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

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

The description clearly states 'Fetch the official e-Gov law_data XML directly with local snapshots disabled' and specifies the purpose: 'Use this when exact official text or display fidelity matters.' It distinguishes from siblings by emphasizing direct e-Gov fetch vs. local snapshots.

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 includes a Japanese note on citation rules for law tools, implying proper use of outputs. It states 'Use this when exact official text or display fidelity matters,' but does not explicitly list when not to use or name alternative tools. Still, context is clear.

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

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

Annotations already declare readOnlyHint=true, so the description adds value by detailing the returned fields and the source website. No contradictions; the description aligns with the read-only nature.

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 concise and front-loaded with the tool's action. Every sentence is informative without unnecessary verbosity.

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

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

Given no output schema, the description lists all returned fields, explains the two-step workflow, and identifies the data source. It is complete for an agent to understand and use the tool correctly.

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

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

The single parameter detail_url is fully described in the schema (100% coverage). The description adds context by linking it to search_judicial_cases's source_url and providing an example, enhancing understanding.

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

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

The description clearly states the tool retrieves detailed information from a Japanese court case page (courts.go.jp), lists the specific fields returned, and distinguishes it from sibling tools like search_judicial_cases.

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 describes the two-step usage: first use search_judicial_cases, then pass the source_url to this tool. It also specifies to pass the URL as-is, providing clear when-to-use guidance.

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

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

Annotations already provide readOnlyHint: true. Description adds value by explaining data source (courts.go.jp) and what fields are returned. No side effects or destructive actions disclosed but consistent with annotations.

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

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

Three sentences, front-loaded with core action, then details and usage guidance. No redundant or unnecessary words.

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 read-only list tool with two required params and no output schema, the description provides all necessary context: purpose, input parameters, output fields, source, and alternative tool for different queries.

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% with descriptions for both parameters. Description does not add new semantics beyond stating they are used to specify the article. 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?

Description clearly states the tool returns a list of judicial cases indexed by law_id and article_num, including specific fields (case name, court, date, URL) from courts.go.jp. It differentiates from the sibling search_judicial_cases.

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 for cases by specific article and to use search_judicial_cases for free keyword search. Provides clear when-to-use and when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint=true, and description is consistent. It adds behavioral context on citation behavior (preferred_citation vs official_verification_url) and fallback scenarios, exceeding annotation coverage.

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?

Description is verbose and mixes multiple instructions (citation rules, usage, parameter details) into one block. While front-loading the citation rule is good, it could be more concisely structured.

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 output schema exists and annotations are present, description covers most aspects: purpose, usage, parameter details, citation rules, and fallback behavior. Minor gap: no mention of handling invalid law_id or missing articles, but overall very complete.

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

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

Schema coverage is 100%, so baseline is 3. Description adds value with concrete examples for law_id and article_num, and reiterates conditions for include_official_verification_url, enhancing parameter understanding.

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

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

Description clearly states it retrieves law metadata, article text, and deep links from law_id, with specific behavior for article_num. It distinguishes from siblings by referencing search_laws and research_law_delegations for different use cases.

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 advises using search_laws if law_id is unknown and research_law_delegations for delegation relationships. Also provides detailed citation rules for preferred_citation, text_provenance, and official_verification_url, guiding the agent on when to use each.

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

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

The description adds that results are returned in descending order (newest first) and include statuses like current/past/unenforced enforcement. However, annotations already declare readOnlyHint=true, so behavioral disclosure beyond that is minimal; no mention of limitations or edge cases.

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 includes a lengthy citation rule that appears to be system-level and not specific to this tool, making it less concise. The core tool description is clear but front-loading a generic rule wastes space.

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 presence of an output schema and readOnlyHint annotation, the description adequately explains the data returned, use cases, and tool combinations. Some minor gaps (e.g., no mention of error handling) but overall sufficient.

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% with detailed parameter descriptions. The description adds a hint that law_id can be obtained via search_laws and clarifies include_official_verification_url's usage for special citation, but this adds only marginal 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?

The description clearly states that the tool retrieves amendment history of a specified law from the e-Gov API, listing publication/enforcement dates, amending law, and enforcement status. It distinguishes itself from siblings like get_law (text retrieval) and research_revision_primary_sources (primary source links).

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 specifies when to use the tool (checking amendments, unenforced amendments, current version) and explicitly recommends combining it with research_revision_primary_sources and get_egov_law_data for related tasks, providing clear guidance versus alternatives.

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, which is consistent. The description adds that the transcription is AI-generated and the original source is authoritative, and that only operator-approved texts are published. This provides 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?

The description is a single paragraph of 4 sentences. Each sentence adds value: purpose, scope, usage hint, and caution about AI transcription. It is clear but could be structured slightly more for readability.

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

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

Given no output schema, the description explains what is returned (transcribed text) and its limitations (AI-generated, original as authoritative). For a single-parameter tool with useful siblings, this provides sufficient context.

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

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

Schema description coverage is 100%, so the schema already documents the id parameter. The description adds guidance: 'id には get_administrative_materials が返す full_text_url をそのまま渡してください', which clarifies how to obtain the id from a related tool.

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

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

The description clearly states the tool retrieves the '読み起こし全文' (transcribed full text) of administrative materials, specifying the verb and resource. It distinguishes from siblings like get_administrative_materials (which lists materials) and read_primary_source (which reads original PDFs).

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 explains when to use: for materials that AI cannot read directly (vertical writing, image PDFs). It also notes only operator-approved texts are available. It provides a specific usage hint: pass the full_text_url from get_administrative_materials as the id. However, it does not explicitly state when not to use or name alternatives.

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

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

The description adds valuable behavioral context beyond the readOnlyHint annotation: it explains the data is user-created working material, not official legal authority, and requires a specific flag to be set. This helps the agent understand the nature and constraints of the operation.

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 four sentences, each with a clear purpose: function, usage condition, prerequisites, and content nature. No unnecessary words or redundancy. It is front-loaded with the core action.

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, and prerequisites well, but there is no output schema, and the description does not explain the response structure or pagination behavior (though limit is described in schema). For a tool with 11 parameters and no output schema, additional context about return format would improve completeness. The description is adequate but could be more thorough.

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 all 11 parameters in detail. The description only briefly mentions include_private_sources=true must be set, which is already in the schema. No additional meaning is added for parameters beyond what the schema provides, meeting the baseline but not exceeding it.

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

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

The description clearly states the tool returns 'the authenticated user's private article memos and requirement fact diagrams as AI source context.' It specifies 'private' and 'authenticated user,' distinguishing it from siblings like get_article_context which likely returns public context. The verb 'Return' and resource 'private article memos and requirement fact diagrams' are specific and non-tautological.

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

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

The description explicitly says 'Use this only when the user explicitly asks to include their saved memo/diagram in the AI output.' It also mentions prerequisites: API key must have personal sources enabled and include_private_sources must be true. While it doesn't name alternatives like get_article_context, the context is clear enough for an agent to differentiate.

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

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

The description discloses that the applied text is machine-generated and should not be treated as legal interpretation, and that the tool stops on article number conflicts. This adds value beyond the readOnlyHint annotation, though it could further clarify 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?

The description contains essential information but is verbose, starting with a lengthy mandatory citation rule in Japanese that may be tangential to tool invocation. It could be more concise by separating tool behavior from citation policies.

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

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

Given the tool's complexity (7 parameters, specialized function), the description covers purpose, parameter details, and behavioral notes adequately. With an output schema available, the omission of return value details is acceptable.

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?

With 100% schema coverage, the baseline is 3. The description adds meaningful context for parameters like reading_article_num (multiple accepted formats), reading_article_location (when to use main), and include_official_verification_url (when to set true), enhancing semantic understanding beyond the schema.

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

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

The description clearly states that the tool applies reading substitution rules to the main provisions and returns both original and applied text, along with audit information. It distinguishes itself from sibling tools like 'get_law' which simply return raw law text.

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 includes extensive citation rules and conditions for using certain parameters (e.g., reading_article_location when article numbers conflict), but it does not explicitly guide the agent on when to use this tool versus its siblings. Usage context is implied rather than direct.

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 annotations (readOnlyHint=true), the description discloses domain restrictions, handling of scanned images (status=no_text_layer), chunking via max_chars/start_char, and citation requirement (use final_url). No contradictions.

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

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

The description is a single dense paragraph covering all points efficiently. It is front-loaded with purpose but could be slightly more structured with bullet points or separate sections. No waste.

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 3 parameters and no output schema, the description fully covers behavior for different inputs (scanned PDFs, chunking), domain restrictions, and citation instruction. 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?

Although schema coverage is 100%, the description adds context: explains max_chars default (50000), start_char default 0, continuation via truncated flag, and that url must be from specific domains. Adds significant value.

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 specifies that it retrieves primary sources (PDF/HTML) from official Japanese government domains (*.go.jp/*.lg.jp) and extracts text for evidence in AI answers. It lists specific document types (notifications, guidelines, etc.) and clearly distinguishes from sibling tools.

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

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

Explicitly states when to use (when URL is known, for official documents) and when not (other hosts are not fetched). Also provides guidance for scanned PDFs by directing to get_material_body_text.

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 denote readOnlyHint=true. The description adds that it returns URLs and a not_found/fallback_recommendation on failure, which provides behavioral context beyond the annotation. No rate limits or auth are mentioned, but the readOnlyHint covers safety.

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 lengthy (over 500 characters) and front-loads a citation rule that is not specific to this tool, reducing clarity. It could be more concise by moving the citation rule to a shared context or trimming it.

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 presence of an output schema, the description need not detail return values. It covers usage context, fallback, and alternatives, making it largely complete for a specialized tool. Minor gaps exist (e.g., no sample output), but overall adequate.

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%, but the description adds significant value: it recommends using article_num for delegation investigation, provides example law_id, and clarifies that query is a fallback. This helps the agent select and fill parameters correctly.

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 is for investigating delegation relationships from law articles to subordinate regulations, and differentiates it from the sibling tool 'research_legal_question'. However, the initial paragraph about citation rules is distracting and delays the core purpose statement.

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 clear when-to-use guidance: '委任関係が主眼ならこのツールが最短です' (if delegation is the focus, this tool is fastest). It also suggests using research_legal_question for general questions and explains fallback behavior on failure.

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

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

The description adds behavioral context beyond annotations: it explains the semantic search engine, citation handling rules, and fallback behavior. Since annotations already provide readOnlyHint=true, the description enhances transparency without contradiction.

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 verbose, including many citation rules and fallback instructions. While structured and front-loaded with important rules, it could be more concise. Every sentence adds value, but the length could be reduced.

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

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

Given the tool's complexity (7 params, many siblings, output schema present), the description provides sufficient context: purpose, usage, fallback, and citation rules. It is complete enough for an agent to use correctly without ambiguity.

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 parameters thoroughly. The tool description focuses on overall usage rather than parameter details, adding minimal extra semantics. 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 clearly states the tool is a natural language entry point for legal questions, using semantic search to retrieve relevant articles, delegations, and URLs. It distinguishes from siblings by specifying it is the first step for general legal queries, with fallback to other tools.

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

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

The description explicitly states when to use the tool (before answering legal questions) and provides fallback recommendations (search_laws → get_law/get_egov_law_data on not_found). It also specifies citation rules for handling results.

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, so the description does not need to restate that. The description adds valuable behavioral context: it returns only direct links verified from a specific source, and states that unreturned material types should be treated as unregistered/unconfirmed. This goes 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 description is extremely concise: two sentences that convey the tool's core function, scope, and limitations. Every sentence adds value, and the structure is front-loaded with the main action. No wasted words.

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 (9 parameters, no output schema), the description is fairly complete: it defines what is returned (confirmed direct links), what is excluded, and how to interpret missing types. However, the absence of any description of the output format (e.g., list of URLs or objects) is a minor omission since there is no output schema to compensate.

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 does not add additional parameter-level semantics beyond what is already in the schema. Each parameter's purpose is well-described in the schema, and the tool description focuses on overall behavior rather than specific parameter usage.

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

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

The description clearly states the tool returns primary source links for amendment research, specifically those confirmed via 政省令わかるくん. It explicitly excludes list/search result pages, making the purpose specific. However, it does not explicitly differentiate from sibling tools like 'read_primary_source' or 'search_egov_law_text', which could overlap.

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 no guidance on when to use this tool versus alternatives such as 'read_primary_source' or 'get_egov_law_data'. It does not mention prerequisites or scenarios where this tool is preferred, which is a significant gap for an AI agent deciding among 20 sibling 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 declare readOnlyHint=true, and the description adds value by listing return fields and requiring citation. No contradiction; the description enriches the behavioral profile.

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 concise, front-loaded with source and purpose, and includes return fields, use case, and citation instruction without unnecessary 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 no output schema, the description lists return fields and explains the context well. It could mention pagination or error handling, but overall it's comprehensive for a 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%; description adds examples for keyword ('bill names, statute names, etc.') and notes limit default, providing context beyond the schema alone.

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

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

The description clearly states it searches diet records (国会会議録) by keyword, specifying the source system and return fields, distinguishing it from sibling tools like search_laws or search_judicial_cases.

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 a clear use case: tracing legislative intent and Diet discussions. It does not explicitly exclude alternatives but contextually implies this tool is for parliamentary records, not laws or court cases.

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

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

The description confirms read-only operation (consistent with readOnlyHint=true). It explains returns are metadata and excerpts, not full text, and covers all e-Gov laws, adding context 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 lengthy and front-loaded with citation rules in Japanese, which distracts from the core purpose. Important functional details are present but buried, reducing conciseness.

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 four parameters and existence of output schema, the description adequately explains return values and search scope. It covers limitations (no full text) and source. Minor omission: no mention of result ordering or pagination.

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?

With 100% schema coverage, description adds meaning: keyword examples and advice, limit range and default, law_type enums, and condition for include_official_verification_url. All parameters are enriched.

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

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

The description clearly states the tool searches full text of all current e-Gov laws by keyword. It returns law_id, law_name, position, and excerpts, distinguishing it from siblings like get_law which retrieves full articles.

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 when to use it: when you don't know which law or article applies, as a starting point. It also tells users to use get_law or get_egov_law_data for actual text. However, it does not explicitly exclude alternatives for similar searches.

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=true, and description confirms read operation. Adds behavioral context: searches courts.go.jp website, returns specific fields (event name, court, date, URL), and performs cross-search beyond specific articles.

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 with no wasted words. Front-loaded with core purpose, then alternative usage, then return fields. Efficient and complete.

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 moderate complexity (4 params, 1 required) and lack of output schema, the description covers purpose, when-to-use, behavior, and return values adequately. No gaps for agent decision-making.

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 provides 100% coverage with descriptions for all 4 parameters. Description adds value by explaining the free-text nature of 'keyword' and listing example search terms (event names, issues, parties) that go beyond the schema's generic 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?

Description clearly states it searches judicial cases from courts.go.jp with free keywords, distinguishing it from get_judicial_cases which targets specific articles. The verb '検索' and resource '裁判例' are specific and unambiguous.

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 provides when-to-use (free keyword search for cases by event name, issues, parties, etc.) and when-not-to-use (prefer get_judicial_cases for article-specific cases). Directs to a sibling tool for an alternative use case.

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, so the read-only behavior is known. The description adds that the search is semantic, uses the same engine as the site's AI search, and can fetch articles from e-Gov even outside the collection if law_id and article_num are known. It does not discuss rate limits or authentication, but these are less critical given the read-only hint. Overall, good additional context 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 lengthy and includes a prominent rule about citation formatting at the start, which is important but may distract from the core purpose. While it front-loads key information, the structure could be more organized (e.g., separating usage rules from behavior). It earns its keep but is not optimally concise.

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 complexity (6 parameters, output schema exists, many sibling tools), the description is complete. It covers when to use the tool, how to format citations, handling of different sources (e-Gov, judicial cases, etc.), and fallback behavior. With an output schema present, it does not need to detail return fields. The description fully equips the agent to invoke the tool correctly.

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

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

Schema coverage is 100%, so parameters are fully documented. The description adds value by providing concrete examples for the 'query' parameter, warning against using appendix numbers in 'article_num', and explaining the nuanced usage of 'include_official_verification_url' (set only when user explicitly asks for independent verification). This helps the agent use parameters correctly.

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

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

The description clearly states that the tool performs semantic search of law articles from natural language, keywords, or law names, and returns citations and URLs ready for use. It explicitly positions itself as the first candidate for Japanese law article search, distinguishing it from sibling tools like search_laws and search_egov_law_text.

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 comprehensive usage guidance: when to use this tool (first candidate for Japanese law article search), how to handle results (prefer preferred_citation, use text_provenance as secondary, official_fallback_url only in failure or explicit user request), and implicitly when to use other tools (e.g., judicial cases use their own tools). It also advises on specifying law_id and article_num for better precision.

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?

While annotations already indicate readOnlyHint=true, the description adds critical behavioral details: it searches both stored laws and live e-Gov, covers about 9,500 laws, and explains citation behavior with preferred_citation, text_provenance, and official_verification_url. No contradiction with annotations.

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

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

The description is front-loaded with a long citation rule that, while important, could be separated or placed in a shared context. The actual search functionality description is succinct but the overall text is verbose. Every sentence is valuable, but structure could be improved for quicker parsing.

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 (3 parameters, output schema, many siblings), the description is very complete. It explains the tool's role in the workflow, how to handle results, and ties to other tools. It covers all necessary aspects for correct invocation and follow-up.

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?

Input schema covers all 3 parameters with descriptions (100% coverage), so baseline is 3. The description adds value by explaining that query can be a law name, abbreviation, or law_id, and by clarifying the specific usage of include_official_verification_url (only when user explicitly asks). This raises the score slightly.

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

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

The description clearly states the tool's purpose: searching for law_id and law page URL from various inputs (law names, abbreviations, etc.). It also distinguishes itself from siblings by specifying that it should be called first when law_id is unknown.

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 when to use this tool ('law_id が不明なときは常にまずこのツールを呼び') and provides extensive citation rules for interacting with its output, including when to use preferred_citation vs official_verification_url. It also references sibling tools for subsequent steps.

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