Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@domain-security-mcp-server Audit email security for google.com"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that lets an AI agent audit the email and domain security of any domain — SPF, DKIM, DMARC, MTA-STS, TLS-RPT, BIMI, DNSSEC, DNS, TLS/SSL and WHOIS — in plain language. No API keys required.
Ask Claude "Is acme.com protected against email spoofing?" and it runs a full authentication audit and hands you a graded report with prioritised fixes — instead of you pasting a domain into five different web tools.
> Is ortamarco.me protected against email spoofing?
email_auth_audit(domain="ortamarco.me")
Grade: A (95/100) · MX: present
✅ SPF ends in '-all' (hard fail). 3/10 DNS lookups.
✅ DMARC policy is enforced ('p=reject').
✅ DKIM key found for selector: google.
Top recommendation: add a TLS-RPT record for delivery-failure reports.The email-security ecosystem is full of single-purpose web checkers (SPF here, DMARC there, WHOIS somewhere else) and the few MCP equivalents are locked behind paid API tokens. This server brings the whole deliverability & domain-security toolkit to any MCP client, key-free, with one headline workflow tool that does the synthesis for you.
It is the agent-facing companion to the network tools at ortamarco.me and shares the same battle-tested core (public-resolver DNS, host validation, timeouts).
Related MCP server: Dechonet MCP
Tool | What it does |
| One-call SPF + DKIM + DMARC + MX audit → 0–100 score, A–F grade, prioritised fixes |
| Parse SPF; recursively count DNS lookups vs the RFC 7208 limit of 10; flag |
| Parse DMARC policy ( |
| Probe |
| Validate the |
| Check the |
| Check the |
| DS/DNSKEY presence + DNSSEC |
| All record types (A/AAAA/CNAME/MX/NS/TXT/SOA) via public resolvers |
| TLS cert issuer, validity window, days-to-expiry, SANs, fingerprint |
| Registrar, dates, name servers, status (raw port-43 WHOIS, IANA-resolved) |
| PTR records for an IP |
| Offline IP geolocation + reverse DNS |
| Mail servers (MX) with priority and resolved IPs |
| Which CAs may issue TLS certificates (CAA records) |
| IP/domain against open-access email DNSBLs |
| Compare a record across 5 public resolvers worldwide |
| Parse raw headers → SPF/DKIM/DMARC verdicts + Received hop chain with delays |
Every tool is read-only, declares an outputSchema and returns
structuredContent (validated by the SDK) alongside human-readable Markdown
(default) or JSON (response_format="json"), plus actionable error messages.
git clone https://github.com/ortamarco/domain-security-mcp-server.git
cd domain-security-mcp-server
npm install
npm run buildclaude mcp add domain-security -- node /absolute/path/to/domain-security-mcp-server/dist/index.jsAdd to claude_desktop_config.json (see examples/):
{
"mcpServers": {
"domain-security": {
"command": "node",
"args": ["/absolute/path/to/domain-security-mcp-server/dist/index.js"]
}
}
}Restart Claude Desktop, then ask: "Audit the email security of stripe.com."
The same server speaks stateless Streamable HTTP for remote/multi-client use — handy behind a reverse proxy such as Coolify or Traefik.
TRANSPORT=http PORT=3000 npm start
# POST JSON-RPC to http://localhost:3000/mcp · health at /healthzOr with Docker:
docker build -t domain-security-mcp .
docker run -p 3000:3000 -e TRANSPORT=http domain-security-mcpSet ALLOWED_ORIGINS=https://your.app to enable Origin-based DNS-rebinding
protection (leave empty when a trusted proxy already restricts access).
npm run dev # tsx watch (stdio)
npm run inspect # open the MCP Inspector against the built server
npm run build # type-check + emit dist/
npm run smoke # call all 19 tools and validate structuredContent vs outputSchemaevals/ holds a 10-question LLM evaluation set (stable, verifiable)
and instructions for running it — see evals/README.md.
src/
├── index.ts # transport selection (stdio | http)
├── server.ts # registers every tool on one McpServer
├── core/ # pure logic, no MCP coupling — reusable & testable
│ ├── dns.ts # public-resolver DNS + DoH client
│ ├── tls.ts # certificate inspection
│ ├── whois.ts # port-43 WHOIS with IANA/registrar referral
│ ├── http.ts # security-header grading
│ ├── geoip.ts # offline IP geolocation
│ └── email-auth.ts # SPF/DKIM/DMARC/MTA-STS/TLS-RPT/BIMI/DNSSEC + scoring
└── tools/ # thin MCP wrappers (Zod schemas, descriptions, formatting)The core/ layer is deliberately free of any MCP types, so the exact same logic
powers both this server and the web tools on ortamarco.me.
MIT © Marco Orta
Parse raw email headers and report the SPF/DKIM/DMARC verdicts (from Authentication-Results), key fields (From, Subject, Date, Message-ID, Return-Path) and the Received hop chain with per-hop delays and total transit time.
Args:
headers (string): the raw email headers.
response_format ('markdown' | 'json'): output format (default 'markdown').
Returns: { auth{spf,dkim,dmarc}, fields{}, hops[{index,from,by,date,delaySec}], totalSec }.
Example: paste the headers from "Show original" in Gmail to trace a message's path and authentication.
| Name | Required | Description | Default |
|---|---|---|---|
| headers | Yes | The raw email headers to analyze (RFC 5322). | |
| response_format | No | Output format: 'markdown' for a human-readable summary (default) or 'json' for the full structured payload. | markdown |
| Name | Required | Description |
|---|---|---|
| auth | Yes | |
| fields | Yes | |
| hops | Yes | |
| totalSec | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint true and destructiveHint false. The description adds behavioral details such as calculating per-hop delays and total transit time, and describes the return structure. It does not contradict annotations.
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 well-structured with Args, Returns, and Example sections. It is concise and every sentence adds value, with no unnecessary words.
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 existence of an output schema, the description covers input parameters, output structure, and a practical example. It is fully complete for the tool's purpose.
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 descriptions for both parameters. The description adds value by explaining the 'Returns' structure and providing an example, which gives context beyond the 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 clearly states that the tool parses raw email headers and reports SPF/DKIM/DMARC verdicts, key fields, and the Received hop chain with delays. It distinguishes itself from sibling tools like spf_check or dkim_check by combining multiple analyses into one function.
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 an example use case (paste headers from Gmail) but does not explicitly state when to use this tool versus the individual sibling tools, nor does it mention when not to use it. Implicit guidance is present but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a domain's BIMI record (default._bimi. TXT), which points to the brand logo (and optional VMC) displayed next to authenticated mail. BIMI requires an enforced DMARC policy to take effect.
Args:
domain (string): the domain to check.
response_format ('markdown' | 'json'): output format (default 'markdown').
Returns: { found, record, findings[] }.
Example: "Does cnn.com have BIMI set up?" -> bimi_check(domain="cnn.com").
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to check, e.g. 'example.com'. | |
| response_format | No | Output format: 'markdown' for a human-readable summary (default) or 'json' for the full structured payload. | markdown |
| Name | Required | Description |
|---|---|---|
| domain | Yes | |
| found | Yes | |
| record | No | |
| findings | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds context beyond annotations: describes the specific DNS record checked, requirement for enforced DMARC policy, and return fields. No contradictions.
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?
Concise with front-loaded purpose, example, and parameter details. Minor redundancy but overall efficient.
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?
Complete for a simple DNS check tool: covers purpose, prerequisite, parameters, return fields, and example. Output schema exists.
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%, but description adds the return structure and example usage, providing added value beyond 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?
Clearly states the tool checks a domain's BIMI record, specifying the verb 'check' and the resource 'BIMI record'. Distinguishes itself from sibling tools like dkim_check, dmarc_check, etc.
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?
Implied usage from domain context and example, but no explicit guidance on when to use vs alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether an IPv4 address (or a domain's A records) appears on email DNS blocklists (DNSBLs). Only open-access lists are queried (SORBS, SpamCop, UCEPROTECT-1, DroneBL, s5h); Spamhaus and Barracuda refuse public-resolver queries and are excluded.
Args:
query (string): an IPv4 address or a domain.
response_format ('markdown' | 'json'): output format (default 'markdown').
Returns: { ips[], listedCount, checked, results[{ip, hits[{list, listed, reason}]}], note }.
Example: "Is 203.0.113.5 blacklisted?" -> blacklist_check(query="203.0.113.5").
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | An IPv4 address or a domain to check against DNSBLs. | |
| response_format | No | Output format: 'markdown' for a human-readable summary (default) or 'json' for the full structured payload. | markdown |
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| ips | Yes | |
| listedCount | Yes | |
| checked | Yes | |
| results | Yes | |
| note | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations mark it as read-only, idempotent, and non-destructive, which the description implicitly supports. It adds value by detailing the return structure (ips, listedCount, etc.) and the specific lists queried, going beyond the annotations.
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 succinct and well-structured with sections for Args, Returns, and an Example. Every sentence is informative, with no redundancy or fluff.
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 tool with two parameters and clear annotations, the description is comprehensive. It covers purpose, usage, parameter details, and return structure. The presence of an output schema (inferred from context signals) further reduces the need for extensive description.
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 baseline 3. The description adds meaning by clarifying query accepts IPv4 or domain (not just IP), describing response_format options with default, and providing an example.
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 tool checks IPv4 addresses or domains against email DNS blocklists (DNSBLs). It specifies the exact lists queried (SORBS, SpamCop, etc.) and excludes others (Spamhaus, Barracuda), distinguishing its scope from any potential sibling tools.
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 explains which DNSBLs are used and why some are excluded, giving context for when the tool is appropriate. However, it doesn't explicitly mention alternatives for excluded lists or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a domain's CAA (Certification Authority Authorization) records — which CAs are allowed to issue TLS certificates for it. Absence means any CA may issue.
Args:
domain (string): the domain to check.
response_format ('markdown' | 'json'): output format (default 'markdown').
Returns: { found, issue[], issuewild[], iodef[] }.
Example: "Which CAs can issue certs for google.com?" -> caa_check(domain="google.com").
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to query, e.g. 'example.com'. | |
| response_format | No | Output format: 'markdown' for a human-readable summary (default) or 'json' for the full structured payload. | markdown |
| Name | Required | Description |
|---|---|---|
| domain | Yes | |
| found | Yes | |
| issue | Yes | |
| issuewild | Yes | |
| iodef | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only and idempotent. The description adds context by explaining what the absence of CAA records means (any CA may issue). This enhances transparency beyond the annotations.
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 highly concise with a clear structure: main purpose sentence, Args section, Returns section, and Example. Every sentence is informative and no unnecessary words.
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 only two parameters and an output schema, the description covers the tool's purpose, parameters, return values, and provides an example. It is complete for the tool's complexity.
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 description's parameter info is redundant. The example usage adds some value but does not significantly enhance semantic understanding beyond the 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 clearly states the tool checks a domain's CAA records, specifying what CAA records are and their significance. It uses specific verb and resource, and distinguishes from sibling tools by focusing specifically on CAA, a different DNS record type.
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 example provides a concrete use case, but the description lacks explicit guidance on when not to use this tool or which sibling tools to consider instead. It does not contrast with generic DNS lookup or other security checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up DKIM public keys at ._domainkey.. Because DKIM selectors are arbitrary and undiscoverable, you should pass the selector(s) your mail provider uses for a definitive answer; otherwise a curated list of common selectors is probed and a miss is inconclusive.
Args:
domain (string): the domain to check.
selectors (string[], optional): DKIM selectors to probe.
response_format ('markdown' | 'json'): output format (default 'markdown').
Returns: { any_found, probed_selectors, selectors[{selector, found, record, key_type}], findings[] }.
Examples:
"Does acme.com publish a DKIM key for selector 'google'?" -> dkim_check(domain="acme.com", selectors=["google"])
"Find any DKIM keys for acme.com" -> dkim_check(domain="acme.com")
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to check, e.g. 'example.com'. | |
| selectors | No | DKIM selectors to check (e.g. ['google']). If omitted, common provider selectors are probed — absence is then inconclusive. | |
| response_format | No | Output format: 'markdown' for a human-readable summary (default) or 'json' for the full structured payload. | markdown |
| Name | Required | Description |
|---|---|---|
| domain | Yes | |
| any_found | Yes | |
| probed_selectors | Yes | |
| selectors | Yes | |
| findings | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, and openWorldHint. The description adds critical behavioral context: the probing of common selectors when none are provided and the inconclusiveness of a miss. It also describes the return structure.
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 about 100 words, well-structured with bullet points for args and returns, and front-loaded with the core purpose. No unnecessary content.
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 moderate complexity (3 parameters, output schema present), the description covers all necessary aspects: purpose, behavior, parameter details, return format, and examples. No gaps.
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?
The schema provides full descriptions for all three parameters (100% coverage), so baseline is 3. The description adds value by explaining the probe behavior for selectors and noting the default for response_format, making the semantics clearer than schema alone.
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 it looks up DKIM public keys with the specific query pattern <selector>._domainkey.<domain>. It distinguishes itself from siblings like dmarc_check and spf_check by focusing solely on DKIM.
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?
It explains when to use the tool—to check DKIM—and provides guidance on selectors: users should pass specific selectors for a definitive answer, and if omitted, a miss is inconclusive. It doesn't explicitly compare to sibling tools, but the sibling context makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch and parse a domain's DMARC record (_dmarc.). Reports the policy (p=), subdomain policy (sp=), reporting addresses (rua/ruf), pct and alignment (aspf/adkim), and warns on monitor-only or partial deployments.
Args:
domain (string): the domain to check.
response_format ('markdown' | 'json'): output format (default 'markdown').
Returns: { found, record, policy, tags{}, findings[] }.
Example: "What is paypal.com's DMARC policy?" -> dmarc_check(domain="paypal.com").
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to check, e.g. 'example.com'. | |
| response_format | No | Output format: 'markdown' for a human-readable summary (default) or 'json' for the full structured payload. | markdown |
| Name | Required | Description |
|---|---|---|
| domain | Yes | |
| found | Yes | |
| record | No | |
| tags | Yes | |
| policy | No | |
| findings | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds behavioral details such as reporting policy components and warnings on monitor-only deployments, going beyond annotations.
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 concise and well-structured: first sentence states purpose, followed by arguments, return type, and an example. Every sentence adds value with no wasted words.
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 and the presence of an output schema, the description adequately covers what the tool does and returns. However, it could mention error handling or DNS behavior for completeness.
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 schema fully documents both parameters. The description repeats the parameters and adds a default for response_format, but adds minimal new semantic value beyond the 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 clearly states it fetches and parses a DMARC record, with specific verb and resource. It distinguishes itself from sibling tools like dkim_check and spf_check by focusing on DMARC policies.
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 implies usage context through an example but does not explicitly state when to use this tool versus alternatives or when not to use it. No exclusions or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve all common DNS record types (A, AAAA, CNAME, MX, NS, TXT, SOA) for a domain in one call, using public resolvers (Cloudflare/Google/Quad9).
Args:
domain (string): the domain to query, e.g. "example.com".
response_format ('markdown' | 'json'): output format (default 'markdown').
Returns: a map of record type -> list of records. Each record has { type, host, value, priority? }.
Examples:
"What are the MX records for stripe.com?" -> dns_lookup(domain="stripe.com")
Use ssl_certificate for TLS details, whois_lookup for registration data.
Errors: returns an error if the domain is malformed or has no resolvable records.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to query, e.g. 'example.com'. | |
| response_format | No | Output format: 'markdown' for a human-readable summary (default) or 'json' for the full structured payload. | markdown |
| Name | Required | Description |
|---|---|---|
| domain | Yes | |
| records | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, ensuring safety. The description adds valuable behavior: uses public resolvers (Cloudflare/Google/Quad9), returns a map of record types, and errors on malformed domains. No contradictions.
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 concise, front-loading the main purpose. It uses clear sections (Args, Returns, Examples, Errors) with no wasted words. Every sentence adds value.
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 moderate complexity and rich annotations, the description fully covers input parameters, return format, error handling, examples, and references to siblings. An output schema exists, so return details are well-documented.
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%, baseline 3. The description adds context: domain example 'stripe.com', response_format defaults, and return structure (each record has type, host, value, priority?). This goes beyond the schema's minimal descriptions.
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 tool resolves all common DNS record types (A, AAAA, CNAME, MX, NS, TXT, SOA) for a domain, distinguishing it from sibling tools like ssl_certificate and whois_lookup. The verb 'resolve' combined with the resource 'DNS record types' makes the purpose specific and unambiguous.
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 explicit alternatives: 'Use ssl_certificate for TLS details, whois_lookup for registration data.' It also gives examples and notes error conditions. However, it doesn't comprehensively differentiate from all 18 sibling tools, especially other DNS-related ones like mx_lookup or dns_propagation, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare a domain's DNS records across multiple public resolvers worldwide (Cloudflare, Google, Quad9, OpenDNS, AdGuard) to see whether a change has propagated.
Args:
domain (string): the domain to check.
type ('A'|'AAAA'|'CNAME'|'MX'|'NS'|'TXT'): record type (default 'A').
response_format ('markdown' | 'json'): output format (default 'markdown').
Returns: { type, consistent, resolvers[{name, server, values[], error}] }.
Example: "Has the A record for example.com propagated?" -> dns_propagation(domain="example.com").
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to check. | |
| type | No | Record type (default 'A'). | A |
| response_format | No | Output format: 'markdown' for a human-readable summary (default) or 'json' for the full structured payload. | markdown |
| Name | Required | Description |
|---|---|---|
| domain | Yes | |
| type | Yes | |
| consistent | Yes | |
| resolvers | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, idempotent behavior. The description adds context about comparing across multiple resolvers and returning consistency status, which goes beyond the annotations.
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?
Very concise (6 lines), structured with Args and Returns sections, front-loaded purpose. Every sentence adds value.
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 simple tool, complete schema/annotations, and presence of output schema (described in Returns), the description fully covers what an agent needs to know.
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% and already describes all parameters with enums and defaults. The description adds minimal extra meaning, just an example and list of record types. Baseline of 3 is appropriate.
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?
Description clearly states the tool compares DNS records across multiple resolvers to check propagation. It lists specific resolvers (Cloudflare, Google, etc.) and distinguishes from siblings like dns_lookup, which likely just performs a single lookup.
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 an explicit example and states the use case ('to see whether a change has propagated'). While it does not explicitly mention when not to use or alternatives, the context of sibling tools makes the usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether a domain is protected by DNSSEC. Queries DS and DNSKEY records over DNS-over-HTTPS and reads the resolver's Authenticated Data (AD) flag to confirm the chain of trust validates.
Args:
domain (string): the domain to check.
response_format ('markdown' | 'json'): output format (default 'markdown').
Returns: { enabled, validated, ds_records, dnskey_records, findings[] }.
Example: "Is cloudflare.com DNSSEC-signed?" -> dnssec_check(domain="cloudflare.com").
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to check, e.g. 'example.com'. | |
| response_format | No | Output format: 'markdown' for a human-readable summary (default) or 'json' for the full structured payload. | markdown |
| Name | Required | Description |
|---|---|---|
| domain | Yes | |
| enabled | Yes | |
| validated | Yes | |
| ds_records | Yes | |
| dnskey_records | Yes | |
| findings | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds useful behavioral details: uses DNS-over-HTTPS, reads the AD flag, and returns specific fields. No contradictions. It provides context beyond annotations, though it could mention rate limits or caching behavior.
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 concise (4-5 lines) with a clear front-loaded purpose, followed by parameter listing, return shape, and a concrete example. Every sentence adds value with no redundancy.
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 moderate complexity (2 parameters, simple output) and the presence of an output schema, the description is complete. It covers purpose, mechanics, parameters, return structure, and an example, leaving no gaps for the agent.
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 schema already documents both parameters. The description adds value by showing the output structure and providing an example usage ('Is cloudflare.com DNSSEC-signed?'), which helps the agent understand parameter semantics contextually.
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 tool checks DNSSEC protection by querying DS and DNSKEY records and confirming chain of trust. It uses a specific verb ('check') and resource ('domain DNSSEC'), and the purpose is distinct from sibling tools like dns_lookup.
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 implies usage for DNSSEC validation and provides an example, but it does not explicitly state when to use this tool versus alternatives (e.g., dns_lookup) or specify when not to use it. The context signals (sibling list) help, but the description itself lacks exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Headline tool. Audits a domain's email-authentication posture in one call — SPF, DKIM, DMARC and MX — then returns a 0–100 score, an A–F grade and a prioritised list of fixes. Use this first; reach for the per-record tools (spf_check, dmarc_check, dkim_check) only when you need the full detail of one mechanism.
Args:
domain (string): the domain to audit.
dkim_selectors (string[], optional): DKIM selectors to probe. If omitted, common provider selectors are tried (absence is then inconclusive).
response_format ('markdown' | 'json'): output format (default 'markdown').
Returns (JSON): { "domain": string, "grade": "A".."F", "score": number, // 0-100 "has_mx": boolean, "mx_hosts": string[], "spf": { found, record, all_qualifier, lookup_count, exceeds_lookup_limit, findings[] }, "dmarc":{ found, policy, tags, findings[] }, "dkim": { any_found, selectors[], findings[] }, "top_recommendations": string[] }
Examples:
"Is example.com protected against email spoofing?" -> email_auth_audit(domain="example.com")
"Audit acme.com, our DKIM selector is 'k1'" -> email_auth_audit(domain="acme.com", dkim_selectors=["k1"])
Errors: returns an error only if the domain is malformed; missing records are reported as findings, not errors.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to audit, e.g. 'example.com'. | |
| dkim_selectors | No | Optional DKIM selectors to check (e.g. ['google','selector1']). If omitted, a list of common provider selectors is probed. | |
| response_format | No | Output format: 'markdown' for a human-readable summary (default) or 'json' for the full structured payload. | markdown |
| Name | Required | Description |
|---|---|---|
| domain | Yes | |
| grade | Yes | |
| score | Yes | |
| has_mx | Yes | |
| mx_hosts | Yes | |
| spf | Yes | |
| dmarc | Yes | |
| dkim | Yes | |
| top_recommendations | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark as read-only and idempotent. The description adds detailed behavioral context: what records are checked, scoring (0-100, A-F), prioritization of fixes, and error conditions (only malformed domain errors; missing records are findings). No contradiction with annotations.
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?
Well-structured with headline, usage note, Args, Returns (with JSON example), and Errors. Every sentence is necessary and no redundancy. Length is appropriate for the 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 three parameters, full schema descriptions, output schema available, and sibling tools, the description covers all relevant aspects: purpose, usage context, parameter details, return structure, examples, and error handling. No gaps.
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 baseline is 3. The description adds value by explaining the implication of omitting dkim_selectors ('absence is then inconclusive') and clarifying response_format default. This exceeds schema-only information.
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 tool audits a domain's email-authentication posture (SPF, DKIM, DMARC, MX) and returns a score, grade, and prioritized fixes. It uses a specific verb and resource, and distinguishes from sibling per-record tools.
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 says 'Use this first; reach for the per-record tools... only when you need the full detail of one mechanism.' Provides clear when-to-use and alternative tools guidance, plus examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a URL and grade its HTTP security headers (HSTS, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy, COOP). Returns a 0–100 score, an A–F grade, and per-header notes.
Args:
url (string): URL or host to check (scheme defaults to https://).
response_format ('markdown' | 'json'): output format (default 'markdown').
Returns: { url, final_url, status, grade, score, checks[{header, present, value, note}], missing[] }.
Example: "Grade the security headers on https://news.ycombinator.com" -> http_security_headers(url="https://news.ycombinator.com"). Errors: returns an error if the URL is invalid or the host is unreachable.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL or host to check, e.g. 'https://example.com'. | |
| response_format | No | Output format: 'markdown' for a human-readable summary (default) or 'json' for the full structured payload. | markdown |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| final_url | Yes | |
| status | Yes | |
| grade | Yes | |
| score | Yes | |
| checks | Yes | |
| missing | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is read-only, non-destructive, idempotent, and open-world. The description adds valuable behavioral details: it fetches the URL (implying network access), specifies error conditions for invalid/unreachable URLs, and clarifies the return structure. No contradiction.
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 succinct: 4 sentences covering purpose, parameters, output, example, and errors. It front-loads the core action and lists headers clearly. No wasted words; every sentence adds value.
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 moderate complexity, the description is fully adequate: it explains what the tool does, what headers it checks, the parameters, the return object, and error handling. The output schema is described sufficiently, and sibling tools are distinct, so no missing context.
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%, setting baseline at 3. The description adds meaning beyond the schema: for 'url' it notes the default scheme (https://), and for 'response_format' it clarifies the default value and output types. The return structure is also detailed, providing context not in the 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 explicitly states the action 'Fetch a URL and grade its HTTP security headers' and lists the specific headers checked (HSTS, CSP, etc.). It clearly distinguishes from sibling tools like ssl_certificate or dns_lookup by focusing on security headers.
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 strongly implies the tool is for security header grading, and sibling tools cover other security checks, so an agent can infer usage. However, it lacks explicit guidance on when not to use this tool or mention alternatives, preventing a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Geolocate an IP address (country, region, city, coordinates, time zone) using an offline database, plus its reverse-DNS hostname. No external API.
Args:
ip (string): IPv4 or IPv6 address.
response_format ('markdown' | 'json'): output format (default 'markdown').
Returns: { ip, country_iso, country_name, region, city, latitude, longitude, time_zone, hostname }.
Example: "Where is 151.101.1.69 located?" -> ip_geolocation(ip="151.101.1.69"). Note: geolocation is approximate (city-level at best) and offline data may lag reality.
| Name | Required | Description | Default |
|---|---|---|---|
| ip | Yes | IPv4 or IPv6 address, e.g. '1.1.1.1'. | |
| response_format | No | Output format: 'markdown' for a human-readable summary (default) or 'json' for the full structured payload. | markdown |
| Name | Required | Description |
|---|---|---|
| ip | Yes | |
| country_iso | No | |
| country_name | No | |
| region | No | |
| city | No | |
| latitude | No | |
| longitude | No | |
| time_zone | No | |
| hostname | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds important traits: offline database, approximate geolocation, data lag, and reverse-DNS hostname. Complements annotations (readOnly, idempotent) with practical 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?
Concise paragraph with clear sections: purpose, args, returns, example, note. Every sentence adds value.
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?
Covers all needed aspects: parameters, return structure, example, and limitations. Output schema exists, so return fields are well-described.
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%, but description adds an example and clarifies parameter behavior (e.g., output format default). Baseline 3, plus extra value.
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?
Description uses specific verb 'geolocate' and resource 'IP address', lists returned fields, and is clearly distinct from siblings like dns_lookup or reverse_dns.
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?
Implies usage for IP geolocation but does not explicitly state when to use vs alternatives or when not to use. No direct comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a domain's MTA-STS deployment: the _mta-sts TXT record AND the policy file at https://mta-sts./.well-known/mta-sts.txt. Reports the enforcement mode (enforce/testing/none) and the listed MX hosts. MTA-STS forces TLS for inbound SMTP and blocks downgrade attacks.
Args:
domain (string): the domain to check.
response_format ('markdown' | 'json'): output format (default 'markdown').
Returns: { dns_record_found, policy_found, mode, policy{}, findings[] }.
Example: "Does gmail.com enforce MTA-STS?" -> mta_sts_check(domain="gmail.com").
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to check, e.g. 'example.com'. | |
| response_format | No | Output format: 'markdown' for a human-readable summary (default) or 'json' for the full structured payload. | markdown |
| Name | Required | Description |
|---|---|---|
| domain | Yes | |
| dns_record_found | Yes | |
| policy_found | Yes | |
| mode | No | |
| policy | No | |
| findings | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (read-only, idempotent), the description adds context: it checks both DNS and HTTP, reports specific fields, and explains the purpose of MTA-STS. This provides good behavioral insight.
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 short, directly states the action, lists arguments, mentions return structure, and gives an example—all without redundancy. Efficient and well-structured.
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 simple two-parameter tool with an output schema, the description fully covers what it does, what it returns, and includes an example. No gaps remain.
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%, and the description mostly repeats schema information. The example adds minor value but does not significantly extend parameter understanding beyond the 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 clearly states the tool checks a domain's MTA-STS deployment by verifying both the _mta-sts TXT record and the policy file. It reports enforcement mode and MX hosts, distinguishing it from sibling tools like spf_check or dmarc_check.
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 does not explicitly state when to use this tool versus alternatives. While the example provides a concrete scenario, no exclusions or comparisons to sibling tools are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up a domain's mail servers (MX records) with priority and the IPs they resolve to.
Args:
domain (string): the domain to query.
response_format ('markdown' | 'json'): output format (default 'markdown').
Returns: array of { exchange, priority, ips[] }.
Example: "What are the mail servers for github.com?" -> mx_lookup(domain="github.com").
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to query, e.g. 'example.com'. | |
| response_format | No | Output format: 'markdown' for a human-readable summary (default) or 'json' for the full structured payload. | markdown |
| Name | Required | Description |
|---|---|---|
| domain | Yes | |
| records | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is read-only, idempotent, and non-destructive. The description adds value by detailing the return structure (array of exchange, priority, ips) and the IP resolution behavior, which goes beyond the annotations.
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 extremely concise and front-loaded with the purpose. The parameter docs, return type, and example are all compact and well-structured, with no unnecessary 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?
Given the output schema exists, the description's summary of return values is sufficient. The tool is simple (2 params, 1 required), and the description covers all key aspects: purpose, parameters, return format, and usage example.
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 schema already documents both parameters. The description repeats schema details and adds an example, but does not provide additional semantic meaning beyond what the schema already conveys.
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 verb (look up), the resource (domain's mail servers), and adds specifics (priority, IPs). It distinguishes from sibling tools like dns_lookup or spf_check by explicitly focusing on MX records and IP resolution.
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 clear example of when to use the tool ('What are the mail servers for github.com?'), implying the appropriate context. While it doesn't explicitly state when not to use it, the specificity of MX lookup and the example give strong guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve the PTR (reverse DNS) records for an IP address — the hostname(s) the IP maps back to.
Args:
ip (string): IPv4 or IPv6 address.
response_format ('markdown' | 'json'): output format (default 'markdown').
Returns: { ip, hostnames: string[] }.
Example: "What hostname does 8.8.8.8 reverse to?" -> reverse_dns(ip="8.8.8.8"). Errors: returns an error if the IP is invalid or has no PTR record.
| Name | Required | Description | Default |
|---|---|---|---|
| ip | Yes | IPv4 or IPv6 address, e.g. '1.1.1.1'. | |
| response_format | No | Output format: 'markdown' for a human-readable summary (default) or 'json' for the full structured payload. | markdown |
| Name | Required | Description |
|---|---|---|
| ip | Yes | |
| hostnames | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the description adds limited behavioral detail beyond confirming it returns errors. It doesn't contradict annotations, but adds little extra transparency.
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 structured with clear sections (Args, Returns, Example, Errors) and is concise. It front-loads the main action but could be slightly tighter without losing clarity.
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 annotations (read-only, non-destructive) and existing output schema, the description covers all essential aspects: purpose, parameters, return format, example usage, and error conditions. It is fully adequate for an agent to select and invoke the tool 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?
Schema coverage is 100% with clear descriptions. The description adds an example and error handling context, which enriches understanding beyond the schema alone. The baseline of 3 is exceeded due to this added value.
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 tool resolves PTR records for an IP address, returning the hostname(s) the IP maps back to. This distinguishes it from forward DNS lookups and sibling tools like dns_lookup, making the purpose explicit.
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 includes an example query and mentions error cases for invalid IP or no PTR record, guiding usage. However, it does not explicitly contrast with sibling tools or specify when not to use it, but the unique purpose reduces ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch and analyse a domain's SPF record. Detects: missing/multiple records, the trailing 'all' qualifier (+all/?all/~all/-all), and counts DNS-querying terms recursively against the RFC 7208 limit of 10.
Args:
domain (string): the domain to check.
response_format ('markdown' | 'json'): output format (default 'markdown').
Returns: { found, record, multiple_records, all_qualifier, lookup_count, exceeds_lookup_limit, findings[] }.
Example: "Does sendgrid.net's SPF exceed the 10-lookup limit?" -> spf_check(domain="sendgrid.net").
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to check, e.g. 'example.com'. | |
| response_format | No | Output format: 'markdown' for a human-readable summary (default) or 'json' for the full structured payload. | markdown |
| Name | Required | Description |
|---|---|---|
| domain | Yes | |
| found | Yes | |
| record | No | |
| multiple_records | Yes | |
| all_qualifier | No | |
| lookup_count | Yes | |
| exceeds_lookup_limit | Yes | |
| findings | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds behavioral details beyond annotations: it detects missing/multiple records, trailing all qualifier, and counts DNS-querying terms recursively against RFC 7208 limit. No contradiction with annotations.
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 well-structured: purpose first, then bullet-like detections, then args and return format. It is front-loaded with purpose. The Returns block may be slightly redundant given the output schema exists, but overall concise.
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 complexity of SPF checking with nested lookups, the description covers key points: detection types, parameters, and return fields. Output schema exists (not shown but signaled). It lacks details on error handling or edge cases but is sufficient for an agent.
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% with clear descriptions for both parameters. The description re-iterates the parameters in Args block but does not add significant new meaning beyond the schema. Baseline 3 is appropriate.
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 'Fetch and analyse a domain's SPF record' and lists specific detections (missing/multiple records, trailing all qualifier, DNS lookup counts). The tool name 'spf_check' differentiates it from sibling tools like dkim_check, dmarc_check, etc.
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 includes an example usage: 'Does sendgrid.net's SPF exceed the 10-lookup limit? -> spf_check(domain="sendgrid.net")' and explains what it detects. However, it does not explicitly state when not to use it or compare to alternatives like email_auth_audit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect the TLS certificate served by a host: issuer, subject, validity window, days-until-expiry, SANs, serial and SHA-256 fingerprint. Flags expired or soon-to-expire certificates.
Args:
domain (string): host to connect to.
port (number): TLS port (default 443).
response_format ('markdown' | 'json'): output format (default 'markdown').
Returns: certificate fields plus { days_until_expiry, expired, expires_soon }.
Example: "When does github.com's certificate expire?" -> ssl_certificate(domain="github.com"). Errors: returns an error if the host is unreachable or serves no certificate.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain (or host) to inspect, e.g. 'example.com'. | |
| port | No | TLS port (default 443). | |
| response_format | No | Output format: 'markdown' for a human-readable summary (default) or 'json' for the full structured payload. | markdown |
| Name | Required | Description |
|---|---|---|
| host | Yes | |
| port | Yes | |
| subject_common_name | No | |
| subject_alt_names | Yes | |
| issuer_organization | No | |
| issuer_common_name | No | |
| valid_from | No | |
| valid_to | No | |
| days_until_expiry | No | |
| expired | Yes | |
| expires_soon | Yes | |
| serial_number | No | |
| fingerprint_sha256 | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the tool is safe. The description adds value by detailing what is returned (expiry flags, error on unreachable host) without contradicting annotations.
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 well-organized with clear sections (purpose, args, returns, example, errors). Each sentence serves a purpose, though slightly verbose in listing args.
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 output schema exists, the description appropriately focuses on key return fields and error conditions. It covers necessary context for the tool's usage.
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 parameters are well-documented. The description supplements with default values and an example call, enhancing understanding beyond the 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 explicitly states the tool inspects TLS certificates from a host and lists specific fields (issuer, subject, validity, etc.). It clearly distinguishes itself from sibling tools like dns_lookup or whois_lookup, which serve different purposes.
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 clear use case with an example ('When does github.com's certificate expire?') and indicates when the tool is appropriate. It does not explicitly mention alternatives but the context of sibling tools makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a domain's TLS-RPT record (_smtp._tls. TXT). TLS-RPT lets you receive reports about TLS delivery failures to your domain.
Args:
domain (string): the domain to check.
response_format ('markdown' | 'json'): output format (default 'markdown').
Returns: { found, record, findings[] }.
Example: "Does microsoft.com publish TLS-RPT?" -> tls_rpt_check(domain="microsoft.com").
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to check, e.g. 'example.com'. | |
| response_format | No | Output format: 'markdown' for a human-readable summary (default) or 'json' for the full structured payload. | markdown |
| Name | Required | Description |
|---|---|---|
| domain | Yes | |
| found | Yes | |
| record | No | |
| findings | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint. The description adds the return structure { found, record, findings[] } but doesn't reveal additional behavioral traits beyond that.
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?
Concise with 4 sentences including example. Front-loaded purpose. Efficient but could be slightly more structured.
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 simple 2-parameter tool with annotations and output schema, the description provides enough context: purpose, parameters, return shape, example.
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%; both parameters have descriptions in the schema. The description's Args section adds little beyond the 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 clearly states the tool checks a domain's TLS-RPT record and explains TLS-RPT's purpose. It is specific but doesn't explicitly differentiate from sibling DNS check tools.
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?
An example invocation is provided, but no guidance on when to use this tool vs alternatives (e.g., DMARC check) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up domain registration data over the raw WHOIS protocol (port 43): registrar, creation/update/expiry dates, name servers and domain status. Resolves the correct WHOIS server via IANA and follows registrar referrals. No API key.
Args:
domain (string): the domain to look up.
response_format ('markdown' | 'json'): output format (default 'markdown'). JSON includes the raw WHOIS text.
Returns: { domain, registrar, created, updated, expires, name_servers[], status[], whois_server }.
Example: "Who is the registrar for openai.com and when does it expire?" -> whois_lookup(domain="openai.com"). Errors: returns an error if no WHOIS server answers (some ccTLDs restrict or rate-limit WHOIS).
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to look up, e.g. 'example.com'. | |
| response_format | No | Output format: 'markdown' for a human-readable summary (default) or 'json' for the full structured payload. | markdown |
| Name | Required | Description |
|---|---|---|
| domain | Yes | |
| whois_server | No | |
| registrar | No | |
| created | No | |
| updated | No | |
| expires | No | |
| name_servers | Yes | |
| status | Yes | |
| registrant_org | No | |
| raw | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, openWorldHint. Description adds valuable details: no API key, IANA referral resolution, return structure, error conditions. Adds context beyond annotations.
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?
Compact 7 sentences with clear sections: overview, args, returns, example, errors. No fluff, front-loaded with key action.
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 output schema, annotations, and parameter schema coverage, description is complete: covers function, parameters, return, errors, and limitations. No gaps.
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 100% so baseline 3. Description adds default for response_format, clarifies JSON includes raw WHOIS text, and explains domain parameter. Adds meaning beyond 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?
Description clearly states it looks up domain registration data via raw WHOIS protocol (port 43) and lists returned fields. Distinguishes from siblings like DNS lookups or email checks by specifying raw WHOIS protocol.
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?
Description implies usage for domain registration queries with an example, but does not explicitly differentiate when to use this vs. sibling tools like dns_lookup or mx_lookup. No direct comparison or excluded scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a distinct, well-defined purpose. Even where there is overlap (e.g., email_auth_audit vs individual checks), the descriptions clarify the difference. An agent can easily distinguish tools like dns_lookup from dns_propagation or spf_check from dkim_check.
Tool names use snake_case consistently and are descriptive. Many end with '_check' or '_lookup', but a few like 'analyze_email_headers' and 'http_security_headers' deviate from that pattern. The naming is still predictable and clear overall.
19 tools is a well-scoped number for a domain security server. Each tool covers a specific check (email auth, DNS, TLS, HTTP, WHOIS, etc.) without redundancy. The count feels comprehensive yet manageable.
The tool set covers most major domain security aspects: email authentication (SPF/DKIM/DMARC/BIMI/MTA-STS/TLS-RPT), DNS security (DNSSEC, CAA), TLS/HTTP security, and basic lookups. Minor gaps like DANE/TLSA checks are missing but not critical.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Domain intel for AI agents: RDAP registration, DNS, email deliverability, tech stack.
Check if a domain can be email-spoofed: SPF, DMARC, DKIM, MX graded from public DNS. Authless.
DMARC analytics and domain onboarding for AI assistants — health, SPF/DKIM, compliance, anomalies.
Email posture for any domain: can it receive mail, can it be spoofed? MX, SPF and DMARC.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/OrtaMarco/domain-security-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
