Assess whether a domain (or the domain of an email address) can receive mail and how strong its sender authentication is. Returns MX presence, SPF and DMARC policy, whether it's a free consumer provider (gmail, etc.) or a known disposable/temp-mail provider, and an overall verdict. Use to qualify leads and flag throwaway signups.
| Name | Required | Description | Default |
|---|---|---|---|
| domain_or_email | Yes | A domain (stripe.com) or an email address (a@stripe.com) |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states what the tool returns (MX, SPF/DMARC policy, provider type, verdict) and implies a read-only assessment, which is sufficient for basic transparency. It does not mention auth needs, rate limits, or live DNS lookup caveats, but these are minor gaps for a stateless assessment tool.
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 exactly two sentences. The first sentence states purpose, and the second lists outputs and use cases. There is no filler, redundancy, or unnecessary detail—every clause earns its place.
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 single-parameter tool with no output schema and no annotations, the description is self-sufficient: it explains what the tool does, the exact outputs an agent can expect, and when to use it. An agent has enough information to invoke it correctly and interpret the result.
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% description coverage for the single parameter, defining domain_or_email as 'A domain (stripe.com) or an email address (a@stripe.com)'. The description merely restates the same concept ('domain of an email address') without adding new parameter-specific detail, 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 states a specific action ('Assess whether a domain... can receive mail') and a clear resource ('a domain or the domain of an email address'). It enumerates concrete outputs (MX presence, SPF, DMARC, free/disposable provider, overall verdict), which clearly distinguishes it from sibling tools like dns_lookup or domain_intel by focusing on email deliverability and sender authentication.
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 gives use cases: 'Use to qualify leads and flag throwaway signups.' This is clear context for when to apply the tool. However, it does not name sibling alternatives or explain when not to use it (e.g., when raw DNS records are needed instead), so it lacks explicit when-not/exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct intelligence area—DNS, registration, email, subdomains, tech stack—so the set is largely unambiguous. The composite domain_report intentionally overlaps with several other tools, which creates minor selection ambiguity, though its description makes the combined-purpose clear.
All tool names follow a consistent pattern: lowercase snake_case noun phrases describing the data or intelligence returned (dns_lookup, domain_intel, domain_report, email_deliverability, subdomains, tech_stack). This is a predictable and uniform convention.
Six tools is well-scoped for a domain and company intelligence server. Each tool covers a distinct reconnaissance area, and the composite domain_report justifies its place without bloating the tool surface.
The server covers the main domain-intelligence lifecycle: DNS, registration, subdomains, email authentication, and technology fingerprinting. Minor gaps exist, such as no direct company-name-to-domain lookup and limited DNS record types, but agents can work around these for most lead-qualification and recon workflows.