Skip to main content
Glama

Reoon Email Verifier MCP by usefulapi

Read Reoon bulk progress and results

reoon_bulk_results
Read-onlyIdempotent

Read a previously created bulk task, its progress, and a bounded page of completed email results. Does not start new verification. Wait between polls. Very large upstream exports must be downloaded in the Reoon dashboard.

Input Schema

NameRequiredDescriptionDefault
limitNo
offsetNo
task_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already cover read-only, idempotent, and non-destructive traits, so the description focuses on what they cannot: results arrive in bounded pages, polling should be throttled, and very large exports are unavailable here and must be pulled from the Reoon dashboard. That export limitation is genuinely non-obvious and valuable.

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?

Four short sentences, purpose front-loaded, and each one adds distinct information (scope, exclusions, polling cadence, export fallback). No repetition of the title or annotations.

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?

There is no output schema, and the description says at a high level what comes back (task, progress, page of results) without enumerating result fields, which would help consumers. Annotations and the export caveat cover the rest, so it is close to complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% — limit, offset, and task_id have no descriptions at all. The phrase 'a bounded page' hints at pagination but never explains limit caps (max 100), offset bounds (max 50000, default 0), or that task_id must be a numeric string, so the gap is left unaddressed.

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?

Names a specific verb (read) and three concrete resources: the bulk task, its progress, and a page of completed email results. It also explicitly disclaims starting new verification, which separates it from the sibling reoon_create_bulk_verification.

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?

States the negative case ('Does not start new verification') and gives polling guidance ('Wait between polls'), plus a fallback route for oversized exports (Reoon dashboard). It stops short of naming which sibling to use for other needs, but the context is clear.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.