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

Goes well beyond the annotations: it discloses exactly what payload leaves the system (supplied message plus the connected account's verified email), that document content and conversation history are opt-in, that secrets should be excluded, and — critically — that success only means the email provider accepted the request, not that support read or replied. That last point is a real behavioral trait an agent needs to avoid over-promising to a user, and it is not derivable from readOnlyHint/openWorldHint/idempotentHint.

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?

Five sentences, all substantive, with the critical precondition front-loaded in sentence one. Slightly dense — the data-sharing and idempotency rules could be tightened — but nothing is filler and each sentence carries distinct information.

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 2-param mutation tool with no output schema and an open-world side effect, the definition covers payload scope, opt-in data sharing, retry semantics, and success criteria. The remaining gap is error/failure behavior (e.g., what a rejection looks like or delivery limits), but the essentials for correct invocation are present.

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 0%, so the description carries the full param burden, and it does so: 'message' is constrained to only the supplied message (nothing else leaks), and 'idempotencyKey' is explained as generate-fresh-per-message versus reuse-with-identical-message-within-24-hours. That is operational semantics far beyond the UUID format in the schema, and it coherently explains the idempotentHint annotation.

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 support message to SharedBrief') and immediately scopes it with a precondition. It is unmistakably distinct from all sibling tools, which are entirely document-management operations, so an agent can never confuse this with get_document or update_document.

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 a clear gating condition ('only when the user explicitly asks to contact support') and clarifies what is shared by default versus what requires explicit user selection. No alternative tool is named, but no plausible alternative exists in this toolset, so the guidance is effectively complete without an exclusion clause.

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