Skip to main content
Glama
Sign In

dns-doctor

by dev.dnsdoctor
OverviewDiscussionsAdmin

Check DKIM Selector

check_dkim_selector
Read-onlyIdempotent

Use this when the user asks whether DKIM is set up for a sending platform, whether a specific selector exists, or why DKIM fails. Check ONE specific DKIM selector on a domain — the exact selector the sending platform uses (e.g. google, s1), which a full scan's common-selector sweep may miss. Returns the verdict, its explanation, and the published key record when one resolves. No fix record is returned: a DKIM key is generated by the sending platform, so the fix is always to publish what that platform gives the owner.

Input Schema

NameRequiredDescriptionDefault
domainYesThe domain to check, e.g. example.com. Bare registrable names and subdomains both work; scheme, path or port do not belong here. Unicode names are accepted and normalized to punycode.
selectorYesThe DKIM selector to probe — the name before ._domainkey, e.g. 'google', 'selector1', or a dotted form like 's1.prod'. The sending platform's settings page names it; it is not guessable from the domain.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / selector / description
      Previous value: -"The DKIM selector to probe — the single DNS label before ._domainkey, e.g. 'google' or 'selector1'. The sending platform's settings page names it; this is not guessable from the domain."New value: +"The DKIM selector to probe — the name before ._domainkey, e.g. 'google', 'selector1', or a dotted form like 's1.prod'. The sending platform's settings page names it; it is not guessable from the domain."
  2. Changed2 schema fields changed
    • addedInput schema / properties / domain / description
      Added value: +"The domain to check, e.g. example.com. Bare registrable names and subdomains both work; scheme, path or port do not belong here. Unicode names are accepted and normalized to punycode."
    • addedInput schema / properties / selector / description
      Added value: +"The DKIM selector to probe — the single DNS label before ._domainkey, e.g. 'google' or 'selector1'. The sending platform's settings page names it; this is not guessable from the domain."
  3. Added

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint), so the bar is lower. The description still adds real context: it returns a verdict, explanation and the published key record, and explicitly notes that no fix record is returned because DKIM keys are generated by the sending platform.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the trigger condition, then scope, then return contract in four tight sentences. Slightly dense but every sentence carries distinct information about when to call it or what comes back.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be spelled out, yet the description still explains the verdict/explanation/key payload and preempts a likely follow-up question about why no fix record is offered. Nothing needed to call the tool correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema: the selector is the exact one the sending platform names and is 'not guessable from the domain', with dotted forms like 's1.prod' exemplified. That clarifies why both parameters are mandatory.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Check ONE specific DKIM selector on a domain') and scopes it precisely against the sibling scan_domain behavior by noting the common-selector sweep may miss this. An agent can distinguish it from the other record-checking tools without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives three concrete user-intent triggers (is DKIM set up for a platform, does a selector exist, why DKIM fails) and explains when this beats a full scan. It stops short of naming the alternative tool or stating an explicit when-not condition, so it is clear but not fully routing-explicit.

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

All dns-doctor toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources