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

Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=false and openWorldHint=true, so the "WRITE:" prefix largely restates structured data. The description adds only the HTTP endpoint, and says nothing about what happens when member ids are invalid or whether a failed create leaves partial state. Some added value, but not much beyond annotations.

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?

Two short sentences with the action and method front-loaded and no filler. The trailing "POST /contactgroups" endpoint is of marginal value to an agent selecting the tool, keeping it just short of a 5.

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 no return-format detail, and the description omits error/validation behavior for a non-idempotent write. The annotations do carry the safety profile, so this is adequate but with clear gaps for a mutation tool.

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 67%: the schema itself documents that members are contact ADDRESS ids (not contact ids) and explains customer_id for MSP accounts. The description's "existing contact address ids" reinforces the most error-prone parameter but adds no new syntax, limits, or meaning beyond the schema; baseline 3 is appropriate.

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 ("create a contact group") plus the construction constraint ("from existing contact address ids"), which separates it from update_contact_group and delete_contact_group. It is clear but never names the siblings it is not, so it stops short of a 5.

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?

"from existing contact address ids" implies the prerequisite that contact address ids must already exist, but there is no explicit when-to-use versus update_contact_group, no guidance when a group already exists, and no mention of the list_contacts/list_contact_groups workflow. Usage is only implied.

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