check_email_securityChecks whether a domain can be email-spoofed, using public DNS only. Verifies SPF (including the RFC 7208 multiple-record permerror), DMARC policy and reporting, MX, and DKIM at common selectors. Returns a graded report with concrete fixes. Accepts a bare domain, a URL, or an email address. Nothing is sent to the domain.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain, URL, or email address, e.g. example.com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral disclosure responsibility, and it delivers. It states the method (public DNS only), denies any contact with the target ('Nothing is sent to the domain'), details the checks performed including a specific RFC edge case, and clarifies the output type ('graded report with concrete fixes'). This is unusually thorough for a tool definition.
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 sentences, front-loads the primary purpose, and every clause contributes information: scope, methods, output, input flexibility, and non-intrusiveness. No wasted words or repetition of the tool's name.
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, read-only DNS tool with no output schema, the description is complete. It covers the operation's effect, the accepted input variants, the technical checks, the return format, and the side-effect profile. Nothing an agent needs to decide whether to call this tool is missing.
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 schema already documents that the single parameter accepts 'Domain, URL, or email address.' The description adds the phrase 'bare domain,' which slightly clarifies accepted formats but does not materially expand on the schema's 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 a specific verb and resource: 'Checks whether a domain can be email-spoofed, using public DNS only.' It then enumerates the exact protocols checked (SPF, DMARC, MX, DKIM) and explicitly states it returns a graded report. This unambiguous scoping also distinguishes it from the sibling compare_email_security, which by name is comparison-focused rather than single-domain verification.
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 usage context: it is a passive, non-intrusive check that 'uses public DNS only' and sends 'nothing... to the domain.' This tells an agent when to select it (e.g., for safe reconnaissance). However, it does not explicitly mention the sibling tool or define when to use compare_email_security instead, so the alternative-selection guidance is implied rather than fully stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
The two tools have clearly distinct purposes: one checks a single domain's email security, while the other compares 2-5 domains. There is no realistic risk of selecting the wrong one.
Both tool names follow the same verb_noun pattern: check_email_security and compare_email_security. The pattern is simple, consistent, and immediately communicates what each tool does.
Two tools is a thin set, but each one earns its place and the pair forms a sensible workflow. Still, the server feels minimal for the broad 'deliverability doctor' name.
For the narrow domain of email-security checking, the surface covers single and comparative checks fully. Minor gaps exist, such as no raw DNS inspection or custom DKIM selector testing, but agents can accomplish the core task without dead ends.