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

Despite destructiveHint=true already signaling a harmful operation, the description adds substantial behavioral context: the confirm flag requirement, conversion of emailBodyText to Lexical content.root, support for emailLexicalContent, business permission prerequisites, FREE-business exclusion, and handling of grace-period warnings and resubscribe links. This goes well beyond the 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?

The description is front-loaded with the core action and mandatory confirm requirement, then moves to content options and preconditions. Every sentence adds meaningful guidance, though the length is slightly high for the amount of schema richness it covers.

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?

The description robustly covers safety preconditions (confirm, access checks, FREE restriction) and content support, which is critical for a destructive tool. However, with 21 params, no output schema, and low schema coverage, many parameter semantics remain incomplete, and it doesn't explain how parameters like sentPlatforms, selectedBuckets, or membership tiers interact or are validated.

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 only 19%, so the description must compensate for poor parameter documentation. It explains confirm, emailLexicalContent, and emailBodyText, but leaves 21 parameters mostly unexplained—many have no schema description at all. The agent is left guessing about communityId, messageId, sentPlatforms, title, author, bucketFilters, selectedUsers, etc.

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 clearly states the action ('Send a Magic Reach message') with a specific verb and resource. However, it does not explicitly differentiate from sibling tools like create_magic_reach_message, update_magic_reach_message, or send_magic_reach_test_message, so it doesn't fully meet the 5-level criterion.

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?

Provides strong contextual guidance: requires confirm=SEND, mandates calling check_business_tool_access before collecting inputs, excludes FREE businesses, and instructs never to proceed when access is blocked. It lacks explicit mention of alternative tools (e.g., test vs. live send), so it doesn't reach a 5.

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