Skip to main content
Glama
Sign In

SpendPreflight

by io.github.spendpreflight
OverviewDiscussionsAdmin

Domain email-auth DNS observations

domain_auth
Read-only

Use when you need public DNS email-authentication observations for a domain. Observe a public domain’s MX, SPF, direct DMARC record, supplied DKIM selectors and resolver-reported DNSSEC evidence.0.005 USDC per usable report, no shared trial. Fixed public Cloudflare DoH only, at most7 queries/shared8s/128KiB, no SMTP, sender authentication test, DNS changes or query storage. Missing selectors and inherited DMARC policy stay unknown. Published records and resolver AD are not proof of inbox delivery, alignment, DNSSEC validation by this service or a secure domain. Price: 0.005 USDC. Minimal input example: {"domain":"example.org","selectors":["selector1"]}. Illustrative output excerpt: {"spf":{"status":"unknown"},"dmarc":{"status":"unknown","alignment_verified":false},"mx":{"status":"unknown","smtp_reachability":"untested"}}. Illustrative output excerpt, not a live result, signature, approval or guarantee. Freshness/data/availability checks still apply. How to pay (MCP): No shared free trial for this tool. Use an x402-capable MCP client. A generic MCP connector without payment support cannot complete a paid continuation. On payment required, STOP. Inspect the exact accepts amount, asset, network and payTo; obtain explicit wallet/budget approval before continuing. Only after approval, let the configured x402 MCP client attach its signed payload in _meta["x402/payment"] and retry the same tools/call arguments. Never send a separate USDC transfer or paste keys into tool arguments. Never silently fall back from free access to payment. If a signed attempt has an unknown outcome, inspect that authorization/transaction; do not create another automatically.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "domain": "<domain>"
    },
    "name": "domain_auth"
  }
}

Input Schema

NameRequiredDescriptionDefault
domainYesRequired. Public DNS hostname string without scheme, path, IP address or credentials. Example: example.com.
selectorsNoOptional. Array of 1–3 unique supplied DKIM selector strings; no discovery guesses. Example: ["default","google"]. Omit to skip DKIM selector checks.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / domain / description
      Added value: +"Required. Public DNS hostname string without scheme, path, IP address or credentials. Example: example.com."
    • addedInput schema / properties / selectors / description
      Added value: +"Optional. Array of 1–3 unique supplied DKIM selector strings; no discovery guesses. Example: [\"default\",\"google\"]. Omit to skip DKIM selector checks."
  2. Added

TDQS

A4.2/5.0
Behavior5/5

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

Beyond the read-only and open-world annotations, it discloses the fixed Cloudflare DoH resolver, query/rate/size ceilings, absence of SMTP and query storage, pricing, and detailed x402 approval and retry safeguards. It also explains important evidentiary limits: published records and resolver AD do not prove delivery, alignment, service-side DNSSEC validation, or domain security.

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

Conciseness2/5

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

The purpose is front-loaded, but the definition is a dense block with malformed spacing such as 'evidence.0.005' and 'at most7', and it repeats both the price and the absence of a shared trial. Much of the payment material is useful, but the repetition and lack of visual separation substantially impede scanning.

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 paid, open-world DNS tool without an output schema, it supplies scope, resolver and query limits, unknown-result semantics, interpretation caveats, an illustrative output excerpt, cost, and a precise payment-recovery procedure. Although the excerpt is not a complete response contract, the definition is comprehensive enough for safe selection and 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 description coverage is 100%, so the baseline of 3 applies. The minimal input example and references to supplied DKIM selectors reinforce correct use but add little beyond the schema's existing domain-format, selector-count, and omission guidance.

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 uses a specific observation verb and enumerates MX, SPF, direct DMARC, supplied-selector DKIM, and resolver-reported DNSSEC evidence for a public domain. This narrow DNS email-authentication scope distinguishes it from generic siblings such as security_check and check_endpoint.

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 opening 'Use when' clause gives a clear selection condition, while exclusions for SMTP sender-authentication testing and DNS changes help prevent misuse. It does not name an alternative for broader security checks, DKIM discovery, or inherited DMARC requirements, so the guidance is not fully comparative.

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

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources