Emailens MCP

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

Annotations already establish read-only, idempotent, non-destructive safety properties. The description adds value by disclosing the return structure ('warnings and per-client scores'), which compensates for the missing output schema. However, it doesn't clarify what 'client' means (email client) or provide performance/rate limit context.

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?

Extremely concise at 9 words. The single sentence is front-loaded with the core action. 'Quick' is minimal fluff that doesn't detract significantly. However, the brevity leaves no room for usage context or parameter hints that could aid agent selection.

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-parameter tool with complete annotations and no output schema, the description adequately covers the basic behavioral contract by mentioning return values (warnings, scores). However, it lacks context on what 'per-client' entails and doesn't address the relationship to the 'fix_email' sibling tool that likely consumes these results.

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?

With 100% schema description coverage, the schema fully documents both 'html' and 'format' parameters. The description adds no parameter-specific guidance, but given the high schema coverage, the baseline score of 3 is appropriate. No additional semantic context (e.g., format examples) is provided.

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 specifies 'CSS compatibility analysis' as the core function, distinguishing it from general auditing (audit_email) or remediation (fix_email). It clearly identifies the resource (email) and the specific domain (CSS). However, it doesn't explicitly differentiate from 'audit_email' which could cause selection ambiguity.

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?

No explicit when-to-use or when-not-to-use guidance is provided. The description doesn't mention sibling tools or prerequisites (e.g., that fix_email might depend on this analysis). While 'CSS compatibility' implies usage context, it lacks explicit guidance on choosing between 'analyze' and 'audit' 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?

Annotations already declare read-only, idempotent, non-destructive behavior. The description adds value by listing the specific audit dimensions (spam, links, etc.), clarifying scope. However, it omits output format details, rate limits, or whether results are cached.

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?

Extremely compact single sentence front-loaded with the purpose ('Comprehensive quality audit') followed by specific dimensions. The em-dash construction efficiently packs eight categories with zero filler words, though the telegraphic style slightly impacts readability.

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?

Input documentation is complete given the schema and annotations. However, lacking an output schema, the description fails to indicate what the audit returns (e.g., scores, error reports, pass/fail flags), which is critical context for an agent invoking an audit 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?

With 100% schema coverage, the parameters (html, skip, format) are fully documented in the schema. The description implicitly maps to the `skip` parameter options by listing audit categories (e.g., 'spam', 'links'), but adds no explicit syntax or usage guidance beyond the schema definitions.

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 establishes a clear action ('Comprehensive quality audit') and enumerates eight specific inspection categories (CSS compatibility, spam, links, accessibility, images, inbox preview, size, templates). However, it does not differentiate from sibling tool `analyze_email`, leaving ambiguity about which analysis tool to invoke.

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?

No explicit guidance on when to use this tool versus alternatives like `analyze_email`, `check_deliverability`, or `fix_email`. No mention of prerequisites (e.g., raw HTML availability) or exclusion criteria.

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?

Discloses the specific deliverability factors verified (SPF, DKIM, DMARC, MX, BIMI) beyond the annotations, though it doesn't explicitly state that this performs DNS lookups (implied by protocol names) or describe the return format. No contradiction with readOnlyHint=true.

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?

Single sentence with zero waste: action upfront ('Check email deliverability'), scope clarified ('for a domain'), and specific behaviors listed via em-dash. Every word 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?

Adequate for a simple single-parameter diagnostic tool with good safety annotations. Lists the five protocols checked, implying the scope of results, though it could briefly mention that it returns status/pass-fail information for each record type.

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?

With 100% schema description coverage for the single 'domain' parameter, the schema fully documents the input. The description aligns with this by mentioning 'for a domain,' meeting the baseline expectation without needing to compensate for schema gaps.

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 specific action ('Check') and resource ('email deliverability for a domain') and distinguishes from siblings by enumerating specific protocols checked (SPF, DKIM, DMARC, MX, BIMI), clearly positioning it as a domain DNS record validator rather than a content analyzer like analyze_email or preview_email.

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?

Provides implied usage through the specificity of protocols listed (domain authentication checks), but lacks explicit guidance on when to select this over siblings like analyze_email (content analysis) or audit_email (broader security audit), and mentions no prerequisites or exclusions.

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?

Annotations declare the operation is read-only and safe. The description adds valuable behavioral context about what the comparison actually evaluates: score changes, fixed issues, and regressions broken down per email client—information not present in annotations or schema. It does not contradict the provided hints.

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, efficient sentence with zero waste. It front-loads the action ('Compare two email HTML versions') and follows with the specific output details, making every word earn 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?

Given the absence of an output schema, the description adequately compensates by describing the return value structure (score changes, issues, regressions per client). Combined with complete parameter documentation and clear annotations, the description provides sufficient context for tool selection.

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?

With 100% schema description coverage (before, after, and format are all clearly documented), the baseline is appropriately met. The description implicitly maps to the 'before' and 'after' parameters by referencing 'two email HTML versions' but does not add semantic depth beyond what the schema already provides.

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 action ('Compare') with clear resources ('two email HTML versions') and distinguishes itself from siblings like analyze_email through the comparison concept. It also specifies the output domain ('score changes, fixed issues, and regressions per client'), making the tool's unique value proposition clear.

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?

While it lacks explicit 'when not to use' exclusions, the description provides clear context through the parameter names ('before', 'after') and the verb 'Compare', making it obvious this is for differential analysis between two versions rather than single-email analysis (which would use analyze_email).

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?

Annotations already establish the operation is read-only, idempotent, and non-destructive. The description adds valuable context that the output is a 'fix prompt' (instructions/plan) rather than the actual fixed HTML, which sets correct expectations. However, it omits details about what the prompt contains, how to consume it, or any rate limiting considerations.

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 single sentence contains no filler words and immediately states the core function. While extremely brief, it efficiently communicates the primary purpose without redundancy. However, it could benefit from a second sentence clarifying the output format or usage context given the tool's 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?

Given the presence of annotations covering safety properties and comprehensive schema coverage for all four parameters, the description provides minimal but adequate context. However, with no output schema available, the description should ideally elaborate on what the 'structured fix prompt' actually contains or how it should be used.

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?

With 100% schema description coverage, the structured documentation already explains all parameters (html, scope, format, selectedClientId) including enum values. The description mentions none of them, but since the schema is complete, it meets the baseline expectation without adding supplementary semantic guidance.

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 the tool generates a 'structured fix prompt' for email compatibility issues, which identifies the verb and resource. However, 'fix prompt' is jargon whose meaning (a prompt for an LLM? a structured repair plan?) is ambiguous without additional context. It also fails to distinguish from siblings like analyze_email or audit_email that may also identify issues.

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 no guidance on when to use this tool versus alternatives. It does not explain the difference between generating a fix prompt (this tool) versus analyzing email structure (analyze_email) or auditing standards (audit_email), nor does it specify prerequisites like having valid HTML or knowing the target client.

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?

Annotations cover safety profile (readOnly, idempotent, non-destructive). Description adds valuable context about data cardinality ('all 15') and business logic ('deprecation status', 'rendering engines') that helps the agent understand this is a static enumeration of supported environments. Does not mention rate limits or caching, preventing a perfect score.

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 sentences with zero waste. First sentence front-loads the core function and return payload structure. Second sentence provides usage guidance. No redundant 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?

No output schema exists, but the description compensates by detailing the returned fields (IDs, names, rendering engines, dark mode support, deprecation status). Given the low complexity (parameterless enumeration) and rich annotations, this is sufficient for an agent to invoke and handle results 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?

Input schema contains zero parameters. Per evaluation rules, zero parameters establishes a baseline of 4. The description correctly implies no filtering is needed ('List all 15'), consistent with 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?

Specific verb 'List' + resource 'email clients' + detailed scope 'all 15 supported' with specific attributes (IDs, names, rendering engines, dark mode, deprecation status). Clearly distinguishes from siblings like 'preview_email' by positioning itself as the prerequisite enumeration 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?

Explicitly states when to use: 'Use the returned IDs to filter other tools like preview_email or capture_screenshots.' This establishes the workflow relationship and clarifies this tool provides the input parameters needed for sibling 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?

Annotations establish read-only, idempotent, non-destructive safety. The description adds valuable behavioral context beyond these hints: it discloses the 15-client transformation scope, CSS analysis depth, scoring generation, dark mode simulation, and size checking. These specifics help agents understand the computational richness of the operation.

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 single sentence is densely packed with zero waste. It front-loads the core purpose ('Full email compatibility preview') and uses an em-dash to efficiently enumerate six distinct capabilities (transforms, analyzes, generates, simulates, checks inbox preview, checks size). Every clause 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?

Despite lacking an output schema, the description adequately hints at return artifacts (scores, transformed previews, CSS analysis results, size metrics). Combined with comprehensive safety annotations, this provides sufficient context for agent invocation, though explicit return structure details would strengthen it further.

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?

With 100% schema description coverage, the baseline is 3. The description references 'HTML' (supporting the html parameter) and '15 email clients' (contextualizing the clients filter), but does not explicitly address the format parameter's support for JSX/MJML/Mazzle inputs. It adds minimal semantic value beyond the well-documented 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 uses specific verbs (transforms, analyzes, generates, simulates, checks) and identifies the exact resource (email HTML) and scope (15 email clients). It clearly distinguishes from siblings like analyze_email, audit_email, and fix_email by focusing on visual compatibility previewing rather than deep analysis, auditing, or remediation.

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?

While the description implies usage through detailed capability listing (previewing across clients, dark mode simulation), it lacks explicit when-to-use guidance or comparisons to siblings. It does not clarify when to choose this over analyze_email or audit_email, leaving agents to infer based on the 'preview' keyword.

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