compare_email_securityRuns the email-security check on 2–5 domains and returns a comparison table with per-domain grades. Useful for checking your domain against competitors.
| Name | Required | Description | Default |
|---|---|---|---|
| domains | Yes | 2–5 domains |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It states the core action and the return format, but does not mention whether the operation is read-only, any authentication requirements, or potential limitations. The basic behavior is transparent, but depth is limited.
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 concise sentences with no redundant wording. The primary action and output are front-loaded, and the second sentence adds a practical use case. 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?
Given the tool's simplicity (1 parameter, full schema coverage, no output schema), the description is largely complete: it defines the input range and the return shape. It could optionally clarify what 'grades' mean or reference the sibling tool, but nothing needed to invoke it correctly 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 description coverage is 100%, so the baseline is 3. The description's '2–5 domains' repeats the schema's minItems/maxItems constraints without adding extra meaning. It does not clarify domain format, examples, or how the 'email-security check' is performed per domain.
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 states the action (runs the email-security check), the resource scope (2–5 domains), and the output (comparison table with per-domain grades). It is distinct from the sibling check_email_security because it explicitly supports multiple domains and comparative output, though it does not directly name or contrast the sibling.
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 a useful example scenario ('checking your domain against competitors'), which implies when the tool is valuable. However, it does not explicitly state when to use this tool versus check_email_security, nor does it offer exclusions or alternatives.
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.