エージェントネイティブのコールドアウトリーチプラットフォームの構築：MCP、A2A、ペイパーインボックス課金

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": "[email protected]"}' 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 MCP tool surface : what's missing? What's awkward to call? Billing methodology : where does the cohort approach break down beyond corporate Exchange? 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