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

Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, so safety is covered; the description adds genuinely new context: values are NHIS-published evaluation results refreshed once a year, and missing values must not be guessed but referred to the page url or contact page. It does not mention result caps or paging behavior despite the limit parameter's max of 20.

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 action is front-loaded and both language versions are tightly written with no filler. Slight inefficiency in that the English half drops the filter enumeration and return fields present in the Korean half, so the bilingual pair is not fully parallel.

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 no output schema, the description correctly fills that gap by naming the return fields (grade, evaluation year, address, page url), and it adds provenance plus an anti-hallucination rule for missing data. It leaves result-set size/paging behavior around the limit parameter unstated, which is the main remaining gap 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 description coverage is 83%, so the schema already documents q, svc, sido, grade and gugun; the description largely restates those same filter axes and the 'code or name' / 'name or region substring' semantics already present in the schema. The limit parameter is not addressed anywhere in the description, so it adds little beyond the 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?

States a concrete verb+resource (find/filter long-term care institutions) plus the exact filter axes (name/region, province, district, service type, grade) and what comes back (grade, evaluation year, address, page url). The multi-result search/filter scope clearly separates it from get_institution and compare_institutions without needing to name them.

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 by the filter enumeration ('find by name/region or filter by province/district/service/grade') and by the directive on missing values, but the description never names an alternative tool or states when a caller should prefer compare_institutions, get_institution, or list_regions. Adequate but leaves routing to inference.

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