Skip to main content
Glama

VerifyPulse: email deliverability checks

by io.github.MohDev212
OverviewDiscussionsAdmin

watch_sending_domains

Hosted monitoring. Register domains for a daily server-side check of SPF, DKIM, DMARC, MX, MTA-STS, TLS-RPT and BIMI; when something changes, the changes are POSTed as JSON to your https webhook_url. Free for up to 3 domains (renew every 30 days). For 4 to 20 domains in one watch, call without a pass: the result is an x402 payment request for the pass that covers them ($2 for up to 50 domains), payable in params._meta["x402/payment"] or with api_key credits; the paid call returns the pass and starts the watch. Returns a token to list or delete the watch.

Input Schema

NameRequiredDescriptionDefault
api_keyNoOptional VerifyPulse API key: pays for a pass with credits when more than 3 domains are watched
domainsYesDomains to watch: up to 3 free, more with a pass
guard_passNoOptional Sender Guard pass (vpg_...) for more than 3 domains
webhook_urlYesPublic https URL that receives the change alerts, for example a Slack incoming webhook

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / api_key
      Added value: +{
+  "description": "Optional VerifyPulse API key: pays for a pass with credits when more than 3 domains are watched",
+  "type": "string"
+}
  2. Added

TDQS

A4.1/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 the side effect (registers a persistent watch that POSTs JSON to the webhook), the pricing model and free-tier expiry (3 domains, renew every 30 days), the two payment paths (x402 payment in params._meta or api_key credits), and that a token is returned.

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-loads the core action before the payment mechanics, and every clause carries information. It is dense, running several concepts into one long sentence, but nothing is genuinely wasted for a tool this involved.

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?

Covers registration, alert delivery, pricing, the two payment routes, and that a token is returned to list/delete the watch. The main remaining gap is the shape of the webhook JSON payload, which matters for someone wiring up the endpoint, but the operational essentials are present.

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 all four parameters are already documented in the schema; that establishes a baseline of 3. The description does add the pass economics ($2 for up to 50 domains) and the x402/payment payment field, but those are largely restatements of what api_key and guard_pass already say.

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?

Opens with 'Hosted monitoring' and states a concrete verb+resource: registering domains for a daily server-side check of a named record set (SPF, DKIM, DMARC, MX, MTA-STS, TLS-RPT, BIMI). It is clear what the tool does, but it never distinguishes itself from the sibling monitor_sending_domains or audit_sending_domains, which an agent could easily confuse it with.

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?

Gives a clear usage condition (register when you want daily server-side checks with webhook change alerts) and an explicit branching rule: free for up to 3 domains, call without a pass for 4-20 domains to receive an x402 payment request. No guidance is given on when to prefer this over the sibling monitoring/audit tools, so the alternatives axis is missing.

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

All VerifyPulse: email deliverability checks 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