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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new context beyond them: the result cap ('up to 15'), the returned fields (field, courses, address, phone), the data source (offices of education registration data), and the fact that returned data is in Korean. It stops short of saying what happens when results exceed 15 or how to retrieve more.

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?

Two tight sentences with no filler: the first establishes the resource, filter, and provenance; the second states the result cap, payload, and language. The most decision-relevant information (what the data is and how it is filtered) is front-loaded.

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 does well to name the returned fields and the 15-result cap, and the annotations cover the safety profile. However, it omits that region is required and that district, while strongly recommended, changes result breadth, and it gives no guidance on truncation when more than 15 matches exist. For a search tool whose main failure mode is over-broad or truncated results, that is a meaningful gap.

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 every parameter already carries its own guidance and Korean examples. The description echoes the subject and district filtering concepts and the 'Data in Korean' note usefully signals that keyword values must be Korean, but it does not document the required region parameter or add format constraints beyond the schema. Baseline 3 applies.

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 names a specific resource (registered private academies/hagwon and tutoring centers) and its scope (a South Korean district, offices of education registration data), which cleanly separates it from the sibling search_schools. It never uses an explicit action verb, but the filtering behavior and entity type are unambiguous enough that an agent can pick it over its siblings.

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 only implied through phrasing like 'filtered by subject keyword' and the schema note that district is 'strongly recommended'. There is no explicit statement of when to use this versus search_schools or get_school_info, and no exclusion guidance. An agent can infer the intent but gets no routing help from the description itself.

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