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

Goes well beyond the annotations (readOnlyHint=false, destructiveHint=true, idempotentHint=false) by disclosing that the request is AUTHENTICATED, must be Ed25519-signed over the handoff-signed-req statement, requires X-Agent-Id/X-Signature/X-Timestamp headers, can be handled by the local signing proxy, and that unsigned senders are rejected for anti-spoof. This is exactly the extra behavioral 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?

Front-loads purpose, then moves to the authentication/signing contract with clear emphasis via capitals and concrete header/proxy names. Every sentence earns its place, though the signing instruction sentence is dense and could be split for readability.

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 complex, nested-payload, auth-gated send tool with no output schema, the description covers the critical prerequisites (identity proof, signing, header names, proxy option, rejection of unauthenticated senders) and the protocol-selection rule. It omits success behavior, error shapes, and rate limits, which for a destructive send operation leaves minor gaps.

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 already 80%, so the schema documents protocol, pattern, message payload, as_company and credentials on its own. The description mainly restates the enum values and adds cross-cutting semantics (a payload with a conflicting protocol is refused, and the sender is authenticated by signature rather than an embedded key), which is useful but not enough to lift it above the high-coverage baseline.

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+resource ('Send a message') plus the full scope of protocols (MCP/A2A/ACP) and delivery patterns (1-1 through many-many), which clearly separates it from read/mutate siblings like get_message or delete_message. It does not explicitly contrast itself with near-neighbors such as send_signal or social_post, 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?

The text never says when to choose this tool over alternatives (e.g., send_signal, social_post, send_order) or what conditions gate usage beyond the auth requirement. The protocol/pattern enumeration is descriptive scope, not usage guidance, so an agent gets no routing help.

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