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

No annotations are provided, so the description carries full burden of behavioral disclosure. The description mentions it returns '会議の全発言本文を含む詳細データ' (full speech text included), which adds some behavioral context. However, it does not disclose rate limits, auth requirements, cost implications of full-text retrieval, or what the response structure looks like beyond noting detailed 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?

The description is a concise single sentence with the key information front-loaded. It efficiently states purpose, output format, and record limit in one compact sentence. No wasted words, but it could have used the space to add sibling differentiation.

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?

This is a complex tool with 22 parameters and no output schema. The description mentions '詳細データ' (detailed data) but doesn't elaborate on what the output looks like or how the many date/range/session parameters interact. While the schema covers all parameter descriptions, the description itself provides limited guidance on how to combine parameters effectively for a search with this many options.

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 documents all 22 parameters with descriptions. The description adds only the 10-record maximum limit which is also in the schema's maximumRecords parameter (maximum: 10). The description's one extra note about meeting-unit output helps frame parameter semantics but adds nothing beyond the schema.

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

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

The description states '国会の会議を検索します（会議単位出力）' with a specific verb (検索 - search), resource (国会の会議 - Diet meetings), and output unit (会議単位 - meeting-unit). It distinguishes from search_speeches by noting meeting-unit output order. However, differentiation from search_meetings_simple is only implicit through the word 'full' in the tool name rather than explicit in the description.

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 notes '最大10件まで取得可能' (max 10 records retrievable), giving some practical usage constraint. However, there is no explicit guidance on when to use this tool vs. search_meetings_simple or search_speeches. The sibling differentiation is implied through the 'full' name and meeting-unit output but not explicitly 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?

No annotations are provided, so the description carries full burden. It discloses the output is '簡易出力' (simple/basic output) and the 100-record cap, but doesn't describe pagination behavior, rate limits, authentication needs, or what fields the basic output contains. For a search/read-only tool this is partially adequate but leaves return-format uncertainty.

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 compact at roughly two sentences, first stating the purpose and then the output. It's appropriately sized and front-loaded with the primary purpose. Each sentence earns its place with useful information (search capability, basic output format, record cap).

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 22 parameters, no output schema, and no annotations, the description is moderately complete. It explains the tool is a simple/basic search with a 100-record cap, but given the sheer number of parameters and sibling tools, the description could do more to explain the simple-vs-full distinction and how the output differs from search_speeches. The mention of '簡易出力' hints at this but doesn't elaborate.

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 mentions AND search for 発言内容 and basic info/speech list retrieval, which adds high-level context. But it doesn't explain how the many search parameters combine with each other (e.g., whether issuing a query for 'any' plus issueID narrows or overrides), so it mostly relies on the well-documented schema.

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

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

The description states it searches Diet meetings with basic output format, retrieving basic meeting info and matching speech list. The '国会の会議を検索します' gives a clear verb+resource. It distinguishes from siblings via '簡易出力' (simple output format), though it doesn't explicitly contrast with search_meetings_full or search_speeches by name.

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

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

The description implies usage for searching meetings with basic output, and '最大100件まで取得可能' gives a key constraint. However, it doesn't explicitly state when to use this vs the 'full' variant or when to prefer search_speeches instead. No exclusions or alternatives are named.

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

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

No annotations are provided, so the description carries full burden for behavioral disclosure. The description notes the 100-record maximum and per-speech output unit, which is useful. However, for a search/search tool with 22 parameters, it doesn't disclose pagination behavior, result ordering, error behavior, or whether results are returned in chronological order. The completeness notes are thin for such a complex tool.

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

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

The description is two tight sentences. It front-loads the core purpose (search speeches), adds output granularity (per-speech unit), and caps expectations with the 100-record limit. No wasteful content. Appropriate for a tool whose heavy lifting is delegated to the comprehensively documented 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 22-parameter tool with no output schema and no annotations, the description is arguably thin. However, the schema is 100% documented, which mitigates the parameter burden. The description confirms output granularity and the cap, which are the biggest unknowns. It could benefit from noting result ordering, but the core usage is adequately conveyed given the schema's thoroughness.

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 22 parameters. Baseline is 3. The description adds nothing about parameter semantics beyond what the schema provides — it doesn't explain any parameter interactions or common filter combinations. Schema carries the full weight, which is acceptable at the baseline level.

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 states '検索します' (search) with clear resource being speeches (国会の発言), and notes it outputs per-speech units (発言単位出力) and returns individual speech text. This distinguishes from siblings search_meetings_simple and search_meetings_full which target meetings, but doesn't explicitly name them as alternatives. Purpose is clear and specific.

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

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

The description implies this is for searching speech-level content (as opposed to meeting-level search in siblings), but does not explicitly state when to use this vs the meeting-search tools or provide exclusion criteria. No mention of when not to use it. Usage context is implied by the resource type rather than explicitly stated.

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