Apple Mail MCP Server

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

With no annotations provided, the description carries the full burden. It successfully discloses performance characteristics (body search slowdown, cross-account penalty, content preview cost) and mentions pagination and date filtering capabilities. However, it lacks disclosure on rate limits, authentication requirements, error handling behaviors, or whether searches include archived/deleted items.

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 appropriately structured with a value-proposition headline, consolidation explanation, detailed Args section, and Returns summary. Given 17 undocumented parameters, the length is justified and information-dense. The 'Args:' and 'Returns:' pseudo-docstring format is clear and parseable. Minor deduction for slightly redundant phrasing ('Optional' appears repeatedly) and the Returns section being somewhat vague given the complexity.

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 17-parameter search tool with no schema descriptions, the description achieves high completeness by documenting every parameter's semantics and providing performance warnings. Since an output schema exists (per context signals), the brief Returns statement is acceptable. It misses only edge-case behaviors (rate limiting, empty result handling, search scope boundaries) that would elevate it to a 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?

The schema has 0% description coverage (titles only), requiring the description to compensate fully. The Args section provides comprehensive semantic meaning for all 17 parameters, including format specifications (e.g., 'YYYY-MM-DD'), value examples (e.g., 'Gmail', 'Work'), default behaviors, and inter-parameter dependencies (e.g., max_content_length only applies when include_content=True). This is exemplary compensation for schema deficiencies.

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 identifies this as a 'Unified search tool' that consolidates subject, sender, body, and cross-account search. While it implies email context through these fields and the tool name, it never explicitly states 'search for emails' in the opening, relying on theArgs section to clarify the domain. It differentiates from siblings by emphasizing its consolidated nature.

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 usage context by stating it consolidates multiple search types (subject, sender, body) into one tool, suggesting it should be used when multiple filters are needed. It provides performance guidance (body search is 'significantly slower', cross-account is 'slower'). However, with many sibling tools like list_inbox_emails or get_email_thread, it lacks explicit when-to-use/when-not-to-use guidance comparing these alternatives.

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