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

The annotations already declare readOnlyHint=false, openWorldHint=true and idempotentHint=false, so the description is not carrying the safety burden alone. It still adds two things annotations cannot express: that no key is required, and an explicit security warning not to post keys, tokens or passwords into the room — meaningful for an open-world write tool. It stops short of saying whether messages are visible to everyone or whether repeat sends duplicate.

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 action, then the two user-facing parameters, then the auth note and the secret-handling warning. It is short and well ordered, with only minor waste in repeating length limits that the schema already enforces.

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?

Three required parameters, no output schema, and annotations covering the mutation profile — the description is serviceable. It omits what happens on an invalid or expired room code, whether joining is a prerequisite, and any hint of the response, which for a write tool with no output schema is a noticeable gap.

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 all three parameters (code, name, text) are already documented in the schema. The description only restates the name range and the 2000-character text cap and adds "스스로 정함" (self-chosen), which is also in the schema — no new meaning beyond structured fields.

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 (post) and resource (room message), and the parenthetical English gloss removes ambiguity. It does not name a sibling such as room_read or room_join, so the agent must infer the write-vs-read split from the verb alone.

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 a useful precondition (no key/auth needed), which is real usage context. However, there is no explicit when-to-use versus room_join or room_read, and no statement about whether the sender must have joined the room first.

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