Scan and fix email auth (SPF, DMARC, DKIM, MX, blacklists, expiry) + DNS checks. Validated fixes.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.6/5 across 10 of 11 tools scored. Lowest: 3.9/5.
Each tool targets a distinct DNS or email authentication task. Despite multiple DMARC-related tools, their purposes are clearly differentiated: build_dmarc_upgrade upgrades policies, generate_dmarc_record creates new ones, validate_dmarc_record validates pasted records, and scan_domain vs get_report differentiate fresh vs cached scans.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., build_dmarc_upgrade, check_record, scan_domain). No mixing of naming conventions, making the set predictable and easy to navigate.
With 11 tools, the server is well-scoped for a DNS/email authentication diagnostics tool. The number covers essential operations without being overwhelming or sparse.
The tool set covers core workflows: DMARC management (generate, validate, upgrade, parse reports), DNS checks (propagation, reverse DNS, SPF lookups), and DKIM selector checks. Minor gaps exist, such as the absence of SPF validation or DKIM signature verification, but the main diagnostic and monitoring use cases are supported.
audit_spf_includesAAudit a domain's SPF supply chain: walks every include and redirect it delegates to, and reports who can transitively send as it. Returns the resolved tree, per-node lookup attribution, the total authorized IPv4 address count, and typed findings — include_broken (a target that no longer publishes SPF, a PermError today), include_registrable (a delegated-to domain that does not exist, so a stranger who registers it becomes an authorized sender), include_expiring (registration lapsing within 30 days), pass_all_nested (a +all deep in the chain) and spf_record_unusable (the audited domain's OWN record is missing or does not parse, so there is no chain to walk). A domain we could not verify is reported as unverified and NEVER as available — never tell anyone a name is free on this tool's say-so unless the finding is include_registrable AND carries registry_confirmed: true. A registry_confirmed: false finding rests on DNS alone, which cannot tell an unsold name from one in redemption or on clientHold: report the mechanism as broken and the takeover risk as possible, but never as an available domain. Findings are risk analysis, not instructions: no SPF fix record exists here or anywhere else in DNS Doctor, because dropping a mechanism can silently de-authorize a real sender — relay the findings and let the domain's owner decide. Use count_spf_lookups instead when the question is only the 10-lookup limit.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | The domain to check, e.g. example.com. Bare registrable names and subdomains both work; scheme, path or port do not belong here. Unicode names are accepted and normalized to punycode. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate a safe, read-only tool, but the description adds critical behavioral nuances: unverified domains are never reported as available, registry_confirmed must be true for include_registrable to claim availability, and it warns about the dangers of SPF changes. This goes far beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but each sentence adds critical information for a complex audit tool. It is front-loaded with purpose and flows logically into return values, findings, and caveats. However, it is one dense paragraph and could benefit from structural breaks, so a 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of SPF supply chain auditing, the description covers the return shape, all finding types, edge cases (unverified, registry_confirmed), warning about availability, and the alternative tool. The presence of an output schema reduces the burden, but the description still explains the key outcomes thoroughly, earning a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the domain parameter, including format, subdomains, unicode normalization, and exclusions. The description doesn't add new parameter semantics; it only references domain in the context of verification failure. With 100% schema coverage, the baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb and resource: 'Audit a domain's SPF supply chain' and specifies what it does: 'walks every include and redirect it delegates to, and reports who can transitively send as it.' This distinguishes it from siblings like count_spf_lookups and scan_domain by focusing on transitive delegation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly names an alternative tool: 'Use count_spf_lookups instead when the question is only the 10-lookup limit.' It also strongly advises on how to interpret findings: 'Findings are risk analysis, not instructions' and 'relay the findings and let the domain's owner decide.' This is clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
build_dmarc_upgradeAInspectReturn a validated DMARC enforcement-upgrade record for a domain. The alignment gate (whether p=reject is safe) is derived server-side from a scan — a caller can never assert alignment. record is null when there is no honest upgrade to offer (the domain does not exist; the DMARC lookup itself hit NXDOMAIN while the existence probe did not resolve; the DMARC lookup temp-failed; or the domain already applies a policy at least as strong as this scan justifies): relay rationale and never compose a record to fill the gap. A returned record also carries np=reject (the DMARCbis tag covering non-existent subdomains, which can have no legitimate aligned mail) unless the domain already publishes an np tag, which is preserved as-is. Present a returned record verbatim; a human must approve before publishing.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | The domain to check, e.g. example.com. Bare registrable names and subdomains both work; scheme, path or port do not belong here. Unicode names are accepted and normalized to punycode. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond annotations by explaining that alignment is derived server-side from a scan and cannot be asserted by the caller. It details the exact conditions under which record is null, the np=reject behavior with preservation of existing np tags, and instructs to present the record verbatim. These are important behavioral constraints not implied by readOnlyHint or openWorldHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but every sentence carries necessary information about result semantics, null conditions, np tag handling, and usage constraints. It is front-loaded with the core purpose, followed by well-structured conditional details. Slightly verbose but justified by the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single well-documented parameter and the presence of an output schema, the description thoroughly covers the tool's behavior. It explains the return record's nature, null cases, and the required action (verbatim relay and human approval), making it complete for an agent to understand and use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for the single parameter `domain` is 100% covered, including accepted formats and punycode normalization. The tool description does not add additional parameter meaning beyond what the schema already provides, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Return a validated DMARC enforcement-upgrade record for a domain,' specifying both the action (return) and the resource (DMARC enforcement-upgrade record). The word 'validated' and the focus on 'enforcement-upgrade' distinguish it from siblings like generate_dmarc_record or validate_dmarc_record.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: to obtain a safe, server-validated DMARC upgrade. It explicitly instructs the caller to never assert alignment and to relay `rationale` when record is null, effectively saying 'do not compose a record to fill the gap.' It also notes a human must approve before publishing, but does not explicitly name alternative tools or when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
build_parked_domain_recordsABuild the three-record hardening pack that makes a NON-SENDING domain unusable for spoofing: a Null MX, a hard-fail SPF record, and a p=reject; np=reject DMARC record. For parked, redirect and brand-defensive domains only — NEVER for a domain that sends any mail, including transactional or one legacy system. Do NOT set confirm_no_mail on your own judgment or because a scan looked quiet: only the human who owns the domain can confirm it sends nothing, so ask them first. That flag unlocks the question, not the answer — the server re-checks DNS itself (existence, MX, SPF, DKIM selectors) and returns records: null with a rationale when it finds evidence of mail; relay that rationale rather than retrying. A lookup failure is reported as a failure, never as a pack. Publishing is the human's decision: present the records verbatim, in the order given, and let them approve each one.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | The domain to check, e.g. example.com. Bare registrable names and subdomains both work; scheme, path or port do not belong here. Unicode names are accepted and normalized to punycode. | |
| rua_email | No | Mailbox to receive DMARC aggregate (RUA) reports, as a plain address like dmarc@example.com. Strongly recommended: without it nobody can see who sends as the domain. | |
| confirm_no_mail | Yes | Must be true, and only the HUMAN who owns the domain may decide it: it records their confirmation that this domain sends no email at all. Never set it on your own judgment or because a scan looked quiet — ask them. It unlocks the question only; the server independently re-checks DNS for evidence of mail and refuses when it finds any. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds essential behavioral details beyond these: the server independently re-checks DNS, returns records:null with rationale when mail evidence is found, reports lookup failures as failures, and requires human approval. This significantly enriches the annotation context without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Although longer than typical, every sentence contributes critical information: the pack contents, domain eligibility, human confirmation requirement, server re-check behavior, failure handling, and publishing workflow. It is front-loaded with the core purpose and well-structured for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, scope, human-in-the-loop safety, server-side verification, failure semantics, and output handling (records verbatim, order, approval). Given the complexity and the presence of an output schema and annotations, the description is fully complete for agent selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds extra meaning for confirm_no_mail ('that flag unlocks the question, not the answer') and domain (scope restrictions), and it reinforces the human-decision aspect. It doesn't fully detail rua_email behavior, but that's already well-described in the schema; the additional context justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool's function: building a three-record hardening pack (Null MX, hard-fail SPF, DMARC p=reject) for non-sending domains. It distinguishes from siblings like build_dmarc_upgrade by explicitly scoping to parked/redirect/brand-defensive domains and excluding sending domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use guidance: 'For parked, redirect and brand-defensive domains only — NEVER for a domain that sends any mail'. It also clarifies the confirm_no_mail flag requires human confirmation and that the server re-checks DNS, with instructions to relay rationale rather than retry on null result.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_dkim_selectorACheck ONE specific DKIM selector on a domain — the exact selector the sending platform uses (e.g. google, s1), which a full scan's common-selector sweep may miss. Returns the verdict, its explanation, and the published key record when one resolves. No fix record is returned: a DKIM key is generated by the sending platform, so the fix is always to publish what that platform gives the owner.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | The domain to check, e.g. example.com. Bare registrable names and subdomains both work; scheme, path or port do not belong here. Unicode names are accepted and normalized to punycode. | |
| selector | Yes | The DKIM selector to probe — the name before ._domainkey, e.g. 'google', 'selector1', or a dotted form like 's1.prod'. The sending platform's settings page names it; it is not guessable from the domain. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits: it 'Returns the verdict, its explanation, and the published key record when one resolves' and explicitly states 'No fix record is returned' with a rationale about DKIM key generation. This adds substantial context beyond the readOnly/openWorld/idempotent annotations, making the tool's output and limitations transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and every clause earns its place. It efficiently conveys purpose, distinguishes from alternatives, describes outputs, and explains the absence of a fix record without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only two parameters, a rich input schema, an output schema, and comprehensive annotations, the description fully covers the necessary context: what it checks, when to use it, what it returns, and why no fix record is provided. There are no significant gaps in the guidance an agent would need.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage with detailed descriptions for both parameters (domain and selector), including the nuance that the selector is 'not guessable from the domain.' The description adds little beyond reinforcing that the selector is the exact one used by the sending platform, so the schema does the heavy lifting; the description only marginally extends the parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Check ONE specific DKIM selector on a domain', a specific verb+resource+scope, and explicitly contrasts with 'a full scan's common-selector sweep may miss', clearly distinguishing it from sibling scan tools. It also clarifies what is returned (verdict, explanation, key record), leaving no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool by stating it targets 'the exact selector the sending platform uses' that a full scan might miss. This provides clear context for choosing this tool over a broader scan, though it does not explicitly name an alternative or spell out 'when not to use' scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_recordACheck whether a DNS change has landed: reads the record from the domain's OWN nameservers (cache-free) and from two public caching resolvers, and reports whether they agree. kind is one of spf|dmarc|txt|mx|cname|a|aaaa — pass the kind, not a query name: dmarc reads TXT at _dmarc. and spf reads apex TXT, each filtered to the matching record. host prepends a label (txt, cname, a and aaaa only). Empty values mean the record is genuinely absent. When in_sync is false, max_wait_seconds is the largest remaining cached TTL — the wait before those resolvers refresh. This samples two resolvers, so never describe it as worldwide or as propagation coverage.
| Name | Required | Description | Default |
|---|---|---|---|
| host | No | Optional label to prepend to the domain (e.g. 'mail' to check mail.<domain>) — honored for txt, cname, a and aaaa only; spf, dmarc and mx derive their own query name. | |
| kind | Yes | Which record to read; the right query is derived from it — 'dmarc' reads TXT at _dmarc.<domain> filtered to v=DMARC1, 'spf' reads the apex TXT filtered to v=spf1, so don't prefix the domain yourself. | |
| domain | Yes | The domain to check, e.g. example.com. Bare registrable names and subdomains both work; scheme, path or port do not belong here. Unicode names are accepted and normalized to punycode. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the readOnlyHint and idempotentHint annotations. It details the exact query logic for each kind (e.g., dmarc reads TXT at _dmarc.<domain>), explains that empty values mean genuinely absent, and clarifies the meaning of in_sync false and max_wait_seconds. The caveat about sampling only two resolvers is critical behavior context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the main purpose, then systematically covers kind semantics, host restrictions, output interpretation, and limitations. Every sentence earns its place, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple record kinds, derived queries, cache-free vs caching resolvers), the description covers all essential aspects. The output schema exists, and the description still explains key output semantics like empty values and max_wait_seconds, making it thoroughly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides comprehensive descriptions for all three parameters (100% coverage), including kind's derived query logic and host's allowed types. The tool description largely restates this information, adding no significant new parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Check' and states the exact resource: 'whether a DNS change has landed' by reading from the domain's own nameservers and two public resolvers. This clearly distinguishes it from sibling tools like check_dkim_selector or check_reverse_dns, which target specific record types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use: 'Check whether a DNS change has landed' and provides an exclusion: 'never describe it as worldwide or as propagation coverage' because it samples only two resolvers. However, it does not name alternative sibling tools for specific DNS checks, so it lacks explicit alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_reverse_dnsACheck one sending IP's forward-confirmed reverse DNS (FCrDNS): reads the IP's PTR record, then resolves that hostname back and reports whether it returns to the same IP. verdict is confirmed (the pair agrees — what receivers want to see), ptr_missing (the IP publishes no reverse record), or mismatch (a PTR that does not resolve back). A PTR on its own proves nothing, because the IP's operator writes its own reverse zone — only the forward confirmation is evidence, so never report a bare PTR as verified. The fix is always made by whoever controls the IP (the hosting or mail provider), never in the sending domain's own DNS. Pass a public IPv4 or IPv6 address.
| Name | Required | Description | Default |
|---|---|---|---|
| ip | Yes | The sending IP to check, IPv4 or IPv6. Must be a public address — private, loopback and CGNAT ranges have no meaningful reverse DNS and are refused. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, idempotent, non-destructive), the description explains the internal two-step resolution process, defines each verdict, and warns about the misleading nature of bare PTR records. This provides rich behavioral context that annotations alone do not capture.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence in the description adds value: purpose, verdict definitions, critical warning about PTR interpretation, fix responsibility, and input requirement. It is front-loaded with the core purpose and remains compact without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter schema, rich annotations, and existing output schema, the description fully covers what the tool does, how to interpret its output, and the operational context (who can fix issues). No significant gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers the single 'ip' parameter with full description including the public address requirement. The description repeats the constraint ('Pass a public IPv4 or IPv6 address') but adds no additional semantic meaning beyond what the schema already provides. Baseline 3 applies due to 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') and resource ('forward-confirmed reverse DNS'), explaining the exact mechanism (PTR lookup then forward resolution) and the three possible verdicts. This clearly distinguishes it from sibling tools like check_record or check_dkim_selector.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool (checking a sending IP's FCrDNS) and crucial guidance on interpreting results ('never report a bare PTR as verified'), plus where fixes belong. It does not explicitly name alternative tools for comparison, but the usage context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
count_spf_lookupsAValidate an SPF record and count what it costs. Returns record_valid (the record parses as RFC 7208 SPF), findings (per-term diagnostics), has_pass_all (a +all that authorizes the whole internet to send as this domain), multiple_all (more than one all, which makes everything after the first unreachable), the parsed terms, and the lookup count against the limit of 10 with over_limit/near_limit and the offending_mechanisms that push it over. Pass EXACTLY ONE of domain (resolves the published record and counts recursively through nested includes) or record (parses a pasted record, its own terms only). This is the SPF validator — there is no separate one. Diagnose-only: no SPF fix record is ever returned, because removing a mechanism can silently de-authorize a real sender — relay the findings and let the domain's owner decide what to drop.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | Domain whose PUBLISHED SPF record should be resolved and counted recursively (nested includes cost lookups too). Pass exactly one of domain or record, never both. | |
| record | No | A pasted SPF record to parse instead of resolving one, e.g. 'v=spf1 include:_spf.google.com ~all'. Counts this record's own terms only. Pass exactly one of domain or record, never both. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description discloses critical behavioral traits: the diagnose-only nature with the explicit promise 'no SPF fix record is ever returned,' the rationale about silently de-authorizing senders, and the nested include recursion behavior. This adds significant context the annotations alone don't provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-structured, front-loading the main purpose and then flowing through return values, parameter usage, and an important caveat. Every sentence adds functional value, with no fluff or repetition. The length is justified by the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a rich description, full schema parameter descriptions, and an output schema present, the tool is fully specified. The description covers the 10-lookup limit, over_limit/near_limit indicators, offending_mechanisms, and the reason for not fixing records — leaving no practical questions about what the tool does and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Even though schema coverage is 100%, the description enriches both parameters by clarifying the exact-one constraint and behavioral difference: 'domain resolves the published record and counts recursively through nested includes' vs. 'record parses a pasted record, its own terms only.' This goes well beyond the schema's field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Validate an SPF record and count what it costs.' It clearly distinguishes this tool from siblings by stating 'This is the SPF validator — there is no separate one.' It also enumerates key outputs (record_valid, findings, has_pass_all, etc.), making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance including the two mutually exclusive modes: 'Pass EXACTLY ONE of domain or record' with detailed explanations of each. It also states when NOT to use it for fixes: 'Diagnose-only: no SPF fix record is ever returned' and explains why, positioning it against potential alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_dmarc_recordABuild a DMARC record from scratch for a domain that has none, using a validating engine — never compose one yourself. policy is none|quarantine|reject; optional rua_email (aggregate-report destination), subdomain_policy, and strict_alignment. Every generated record carries np=reject — the DMARCbis tag for non-existent subdomains, which can have no legitimate aligned mail — independently of the p= you choose. The generated record is re-validated before it is returned. Present it verbatim; a human must approve before publishing.
| Name | Required | Description | Default |
|---|---|---|---|
| policy | Yes | The requested p= policy: 'none' monitors only, 'quarantine' sends failing mail to spam, 'reject' refuses it outright. Start at 'none' unless the domain's aggregate reports already justify enforcement. | |
| rua_email | No | Mailbox to receive DMARC aggregate (RUA) reports, as a plain address like dmarc@example.com. Strongly recommended: without it nobody can see who sends as the domain. | |
| strict_alignment | No | Set true to emit strict alignment (aspf=s adkim=s), requiring an exact domain match instead of the organizational-domain match. Leave false unless you know every sender aligns strictly. | |
| subdomain_policy | No | Optional sp= policy for subdomains when it should differ from the main p= policy. Omit to let subdomains inherit p=. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral context beyond the annotations: every generated record includes 'np=reject' regardless of p=, the record is 're-validated before it is returned,' and it must be 'present[ed] verbatim' with human approval. These details are not visible in the readOnlyHint, idempotentHint, or destructiveHint annotations, and they inform the agent's action and output handling. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: the first states the core function, the second summarizes parameters and the critical np=reject behavior, the third explains re-validation and the human-approval requirement. It is front-loaded and free of redundant or vague phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description does not need to detail return values. It covers the essential context: when to use (domain without a record), key behavioral traits (np=reject, re-validation), and process requirements (verbatim presentation, human approval). This is complete for a 4-parameter, 1-required tool and complements the rich schema and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% parameter descriptions, covering policy, rua_email, subdomain_policy, and strict_alignment. The description merely summarizes these parameters (e.g., 'policy is none|quarantine|reject') without adding semantic depth beyond the schema. The np=reject mention is about output behavior, not parameter meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Build a DMARC record from scratch for a domain that has none.' This clearly distinguishes the tool from siblings like build_dmarc_upgrade (which implies working with an existing record) and validate_dmarc_record (which checks rather than builds). The phrase 'never compose one yourself' reinforces the tool's specific role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear usage condition: 'for a domain that has none,' implying this tool is for domains lacking DMARC records. It does not explicitly name alternatives or enumerate when-not-to-use scenarios, but the context is sufficiently clear. The guidance that a human must approve before publishing adds an important usage boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_alertsARead the monitoring alert log for the domains the caller's account monitors, newest first. Requires an API token. Each row carries id, domain, type, check, summary, a deterministic detail map, created_at, email_sent_at, acknowledged_at and delivery_class — a 'dashboard_only' row was deliberately kept out of the digest mail, so an agent watching only the inbox would never see it; this log is the complete picture. PAGE DOWN BEFORE ADVANCING since: next_before is non-null exactly when older rows remain, and a caller that ignores it, takes a full page and moves its watermark to the newest row it saw drops every row it did not receive. since is an INCLUSIVE floor, so rows repeat rather than go missing — de-duplicate on id. READ-ONLY by decision: there is no ack and no delete here, because acknowledging an alert is the human's own triage on their dashboard and an agent that acks on their behalf silences a row they have never seen. Report what the log says and let them clear it.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Optional alert-type filter, e.g. 'record_changed'. An unknown value is rejected rather than silently returning an empty page — omit it unless you know the exact type. | |
| limit | No | Page size, 1..100 (default 50). Page down with `before` before you advance `since`, or you will skip every row you did not receive. | |
| since | No | Optional ISO-8601 timestamp: return alerts created at or after it (INCLUSIVE). Poll by storing the newest created_at you have seen and passing it back — rows repeat rather than go missing, so de-duplicate on id. | |
| before | No | The opaque cursor from a previous page's next_before, relayed verbatim to fetch the next older page. Never construct or edit one. | |
| domain | No | Optional filter to ONE of the account's verified monitored domains. Omit it for every domain the account monitors; an unowned or unknown name is refused as not found. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds rich behavioral context: it requires an API token, explains why the tool is read-only (to avoid silencing unread alerts), details the `dashboard_only` delivery_class nuance, and exposes pagination edge-case behavior (dropping rows when ignoring `next_before`). No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average but every sentence carries operational weight. It is front-loaded with the core purpose and scope, followed by field highlights, then high-stakes pagination warnings in caps, and finally the read-only rationale. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a data retrieval tool with a generic output schema (indicated by 'Has output schema: true'), the description covers all necessary contextual aspects: authentication, scope, field list, pagination behavior, exclusion semantics, and usage guardrails. It is complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds significant semantic value: it explains the inclusive `since` floor and de-duplication need, warns that `before` is an opaque cursor never to be constructed/edited, and notes that unknown `type` or `domain` values are rejected, not silently ignored. This goes well beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise verb-resource-scope statement: "Read the monitoring alert log for the domains the caller's account monitors, newest first." This distinguishes it clearly from all sibling tools, which are about DNS/SPF/DMARC checks or report generation, not alert logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly frames when this tool is appropriate ("agent watching only the inbox would never see it; this log is the complete picture") and when not to use it for actions ("there is no ack and no delete here"). It also gives crucial operational guidance on pagination ('PAGE DOWN BEFORE ADVANCING `since`') and the inclusive `since` semantics with de-duplication advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_readinessARead the DMARC enforcement-readiness verdict for ONE domain the caller's account monitors, computed from its aggregate (RUA) report window. Requires an API token. Returns whether the domain is ready to step its policy up, the blockers that say why it is not, the window the verdict rests on, and next_record — the validated record for the next step, generated by the engine and null while blocked. THAT NULL IS AN ANSWER: relay the blockers and never compose a stronger record to fill the gap. Present a returned record verbatim; a human must approve it before it is published. Use this before proposing enforcement — a scan can show a domain's current policy, but only this evidence window can say whether tightening it would start rejecting real mail.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | One of the token account's VERIFIED monitored domains, e.g. example.com. Any other name — another account's, or one nobody monitors — is refused as not found; ownership is never disclosed. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations declare readOnlyHint=true, the description adds critical behavioral nuance: it explains that next_record is null when blocked, and that 'THAT NULL IS AN ANSWER: relay the blockers and never compose a stronger record to fill the gap.' It also mandates presenting the record verbatim and requiring human approval, plus notes 'Requires an API token.' These details go well beyond the annotation safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place. It front-loads the core purpose, then explains return fields, null semantics, usage caveats, and approval requirements without repetition or filler. The structural flow is logical and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is conceptually complex (readiness verdict, blockers, null handling, human approval), yet the description covers the full context: what it returns, what null means, how to handle the record, when to use it, and the required authentication. With an output schema also present, this description is complete for correct invocation and handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the domain parameter description already explains it must be a 'VERIFIED monitored domain' and that ownership is not disclosed. The tool description reinforces 'ONE domain' and 'caller's account monitors' but adds no new semantic meaning beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Read the DMARC enforcement-readiness verdict for ONE domain the caller's account monitors.' It clearly distinguishes this from sibling tools like scan_domain by emphasizing the evidence window and the readiness verdict, noting that 'only this evidence window can say whether tightening it would start rejecting real mail.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'Use this before proposing enforcement' and contrasts with scan_domain ('a scan can show a domain's current policy, but only this evidence window can say whether tightening it would start rejecting real mail'). It also gives strong when-not-to instructions: 'never compose a stronger record to fill the gap' and 'a human must approve it before it is published.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_reportAReturn the stored report for a domain, scanning once only if none exists yet — the cheap read, and the right default for a first look. Returns the same seven-check report as scan_domain (SPF, DKIM, DMARC, MX, DNS hardening, domain/TLS expiry, blacklist; each with a status, the observed record and any fixengine fix_record), including scanned_at so you can judge staleness yourself. Prefer scan_domain when you specifically need state re-read right now — for example after a DNS change.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | The domain to check, e.g. example.com. Bare registrable names and subdomains both work; scheme, path or port do not belong here. Unicode names are accepted and normalized to punycode. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a key behavioral trait beyond annotations: it may 'scan once only if none exists yet,' explaining why readOnlyHint is false. It also adds the `scanned_at` field so the agent can judge staleness, providing context that annotations alone do not convey. It doesn't go into error cases or rate limits, but for this tool the disclosed behavior 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly packed: two sentences deliver purpose, behavior, return contents, staleness cue, and explicit alternative. Every clause earns its place, and the most important 'cheap read' framing is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter, a rich schema, and an output schema (though not shown). The description explains the full return face (the same seven-check report as scan_domain, including statuses and observed records) and provides the alternative guidance. There are no significant gaps for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% parameter coverage with a detailed description of the domain parameter including format rules and punycode normalization. The tool description does not add further parameter semantics, but it doesn't need to given the schema's richness. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's verb and resource: 'Return the stored report for a domain.' It also distinguishes itself from the sibling 'scan_domain' by framing get_report as the 'cheap read' and 'right default for a first look,' while scan_domain is for forcing a fresh scan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: get_report is recommended as the default first look, while 'Prefer scan_domain when you specifically need state re-read right now — for example after a DNS change.' This directly tells the agent when to choose this tool over its alternate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
parse_dmarc_reportAParse ONE DMARC aggregate (RUA) report into readable per-source aggregates: who sent mail as the domain, how much, and what share was SPF/DKIM aligned. Pass the file's bytes base64-encoded in content_base64 (XML, .gz or .zip; up to 2 MiB decoded) with an optional filename. Nothing is stored — the report is parsed and discarded.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | No | Optional original attachment filename, recorded in logs only — format detection is content-based, so this changes nothing about parsing. | |
| content_base64 | Yes | One DMARC aggregate (RUA) report file, base64-encoded: the .xml, .xml.gz or .zip attachment exactly as received, up to 2 MiB decoded. Encode the file bytes — do not paste raw XML here. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=true, destructiveHint=false), the description adds valuable behavioral context: 'Nothing is stored — the report is parsed and discarded' and the 2 MiB decoded size limit. This clarifies side effects and constraints, complementing the annotation-provided safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states purpose and output, the second provides input instructions and a key behavioral note. Every sentence earns its place, with no冗余. It is front-loaded and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, the description covers input format, size constraints, output summary, and side effects. An output schema exists, so return values are already structured; the description's output summary is sufficient context. No significant gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptive parameter comments. The description adds further meaning by specifying that content_base64 expects encoded file bytes (not raw XML), the decoded size limit, and that filename only affects logs, not parsing. This enriches the schema with practical usage details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Parse' with a specific resource 'DMARC aggregate (RUA) report' and defines the output as readable per-source aggregates (who sent mail, how much, alignment share). This distinguishes it from sibling tools like get_report, which likely fetches reports rather than parsing provided content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear invocation context: pass file bytes base64-encoded in content_base64, with optional filename. It also specifies supported formats and size limit. However, it does not explicitly name alternatives or when-not-to-use, though the instruction is sufficiently clear for the intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scan_domainAInspectForce a fresh scan of a domain and return its full report: seven deterministic checks — SPF, DKIM, DMARC, MX, DNS hardening, domain/TLS expiry and blacklist listing — each with a status (pass/warn/fail/info/temperror), the observed record, and a fixengine-generated fix_record where one exists. Explanations are cache-first. A repeat scan of the same domain within a minute reuses the stored report. Use this when you need current state; use get_report when a recent cached answer will do.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | The domain to check, e.g. example.com. Bare registrable names and subdomains both work; scheme, path or port do not belong here. Unicode names are accepted and normalized to punycode. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, but the description adds useful behavioral details beyond those: it forces a fresh scan, uses cache-first explanations, reuses stored reports within a minute, and includes a fixengine-generated fix_record when available. These details clarify the tool's execution model and output, going beyond the annotated safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a purpose sentence, a breakdown of checks and outputs, a caching note, and a usage comparison. Every sentence earns its place with no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a rich output schema and a single well-documented parameter. The description covers purpose, output structure (seven checks, statuses, observed record, fix_record), caching behavior, and sibling differentiation, making it complete for an AI agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single 'domain' parameter, including examples and constraints (no scheme/path/port, punycode normalization). The description does not add new parameter semantics beyond what the schema already documents, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: 'Force a fresh scan of a domain and return its full report.' It lists exact checks (SPF, DKIM, DMARC, MX, DNS hardening, expiry, blacklist) and distinguishes itself from sibling 'get_report' by explicitly contrasting 'current state' vs 'recent cached answer.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use guidance: 'Use this when you need current state; use get_report when a recent cached answer will do.' It also clarifies the one-minute cache reuse rule, helping the agent decide if a fresh scan is actually needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
start_monitoring_signupAReturn a sign-up link to give to the HUMAN who owns a domain, so they can start monitoring it themselves. Nothing is created and no email is sent by this call: the returned signup_url opens a page that explains monitoring and asks them to sign in with their own email address; the domain is carried over to their dashboard, already filled in, only after that, and monitoring itself starts once they prove ownership with a TXT record. Hand them the URL and relay message — never sign in on their behalf.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | The domain to check, e.g. example.com. Bare registrable names and subdomains both work; scheme, path or port do not belong here. Unicode names are accepted and normalized to punycode. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations (readOnlyHint, idempotentHint, destructiveHint) by explaining exactly what happens: nothing is created, no email is sent, the returned URL requires the user to sign in, and monitoring starts only after TXT ownership proof. It also warns against signing in on the user's behalf, which is critical safety context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, yet conveys all essential information: purpose, side effects, workflow, and usage instructions. Every clause earns its place without redundancy, making it both concise and effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a single parameter, rich schema, output schema, and annotations, the description fully covers the behavioral workflow and expected handling. It explains the multi-step signup process and the agent's role, leaving no significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for 'domain' is already comprehensive (100% coverage), detailing accepted formats, exclusions, and normalization. The tool description adds no parameter-specific information, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Return a sign-up link to give to the HUMAN who owns a domain, so they can start monitoring it themselves.' It distinguishes itself from all sibling tools, which perform scanning, checking, or generation, by focusing on the signup flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs when to use the tool (when the human owner should start monitoring themselves) and provides behavioral guidance: 'Hand them the URL and relay message — never sign in on their behalf.' It does not explicitly name alternatives, but the context makes it clear that this is for user-driven signup rather than direct action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_dmarc_recordAValidate a pasted DMARC record: parsed tags, level'd findings, and whether it is valid. No DNS lookup — pass the record string itself. upgrade_record previews a stronger policy and is capped at p=quarantine: a pasted record carries no alignment evidence, so p=reject needs a full scan (use build_dmarc_upgrade). Present any returned record verbatim.
| Name | Required | Description | Default |
|---|---|---|---|
| record | Yes | The DMARC record text to validate, e.g. 'v=DMARC1; p=none; rua=mailto:reports@example.com'. The record value only — not the _dmarc hostname it is published at. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, safe behavior. The description adds beyond that by disclosing the no-DNS-lookup constraint and instructing 'Present any returned record verbatim,' which aids agent behavior without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence serves a distinct purpose: purpose, input constraint, alternative guidance, and output handling. It is front-loaded with the core action and remains compact without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a rich output schema and strong annotations, the description fills all remaining gaps: when to use, what not to expect (no DNS), how to handle output, and relationship to siblings. Nothing important is missing for a simple single-parameter validation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers the single parameter at 100%, so baseline is 3. The description reinforces semantics by clarifying the record is a string value (not hostname) and adds context about p=reject limitations, adding value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates a pasted DMARC record, listing specific outputs (parsed tags, findings, validity). It distinguishes itself from siblings by explicitly noting 'No DNS lookup' and contrasting with upgrade_record and build_dmarc_upgrade.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'pass the record string itself' and 'No DNS lookup.' It also names alternatives (upgrade_record for previews, build_dmarc_upgrade for p=reject via full scan), making the decision boundary clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.