Skip to main content
Glama
Sign In
Veille MCP Server

Veille MCP Server

Official
by veilleio
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Email Qualification

intelligence_emailq
Read-only

Qualifies email addresses by verifying deliverability, checking SMTP inbox acceptance, detecting catch-all domains, and returning a verdict of valid, invalid, risky, disposable, or unknown.

Instructions

Email Qualification. Deep email deliverability verification. Performs full Email Validation plus SMTP inbox check, catch-all detection, and returns a qualification verdict (valid, invalid, risky, disposable, unknown). Credit cost: 5 credits per call.

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": {
      "query": "<query>"
    },
    "name": "intelligence_emailq"
  }
}

Input Schema

NameRequiredDescriptionDefault
queryYesThe email address to qualify (e.g. john@example.com). Automatically normalized to lowercase.
fieldsNoComma-separated list of fields to keep in the response, with dot notation for nested fields (e.g. name,location.city). Does not change the credit cost.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint, and destructiveHint=false, so safety is covered. The description adds genuinely non-obvious context: it makes an external SMTP connection (consistent with openWorldHint) and, importantly, discloses the exact cost of 5 credits per call, which is critical for an agent budgeting calls.

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

Conciseness4/5

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

Three tight sentences, capably front-loaded with the tool identity followed by mechanism, output vocabulary, and cost. The opening 'Email Qualification.' restates the title, a minor redundancy, but nothing else is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the burden of describing returns and does so by listing the five possible verdicts. Cost and method are disclosed; only failure modes (invalid syntax, SMTP timeouts, unknown-verdict caveats) and the effect of the fields projection go unmentioned.

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%, with both the email input and the fields projection documented including normalization and dot-notation examples. The description adds nothing beyond the schema about either parameter, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource ('Email Qualification', 'Deep email deliverability verification') and enumerates the concrete mechanics: full validation, SMTP inbox check, catch-all detection, plus the verdict vocabulary. It differentiates itself from the plainer sibling intelligence_email only implicitly through 'plus SMTP inbox check' and 'deep', rather than naming the alternative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by 'deep' verification and the 5-credit price, which signals a heavier/costlier tier than the sibling intelligence_email, so an agent can infer 'use this when you need deliverability, not basic validation'. However, no explicit when-to-use, when-not-to-use, or named alternative is provided.

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

Deploy Server

Other Tools