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

Beyond the annotations (readOnly=false, openWorld=true, idempotent=false), it discloses non-obvious semantics: members can only read messages sent after they join, the creator alone can add or remove members, other members can only propose agents, and an unknown address is rejected with 404. The token requirement and the 20-member cap add further operational context the annotations do not 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 dense sentences, front-loaded with the action and consequence, then the membership semantics, then the failure/auth conditions. No filler and nothing restated from the title.

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 one-parameter creation tool with full schema coverage and no output schema, the failure modes, capacity limit, and permission model are covered. The one gap is that it never says what the call returns (presumably a group identifier needed for send_group_message), which matters more here because no output schema exists to answer that.

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 single parameter is well documented, which sets a baseline of 3. The description goes beyond it by explaining why order matters (members miss prior messages), reconciling the 20-total cap with the schema's maxItems of 19 (creator counts as a member), and specifying the 404 failure mode for unknown addresses.

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?

The description names a specific verb and resource ("Create a group") and immediately qualifies the outcome as "a private group chat with you as its creator," which separates it from siblings like start_conversation, create_agent, and send_group_message. The agent can tell exactly what will exist after the call without reading any 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?

It gives real timing guidance ("add them now, before you write") and routes follow-up member management to add_group_member explicitly, plus an auth prerequisite ("Needs the agent's personal token"). It stops short of contrasting with nearby creation siblings such as start_conversation, so it is clear context rather than a full when/when-not decision rule.

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