WarmInboxes Free MCP: Fleet Planner

Inboxes and domains for a send volume (estimate)

plan_infrastructure

Read-onlyIdempotent

Estimates how many inboxes and domains a daily cold email volume needs and the monthly cost at WarmInboxes' published prices. Inputs: emailsPerDay; optionally the provider (esp), prewarmed or fresh, billing cycle, emails per inbox per day and inboxes per domain. With currentInboxes (healthy inboxes already sending) it sizes only the shortfall between their capacity and the target, and says when nothing needs adding; with reservePercent it adds that much spare capacity on top, and only when asked: no reserve is recommended by default. With dealValue (and optionally closeRate and positiveRate) it adds a revenue and ROI projection from those inputs. Assumes the provider's default daily pace per inbox unless emailsPerMailbox is given, and 22 sending days a month. The result is a planning estimate: it orders nothing, does not guarantee placement or replies, and its revenue figures follow only from the rates supplied.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "emailsPerDay": "<emailsPerDay>"
    },
    "name": "plan_infrastructure"
  }
}

Input Schema

Name	Required	Description
`esp`	No	Sending platform. Defaults to google.
`billing`	No	Prewarmed commitment length. Longer cycles are cheaper. Defaults to monthly. Google and Microsoft are billed per inbox; Azure is billed per tenant, flat, whatever is on the tenant.
`rotation`	No	Rest half the fleet at any moment, which doubles the inboxes bought. Defaults to false.
`closeRate`	No	Percent of positive replies that close. Defaults to 10.
`dealValue`	No	Average deal size. Supply it to get replies, deals, revenue and ROI.
`prewarmed`	No	true for prewarmed inboxes (ready to send on delivery), false for fresh (14-21 day warmup, about a third the price). Defaults to true.
`emailsPerDay`	Yes	Target cold emails per day, e.g. 500.
`positiveRate`	No	Percent of sends that reply positively. Defaults to 1.
`currentInboxes`	No	Healthy inboxes already sending on this platform. When given, only the shortfall between their capacity and emailsPerDay is sized.
`reservePercent`	No	Spare capacity to add on top of the target, 0 to 100, only when the person asks for a reserve. Defaults to 0.
`emailsPerMailbox`	No	Daily sends per inbox. Defaults to the platform's safe pace: 15 Google, 8 Microsoft, 2 Azure.
`inboxesPerTenant`	No	Fresh Azure only: how densely a tenant is packed. Also sets the pace, since a lighter tenant sends more per inbox (25/6, 50/4, 100/2). Defaults to 100.
`mailboxesPerDomain`	No	Fresh Google and Microsoft only. Defaults to 3.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare read-only, idempotent, non-destructive, closed-world, but the description goes well beyond: it discloses a 22-sending-day-per-month assumption, default pace per provider, that no reserve is recommended unless requested, that it orders nothing, and that revenue figures follow only from supplied rates. Those are exactly the behavioral caveats an agent cannot get from structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense paragraph is front-loaded with purpose and cost, then inputs, then conditional behaviors, then assumptions and disclaimers — a sensible order for a 13-parameter tool. It is long, and the reserve clause is slightly repetitive, but every sentence carries information and nothing reads as filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 13-parameter estimator with no output schema, the description covers purpose, optional-input effects, default assumptions, and the non-guarantee caveats. It does not enumerate every parameter (rotation, inboxesPerTenant) in prose, but the 100% schema coverage handles those, so the remaining gap is minor.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so per-parameter meaning is already documented and the baseline is 3. The description earns above baseline by explaining cross-parameter interactions the schema cannot: currentInboxes caps sizing to the shortfall, reservePercent applies only on request and defaults to none, and dealValue optionally unlocks revenue projection when paired with closeRate and positiveRate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and deliverable: estimates inboxes, domains, and monthly cost for a daily cold email volume at published prices. The resource and output are unambiguous, though it never names how it differs from siblings like quote_inboxes or plan_rotation, which operate in adjacent territory.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied through conditional clauses (with currentInboxes it sizes only the shortfall; with dealValue it adds ROI; with reservePercent it adds reserve only when asked), which is useful conditional guidance. But there is no explicit 'use this instead of X' routing to quote_inboxes or plan_rotation, leaving the agent to infer the boundary between planning and quoting.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All WarmInboxes Free MCP: Fleet Planner tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?