search_tanka

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

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

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

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

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

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

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

For a tool with 7 parameters, no annotations, and no output schema, the description is remarkably complete. It covers the purpose, parameter semantics, special-case behaviors, and filter interpretation. The only missing details are minor (e.g., exact return-field structure, pagination behavior), and the schema already documents limit defaults.

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

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

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

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

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

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

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

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

The description provides explicit routing guidance: when to use besshi vs. the legacy type parameter, which besshi values return structured data vs. raw text, and when kasan_keyword applies. It clearly states exclusions, such as besshi="3","6","8","11","12" returning full text rather than structured tables, so an agent can select the correct mode without guesswork.

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