find_benefits

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuine behavioral context beyond that: eligibility is determined by coded conditions, and insufficient information is returned as follow-up questions rather than silently dropped, plus include_needs_info controls whether pending determinations appear.

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?

Front-loads the purpose sentence before the parameter list, and each arg line is tight. The length is justified by 10 undocumented parameters, though a few lines could be trimmed without loss.

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 values need not be described, and the description fully covers parameters and the follow-up-question behavior. The only material gap is the absence of sibling routing guidance for a tool sitting alongside search_benefits and check_eligibility.

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 must carry the full burden, and it does: every one of the 10 params gets meaning, format, and examples (e.g., sido '서울, 경기도, 부산광역시', traits ['직장인','1인가구'], limit default 20/max 50). It also encodes edge-case rules (leave blank if unknown, empty list [] if not applicable) and cross-references list_profile_options for valid trait values.

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+scope: finding government/municipal benefits a user can receive, judged by coded eligibility conditions, and returning follow-up questions when data is insufficient. This is clear, but it does not explicitly differentiate itself from siblings like search_benefits or check_eligibility, which appear to operate in the same space.

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 rather than explicit: it tells the agent to leave params blank if unknown and to consult list_profile_options for trait options, but never states when to choose this tool over search_benefits or check_eligibility. Partial guidance for parameter handling, none for tool selection.

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