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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered; the description adds genuinely new behavioral detail the annotations cannot: the specific counting rules (NEIS Hangul 3 / ASCII 1), that SMS/LMS byte counts come back with a message type, and the token-vs-character rationale. It does not state the SMS/LMS thresholds that determine the type, which keeps it off a 5.

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 sentences, front-loaded with the deliverable and followed by the reason to use it. The enumerated list is dense but each item is a distinct output metric, so nothing is padding.

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 carries the burden of describing returns and does so by listing every count produced, which is sufficient to call the tool correctly. The only shortfall is that it never defines SMS/LMS byte cutoffs, so an agent cannot predict which message type will be reported.

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 coverage is 100% and the single parameter is already documented as 'Text to count (up to 100,000 characters)'. The description clarifies what kind of text is expected (Korean) but adds no syntax, encoding, or boundary behavior beyond the schema, so the 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?

Names a specific verb (count) and resource (Korean text) and enumerates exactly what is measured: characters with/without spaces, lines, words, UTF-8 bytes, NEIS bytes, SMS/LMS bytes. The enumeration and the '자기소개서' framing make it unmistakable versus the date/format/amount siblings, none of which measure text length.

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?

Explicitly states when to reach for it: 'Models see tokens, not characters, so use this instead of estimating length' — a clear trigger that preempts the common failure mode. It stops short of naming when-not conditions or a sibling alternative, but no sibling overlaps this function, so the gap is minor.

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