check_domainCheck whether a domain is set up to send email that reaches the inbox — its mail servers plus its SPF and DMARC sender-authentication, and what's missing. A plain deliverability health check for a sending domain. No credit used. Available on the Qualisend Pro plan.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | The domain to check, e.g. acme.com. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral details: it explicitly says 'No credit used' (a cost implication) and that the check reports 'what's missing' in sender authentication. It does not contradict any annotation and adds useful context beyond the 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four short sentences, with the purpose front-loaded. The first sentence captures what the tool does, the second restates it as a 'health check' (slight redundancy but reinforces clarity), and the final two sentences provide cost and plan info. Every sentence earns its place with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read-only tool, the description covers purpose, scope, cost, and plan restriction. It hints at output behavior by noting 'what's missing,' which gives some expectation of the result. It does not describe the exact output format, but given the simplicity and the absence of an output schema, the description is reasonably 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?
Schema coverage is 100%: the single 'domain' parameter is described as 'The domain to check, e.g. acme.com.' The description confirms 'a sending domain' but does not add extra formatting details or examples beyond the schema. With full schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Check' with the resource 'a domain's email setup' and further details the scope: 'mail servers plus its SPF and DMARC sender-authentication, and what's missing.' This distinguishes it from sibling tools like verify_email (which checks individual addresses) and check_blacklist (which checks reputation). The purpose is unambiguous and specific.
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 phrase 'a plain deliverability health check for a sending domain' provides clear context for when to use this tool. It also notes 'No credit used' and 'Available on the Qualisend Pro plan,' which are practical usage constraints. It does not explicitly state when not to use it or name alternatives, but the context is sufficient for common cases.
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 function: single verification, synchronous batch, asynchronous bulk list, plus separate diagnostic checks (disposable, typo, domain, blacklist, header, SMTP code). The three verify tools are clearly differentiated by single vs. batch, sync vs. async, and size limits.
All tool names follow a consistent verb_noun pattern in snake_case: check_*, get_*, verify_*, generate_*, analyze_*, lookup_*. The batch variations (verify_emails, verify_list) are predictable extensions of verify_email.
12 tools is well within the ideal range for a focused email verification service. Each tool serves a clear purpose covering verification, diagnostics, DNS generation, and account management without unnecessary bulk.
The domain is well-covered: single/batch/large-list verification, common pre-check diagnostics, blacklist lookup, DNS record generation, and SMTP code explanations. Minor gaps include no history listing or batch job management beyond polling, but these are not core to the stated purpose.