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

Goes well past the annotations (destructiveHint=true only signals danger) by explaining why: every new member receives the result, so each call is confirmed by default and that confirmation can be switched off, and the call waits for the owner's approval. The plan gating and admin restriction are operational facts an agent needs before invoking and are absent from the structured data.

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-loads the action and follows with prerequisites and approval behavior in a compact five-sentence block. The first two sentences overlap somewhat, restating the same change twice (welcome message / the group's AutoDM), which is minor waste but not confusing.

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 a three-parameter mutation with annotations and no output schema, the description covers permissions, plan gating, approval flow, and blast radius. The notable gap is that only `group` is required, yet nothing says at least one of `message` or `enabled` must be supplied for the call to do anything.

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 the baseline is 3; the description adds only a small increment, clarifying that `message` replaces the existing text rather than appending and restating that `enabled` toggles the AutoDM. It says nothing about the required-only `group` parameter or about calling with neither `message` nor `enabled`.

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 and resource: it changes the group's AutoDM, the welcome chat message Skool sends to each new member on approval, and can toggle it on or off. The read counterpart (get_auto_dm) is implicit in the framing, and an agent can distinguish this mutation tool from the many list/update group-content siblings 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 clear preconditions — admins only, `enabled` requires the Pro plan, and the call blocks on the owner's approval — which tells the agent when the call will succeed. It does not explicitly name get_auto_dm as the tool to read current state first, so the read-vs-write routing is left to inference rather than stated.

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