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

Beyond readOnlyHint=false and openWorldHint=true, the description discloses that each call consumes one token, creates an XBOSS task, and persists the processed result. It reinforces the non-read-only nature ('순수 읽기 전용이 아닙니다'), which is consistent with the annotations, and states no credential or login is required. The weakness is the unexplained distinction between 'authenticated calls' and 'anonymous taste calls' despite no auth parameter existing, leaving the idempotency applicability ambiguous.

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 purpose is present but buried behind a credential disclaimer, and the idempotency instructions form a dense bilingual block. The trailing sentences about institution source lookups and institution data changes are irrelevant copy-paste that do not earn their place on a blog-style tool. The Korean/English mixing further slows parsing, though the core workflow sentence is well 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?

There is no output schema, and the description never indicates what the returned style profile contains (structure, sections, or format), so an agent cannot anticipate the result shape. Operational behavior, cost, and idempotency are covered thoroughly, but the return-value gap and the irrelevant institution boilerplate keep this at a minimum-viable level.

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 there is only one optional parameter, but the description adds real semantic value: generate request_idempotency_key before the first request, reuse it only to recover a lost response, use a new key for a new execution, and do not confuse it with a provider-specific idempotency_key. It also notes that the key does not apply to anonymous calls, which the schema does not state.

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 second sentence states a specific verb and resource: retrieves the post composition and style compiled from the public XBOSS blog. It separates itself from generation-type siblings by declaring that it does not run paid AI generation, provider login, staging, or publishing. The signal is somewhat diluted by the leading credential sentence and by unrelated institution ('기관') boilerplate, but the resource is still identifiable.

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?

It gives a concrete downstream workflow: have the current AI write the body in this style, then stage it to naver.content.stage or tistory.content.stage. It also enumerates what the call does not do (paid AI generation, provider login, temp save, final publish), which functions as a when-not list. What is missing is an explicit rule for choosing among the actual sibling tools if those stage targets are unavailable to the agent.

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