Check a domain's DKIM signing record for a specific selector to confirm email authentication is configured correctly. Use it to spot missing or broken DKIM DNS entries.
Check a domain's DKIM signing record for a given selector. Free — no verification credits.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | The domain to inspect, e.g. example.com | |
| selector | No | The DKIM selector, e.g. 'google' or 'mail'. Optional. |
Changes observed during successful MCP inspections.
v1.2.3Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds a real behavioral trait beyond annotations — the operation is free and consumes no verification credits — which is precisely the kind of cost/rate context an agent needs when choosing among paid siblings. It stops short of saying what a missing or malformed record yields.
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 short, front-loaded sentences with zero padding: the operation first, the cost caveat second. 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?
With no output schema, the description should convey something about what a check returns (pass/fail, expected vs found record) and the behavior of the optional selector. Those gaps are meaningful for a diagnostic tool, though low overall complexity keeps the impact moderate.
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% with examples for both domain and selector, so the schema does the heavy lifting. The description names the selector parameter but adds no guidance beyond it, notably omitting what happens when the optional selector is left out.
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 a specific verb (Check), a specific resource (a domain's DKIM signing record), and the scoping parameter (selector). The explicit 'DKIM' framing cleanly separates it from sibling record checks such as check_spf, check_dmarc, and check_mx without needing to name them.
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?
Usage is only implied: an agent can infer this is the tool for DKIM lookups, and 'Free — no verification credits' hints there's a cost tradeoff versus paid verification tools like verify_email. But there is no explicit when-to-use/when-not statement and no routing to alternatives such as check_domain_health for combined checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.