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

Goes well beyond the readOnly/openWorld annotations: discloses a seven-day cache, a per-person 60-second server-path throttle with no daily cap, the two execution paths (extension vs server) and how the 'via' field reports which answered, and named error codes with retryAfterSeconds. This is exactly the behavioral context annotations cannot carry.

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-loaded with the core purpose and scope in the first sentence, then error/rate-limit handling. It is long and dense, but nearly every sentence targets a distinct failure mode or routing decision, so little is wasted.

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 compensates by describing the return shape (found[].from is seed or L1:<seed>), the 'via' field, and every notable error path including retryAfterSeconds and the enableUrl. Nothing an agent needs to call or recover from this tool is missing.

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%, so both parameters are already documented. The description restates the 'up to 10 seeds' limit and reinforces the workspaceId omission rule, but adds little syntactic meaning beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

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 (expands), resource (seed keywords), mechanism (Naver autocomplete), and scope constraint (Naver Blog only), then disambiguates from the sibling by noting these are 'candidates to measure with research_naver_keywords, not proven keywords.' An agent can tell it apart from research_naver_keywords without opening the schema.

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?

Names the alternative tool and the condition that selects it, and gives explicit fallback routing: when naver_autocomplete_unavailable, 'pass your own keyword list to research_naver_keywords instead.' It also states the enablement precondition for the 403 case, covering when-not-to-call.

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