Check an email address for deliverability with Truelist and get status, risk state, and domain metadata to confirm list quality.
Validate an email address for deliverability using Truelist. Returns state (ok/email_invalid/risky/accept_all/unknown), sub_state, and metadata like domain, canonical, mx_record, first_name, last_name, and verified_at.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes |
Changes observed during successful MCP inspections.
v0.1.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no output schema, the description usefully enumerates the possible return states (ok/email_invalid/risky/accept_all/unknown) and the returned metadata fields, which is real behavioral value. However, it omits auth/permission requirements, rate limits or credit costs, and what distinguishes 'risky' from 'accept_all' from a caller's standpoint.
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 tight sentences, front-loaded with the core purpose and followed by the response contract. 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?
For a single-parameter validation tool with no output schema and no annotations, the description does the essential work by enumerating return states and metadata fields. It falls short only on operational context (auth, cost, error semantics) that a caller might still 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?
Schema description coverage is 0% and the single 'email' parameter has no description, so the description carries the burden — yet 'an email address' merely restates the parameter name without format, normalization, or canonicalization behavior. The parameter is self-evident, which keeps this from being a 1, but nothing is added 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?
States a specific verb and resource ('Validate an email address for deliverability') plus the underlying provider (Truelist), which is unambiguous. It hints at the singular scope versus the sibling validate_emails, but never names or contrasts the batch variant, so sibling differentiation is only implicit.
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?
No guidance on when to choose this over validate_emails (batch) or check_account, and no prerequisites, quotas, or exclusions are stated. The only contextual signal is the word 'deliverability', which an agent must interpret on its own.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.