committee_search

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety profile is covered. The description adds behavioral details beyond annotations: response formats ('JSON', 'XML', 'HTML'), search modes (search=1 for case name, 2 for full text), OC override behavior ('defaults to env var'), and automatic injection of ctx. It also explains pagination defaults (display max 100, page 1-based). This adds meaningful context beyond the structured 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 well-structured with sections for purpose, Args, Returns, and Examples. It is appropriately sized for a tool with 9 parameters and includes only relevant information. The only mild redundancy is the Korean phrase duplicating the English statement, but all content earns its place.

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

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

Given the tool's complexity (9 parameters, no output schema), the description is remarkably complete. It covers parameter meanings, valid values, defaults, response format options, and an example. It states the return type ('Committee decision list or error') which suffices in absence of an output schema. No significant gaps remain.

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

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

Schema description coverage is 0%, so the description carries full responsibility for explaining all 9 parameters. It does so thoroughly: committee lists valid Korean names, query has default '*', display has max/default, page is 1-based, oc overrides env var, type lists accepted formats, search defines numeric meanings, sort and gana are briefly described. This fully compensates for the schema's lack of descriptions.

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: 'Search committee decisions (위원회 결정문 목록 조회)' from Korean government committees. The verb 'Search' plus the specific resource 'committee decisions' distinguishes it from sibling tools like law_search and prec_search, which target different legal document types.

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 context: it searches decisions from Korean government committees, and lists the valid committee names. It includes an example. However, it does not explicitly state when not to use this tool versus alternatives (e.g., 'use for committee decisions only'), but the context is unambiguous enough for an agent to select it appropriately.

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