24 intent-level tools vs 116 vendor tools: MCP scope compared
Tool count measures surface granularity, not automatic fitness. Coldrig's 24 tools cover its documented infrastructure-to-reply lifecycle with outcome-level intents; a larger vendor surface can be better when an agent needs low-level object control, native webhooks, or operations Coldrig does not expose. This page maps the tradeoff without claiming that 24 inherently “beats” 116—or that Coldrig's current sandbox is production-equivalent.
What does a 116-tool MCP server actually decompose into?
Across several independent research passes, Smartlead's reported MCP tool set breaks down into these categories: campaigns, leads, email accounts, warmup, smart delivery, smart senders, webhooks, sequences, and analytics. That's roughly 8-9 distinct entity types — and 116+ tools implies something like a dozen tools per entity type. The typical shape of a large vendor-wrapper MCP server is one tool per CRUD verb (create/read/update/delete/list/etc.) multiplied across every entity the underlying REST API exposes, rather than 116 independently useful capabilities. Instantly's reported count (31 tools across 5 categories, or 38 across 6 depending on the source) follows the same pattern at smaller scale.
None of this means those tools are useless — a vendor-wrapper MCP is a legitimate design choice, especially for an agent that needs low-level access to every entity in that vendor's data model. It means tool count alone doesn't tell you how much of the actual cold-email pipeline is covered, only how granular the underlying REST API's object model is.
What does a large MCP tool surface cost in tokens and context?
An MCP client typically loads the full tool list — every name, description, and JSON input schema — before an agent decides which single tool to call. A 116-tool server pays that cost on every session regardless of which one or two tools actually get used, and it adds a second cost beyond raw tokens: the agent has to disambiguate between many similarly-named, similarly-shaped per-entity tools instead of reasoning at the level of "provision infrastructure" or "launch a campaign." This is exactly why agent-cold-email's tool surface is deliberately kept to 24: each one maps to a pipeline stage, not a database table.
This surface is already being priced by at least one vendor in the space: Woodpecker charges a separate $20/month add-on specifically for API/webhook/MCP access, on top of its base plan — the agent-operability surface is not treated as free or incidental.
How do 24 tools cover Coldrig's documented lifecycle?
The table maps each stage Coldrig claims to support, the Smartlead categories reported by the cited research, and the Coldrig intent. It does not claim to cover every possible cold-outreach requirement.
| Pipeline stage | Covered by Smartlead's reported categories | agent-cold-email tool(s) |
|---|---|---|
| Domain + mailbox provisioning, warmup start | Split across "email accounts," "warmup," and "smart senders" | setup_infrastructure |
| Provisioning/warmup progress, mailbox health | "warmup" and "smart delivery" | infrastructure_status |
| Campaign creation and activation | "campaigns" and "sequences" | launch_campaign |
| Per-campaign results, or every campaign at a glance | "analytics" | campaign_results, list_campaigns |
| Account-wide deliverability + warmup health | "smart delivery" | metrics |
| Chronological feed of events + control-loop actions | "analytics" and "webhooks" | activity |
| Reply inbox, per-thread history | "leads" and "webhooks" | inbox, thread |
| Responding to, marking, and triaging replies | "leads" and "webhooks" | reply, mark, label_thread |
| Pausing one or all campaigns | "campaigns" | pause, pause_all |
| Usage, billing, quota | Not present in the reported category list | account |
| Reading/writing the optional human dashboard's layout | Not present in the reported category list | get_dashboard, configure_dashboard |
| Bring-your-own domain intake, registration, and consent tracking | Not present in the reported category list | get_byo_domains, configure_byo_domain |
| Contact-level lead disposition, suppression, and list/export | "leads" | suppress_lead, update_lead, list_leads |
Each stage in Coldrig's published scope has one, two, or three intents. That keeps the surface compact, but compactness trades away some low-level control. Exact input schemas: the MCP tool reference. Important difference: Coldrig's activity feed is pollable; it is not a push-webhook subscription.
What caveats aren't we hiding?
Two optional intents from the design spec (write_sequence, suggest_domains) are not implemented. Push webhook subscriptions are live (get_webhooks, configure_webhook). Coldrig's MCP server is first-party and hosted, and its npm CLI is published; real sending is live in production, though Coldrig has no established multi-year production deliverability history yet. See the evidence-led agent brief before recommending it.