LDM launches on Product Hunt this weekend. Sharing what's under the hood for builders.

The two technical bets

Most cold email tools (Instantly, Smartlead, Lemlist, Apollo) are built UI-first. Sales teams click through onboarding, build sequences in dashboards, monitor in dashboards. The API is an afterthought. Agent integration is a webhook at best.

LDM is built API-first, then UI. This let me make two unusual technical bets.

1. Native MCP server, not a plugin

ldm-crm-mcp ships as an npm package. Drop it into Claude Desktop's claude_desktop_config.json and the agent gets typed access to:
contacts.create(data)
contacts.search(query)
pipelines.list()
pipelines.move_card(card_id, stage_id)
campaigns.create(spec)
campaigns.send(id)
dialogs.list(filter)
dialogs.reply(dialog_id, message)
billing.summary(period)

The agent doesn't scrape a UI or call REST manually. It calls tools with typed args, gets typed results. Errors come back as proper tool-call failures, not HTTP status codes the agent has to interpret.

This sounds basic but no other cold outreach platform ships an MCP server today. Smartlead, Lemlist, Instantly — all UI-first, API as afterthought, no MCP.

2. A2A agent card at /.well-known

curl https://live-direct-marketing.online/.well-known/agent-card.json

Returns the A2A protocol manifest — what LDM can do, how to authenticate, what tasks it accepts. Other agents can discover and delegate to LDM without any human pre-configuration.

Why this matters: as agentic systems compose, agents need to discover services they don't know about. A2A is Google's proposed protocol for that. We shipped it as a default, not an add-on.

The pay-per-inbox methodology

The other unusual bet — billing.

Every other cold email tool charges per send. SMTP returns 250 OK, vendor charges, recipient gets it in spam folder. Up to 40% of B2B cold outreach goes to spam (Validity / GlockApps benchmarks). Customers pay for the invisible half.

LDM bills only on verified inbox delivery. Methodology:
For each outbound message M sent at time T from sender S to provider P:

Run concurrent seed test: send equivalent message to our seed mailbox
at provider P from sender S within ±5min window of T
Classify seed result: Inbox, Promotions, Spam, Not-received
Bill on M only if seed verdict ∈ {Inbox, Promotions}
If seed verdict = Spam: don't bill, log as cohort_negative
Maintain rolling cohort accuracy per (provider, sender) pair, exposed in API

Critical honesty: this is probabilistic, not per-message guarantee. We can't see inside the recipient's mailbox. What we can do is bet our revenue that the seed cohort matches the real recipient pool within ±X% — and publish backtest data to prove it.

This is why we don't promise "100% inbox guarantee". Anyone who promises that without controlling the recipient mailbox is lying. We promise: "if our seed cohort says spam, you don't pay."

Edge cases we don't pretend to solve

Corporate Exchange / M365 tenants with custom rules. Our seed cohort can't replicate a recipient's corporate spam policy. We mark these recipients with cohort_confidence: low in the API response. We're explicit about it.

Apple Mail Privacy Protection prefetches images. Open-pixel data is unreliable. Opens are a UX signal in dashboard, never a billing trigger.

Engagement-based gaming. We don't bill on engagement (opens, clicks, replies), so there's nothing to game. Billing is on cohort delivery — which depends on sender domain reputation, which can't be gamed.

The architecture

For builders curious about the stack:

• Backend: NestJS + TypeScript + Prisma with multi-tenant DB-per-tenant pattern on PostgreSQL
• Workers: BullMQ + Redis for queue management, separate worker pools for send / seed-test / cohort-classification / billing
• Monorepo: Turborepo with api, web, mcp-server, agent-card, shared core package
• Hosting: EU (Netherlands), GDPR-aligned
• MCP transport: stdio (for Claude Desktop / Cursor) and HTTP-SSE (for remote agents)
• AI: hybrid OpenAI + Anthropic for content generation, classification, ICP discovery

Try it

Sandbox key in one curl, no signup form:

curl -X POST https://developers.live-direct-marketing.online/v1/signup \
  -H "Content-Type: application/json" \
  -d '{"email": "you@example.com"}'

Then drop into Claude Desktop config:

{
  "mcpServers": {
    "ldm": {
      "command": "npx",
      "args": ["-y", "ldm-crm-mcp"],
      "env": { "LDM_API_KEY": "ldm_pk_..." }
    }
  }
}

Restart Claude. Ask: "show me my LDM pipelines". The agent calls the tool, you see real (empty) data.

What I want feedback on

1. MCP tool surface: what's missing? What's awkward to call?
2. Billing methodology: where does the cohort approach break down beyond corporate Exchange?
3. A2A agent card schema: is the manifest complete enough for cross-agent delegation?

Comments here, on Product Hunt, or DM on X.

Product Hunt launch: https://www.producthunt.com/products/live-direct-marketing?utm_source=devto&utm_medium=article

Docs: https://developers.live-direct-marketing.online

MCP server: npm package ldm-crm-mcp
Перед публикацией — три вещи проверь

ldm-crm-mcp реально опубликован на npm? В памяти у меня ldm-inbox-check-mcp (из awesome-mcp-servers). Если crm-версии нет — либо публикуй пакет до dev.to-публикации, либо поменяй в статье на реальное название
Tool surface в первой code-секции (contacts.create, pipelines.list и т.д.) — это то что реально экспортирует твой MCP сервер? Если нет — поправь под актуальные exports. dev.to-аудитория проверит и спалит несовпадение
/.well-known/agent-card.json — он реально отдаётся? Если нет — либо подними, либо убери эту секцию из статьи

Если хоть один пункт нет — лучше отложи статью на день после PH, доделаешь и опубликуешь когда всё работает. На dev.to легче перенести дату, чем чинить репутацию после "это не работает" коммента.You said: давай в формате md без таблицдавай в формате md без таблиц12:29 PMClaude responded: curl https://live-direct-marketing.markdown---
title: "Building an Agent-Native Cold Outreach Platform: MCP, A2A, and Pay-Per-Inbox Billing"
published: true
description: How we built the first cold email platform with native MCP server and A2A agent card, plus the methodology behind pay-per-inbox billing.
tags: mcp, ai, agents, saas
canonical_url: https://live-direct-marketing.online

cover_image:

LDM launches on Product Hunt this weekend. Sharing what's under the hood for builders.

The two technical bets

Most cold email tools — Instantly, Smartlead, Lemlist, Apollo — are built UI-first. Sales teams click through onboarding, build sequences in dashboards, monitor in dashboards. The API is an afterthought. Agent integration is a webhook at best.

LDM is built API-first, then UI. This let me make two unusual technical bets.

1. Native MCP server, not a plugin

ldm-crm-mcp ships as an npm package. Drop it into Claude Desktop's claude_desktop_config.json and the agent gets typed access to operations like creating contacts, listing pipelines, moving cards between stages, building campaigns, sending them, reading dialogs, replying in threads, and pulling billing summaries.

The agent doesn't scrape a UI or call REST manually. It calls tools with typed args, gets typed results. Errors come back as proper tool-call failures, not HTTP status codes the agent has to interpret.

This sounds basic but no other cold outreach platform ships an MCP server today. Smartlead, Lemlist, Instantly — all UI-first, API as afterthought, no MCP.

2. A2A agent card at /.well-known

curl https://live-direct-marketing.online/.well-known/agent-card.json

Returns the A2A protocol manifest — what LDM can do, how to authenticate, what tasks it accepts. Other agents can discover and delegate to LDM without any human pre-configuration.

Why this matters: as agentic systems compose, agents need to discover services they don't know about. A2A is Google's proposed protocol for that. We shipped it as a default, not an add-on.

The pay-per-inbox methodology

The other unusual bet — billing.

Every other cold email tool charges per send. SMTP returns 250 OK, vendor charges, recipient gets it in spam folder. Up to 40% of B2B cold outreach goes to spam — that's the Validity and GlockApps benchmark range. Customers pay for the invisible half.

LDM bills only on verified inbox delivery. The methodology in plain English:

For each outbound message at time T from sender S to provider P, we run a concurrent seed test — send an equivalent message to our seed mailbox at provider P from sender S within a five-minute window of T. The seed result gets classified as Inbox, Promotions, Spam, or Not-received. We bill on the first two outcomes only. If the seed verdict is Spam, we don't charge and we log it as cohort_negative. We maintain rolling cohort accuracy per provider-sender pair and expose it in the API.

Critical honesty: this is probabilistic, not a per-message guarantee. We can't see inside the recipient's mailbox. What we can do is bet our revenue that the seed cohort matches the real recipient pool within a known error margin — and publish backtest data to prove it.

This is why we don't promise "100% inbox guarantee". Anyone who promises that without controlling the recipient mailbox is lying. We promise: if our seed cohort says spam, you don't pay.

Edge cases we don't pretend to solve

Corporate Exchange and M365 tenants with custom rules. Our seed cohort can't replicate a recipient's corporate spam policy. We mark these recipients with cohort_confidence: low in the API response. We're explicit about it instead of pretending it works.

Apple Mail Privacy Protection prefetches images. Open-pixel data is unreliable. Opens are a UX signal in the dashboard, never a billing trigger.

Engagement-based gaming. We don't bill on engagement — opens, clicks, replies — so there's nothing to game. Billing is on cohort delivery, which depends on sender domain reputation, which can't be gamed.

The architecture

For builders curious about the stack: NestJS with TypeScript and Prisma on the backend, multi-tenant DB-per-tenant pattern on PostgreSQL, BullMQ on Redis for queue management with separate worker pools for send / seed-test / cohort-classification / billing. Monorepo on Turborepo with separate packages for api, web, mcp-server, agent-card, and shared core. EU-hosted in the Netherlands, GDPR-aligned. MCP transport over stdio for Claude Desktop and Cursor, plus HTTP-SSE for remote agents. AI is hybrid OpenAI plus Anthropic for content generation, classification, and ICP discovery.

Try it

Sandbox key in one curl, no signup form:

curl -X POST https://developers.live-direct-marketing.online/v1/signup \
  -H "Content-Type: application/json" \
  -d '{"email": "you@example.com"}'

Then drop into Claude Desktop config:

{
  "mcpServers": {
    "ldm": {
      "command": "npx",
      "args": ["-y", "ldm-crm-mcp"],
      "env": { "LDM_API_KEY": "ldm_pk_..." }
    }
  }
}

Restart Claude. Ask "show me my LDM pipelines". The agent calls the tool, you see real (empty) data.

What I want feedback on

The MCP tool surface — what's missing, what's awkward to call. The billing methodology — where the cohort approach breaks down beyond corporate Exchange. The A2A agent card schema — whether the manifest is complete enough for cross-agent delegation.

Comments here, on Product Hunt, or DM on X.

Product Hunt launch: https://www.producthunt.com/products/live-direct-marketing?utm_source=devto&utm_medium=article

Docs: https://developers.live-direct-marketing.online

MCP server: npm package ldm-crm-mcp