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

There are no annotations, so the description carries the burden of behavioral disclosure. It does disclose the critical non-sending behavior, but it does not mention whether the draft is saved/persisted, what the response contains, or any permissions/side effects. It adds some value but not complete transparency.

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?

A single sentence that front-loads the action and then gives the two most decision-relevant facts: the field set matches send_message and the message will not be sent. No filler.

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 seven-parameter tool with no annotations and no output schema, the description is lean. It relies on the agent knowing send_message's field semantics, and it does not describe return values or whether draft creation modifies anything beyond creating a draft. This is adequate but leaves gaps for an agent invoking it independently.

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 14%, so the description needed to compensate. It names reply_to_message_id and defers the rest to 'same fields as send_message,' which is a useful pointer but does not explain the semantics of the six other parameters. The parameter names are mostly self-explanatory, but the description adds little per-field meaning.

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 opens with the specific action 'Create a draft' on a message resource, and immediately contrasts it with send_message by stating it 'Does not send.' This clearly differentiates it from the sibling send_message tool.

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 explicit 'Does not send' sets the primary selection criterion: use this when a draft is needed rather than an immediate send. It references send_message's field set as the format to reuse, though it does not give an explicit when-not-to-use or alternative.

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

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

There are no annotations, so the description must carry behavioral context on its own. It clearly discloses that the tool retrieves the full message, returns headers, and includes a decoded text/plain body. This goes beyond a simple 'get message' phrase, though it does not cover error behavior or handling of non-text body parts.

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 a single, front-loaded sentence that communicates the action, target, and response content without any filler. Every word contributes to understanding.

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 simple get-by-id tool with one parameter and no output schema, the description covers the essential behavior: fetching the full message and what it includes. It is adequately complete, though it omits details like error semantics and non-plain-text body handling.

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?

The schema has one parameter, message_id, with 0% description coverage. The tool description only restates that the message is fetched 'by id,' adding little meaning beyond the property name. It does not clarify the ID format, provenance, or any constraints, so it does not compensate meaningfully for the missing schema description.

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 uses a specific verb ('Fetch') and a clear resource ('full message by id'), and it further specifies what is included: 'headers plus decoded text/plain body.' This differentiates it from sibling search_messages, which would be used for finding messages rather than retrieving one by id.

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 phrase 'by id' implies the tool is for direct retrieval when a message_id is already known, as opposed to search_messages for discovery. However, the description does not explicitly state when to use this tool vs alternatives or mention exclusions, so the guidance is only implied.

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

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

No annotations are provided, so the description carries the burden. 'List all' clearly signals a read-only operation with no mutation or side effects, and 'with their ids' hints at the returned data. It does not detail pagination or response encoding, but for a zero-parameter list operation this is a minor omission.

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 a single, front-loaded sentence with no filler. Every word contributes to the tool's purpose and output, making it immediately scannable for an agent.

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?

Given the tool's simplicity—no parameters, no output schema, minimal annotations—the description is nearly complete: it names the resource, the operation, and the returned fields. It could add a little more context about Gmail account scope or the exact response shape, but these are minor given the trivial interface.

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?

The tool has zero parameters, so there is nothing for the description to add beyond the input schema. This matches the baseline for parameterless tools, and the description accurately reflects that no inputs are needed.

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 uses a specific verb ('List') and resource ('Gmail labels'), and specifies the returned data ('with their ids'). This clearly distinguishes it from the sibling message-focused tools such as search_messages and get_message, as well as from modify_labels, which performs a different action.

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 intended use is implied: use this tool when you need all Gmail labels or their IDs, possibly before calling modify_labels. However, it does not explicitly state when to prefer this over alternatives or exclude cases where it should not be used.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It clearly states the core mutating behavior ('add and/or remove labels') and the target scope ('on a message'), but omits details such as the response format, behavior on invalid label IDs, error handling, and whether existing labels are preserved or merged. This is adequate for basic understanding but lacks depth.

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?

Two short sentences with no filler. The action is front-loaded, and the dependency on list_labels is stated in a separate sentence. Each sentence earns its place, making the description highly scannable.

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 mutation tool with no annotations and no output schema, the description doesn't mention what the tool returns or any side-effect/error semantics. However, the operation and the parameter source are sufficient for basic invocation, and the sibling list_labels is present to supply valid IDs. It is adequate but not fully complete.

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 must compensate. It adds meaningful semantic value by clarifying that 'add' and 'remove' take label IDs ('Use label ids from list_labels') rather than plain names, and by associating 'message' with the message_id parameter. It could be more explicit about optionality/combinations, but 'and/or' provides a useful hint.

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 and resource: 'Add and/or remove labels on a message.' It clearly differs from siblings like list_labels, search_messages, get_message, send_message, and create_draft, none of which modify labels. An agent can identify the tool's unique purpose immediately.

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 instruction 'Use label ids from list_labels' provides a clear prerequisite and points the agent to the correct sibling tool for obtaining valid IDs. It doesn't explicitly state when not to use this tool, but no sibling offers label modification, so an alternative-condition exclusion isn't necessary.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the read-only search nature, the accepted Gmail search syntax, and the exact return shape (subject/from/date/snippet). It omits authentication or rate-limit details, but core behavior is well communicated.

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?

One concise sentence with an illustrative example and explicit return fields. The core purpose is front-loaded ('Search Gmail'), and every clause provides useful information without filler.

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-only search tool with two simple parameters and no output schema, the description sufficiently covers query semantics, result format, and invocation basics. A note about ordering or pagination would be a minor enhancement, but it is not essential for correct use.

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?

The description adds important meaning to the query parameter by giving a concrete Gmail search syntax example, which is crucial since schema description coverage is 0%. The max_results parameter is not described in text, but its name, default, and maximum are self-explanatory in the input 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 clearly identifies the action (search), the target resource (Gmail messages), and the distinguishing feature of Gmail search syntax. It also states the return type as a list of messages with specific fields, making it distinct from siblings like get_message and list_labels.

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 provides clear context for when to use the tool: searching Gmail with Gmail's query syntax. However, it does not explicitly say when not to use it or recommend alternatives, such as using get_message for a specific message or list_labels for label operations.

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

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 well: it discloses that the mail is 'threaded properly (In-Reply-To/References + Gmail threadId)' and that 'to'/'subject' default to the original sender and 'Re: <original subject>'. It does not cover failure modes or delivery semantics, but the key non-obvious threading and defaulting behaviors are transparently stated.

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 a compact block that front-loads the core action ('Send an email.') before moving to attachments and the reply mechanism. The reply sentence is dense but every clause earns its place; there is no fluff or repetition of schema data.

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 covers the core action, attachments, and the reply threading path well. However, with no output schema and no annotations, it omits what the tool returns (e.g., message id or thread id) and leaves recipient address formatting unspecified — meaningful gaps for an agent invoking a 7-parameter mutating tool.

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 29%, so the description must compensate. It adds real meaning for reply_to_message_id (makes 'to'/'subject' optional, threads the mail) and attachments ('local files by absolute path'), but recipient fields (to, cc, bcc) and subject receive no format clarification — e.g., whether multiple addresses are comma-separated is left ambiguous.

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 opens with 'Send an email' — a specific verb and resource that clearly identifies the core function, and it goes beyond the generic name 'send_message' by specifying email. It is easily distinguished from read-oriented siblings like search_messages and get_message, though it does not explicitly contrast with the overlapping sibling create_draft.

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 explicitly explains the reply scenario: 'To reply inside an existing conversation, pass reply_to_message_id' and details the resulting defaults for 'to' and 'subject'. This gives clear context for the threading path, though it stops short of naming alternatives like create_draft for drafting-without-sending.

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