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

Annotations already flag destructiveHint=true and openWorldHint=true, and the description earns credit beyond them by explaining why: it starts messaging real people immediately, is limited to once per person per rule, and messages land in Message requests where they may go unseen. The safety confirmation requirement and plan gating are exactly the kind of 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?

Three sentences, front-loaded with the action and mechanism, then the risk warning and mitigation, then the plan requirement. Nothing is repeated from the schema and every sentence changes how the agent would behave.

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?

Covers purpose, risk, preconditions, plan gating, and delivery channel for a mutation tool with no output schema. The only minor gap is that it never says what is returned on success (a rule record, including the disclosure_missing field referenced in the schema), which matters slightly given there is no output schema.

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 parameter descriptions are already thorough (keyword whole-word matching, 1,000-byte DM limit, idempotency window, post_id null meaning all posts). The description only indirectly touches parameters via 'confirm the keywords and text' and 'enabled=false', so it does not add meaningful semantics beyond the schema. 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 (Creates) and resource (an Instagram comment DM rule) and then explains the mechanism: anyone commenting a keyword receives the message as one private DM, once per person per rule. That mechanism-level detail makes it unmistakable against siblings like update_comment_dm_rule or reply_to_comment without touching either 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 clear preconditions: confirm keywords and text with the user first, or set enabled=false, and the plan requirement (Team plan or Creator add-on). It stops short of naming the sibling that modifies an existing rule (update_comment_dm_rule) or the listing tool, but the when-to-use context is strong.

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