Verifly MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.1.0
Disambiguation4/5
Most tools have distinct purposes, but a few overlap in concept: verify_batch and submit_bulk both verify lists (sync vs async), and get_credits, get_usage, and get_account all touch credit information. Descriptions are clear enough to disambiguate, but the boundaries are slightly fuzzy.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern in snake_case (verify_email, submit_bulk, get_job_status, buy_credits, etc.). No naming deviations or mixed conventions.
Tool Count5/5
15 tools is at the upper end of the well-scoped range, but each tool earns its place by covering a distinct operation within email verification, bulk job lifecycle, and account management. No tool feels redundant.
Completeness5/5
The surface is remarkably complete for the domain: single verification, sync batch, async bulk with full job lifecycle (submit, status, results, list), cleaning, extraction, domain health, account management, credit tracking, purchase, and self-onboarding. No obvious dead ends or missing critical operations.
Average 4.2/5 across 15 of 15 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It accurately indicates a read operation ('Return') and describes the response contents, but it does not disclose potential limitations such as data freshness, pagination, or performance implications. The schema covers limits via the 'limit' parameter, but the description itself adds no extra behavioral context.
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?
The description is a single sentence that front-loads the core function and then enumerates the response components. It is efficient, with no redundant phrases, though the list is somewhat long. Every part contributes value.
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 adequately explains the return values by listing the main data points. It covers the period options and mentions recent activity, which aligns with the 'limit' parameter. It does not clarify the default period or the default limit, but those are in the schema defaults. Overall, sufficient for a reporting tool with no annotations.
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 'limit' and 'period' already documented in the schema. The tool description restates the period options ('day, week, or month') but does not add new parameter details. Per rubric, baseline 3 applies when schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and clearly identifies the resource ('detailed usage statistics for the account over a period'). It lists concrete data (credits used, emails processed, request counts by endpoint/source, daily breakdown, recent activity), making it distinct from siblings like get_credits or get_account.
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?
The description implies use for detailed reporting but does not explicitly state when to use this tool versus alternatives such as get_credits (for credit balance) or get_account. No when-not-to-use guidance is provided, so the usage context is only implied by the detailed scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosure. It reveals the specific DNS records checked, but does not explain the response format, scoring criteria, or any potential side effects/limitations. For a read-only check tool, some behavioral context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Exceptionally concise: two sentences that immediately convey what the tool does, what it checks, and when to use it. No wasted words or redundant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should compensate by explaining return values. It mentions an 'overall health score' but does not describe the response structure, interpretation, or error handling. For a simple single-parameter tool, it is adequate but leaves the agent uncertain about the result format.
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% and the single 'domain' parameter is well-documented with an example. The description adds no additional parameter semantics beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it checks DNS and deliverability health of an email domain, listing MX, SPF, DMARC, and health score. This distinguishes it from sibling tools like verify_email which check individual addresses rather than domain-level configuration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes two use cases: diagnosing bounced domains and validating sending domains. It does not explicitly name alternative tools, but the domain-vs-address distinction is clear from the description and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses optional deduplication and lowercasing behavior, adding value beyond the schema defaults. However, it does not mention edge cases like invalid formats, no matches, or the return type, which could be relevant for an extraction tool. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a trailing clause, front-loaded with the core purpose. Every word earns its place—no fluff or redundancy. It is highly concise while conveying essential behavior.
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?
This is a low-complexity tool with no output schema, but the description explains the input and optional processing, making the return (a list of extracted emails) fairly obvious. It is complete enough for the tool's simplicity, though a note about empty results could improve it.
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 coverage is 100%, so the baseline is 3. The description adds context by framing the text parameter as 'free-form text' and noting optional processing, but it largely mirrors the schema's default descriptions. It does not add significant syntactic or behavioral detail beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (extract), the resource (email addresses), and the context (free-form text), which is distinct from sibling tools like verify_email or clean_email_list. It also notes optional deduplication and lowercasing, adding specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use: when you have free-form text with email addresses, such as notes, documents, or signatures. It does not explicitly exclude alternatives, but the context and sibling list make the extraction use case clear. No exclusions are needed for this simple utility.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses a key behavioral trait by stating 'Costs no credits' and clearly lists the data returned (today/this month usage, plan). This exceeds minimal transparency, though it omits details like data freshness or authentication.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the primary action and result, and includes an important cost note. Every word earns its place with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema or annotations, the description is remarkably complete: it specifies exactly what data is returned (remaining credits, today's/monthly usage, plan) and the cost behavior. It provides all necessary context for an agent to invoke this tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline for this dimension is 4. The description adds meaning by explaining the return values, which is essential given there is no output schema. It does not need to explain parameters that do not exist.
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 clearly states the tool returns remaining verification credits, recent usage, and plan. The verb 'Return' and specific resource (API key's remaining verification credits) make the purpose unambiguous, though it doesn't explicitly differentiate from sibling tool get_usage.
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?
The description implies usage for checking credit status without cost, but it does not explicitly state when to use this tool versus others like get_usage or get_account. The 'Costs no credits' note is a contextual hint but not full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly states what cleaning operations are performed (dedupe, invalid syntax, disposable/role) and what is returned (cleaned list plus summary). It does not cover edge cases like case normalization or whether the input is modified, but it is reasonably transparent for a cleaning tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main purpose, then scope, then return detail. No wasted words.
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?
The description is complete for a simple cleaning tool: it explains the operation and return value. It does not explicitly differentiate from verification tools (e.g., checking deliverability), but the sibling list and context make this clear enough. The lack of an output schema is offset by the description's mention of a summary.
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%, so the description does not need to repeat parameter definitions. The description's 'optionally strips disposable and role accounts' aligns with the schema defaults, but adds no new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool cleans an email list, specifying concrete actions: dedupe, remove invalid syntax, and optionally strip disposable and role accounts. This distinguishes it from sibling tools like verify_email and extract_emails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'before an import or campaign.' It does not explicitly mention when not to use it or name alternative tools, but the context is sufficient for most scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It explicitly notes 'Costs no credits' and enumerates the return fields, providing useful transparency beyond the basic action. It does not mention rate limits or error handling, but for a simple getter with no parameters these are less critical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately names the action and resource. It efficiently lists the returned fields and adds a concise cost note. Zero waste.
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?
Since there is no output schema, the description compensates by listing the exact returned fields. It also informs about the credit cost. For a zero-parameter tool, this is sufficiently complete. Minor gaps like error behavior are not significant given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty (0 parameters), so the baseline is 4. The description adds context by specifying that the account is identified via the 'current API key', which is an implicit authentication input. No parameter details are needed since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Return the account profile for the current API key' and lists specific fields (email, name, company, timezone, credits, etc.). This specific verb+resource combination distinguishes it from sibling tools like get_credits or get_usage, which focus on narrower data subsets.
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?
The implied usage is evident from the resource description ('current API key'), but there is no explicit guidance on when to use this versus alternatives like get_credits or get_usage, nor any exclusions. The context is clear but the guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It discloses the return content (per-address results, summary, credits used) and the precondition (only for completed jobs). It does not mention error behavior or side-effects, but 'fetch' implies read-only, and the main traits are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: first states the core action and return contents, second gives the necessary precondition. No redundant words, and it is front-loaded with the verb and resource.
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?
For a single-parameter read tool with no output schema, the description is complete enough to invoke correctly. It specifies the resource, return values, and usage condition. It could add pagination or error details, but these are not essential for basic use.
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 coverage is 100% and the parameter description already explains job_id as returned by submit_bulk. The description adds no extra semantic detail about the parameter, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches full per-address results of a completed bulk verification job, listing specific data fields (verdict, recommendation, reason) and the summary/credits used. This distinguishes it from siblings like get_job_status (status) and list_jobs (job list).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the job must be 'completed' and instructs to 'check get_job_status first', providing a clear precondition and directing the agent to the relevant sibling tool. It does not contrast with all alternatives, but the key ambiguity is resolved.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It accurately states the operation is a list and specifies the output fields, but doesn't disclose authentication requirements, rate limits, or whether the list is complete/unpaginated. The verb 'List' implies read-only, but this is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first states the purpose and lists return fields, the second gives a direct usage directive. No wasted words or redundant elaboration.
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?
Given no output schema and no parameters, the description adequately explains what is returned and how to use it. It doesn't mention pagination, ordering, or authentication requirements, but for a presumably small list of credit packages, these are minor omissions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is trivially 100%. The description adds no parameter-specific semantics, but with no parameters to document, the baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with a specific resource 'credit packages', and enumerates the exact fields returned (id, name, credit amount, price in USD, price per 1k credits). This clearly distinguishes it from siblings like buy_credits (purchase) and get_credits (likely balance).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly directs the agent to use the returned package id with buy_credits, providing a clear next step and implicit alternative. It doesn't state when not to use or mention sibling tools like get_credits, but the context is sufficient for typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool returns jobs most recent first, includes status/progress/summary, and supports filtering/pagination. The 'List' verb implies a read-only operation with no side effects, which is adequate for a simple list tool. It doesn't mention rate limits or authentication, but these are not critical for a list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the verb and resource, and includes only essential information. No redundant details.
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?
The tool is simple, with 3 optional parameters and no output schema. The description covers purpose, ordering, filters, and gives use-case guidance. It mentions the output fields (status, progress, summary) partially compensating for the missing output schema. Overall, it's complete for this level of complexity.
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%, so the schema already fully documents all three parameters. The description adds a high-level statement about filtering and pagination, but doesn't add details beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a list operation for bulk verification jobs, specifying what it returns (status, progress, summary) and the ordering. It distinguishes from siblings like get_job_status by focusing on listing multiple jobs and providing job_ids.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Use this to find past jobs and their job_ids,' giving a clear use case. It also mentions optional status filtering and pagination, providing context for when to use these features. However, it does not explicitly exclude alternatives like get_job_status for specific job lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It notes the synchronous nature and return of per-address verdicts, but does not mention credit consumption, rate limits, or whether the operation is read-only. This is a mid-level disclosure: some useful context is provided, but significant behavioral aspects remain unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and includes both return behavior and size guidance. Every sentence contributes value, with no filler or redundancy.
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?
Given the absence of an output schema, the description explains that a per-address verdict is returned, which provides a basic understanding of the results. It also covers scale limits and suggests an alternative for large batches. However, it does not elaborate on the exact verdict structure or how the exclude_* parameters affect results, leaving some gaps. Still, for a tool of this complexity, it is reasonably complete.
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 coverage is 100%, so parameters are already well-documented. The description adds no additional parameter details beyond the schema; it only reiterates the 'list of email addresses' concept. Thus the baseline score of 3 applies, as the description does not go beyond schema-provided semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool verifies a list of email addresses synchronously, and explicitly distinguishes itself from the bulk async endpoint for large lists. The verb 'verify' and resource 'list of email addresses' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('best for up to a few hundred') and when to use an alternative ('For very large lists use the bulk async endpoint instead'). This directly addresses usage context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the deliverability verdict, reason, flags (disposable, role account, catch-all, etc.), recommendation, and credit usage—giving a solid picture of behavior. It does not mention error handling or rate limits, but for a verification tool, it transparently indicates output and cost.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the core purpose ('Verify one email address in real time'), followed by a concise list of valuable outputs. Every clause adds meaningful detail without redundancy or fluff.
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?
Given one parameter, no annotations, and no output schema, the description covers the purpose, the return values (verdict, flags, recommendation), and the cost (credit usage). It could add error handling or timeout behavior, but for a straightforward verification tool, it is largely complete.
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 coverage is 100% and the only parameter 'email' is described with an example ('e.g. lead@example.com'). The description adds no extra parameter semantics, but the parameter is self-explanatory, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Verify one email address in real time.' It clearly distinguishes itself from batch and list-cleaning tools by emphasizing the singular, real-time nature. It also enumerates key outputs (verdict, flags, recommendation, credit usage), making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'one email address' and 'real time' implies this is for immediate single-address checks, which implicitly contrasts with batch tools like verify_batch. However, it does not explicitly name alternatives or state when not to use this tool, so it provides clear context but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that this is a polling operation, lists the returned fields, and implies a read-only nature. It does not mention error behavior or rate limits, but for a simple status endpoint this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Exactly two sentences: the first defines the action and output, the second provides the workflow. No fluff, front-loaded verb, and every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description covers the returned fields (status, percent progress, processed count, valid/invalid/risky summary), when to call it, and the next step. It is fully sufficient for an agent to use correctly.
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?
The schema already fully describes job_id as 'The job_id returned by submit_bulk', with 100% coverage. The description merely restates 'by its job_id', adding no new parameter meaning, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch the current status and progress of a bulk verification job by its job_id', using a specific verb and resource. It distinguishes itself from the sibling get_job_results by focusing on status/progress rather than final results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs to 'Poll this after submit_bulk until status is completed, then call get_job_results', naming both a predecessor and a successor tool. This provides clear when-to-use guidance and an explicit alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral disclosure burden and does so excellently: it warns about the one-time visibility of the API key, instructs immediate capture, states it cannot be retrieved again, mentions free credits, and discloses domain rejection. These side effects go well beyond a basic creation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: purpose, requirements/free credits, and critical one-time key behavior. It is front-loaded with the core action and contains no fluff or redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with no output schema, the description covers purpose, prerequisites, response contents (account id/email and API key), and the crucial one-time-capture behavior. There is no ambiguity left for an agent to misuse the tool or lose the key.
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 coverage is 100% because both parameters have descriptions in the schema (e.g., 'not a disposable domain', 'minimum 8 characters'). The description adds minimal parameter-specific meaning beyond restating these constraints; its extra value about the key pertains to the response, not the input parameters. Baseline 3 is appropriate when schema already documents parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a brand-new Verifly account and frames it as the self-onboarding mechanism, using the specific verb 'create' and naming the resource. It is clearly distinguished from sibling tools like get_account or buy_credits, which operate on existing accounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit context for when to use the tool ('this is how an agent self-onboards with no human in the loop') and notes key requirements (email/password, disposable domains rejected). However, it does not explicitly state when not to use it or compare to alternatives, though no sibling tool serves the same account-creation purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so thoroughly. It discloses the async behavior, immediate return with job_id/status/URLs, inline completion for small lists, pending status for large lists, polling requirements, and optional webhook notification.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences convey purpose, behavioral details, polling flow, and webhook option with no filler. The first sentence front-loads the main action, and each subsequent sentence adds necessary context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return fields (job_id, status, URLs) and the job lifecycle, covering inline completion, polling, and webhook notification. It is complete for the tool's complexity and usage path.
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 coverage is 100% and the description adds no new parameter semantics. It merely reinforces that webhook_url is optional and used for notification, while emails are the list to verify. This aligns with the baseline score for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's function: 'Submit a list of email addresses as an asynchronous bulk verification job' and frames it as 'the right tool for large lists', distinguishing it from other verification tools like single-email checks or synchronous batch options.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly explains when to use this tool (large lists) and provides a workflow: returns immediately, poll get_job_status until completed, then call get_job_results. It doesn't explicitly name alternatives like verify_batch or verify_email, but the context strongly implies its use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: it does NOT complete payment, returns a payment link/address, specifies the human requirement for stripe, and explains that credits are added automatically once crypto payment confirms. This goes beyond basic purpose to detail the exact transaction flow and autonomy levels.
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?
The description is longer than two sentences, but it is well-structured with bullet points and every sentence carries functional weight. It avoids fluff while covering method-specific behavior, return values, and prerequisites.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (two payment methods with different requirements), the description is remarkably complete. It covers prerequisites, what is returned for each method, who can complete the payment, and follow-up behavior (automatic credit addition), leaving no critical gaps even without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all parameters with descriptions and enum values, so the bar is higher. The description adds valuable interaction semantics, such as how method 'crypto' with a currency returns a raw wallet address and amount. This enriches the schema without redundancy, justifying a score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Start a purchase of a credit package and return a way to pay', identifying the specific action and resource. It distinguishes itself from sibling tools like get_credits (checking balance) and get_packages (listing packages) by explaining the purchase initiation purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'Prefer crypto for fully autonomous top-ups' and instructs to 'Get a package id from get_packages first'. It also gives an exclusion by warning that an agent cannot finish a card payment on its own, thus steering agents toward the crypto method when needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![verifly-mcp-server MCP server](https://glama.ai/mcp/servers/james-sib/verifly-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/james-sib/verifly-mcp-server)

Score Badge

Copy to your README.md:

[![verifly-mcp-server MCP server](https://glama.ai/mcp/servers/james-sib/verifly-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/james-sib/verifly-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/james-sib/verifly-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server