intodns-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.4.0
Disambiguation4/5
Most tools have clearly distinct purposes, e.g., check_spf vs check_dmarc. Some overlap exists (e.g., check_email_security vs individual checks), but descriptions clarify when to use each.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern (check_, create_, get_, etc.) with no mixing of conventions like camelCase.
Tool Count4/5
36 tools is slightly high, but each serves a specific need in the broad DNS/email security domain. The count is justified by the comprehensiveness of the server.
Completeness5/5
The tool set covers an exhaustive range: DNS lookups, all email authentication methods, TLS, blacklists, deep scans, AI explanations, snapshots, NIS2, and more. No obvious gaps for the server's stated purpose.
Average 4.7/5 across 36 of 36 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 15 commits in the last 12 weeks
- Last stable release on May 27, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses read-only nature and no auth required. Explains the multi-step process (PTR lookup, forward resolution, warnings). Lacks mention of potential latency but is otherwise transparent.
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?
Information-dense single paragraph, front-loaded with main purpose. Could be slightly more concise but effectively communicates all necessary details.
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?
Given no output schema, description fully explains return values (per-IP PTR, forward result, verdict, warnings) and covers warnings types. Completely conveys what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage for the only parameter 'domain'. Description adds context about MX record retrieval but does not significantly enhance understanding beyond the schema.
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?
Description clearly specifies the tool performs a read-only FCrDNS audit on IPs from domain's MX records, detailing each step. It distinguishes from siblings like check_blacklist by stating pairing for reputation signals.
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?
Explicitly states use cases: mail deliverability audits, debugging mail rejections, and suggests pairing with check_blacklist. No explicit 'when not to use' but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It describes the output components (score, per-measure status, evidence, gaps, suggestions) and the scope limitation (only DNS/email layer). It does not explicitly state read-only or error behavior, but the tool appears non-destructive and the scope clarification adds transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of three sentences with no wasted words. First sentence defines core functionality, second lists outputs, third clarifies scope and usage. Well-structured and front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the output structure adequately. It covers the return elements and scope limitation. It does not mention error handling or domain validation, but for a simple DNS-based tool with two parameters, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/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. The description adds minimal extra meaning: domain parameter is straightforward; lang parameter's 'caveat text' is already in schema. No additional semantics beyond schema.
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?
The description clearly states the tool's purpose: computing a NIS2 Article 21.2 readiness score for a domain. It specifies the verb 'compute', the resource 'domain', and the context 'mapping IntoDNS quickscan onto NIS2 measures'. It distinguishes from siblings by focusing on NIS2 compliance, which is unique among the listed sibling tools.
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?
The description explicitly states when to use the tool: when the user asks about NIS2 compliance, readiness, Article 21.2, or cyber-hygiene. It also clarifies the tool's limitation (only DNS and email layer) implying it's not for full NIS2 audits. However, it does not name alternative sibling tools for further checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It states the tool is read-only, uses a single GET, requires no auth, and returns per-requirement pass/fail/warning verdicts with cited rules. This adequately discloses behavior, though it could mention if there are any side effects or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. First sentence explains purpose and checks, second sentence gives usage context and alternative. Information density is high and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one required param, no output schema), and the description covers purpose, scope, and return format adequately. Missing minor details like potential error conditions, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (domain) with schema description covering 100%. The description adds no extra semantic detail beyond 'Domain name, e.g. example.com.' Baseline score is appropriate as schema does the work.
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?
The description clearly states the tool checks Google/Yahoo 2024 bulk-sender requirements and lists specific checks (SPF, DKIM, DMARC, etc.). It distinguishes from sibling check_email_security by specifying what this tool covers beyond that sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use before sending bulk mail (5k+ messages/day to consumer providers)' and provides a clear alternative: 'use check_email_security for the broader read of SPF/DKIM/DMARC alone.' This gives direct when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses critical behavior: long duration (30-120s), immediate return, read-only nature, and polling requirement. Could mention error handling or failure modes, but overall strong for a read-only scan tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with no wasted words. Front-loaded with core purpose, followed by usage guidance and behavioral notes. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a long-running polling scan and no output schema, the description covers purpose, usage context, alternatives, and polling instructions. Missing error handling or outage scenarios, but sufficient for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for each parameter. The tool description adds no extra parameter-specific information beyond what is in the schema, so baseline 3 is appropriate.
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?
Clearly states it starts a long-running Internet.nl deep scan, returning a scanId immediately. Distinguishes from sibling scan_domain by noting the depth and compliance focus, and from cancel_deep_scan as the abort counterpart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly specifies when to use (for stricter compliance reporting or when Internet.nl-grade audit is requested) and when not (sub-10s answers use scan_domain). Also mentions polling pattern and links to cancel_deep_scan as alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully carries behavioral disclosure. States read-only, no auth, estimated 2-5s timeout. Details three combined signals and aggregate boolean return. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, efficient and no redundant information. Every sentence adds value.
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?
Given low complexity (one param, no output schema), description covers purpose, method, use cases, timing, and return structure. Complete for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'domain' with clear description. The tool description adds no further parameter meaning beyond schema, but implies domain usage. Baseline 3 is appropriate.
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?
The description clearly states it checks HTTP/3 and QUIC support for a domain, with specific verb and resource. It distinguishes from sibling check tools by focusing on modern transport protocol, not email security or DNS.
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?
Explicitly mentions use cases: validating CDN/Cloudflare HTTP/3 rollouts or auditing modern transport posture. Also says not relevant for mail-only domains. Lacks explicit alternative tool names but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses the behavior: it is read-only, performs only DNS and HTTPS GET requests, and details the specific checks (TXT record, policy file, certificate validity, consistency). No side effects or mutations are implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and well-structured: first sentence states purpose and method, second sentence describes return values and usage guidance. Every sentence adds value without redundancy.
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?
Given the tool's simplicity (single parameter, no output schema, no annotations), the description adequately covers what the tool does, what it returns, and how to use it. It even describes the return values in detail, compensating for the lack of output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a clear description for the 'domain' parameter (type string, example). The description does not add additional meaning or constraints beyond the schema, so a baseline score of 3 is appropriate.
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?
The description clearly states the tool performs a read-only check of MTA-STS by querying DNS TXT record and HTTPS policy file. It specifies the exact resources and distinguishes itself from sibling tools like check_smtp_tls by suggesting pairing for live validation.
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?
The description explicitly states the purpose: to verify enforced TLS for inbound mail, and recommends pairing with check_smtp_tls for live STARTTLS validation. It also notes that no authentication is needed, but lacks explicit 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool is read-only, recursively walks SPF mechanisms, counts DNS lookups against RFC limits, and returns specific outputs like parsed mechanisms and warnings. It could be slightly more explicit about error handling (e.g., missing SPF record), but overall it provides strong behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4 sentences) and front-loaded with the core purpose. Every sentence adds value: purpose, behavior, outputs, and usage guidance. No extraneous words or repetition.
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?
Given the simplicity of the tool (1 parameter, no output schema), the description covers input, behavior, outputs (parsed mechanisms, lookup graph, count, qualifier, warnings), and usage context. It is fully self-contained and informs the agent of everything needed to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'domain' with 100% coverage in its description ('Domain name, e.g. example.com'). The tool description does not add new semantics beyond this, as the schema already defines it clearly. Following the guidelines, baseline is 3.
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?
The description clearly defines the tool as 'Read-only SPF parse and validation for a domain,' specifying the verb (check/validate), resource (SPF record), and scope (a single domain). It distinguishes itself from the sibling tool 'check_email_security' by noting its narrower focus on SPF only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('for SPF auditing or before adding new include: senders') and when to use an alternative ('use check_email_security for the broader SPF+DKIM+DMARC overview'). It also notes there is no auth required and no side effects, guiding the agent appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Declares 'Read-only', 'No auth, no destructive actions.' Discloses lookup process and return values (parsed TLSA tuples, live cert digest, match verdict). Lacks details on potential errors or caching effects, but covers key behavioral aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences efficiently cover purpose, default behavior, parameter usage, and return values. Front-loaded with primary action and ends with usage guidance. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Describes return values despite no output schema. Covers main functionality and usage scenarios. Slight gap in error handling or interpretation of verdict, but overall sufficient for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning beyond schema by explaining defaults ('Defaults to port 25 / tcp') and providing examples ('HTTPS (443), SMTP submission (587)'). Schema has 100% coverage, and description enriches parameter understanding.
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?
Description clearly states 'Read-only TLSA/DANE record check' with a specific verb (check) and resource (TLSA/DANE record). It distinguishes itself from sibling tools like check_smtp_tls, check_dmarc, etc., by focusing on DANE record verification.
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?
Explicitly says 'Use before publishing DANE records or when troubleshooting mail-handover failures with DANE-enforcing senders.' Provides context on defaults (port 25/tcp) and ability to check other ports. However, does not explicitly contrast with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses it is read-only, requires no authentication, and takes ~3-8 seconds due to parallel DNS queries. Could include error handling details but is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with main purpose, includes specific examples of selectors and return values, no extraneous information.
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?
For a simple one-parameter tool without output schema, description details return values (parsed key tags, public key length, etc.) and behavior, making it complete for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already describes the 'domain' parameter. Description adds no additional parameter-specific context beyond what the schema provides.
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?
Clearly states 'Read-only DKIM selector discovery for a domain', specifies what it queries and returns, and distinguishes from sibling 'check_email_security' for combined overview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use when you do not know which DKIM selectors a domain publishes' and provides an alternative tool (check_email_security) for a different use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behavior: read-only, idempotent GET, no auth, returns pending state first then full results. It explains lifecycle and required inputs, leaving no ambiguity about side effects or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, highly concise, front-loaded with the core purpose. Every sentence adds information without redundancy. Ideal length for clarity.
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?
For a simple read tool with one parameter, the description covers all necessary context: return values, prerequisite, lifecycle, and an alternative tool. No gaps given the tool's complexity and lack of output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 adds marginal value by emphasizing the parameter's origin ('from create_email_test'), but does not provide additional semantic detail beyond the schema.
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?
Clearly specifies 'Read-only status read for an email-test session' with specific resource (email-test session) and verb (status read). It distinguishes from sibling poll_email_test by explaining different use cases and return values.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool: 'Use after sending a test message to that address' and provides an alternative: 'for explicit processing of just-arrived mail use poll_email_test instead.' Also notes prerequisite: 'Requires testId from create_email_test.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states 'Read-only' and 'No auth', disclosing safe behavior. It explains conditional output based on domain presence, compensating for lack of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (3 sentences) and front-loaded with the primary purpose, followed by parameter details and use cases. No redundancy.
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?
Without an output schema, the description adequately describes return values (entries with scores/timestamps or rank). Both parameters are explained, and the tool's read-only nature is clear.
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%, and the description adds value by clarifying default limit (10, max 50) and the behavioral difference when domain is provided versus omitted.
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?
The description clearly states the tool fetches the IntoDNS.ai Hall of Fame for A+ domains, specifying the full check suite. It distinguishes from sibling tools by focusing on a specific curated list rather than scanning or analysis.
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?
The description explains when to use the tool: to surface trust signals, embed badges, or pitch A+ posture. It details behavior for both parameter cases but does not explicitly mention when not to use or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It declares read-only nature, in-memory processing (no storage), and max 500KB constraint. Could mention error handling for oversized input, but overall sufficient.
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?
Single paragraph but packs all necessary information: purpose, what it parses, output, usage guidance, and constraints. Could be slightly more structured but remains concise and front-loaded.
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?
For a tool with one parameter and no output schema, the description adequately covers input constraints, analysis scope, output summary (spam score + suggestions), and usage context. No gaps identified.
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 covers 100% of parameters, and description adds meaning by specifying max size (500KB) and format (full headers+body) for the rawEmail parameter, beyond schema's description.
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?
The description clearly states it performs read-only analysis of pasted raw RFC-5322 MIME email source, lists specific parsed elements (Authentication-Results, SPF/DKIM/DMARC/ARC, etc.), and distinguishes from sibling create_email_test by specifying when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (debug a specific failing email with pasted raw source) and when to use an alternative (create_email_test when user can resend). Also mentions in-memory processing and no auth, providing clear boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It explicitly says 'Read-only', 'No auth, no destructive actions; only fetches the public logo + certificate.' This fully discloses safety and non-destructive nature.
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?
The description is moderately long but each sentence adds value: purpose, detailed checks, usage advice. It is well-structured and front-loaded with the main action. Could be slightly tighter, but not wasteful.
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?
For a single-parameter tool with no output schema, the description fully covers input, process, and outputs (parsed tags, compliance, etc.). No gaps remain.
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% (one parameter 'domain' with description). The description adds meaning by explaining what actions are performed on the domain (validate BIMI TXT, fetch logo, etc.), which goes beyond the schema's simple type definition.
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?
The description clearly states it is a 'Read-only BIMI readiness check' and specifies exact validations: BIMI TXT record, logo, certificate. It returns parsed BIMI tags, logo compliance, certificate validity, and vendor readiness. This differentiates it from sibling tools like check_dmarc or check_spf.
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?
Explicitly states 'Use before paying for a VMC/CMC and before publishing the DNS record.' This gives clear context. However, it does not explicitly mention when not to use or specify alternatives, though the list of sibling tools implies distinct purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses immutability, write-once, non-idempotent behavior, and return values (ID, timestamp, hash, URLs). Lacks details on auth/rate limits but is thorough for a read-only-like creation tool.
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?
Concise paragraph with front-loaded purpose. Contains multiple useful details without being verbose. Could be slightly more structured but effective.
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?
Given no output schema, description fully explains return values and behavior. Covers purpose, usage, parameters, and outcomes. No gaps identified for this tool's complexity.
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 covers all parameters (100% coverage). Description adds context: format parameter controls initial return but both JSON and Markdown URLs are returned, and note about non-idempotent POST.
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?
Clearly states it creates an immutable snapshot of the Everything Report. Distinguishes from siblings like get_everything_report and get_report_snapshot by emphasizing immutability and write-once nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (when stability is needed) and when not (use get_report_snapshot to read back). Mentions use cases: tickets, audits, compliance, LLM citations. Provides alternative tool recommendation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description fully discloses read-only nature, polling behavior, and status progression. Lacks details on error handling or timeouts, but covers essential traits for a polling tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each purposeful: defines tool, lists returns, gives usage instructions, provides alternative and behavioral note. No redundancy, efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers purpose, usage, return fields, and polling guidance. No output schema but description lists expected items. Could elaborate on error responses, but sufficient for a simple polling tool.
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?
Only one parameter scanId with schema description matching tool description. Schema coverage 100% so baseline 3; description reinforces where scanId comes from and how to use it, adding value.
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?
Description clearly states it's a read-only status poll for a long-running Internet.nl deep scan, with verb 'poll' and resource 'deep scan status'. It distinguishes from sibling 'scan_domain' by noting preference for fast scans, making purpose specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states prerequisite (scanId from start_deep_scan), polling interval (10-30s until finished), and when to use alternative (prefer scan_domain for fast scans). Also notes no auth and no side effects, providing clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
In the absence of annotations, the description discloses it is 'read-only HTTP, no auth, typical latency 5-15s', covering key behavioral traits. It does not mention rate limits or potential errors, but the disclosed information is substantial and matches the tool's read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently convey purpose, defaults, output, usage guidelines, and latency. No unnecessary words; front-loaded with the core action.
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?
For a tool with three parameters, no output schema, and no annotations, the description fully covers purpose, parameters defaults, output nature, usage context, and behavioral traits, making it complete for agent decision-making.
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 description coverage is 100%, so the baseline is 3. The description adds value by stating defaults ('Defaults to record type A, region all') and explaining that results include per-resolver answers with mismatch grouping and consensus, which goes beyond the schema.
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?
The description clearly states the tool compares DNS responses across multiple resolvers to detect propagation lag, with a specific verb (compare) and resource (DNS responses). It also distinguishes itself from sibling lookup_dns by highlighting its multi-resolver scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use when records were just changed and you suspect staleness' and provides an alternative: 'for single-resolver lookups use lookup_dns instead'. This gives clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It clearly labels the tool as 'Read-only', indicating no mutation, and discloses timing ('~3-8s') and authentication requirements ('No auth'). It also describes the combined nature and output (score, issue list).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus a summary. It front-loads the main purpose and includes all essential information without any wasted words.
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?
Given the tool's complexity (combining multiple checks), the description is very complete. It lists all checks performed, mentions the output (score and prioritized issue list), gives usage guidance, timing, and auth info. No output schema exists, but the description sufficiently covers what the agent needs to know.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'domain' has full schema coverage (100% described in input schema as 'Domain name, e.g. example.com'). The description does not add further parameter-specific details beyond what the schema provides, so baseline 3 is appropriate.
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?
The description clearly states it performs a combined read-only email security check including SPF, DKIM, DMARC, MX blacklist, and an aggregated score. It uses the verb 'check' and specifies the resource 'email security', distinguishing it from sibling tools like check_spf, discover_dkim, etc., by stating it replaces sequential calls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool ('one-shot email security overview') and when not to, providing alternatives: 'use check_sender_requirements for Google/Yahoo bulk-sender compliance, or the individual check_* tools when you need only one signal.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Clearly declares read-only behavior ('connects and quits without sending mail'), performance characteristic, and what it checks. No annotations provided, so description fully carries behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
No wasted words; all sentences informative. Front-loaded with main actions, followed by behavioral and usage details. Excellent structure.
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?
Although no output schema, description lists return values (cipher, cert SANs, expiry days, FCrDNS, STARTTLS flag). Covers live check nature, method, and use case comprehensively for a single-parameter tool.
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 has single parameter 'domain' with basic description. The tool description adds context that it queries all MX hosts for that domain, enhancing understanding beyond schema.
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?
Description clearly states specific actions: live check of MX hosts, TCP 25, EHLO+STARTTLS, certificate validation, etc. Distinguishes from sibling tool 'check_mta_sts' for policy layer.
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?
Explicitly recommends pairing with check_mta_sts and mentions slower speed (10-30s). Does not list when not to use, but context clarifies its role for inbound TLS posture checking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: idempotent POST, creates a fresh session each call (no modification of prior sessions), returns an address valid for 60 minutes, language defaults to en, and no auth required. With no annotations, the description fully covers behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each essential: main purpose, return values and idempotency, then usage instructions. No redundant words, well-structured, and front-loaded with key info.
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?
For a tool with one optional parameter and no output schema, the description covers creation, return values, validity, usage steps, idempotency, and language variants. It is fully self-contained and clear.
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% with one parameter already described. The description adds 'controls result text' for language, providing context beyond the schema's 'Result language'. This extra meaning justifies a score above baseline.
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?
The description clearly states it creates a new inbound email-test session, returning a unique single-use email address and testId. It distinguishes itself from sibling tools like get_email_test and poll_email_test by mentioning them.
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?
Explicitly explains when to use: debugging outbound mail's SPF/DKIM/DMARC/headers/spam triggers, and that after sending a mail to the returned address, one should call poll_email_test. Does not explicitly state when not to use, but provides clear workflow guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must communicate behavior. It states the tool is 'read-only POST to /ai/explain — never mutates DNS or domain state', which gives clear safety assurances. It does not fully address rate limits or authentication, but the disclosure of non-mutating behavior is sufficient for safe usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences effectively front-load the core purpose and then provide actionable usage details. Every sentence adds value without redundancy.
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?
Given the tool's simplicity (3 parameters, no output schema), the description explains input usage, hints at output format, and situates the tool within a workflow (after scan_domain, before generate_dns_fix). It is fully self-contained for an AI agent to use correctly.
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?
The input schema covers all three parameters with descriptions. The description adds value by explaining that `context` should come from prior scan output for better results, which goes beyond the schema's generic 'Optional issue context'. It also reiterates that `issue` is an enum, though this is already in the schema.
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?
The description clearly states the tool uses AI to explain a specific issue, listing the output fields (severity, business impact, root cause, recommended fix steps). It distinguishes from siblings like generate_dns_fix by noting that this tool explains 'why' a finding matters, while the sibling provides the actual fix snippet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use the tool ('after scan_domain when an agent needs to walk a user through why a finding matters') and when not to ('use generate_dns_fix for the actual DNS record snippet that resolves it'). Also advises passing `context` from prior scan output for higher-quality answers, providing clear guidance on tool invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: no scan, no network call, no auth, and returns JSON with badgeUrl. However, no mention of error handling for invalid domains or edge cases, but acceptable for a simple URL construction tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence adds value: purpose, behavior, return format, style options, sibling comparison. No redundancy. Well-structured and front-loaded.
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?
Given the tool's simplicity (2 params, no output schema), the description is complete. It explains what it does, what it returns, options, and differentiation from a sibling.
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 covers domain with example, style has enum but no description in schema. The description adds meaning by listing the style options, compensating for the schema gap.
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?
The description clearly states the tool builds a direct SVG badge URL for a domain's security score, with specifics like pure URL construction, no scan triggered, and no auth. It distinguishes from sibling get_pdf_report_link.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool (for embeddable status badges) and when not (use get_pdf_report_link for downloadable report URL). Also lists style options for customization.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description fully discloses read-only nature, no domain mutation, no auth, no side effects, and provides latency estimate (~5-15s). No contradiction with structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each with specific value: purpose, behavioral traits, usage guidance. No filler or redundant phrasing.
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?
No output schema, but description sufficiently covers scope, behavior, latency, and usage context for a complex tool with many siblings. Lists specific report sections (DNS, email, etc.) making it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already well-documented. Description adds no new parameter details beyond mentioning the format options (JSON/Markdown) which is inferable from the enum.
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?
Describes specific verb 'Generate' and resource 'complete live IntoDNS.ai report' with enumerated coverage areas. Distinguishes from siblings by naming alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('when the user asks for everything, the full picture, or a deep current-state summary') and when not to ('use scan_domain for a faster default scan, or create_report_snapshot when immutable'), with clear sibling references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully shoulders transparency. It discloses tool is idempotent: 'Pure URL construction — no scan triggered, no network call.' Describes output format: 'Returns a JSON object with `pdfUrl`' and fetch behavior: 'fetching the URL itself returns `application/pdf` of the latest scan results.' 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Highly concise: three sentences cover purpose, behavior, output, usage guidelines, alternatives, and auth. Front-loaded with key action and outcome. Every sentence adds value with zero redundancy.
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?
Given tool simplicity (1 param, no output schema, no nested objects), description fully covers what it does, how it works, what it returns, when to use, and what not to use. No missing critical details for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter 'domain' with schema description 'Domain name, e.g. example.com'. Schema coverage is 100%, so baseline 3. Description adds no additional semantics beyond the schema's example; no further constraints or formatting details are provided.
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?
Description clearly states verb 'Build' and resource 'direct PDF report endpoint URL for a domain.' It specifies 'Pure URL construction — no scan triggered, no network call from this tool.' Explicitly distinguishes from siblings like get_badge_link and create_report_snapshot, ensuring no confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Use for downloadable shareable reports.' Provides clear alternatives: 'use get_badge_link for an embeddable SVG status badge instead, or create_report_snapshot for an immutable hashed evidence URL.' Also notes 'No auth.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description declares read-only, explains use of DNS-over-HTTPS, and mentions return fields. Lacks explicit error handling behavior (e.g., NXDOMAIN), but overall transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded key purpose and return format. No fluff, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, description covers purpose, usage, default parameters, return content, and sibling differentiation. Lacks error handling details but is sufficient for a read-only lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. Description adds critical context: 'Pass `type` for a single record type or `types` for an array; if both omitted, returns A records.' This clarifies default behavior and the relationship between type and types.
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?
The description clearly states it is a 'Read-only DNS record lookup via DNS-over-HTTPS' and specifies return content. It distinguishes from siblings validate_dnssec and check_dns_propagation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use for arbitrary record queries' and provides alternatives 'use validate_dnssec for full DNSSEC chain validation, or check_dns_propagation for multi-resolver consensus.' Also notes no auth/rate limits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully covers: read-only, no destructive side effects, approximate timing (3-8s), and details of return (grade, score, issues, etc.).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences with clear structure: purpose, output, behavior, alternatives. No wasteful words.
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?
Despite no output schema, the description lists all return components (grade, score, issues, recommendations, sections) and suggests follow-up tools. Complete for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with description for 'domain' parameter. The tool description adds no extra semantic beyond what schema already provides, so baseline 3 is appropriate.
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?
The description clearly states 'Run the fast IntoDNS.ai DNS and email security scan' and distinguishes it from siblings like get_everything_report and start_deep_scan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says it's the default tool for scan evidence, mentions alternatives (get_everything_report for deeper, start_deep_scan for slower), and suggests post-scan actions (explain_issue, generate_dns_fix).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description fully carries the burden. It declares 'Read-only', 'Single GET, no auth, no side effects', and describes return values (parsed tag map, policy strength, warnings). There is no contradiction with any annotations.
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?
The description is concise: two sentences covering functionality, return values, usage guidance, and behavioral traits. It is front-loaded with the core action. Could be slightly more structured, but overall efficient.
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?
Despite lacking an output schema, the description explains the parsed tags and warnings returned. It covers prerequisites (domain), operation (fetch and parse), and results, making it complete for an agent to select and use the tool correctly.
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. The description adds context by specifying that the 'domain' parameter is for checking the _dmarc TXT record, which reinforces the tool's purpose beyond the schema description.
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?
The description specifies a precise action ('Read-only fetch and parse of the _dmarc TXT record') and lists detailed return values. It distinguishes itself from the sibling tool 'check_sender_requirements', which provides a combined pass/fail verdict.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool ('Use for DMARC policy review') and directs agents to an alternative ('use check_sender_requirements for combined Google/Yahoo SPF+DKIM+DMARC pass/fail verdict'). This provides clear decision guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, description fully discloses it is read-only GET, idempotent, returns immutable JSON with SHA-256 hash and timestamp, and requires no authentication. Covers safety and behavior comprehensively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, front-loaded with purpose and key traits. Every sentence adds information without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description explains return contents (immutable JSON with hash and timestamp). Covers how to get snapshotId and when to use. Lacks mention of error handling for invalid IDs, but sufficient for a simple read tool.
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%, baseline 3. Description adds context: 'Requires snapshotId from create_report_snapshot' and explains format enum values ('JSON data or LLM-ready Markdown'). Adds meaningful value beyond schema.
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?
Explicitly states verb 'Read', resource 'IntoDNS.ai Everything Report evidence snapshot', and distinguishes from sibling 'get_everything_report' which provides current live data. Clear and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use ('verify or re-read an audit-trail evidence record without re-running a live scan') and when not to ('use get_everything_report for current live data instead'). Also names the alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses idempotency ('Idempotent DELETE — safe to call even if scan already finished or never started'), safety ('returns acknowledgement either way'), and side effects ('No auth, no side effects beyond freeing the upstream job slot'). This is comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the key action. Each sentence serves a distinct purpose: action, idempotent behavior, usage guidance. No fluff or redundancy.
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?
Given the tool has one required parameter, no output schema, and no annotations, the description covers all essential aspects: purpose, prerequisites, behavioral guarantees, and usage scenarios. Nothing is missing for an agent to safely invoke this tool.
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% and schema already describes scanId as 'Deep scan ID returned by start_deep_scan.' The description reinforces this same information. While not adding new detail, it confirms the parameter's origin. Since the baseline for high coverage is 3, but description adds confirmation and context, a 4 is warranted.
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?
Description starts with 'Cancel an in-progress Internet.nl deep scan.' This clearly states the verb (cancel) and the resource (deep scan). It distinguishes from sibling tools like start_deep_scan and get_deep_scan_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'when the user changes their mind mid-scan or when polling get_deep_scan_status would otherwise time out.' Also specifies prerequisite: 'Requires scanId returned by start_deep_scan.' No guidance on when not to use, but the positive cases are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavior: read-only, no auth, typical latency 3-10s, and throws if neither domain nor ip is provided. Also explains domain resolution to MX IPs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and condensed into four sentences with no extraneous information. Every sentence adds value.
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?
Despite no output schema, the description details return values: per-feed status, response codes, and aggregate count. All parameters are covered, and behavioral notes complete the picture for a simple query tool.
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%, but description adds meaning: domain resolves to MX IPs, ip is checked directly, and at least one is required. This exceeds the schema's minimal descriptions.
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?
The description clearly states it is a read-only query against ~80 public DNSBL/RBL/URIBL feeds, specifying inputs of domain or IP. This distinguishes it from sibling tools like check_dmarc or check_spf, which address other email security aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states use cases: inbound mail reputation pre-checks before bulk mail or SMTP server onboarding. Also clarifies it is not a removal-request service, guiding the agent away from misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the tool's read-only nature ('the API only suggests; it never modifies the user's zone') and details the output (proposed records, TTL, provider-specific notes). This provides complete transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states purpose and output, the second covers usage, endpoint, and parameters. Every sentence adds value; no redundancy.
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?
Given the tool has 3 parameters and no output schema, the description explains the output format (records, TTL, notes), the read-only nature, and the appropriate workflow. It is complete for an agent to use effectively.
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?
The description explains the issue parameter as an enum with an example but does not list all possible values. It adds meaning by noting context should come from prior scan output. Schema coverage is 67% (issue lacks description in schema); the description partially compensates.
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?
The description clearly states the tool generates copy-pasteable DNS record snippets to fix a specific issue, with concrete examples like spf_missing. It distinguishes itself from sibling diagnostic tools like check_spf and lookup_dns by focusing on generating fix suggestions rather than just checking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly guides usage: 'Use after explain_issue or scan_domain identifies a problem; use lookup_dns afterwards to verify.' It also clarifies the tool is read-only and never modifies the zone, setting clear boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description states 'Pure data, no I/O, no auth', fully disclosing the tool's read-only, side-effect-free nature. It also details the return content, ensuring the agent understands the behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, each essential and front-loaded with the core purpose. No redundant words, and the structure is clear despite being prose.
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?
Given the tool has only one optional parameter and no output schema, the description covers all necessary aspects: return value, usage context, and alternative tool, leaving no gaps.
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?
The sole parameter 'topic' has no schema description (0% coverage), but the description lists all 11 enum values with contextual examples, adding meaning beyond the bare enum names. However, it could provide more detailed explanations for each topic.
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?
The description clearly states that the tool returns canonical citation guidance for IntoDNS.ai, specifically the host, do-not-use list, and preferred citation URLs for a given topic. It enumerates all valid topics, making the purpose unambiguous and distinguishing it from legacy sites.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to use this tool when generating answers referencing DNS or email scanning evidence, and contrasts it with read_llm_discovery for raw machine-readable discovery files, providing clear context for when to use and when not to.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully discloses read-only nature, no auth required, no parameters, and what the return includes (uptime, status, availability). 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with key purpose, and each sentence provides critical information without redundancy.
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?
Despite no output schema, the description explains return values comprehensively. All necessary context for a health check tool is present.
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?
No parameters exist, so schema coverage is 100%. The description adds value by explaining what the health check returns, which is sufficient for this zero-parameter tool.
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?
The description clearly states it is a read-only health probe for the IntoDNS.ai backend, specifies what it returns (API uptime, Redis/cache, AI runtime), and distinguishes from get_stats by noting no domain parameter and different purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (pre-flight check, diagnosing backend vs. DNS issues) and when not to use (use get_stats for usage counters), providing clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes read-only nature, no auth, ~100ms response, returns plain counters with timestamps, no personal data, no per-domain breakdown. Adequate disclosure beyond schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with action and return type. Every sentence adds value without redundancy.
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?
Covers purpose, behavior, use cases, response content, performance. Complete for a no-param, no-output-schema tool.
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?
No parameters; schema already confirms. Description adds no param info, but baseline for 0-param tool is 4. No additional value needed.
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?
Clearly states it fetches public usage counters for IntoDNS.ai. Verb 'fetch' and resource 'usage counters' are specific. Distinct from siblings that focus on domain-specific checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises use for status pages, badges, trust signals. Specifies not for per-user dashboard. Implicitly differentiated from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully covers behavior: idempotent POST, return states ('pending' vs parsed result), what it does (parses and returns full authentication + content analysis), and explicitly declares 'No auth, no destructive side effects.'
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: function, behavioral traits, and usage guidance. No redundant or irrelevant information.
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?
For a simple 1-param tool with no output schema, the description covers prerequisites, return values, behavior, and safety. No gaps remain.
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% with a clear description of testId. The description adds value by linking testId to its origin ('from create_email_test'), providing context beyond the schema's own description.
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?
The description clearly states 'Process the latest received message in an email-test session', specifying both the action (process) and resource (email-test session). It also distinguishes from the sibling tool 'get_email_test' by contrasting active vs passive usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('actively trigger parsing after the user reports sending the test mail') and when not to ('use get_email_test for passive status polling'). Names the alternative tool directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully discloses behavior: 'Pure HTTPS GET, no auth, no side effects.' This clearly indicates no destructive actions or side effects.
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?
Description is a single dense paragraph; all sentences are informative but could be broken into bullet points or shorter sentences for readability. Still concise relative to content.
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?
Given the tool's simplicity (one parameter, no output schema) and rich annotations of purpose and behavior, the description covers all necessary context without gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has one parameter with enum values but zero description coverage. The description adds meaning by explaining each file type's purpose (e.g., 'llms.txt (canonical agent index)') and default value, which goes beyond schema.
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?
The description specifies a read-only fetch of IntoDNS.ai LLM/agent discovery files, listing each file type and its purpose. It distinguishes from sibling tool get_citation_guidance by stating when to use this tool instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: when an agent needs canonical citation URLs, machine-readable API surface, or prompt-routing hints. Also provides alternative: 'use get_citation_guidance for a topic-narrowed citation list'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses it is a read-only operation ('Single HTTP GET, no auth, no destructive actions') and describes the full validation process, including what it checks (signatures, algorithm strength, key rollover) and what it returns (chain steps, grades, boolean). No annotations provided, so description carries full burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the main purpose, each sentence adds value. No wasted words.
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?
Given the tool's complexity (DNSSEC chain validation) and no output schema, the description is complete. It explains the validation steps, return values (chain steps, grades, boolean), and use case. No missing critical information.
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% for one parameter 'domain', so baseline is 3. The description adds meaningful context by explaining the domain is used in chain validation from root, adding value beyond 'Domain name, e.g. example.com'.
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?
The description clearly states the tool performs DNSSEC chain validation, walking the DS/DNSKEY chain, checking signatures, algorithm strength, and key rollover state. It distinguishes itself from lookup_dns(type='DNSKEY') by specifying it returns chain steps and validity, not raw data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use when a domain claims DNSSEC; use lookup_dns(type='DNSKEY') for raw key data only.' This provides clear guidance on when and when not to use, including an alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![intodns-mcp-server MCP server](https://glama.ai/mcp/servers/RoscoNL/intodns-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/RoscoNL/intodns-mcp-server)

Score Badge

Copy to your README.md:

[![intodns-mcp-server MCP server](https://glama.ai/mcp/servers/RoscoNL/intodns-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/RoscoNL/intodns-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/RoscoNL/intodns-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server