Publish a new post (새 글 발행)

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

Annotations already flag non-idempotent, non-read-only, open-world behavior; the description goes further by spelling out the concrete consequence (duplicate posts on retry) and adding rate limits (60 s apart, 20/day) plus the default-private safety posture, none of which appear in the annotations or schema. It stops short of describing the response or what happens to attachments, keeping it at 4 rather than 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?

Four short sentences, front-loaded with the highest-stakes fact (every call creates a new post), then the duplication hazard, then the safe default, then rate limits. No filler and no repetition of schema content.

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 an 11-parameter, non-idempotent mutation with an output schema already covering return values, the description supplies exactly the missing operational context: duplication risk, retry procedure, visibility default, and throttling. Nothing an agent needs in order to invoke it safely 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 100%, so every one of the 11 parameters is already documented, including enum meanings and defaults. The description restates the private default and markdown default but adds no syntax or format detail 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?

States a specific verb+resource ('Create a NEW post') and immediately disambiguates it from two siblings: 'this is not a draft and not an update,' ruling out tistory_save_draft and tistory_update_post. An agent can classify the tool 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?

Gives explicit when-to-use and when-not-to: check tistory_list_posts before retrying after an error/timeout, and use tistory_update_post to flip visibility to public after review. It also names the alternative path and the condition that selects it.

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