Skip to main content
Glama

PricklyMails

by com.pricklymails
OverviewDiscussionsAdmin

submit_batch

Submit a list of emails (up to 4096 per call) for bulk verification. Billed per unique valid address, and governed by the plan's batch_max (see get_pricing); omitting checks runs every check the plan allows, SMTP included. Pass api_key to bill and scope this batch against that pm_live_/pm_test_ key's own account instead of the caller's session account; omit it to use the caller's own session account. Requires the email:verify:bulk scope on whichever account ends up authenticating the call. Returns a batch_uuid; poll it with get_batch or get_batch_results. Set final false to keep intake open, then feed further chunks with append_batch_emails.

Input Schema

NameRequiredDescriptionDefault
finalNoWhether this is the batch's only or final chunk (defaults to true). Set false to keep intake open, then feed further chunks with append_batch_emails.
checksNoOptional check wire strings (syntax, mx, smtp, disposable, role, free, catchall); defaults to every check the caller's plan allows, smtp included. A check outside the plan is refused.
emailsYesEmail addresses to verify (up to 4096). Billed per unique valid address and governed by the caller's plan batch_max (see get_pricing). A batch closed by this call (final: true, the default) needs at least batch_min (20) distinct valid addresses; verify fewer with verify_email.
api_keyNoOptional pm_live_ (or pm_test_) API key. When present, this batch is billed and scoped against that key's own account instead of the caller's session account, and the key must carry the email:verify:bulk scope. Omit to use the caller's own session account.
custom_idsNoOptional per-email client references, index-aligned 1:1 with emails. Echoed back verbatim in get_batch_results so you can map each result to your input row. Do not put the email address or any PII here, use your own row identifier (e.g. a CRM id).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / checks / description
      Previous value: -"Optional check wire strings (syntax, mx, smtp, disposable, role, free, catchall); defaults to the plan's allowed checks minus smtp. SMTP is opt-in and still subject to plan gating."New value: +"Optional check wire strings (syntax, mx, smtp, disposable, role, free, catchall); defaults to every check the caller's plan allows, smtp included. A check outside the plan is refused."
    • changedInput schema / properties / emails / description
      Previous value: -"Email addresses to verify (up to 4096). Billed per unique valid address and governed by the caller's plan batch_max (see get_pricing)."New value: +"Email addresses to verify (up to 4096). Billed per unique valid address and governed by the caller's plan batch_max (see get_pricing). A batch closed by this call (final: true, the default) needs at least batch_min (20) distinct valid addresses; verify fewer with verify_email."
  2. First observed

TDQS

A4.8/5.0
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: it discloses per-unique-valid-address billing, plan batch_max limits, the required email:verify:bulk scope, and that passing api_key rebills/scopes the batch to that key's account. The default of running every plan-allowed check, SMTP included, is also surfaced.

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?

Front-loaded with the core action and capacity, with no filler sentences. The middle sentence is dense, packing billing, plan limits, checks defaults and account scoping into one long clause chain, which slightly hurts scannability.

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 5-parameter write/billing tool with no annotations and no output schema, the description still covers lifecycle (batch_uuid plus polling), cost model, permission requirement, chunking, and the minimum-address constraint. Nothing essential for a correct first call is missing.

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?

Schema coverage is 100%, so baseline is 3, but the description adds real meaning beyond the schema: it frames api_key as an account/billing switch rather than just a credential, and summarizes the final/append_batch_emails interaction and the checks default. It stops short of adding format or validation detail the schema doesn't already give.

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?

States a specific verb and resource ('Submit a list of emails ... for bulk verification') with an explicit capacity bound (4096 per call). It is clearly separable from the single-address sibling verify_email, which it names for small inputs.

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?

Gives explicit routing: poll with get_batch or get_batch_results, set final false and continue with append_batch_emails, use verify_email when below batch_min, and consult get_pricing for batch_max. When-to-use and when-to-use-something-else are both covered.

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

All PricklyMails toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources