mxprobe
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MXPROBE_API_KEY | No | Optional hosted-tier API key from the signup tool or POST https://api.mxprobe.dev/v1/signup. Without it the verify tools run the free local DNS tier. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| verify_emailA | Check whether an email address can receive mail before sending to it. Each result is { email, action, verdict, reason, checks }. action is send | hold | kill: send means go ahead, hold means send only with a fallback in hand (catch-all, forwarder, greylisted or refused probe), kill means never send (no mail server, or the mailbox does not exist). checks.smtp is skipped on the free DNS tier; the hosted tier probes the mailbox. Uses the hosted SMTP probe (1 credit) when an API key is configured and hosted is not false; otherwise the free local DNS tier. |
| verify_batchA | Check up to 500 addresses in one call. Each result is { email, action, verdict, reason, checks }. action is send | hold | kill: send means go ahead, hold means send only with a fallback in hand (catch-all, forwarder, greylisted or refused probe), kill means never send (no mail server, or the mailbox does not exist). checks.smtp is skipped on the free DNS tier; the hosted tier probes the mailbox. DNS kills cost nothing; with a key the survivors go to the hosted probe at 1 credit each. If the key runs out of credits, every result still comes back: out_of_credits says how many were not probed and carries checkout_url, a payment link for your operator. |
| signupA | Sign up with an email address. Returns an API key and saves it locally for the other tools. The key is also mailed to the address. One key per address; the 100 free checks come once per IP address and company domain, and a repeat key starts at 0 with a checkout_url for your operator. |
| balanceA | How many hosted checks are left on the configured API key. |
| buy_creditsA | Get a Stripe Checkout link for more hosted checks: 9 USD per 10,000, one payment, credits never expire. Open the link to pay; credits land on the key when Stripe confirms. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 5 tools
The account tools (signup, balance, buy_credits) are clearly separable from the verification tools, and verify_batch is distinguished by its 500-address scope. The only soft overlap is verify_email versus a single-address verify_batch call, since both return identical schemas and differ mainly in the hosted-vs-free tier and batching.
Two tools follow a clean verb_noun form (verify_email, verify_batch) and buy_credits fits, but signup is a bare verb and balance is a bare noun, so the pattern breaks in two of five cases. Mixed conventions, though each name remains readable in context.
Five tools cleanly cover the two halves of the service: verification (single and batch) and account/credit lifecycle (signup, balance, buy_credits). Nothing feels padded or missing at the count level; each tool maps to a distinct user intent.
The core loop — get a key, check credits, buy more, verify addresses — is fully covered, including an out_of_credits path with checkout_url. Minor gaps: no way to inspect or rotate an existing key, no credit/usage history, and no status retrieval for long batch work beyond the synchronous response.