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

With readOnlyHint=true and openWorldHint=false already declaring a safe, closed-world read, the description adds genuine behavioral context: the result is an estimate, it returns the source and page URL, it is based on the 2027 CSAT reference, and grade cutoffs vary yearly with actual scoring. These caveats go beyond the annotations, though it says nothing about how inputs affect or limit the computation.

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?

It is reasonably short and front-loads the operation, but mixes Korean/English, a URL, and reference notes in a somewhat jumbled run-on. Nothing is wasted, but the structure is not cleanly organized around what the tool does versus what it returns.

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 6-parameter calculator with no output schema, the description explains neither the required inputs (mean, sd, raw, percentile) nor how they interact, which is the critical missing information. The output-side caveats ('estimate', source URL) are covered, but the input side — the actual burden here — is absent.

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 only 17% (just the subject enum); sd, raw, mean, percentile, and english_raw carry no descriptions in schema or prose. The description does not compensate at all, so an agent cannot tell what sd vs mean vs raw should hold or how they combine.

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 and title name a specific computation+resource (수능 표준점수·등급 / Korean CSAT standard score and grade), so the agent knows this converts CSAT raw scores into standard scores and grades. It does not differentiate from education siblings like naesin_grade or gpa_converter, but the purpose itself is unambiguous.

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?

There is no explicit when-to-use guidance and no mention of alternatives among the education siblings (naesin_grade, gpa_converter). The only hint is that it 'returns an estimate', which is about output, not usage. The agent must infer applicability from the name alone.

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