check_blacklistCheck whether a sending domain or IP is currently on any of the major email blacklists that can push your mail to spam — a point-in-time reputation check across lists like Spamhaus, SpamCop, and Barracuda. No credit used. Requires the Qualisend Blacklist Monitoring add-on.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | A domain (acme.com) or an IPv4 address. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=true, destructiveHint=false), the description adds 'No credit used' (cost impact) and 'Requires the Qualisend Blacklist Monitoring add-on' (prerequisite). It also clarifies scope with named blacklists and 'point-in-time' nature, which annotations do not convey.
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?
Two sentences: the first clearly states the purpose, the second adds cost and prerequisite. No redundancy or fluff; the most important information 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?
With one parameter and strong annotations, the description covers purpose, scope, prerequisites, and cost. However, since there is no output schema, it could more explicitly describe the return format (e.g., boolean vs list of blacklists), though the phrasing 'whether... is currently on any' implies a binary result. Overall, sufficiently complete for a simple read-only 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 already fully covers the single 'target' parameter with format examples ('A domain (acme.com) or an IPv4 address'). The description merely repeats 'domain or IP' without adding syntax, constraints, or parameter behavior, so it adds no 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 uses a specific verb+resource: 'Check whether a sending domain or IP is currently on any of the major email blacklists' and names concrete examples (Spamhaus, SpamCop, Barracuda). This clearly distinguishes it from sibling tools like check_domain, which likely covers broader domain reputation, by focusing on blacklist status.
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 clear context: use for a point-in-time reputation check that can affect spam placement. Also mentions prerequisites ('Requires the Qualisend Blacklist Monitoring add-on') and cost behavior ('No credit used'). However, it does not explicitly contrast with alternatives or state when not to use.
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.