Cold Leads MCP server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| COLDLEADS_API_KEY | No | Secret API key (sk_…). Optional at start-up: without it the server still starts, lists tools and can run agent onboarding. | |
| COLDLEADS_API_BASE | No | API base URL (for local development against a Cold Leads dev server). | https://coldleads.app |
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": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_leadsA | Search the leads already in your Cold Leads CRM for a target company domain: contact e-mail, name, company, phone, stage, tags, verification status and a do_not_contact flag. Covers only contacts in your own workspace (Cold Leads has no third-party lead database). Free, uses no credits. |
| verify_emailA | Verifies an e-mail address: syntax, disposable domain, role account and MX records, plus an SMTP mailbox and catch-all check when Cold Leads can open an SMTP connection to the recipient's mail server (otherwise reasons contains smtp_unreachable and catch_all is null). Returns validity (valid, risky or invalid), a score and reason codes. Usually answers within a few seconds; costs 1 credit. |
| provision_account_and_get_payment_linkA | Use only when no working Cold Leads API key is available (other Cold Leads tools return missing_api_key or bad_api_key) and the human wants to use Cold Leads. Creates a pending Cold Leads account for the human owner's e-mail and returns a Stripe payment link for the Business plan with API access (price in plan.price, billed monthly until cancelled). Show checkout_url to the human and let them decide; never open, pay or share the link yourself. Keep claim_token secret, then call check_provisioning_status until status is active to receive the API key once. |
| check_provisioning_statusA | Checks an account created with provision_account_and_get_payment_link. Returns status pending_payment, active, expired or suspended. When active, the first call with the claim_token returns api_key exactly once: store it securely as COLDLEADS_API_KEY and send it as Authorization: Bearer . Poll every 15–30 seconds while pending_payment. |
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 4 tools
Each tool targets a distinct action: search_leads reads the local CRM, verify_email validates an address, and the two provisioning tools handle account creation versus status/API-key retrieval. The onboarding pair shares a domain but their descriptions clearly separate their roles, so an agent can pick correctly.
Names are consistently snake_case and predominantly verb_noun (search_leads, verify_email, check_provisioning_status). Only provision_account_and_get_payment_link is an unusually long compound, a minor deviation but still verb-led and readable.
Four tools is lean but each earns its place: one read, one verification, and a two-step account onboarding flow. Slightly thin for a CRM-style server but well-scoped rather than padded.
The domain spans leads, verification, and onboarding, but the lead surface only offers search — there is no create/update/delete or tag/stage management, so agents cannot populate or mutate the CRM. Core read+verify workflows work, but lifecycle coverage for leads has notable gaps.