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

With no annotations, the description bears the burden of behavioral disclosure. It explains what is returned and that the body is optional, but it does not state side-effect behavior, authentication needs, or error conditions. 'Get' implies read-only, but this is not made explicit.

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 two sentences with no filler. It front-loads the core purpose and then gives the return payload categories, making it easy for an agent to scan and understand.

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 retrieval tool with an output schema and fully documented parameters, the description is largely complete: it specifies the URL scheme, the resource type, and the returned content. A minor gap is not explicitly stating that this is a non-mutating read operation, especially given the absence of annotations.

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 100%, and all parameters already have clear descriptions. The tool description adds little beyond saying the body is optional, which mirrors the include_body parameter. The schema carries the parameter semantic load.

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: get full details of an email by its message:// URL, and enumerates the returned data (headers, metadata, tags, optionally body). This clearly distinguishes it from siblings like search_messages_tool or open_message_in_mailmate.

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 clearly implies when to use the tool: when you have a message:// URL and need full message details. It does not explicitly name alternatives or exclusions, but the resource and purpose make the appropriate context evident.

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 burden of behavioral disclosure. It does state that the tool opens MailMate and returns a URL, which is useful. However, it does not describe any other side effects, error conditions, or what 'open it in MailMate' concretely entails (e.g., app focus or background behavior), so transparency is only partial.

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 short and front-loaded with the main action. The second sentence adds useful context about the returned URL's utility without excessive verbosity. There is slight redundancy between 'Get the message:// link' and 'The returned URL...', but overall it is efficient.

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 tool is simple with one parameter and an output schema is present, so return values need not be explained in the description. The description covers the core behavior and the purpose of the output. The only notable omission is explicit differentiation from the sibling open_message_in_mailmate, but this is a minor gap given the low complexity.

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 input schema has 100% description coverage for the single parameter, so the schema already explains that message_url is 'The message:// URL to open in MailMate.' The description adds no additional parameter-level semantics, such as the relationship between the input URL and the returned link, so the baseline of 3 is appropriate.

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 tool's purpose: 'Get the message:// link for a message and open it in MailMate.' It states a specific verb and resource, and the reference to 'Edit > Copy as Link' helps clarify the action. However, it does not explicitly differentiate from the sibling tool open_message_in_mailmate, leaving some ambiguity about the distinction.

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 usage context is implied: 'The returned URL can be pasted into any app to jump directly to the message in MailMate' suggests when an agent would want this tool. But there is no explicit guidance about when to use this instead of open_message_in_mailmate, nor any stated exclusions or alternatives.

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 operation is a listing (non-mutating) and specifies the return fields (account name, mailbox path, message count). It does not need to warn about side effects because a list operation has none.

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 two sentences long, front-hoaded with the action, and contains no fluff. Every sentence contributes: the first defines scope, the second defines the output contract.

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?

This is a simple zero-parameter listing tool. The description states the full scope and the returned fields, and an output schema exists to define the exact return shape. Nothing relevant is mising.

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 input schema has zero parameters, so the baseline is 4. The description adds no parameter information because there are no parameters to document; schema coverage is 100% by virue of noparams.

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 ('List') and a clear resource ('all mailboxes across all configured MailMate accounts'). This differentiates it from sibling tools like list_tags or search_messages_tool, which operaze on different entities.

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 implies the tool should be used when a user needs to enumerate mailboxes across accounts, but it does not explicitly mention when to prefer it over alternatives or when not to use it. Since siblings have distinctly different purposes, the implication is sufficient but not stated.

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 burden of behavioral disclosure. It adds useful context about tags being IMAP keywords and where they are configured, but it does not explicitly state that the operation is read-only or describe side effects, caching, or failure modes. 'List' implies a read operation, but additional disclosure would strengthen it.

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 three short sentences with the purpose front-loaded in the first sentence. The additional sentences about IMAP keywords and configuration location are informative rather than filler, so 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 zero-parameter list operation with an output schema available, the description is complete enough for an agent to select and invoke the tool correctly. No prerequisites or alternate routing are necessary, and the output schema would cover return details.

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 input schema has zero parameters, and the description correctly adds no parameter-specific details. The zero-parameter baseline of 4 applies here because there is nothing to explain beyond the empty 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 opens with 'List all tags defined in MailMate' — a specific verb and resource. It further clarifies that tags correspond to IMAP keywords, which distinguishes this tool from siblings like list_mailboxes and tag_message.

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?

There is no explicit when-to-use guidance or mention of alternatives. An agent can infer from the purpose that it should be used to enumerate available tags, but the description does not state when to prefer it over sibling tools or connect it to tag_message.

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 does well by stating that MailMate performs the actual IMAP MOVE and that the message will also be moved on the server. It also discloses the potentially surprising behavior of matching a supplied name against the first mailbox across all accounts. It does not discuss reversibility or permissions, but the main side-effect is clearly surfaced.

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 compact and front-loaded with the core action. Every sentence contributes: the main operation, the important server-side behavior, and the parameter-resolution nuance. No filler or redundant restatement is present.

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 two-parameter mutation tool with an output schema present, this description is complete enough for an agent to select and invoke it correctly. It covers what the tool does, the key server-side effect, and the ambiguous name-matching behavior. The required parameters are clear from the schema, and the description adds the necessary guidance about where to get the target path.

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 already documents both parameters with 100% coverage, which establishes a baseline of 3. The description adds meaningful value by explaining how to obtain the target path (from list_mailboxes) and what happens when a bare mailbox name is supplied: the first matching mailbox across all accounts is used. This nuance goes beyond the schema's field descriptions.

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 a specific verb and resource: 'Move a message to a different mailbox.' It clearly distinguishes the tool from siblings like get_message, tag_message, or list_mailboxes by defining its unique action. The server-side IMAP MOVE detail further reinforces what this tool specifically does.

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 clear practical context for use, including how to supply the target mailbox: use the 'path' from list_mailboxes or fall back to a mailbox name. It explicitly references a sibling tool as the source for a parameter and warns about first-match ambiguity, but it does not explicitly state when not to use this tool versus alternatives.

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 present, the description carries the full behavioral burden. It usefully discloses that the tool 'Activates MailMate' and navigates to the message, which signals a non-trivial side effect of bringing an external application to the foreground. It also clarifies the input format as a message:// URL, providing meaningful behavioral context beyond the tool name.

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 compact and front-loaded: the first sentence states exactly what the tool does, and the second sentence adds the key activation behavior. Every sentence earns its place, with no filler or redundant elaboration.

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 single-parameter tool with full schema coverage and an output schema, the description is largely complete. It covers the action, the input format, and the side effect of activating MailMate. A small gap is the absence of any guidance about when to prefer this tool over related siblings, but the simplicity of the tool keeps this from being a major omission.

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 already fully documents the single parameter with 'The message:// URL to open', and the description repeats the same concept without adding format details, validation rules, or edge-case guidance. Since schema description coverage is 100%, the baseline of 3 is appropriate.

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 ('Open'), a specific resource ('a specific message in MailMate'), and the exact input type ('message:// URL'). It clearly distinguishes from sibling tools like get_message or get_message_link, since the goal is to open and navigate in the MailMate application rather than retrieve or link a message.

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 no explicit guidance about when to use this tool versus alternatives such as get_message, get_message_link, or search_messages_tool. It implies usage by describing the action, but it does not state exclusions, prerequisites, or conditions that should route an agent to a sibling tool.

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 of revealing behavior. It discloses that query/tag are optional and that the result is a list with specific fields, but it does not state matching semantics (e.g., query matched against subject/from/to), case-insensitive exact tag matching, or the slower body-search behavior; these are delegated to schema descriptions.

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, no filler, with the core purpose first, followed by usage modes and a compact return-value list. Every sentence contributes to selection or invocation.

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 an output schema and 100% schema coverage, the description covers the essential search modes and result shape. It does not enumerate account/mailbox/body filters, but those are documented in the input schema, so the agent has what it needs to call the tool correctly.

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 coverage is 100%, so the baseline is 3. The description adds real semantic value by defining the relationship between query and tag—both optional, with distinct list-by-tag and text-search modes—and by pointing to list_tags for valid tag values. The other parameters (account, mailbox, max_results, include_body) are already well described in the 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?

Description names the exact operation ('Search MailMate messages') and its two key criteria (query string and/or tag), which is enough to distinguish it from sibling tools like open_message_in_mailmate or get_message. It also states the output is a list of matching messages, confirming it is a search/list 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?

It explicitly explains how to combine the optional query and tag parameters ('omit query to list all messages with a given tag, or omit tag to search by text only') and points to list_tags as a prerequisite helper. It does not mention exclusions or when to prefer get_message/open_message, but the main invocation pattern is clear.

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 behavioral burden. It discloses the non-obvious storage mechanism ('stored as IMAP Keywords headers'), synchronization behavior ('synced to the server'), and timing ('MailMate will pick up the change on next access'). It could also mention edge cases like requiring at least one of add_tags or remove_tags, but the key mutation semantics are well covered.

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 short, purposeful sentences: the core action, the storage/sync behavior, and a helpful sibling pointer. No redundant filler or restatement of the name, and the most important information is front-loaded.

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 three-parameter mutation tool with 100% schema coverage and an output schema, this is nearly complete. It covers the tag format, sync implications, and how to discover valid tags. It omits edge cases such as whether both add_tags and remove_tags can be combined or whether at least one is required, so it is not a perfect 5.

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 100%, so the schema already documents all three parameters with clear descriptions. The description adds little beyond the schema's parameter details, but it reinforces that tags are synced as IMAP keywords, which matches the add_tags schema note. This is a baseline 3 situation.

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 a specific verb and resource: 'Add or remove tags on a message.' It immediately clarifies the tool's scope and differentiates it from message-retrieval or message-movement siblings. It also points to list_tags for tag definitions, reinforcing its role in the tagging workflow.

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?

It gives actionable guidance to use list_tags to see defined tags, which helps the agent choose the right sibling when it needs tag names. It does not state explicit exclusions for when not to use this tool, but the sibling purposes are distinct enough that the main usage context is clear.

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