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

With no annotations provided, the description carries the full burden and does add a behavioral trait: 'HTML-only messages are converted to plain text.' It also clarifies the decoded body and attachment metadata. However, it does not mention side effects (e.g., whether reading marks as read), auth specifics, or error behavior, so transparency is moderate.

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 sentences with no filler. The first sentence front-loads the primary purpose and scope, the second adds a key transformation behavior, and the third provides the ID-source workflow. Every sentence earns its place.

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 read tool with no output schema and no annotations, the description covers the essential return values (decoded body, attachment name/type/size/attachmentId), the HTML conversion behavior, and how to obtain the messageId. It lacks an exact response structure and error conditions, but an agent has enough to invoke and interpret the result.

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 67%: mailbox and maxChars have descriptions, messageId does not. The description partially compensates by stating 'Get the message ID from search_gmail_messages,' giving provenance for the undocumented parameter. It also clarifies the attachmentId output that sibling tools consume, adding meaning beyond the raw schema.

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 states a specific verb ('Read'), a resource ('one message'), and scope ('in full', including decoded body and attachment metadata). This clearly distinguishes it from nearby siblings like search_gmail_messages and get_gmail_thread, and the title reinforces the purpose.

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 description gives useful workflow context: 'Get the message ID from search_gmail_messages' and it names the downstream attachment tools that consume the returned attachmentId. It does not explicitly state when-not-to-use or list alternatives (e.g., get_gmail_thread), but the read-one-message use case is clear.

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