MCP vs REST: which to use (and why most teams need both)

"Should I wire Inbox Check into my stack through the MCP server or the REST API?" The question comes up once a week. The answer is boring: usually both, but for different jobs. This article draws the dividing line.

What MCP is good at

MCP (Model Context Protocol) was designed for a specific shape of workload: an interactive agent with a human in the loop. The LLM decides which tool to call, passes arguments, reads results and reasons over them. Humans give it vague instructions like "figure out why my last campaign tanked in Outlook" and the agent picks the right sequence on its own.

Where MCP shines:

• Exploratory debugging. A deliverability engineer is triaging a live incident. They paste the template, ask the agent to run a test and diagnose. The agent chains start_test → get_test → list_providers based on what it sees. No orchestration code.
• Multi-turn refinement. "Now try it with the footer image removed." "OK, and what if I change the subject to sentence case?" The agent keeps context and re-runs.
• One-shot fixes. "What SPF record do I need" needs exactly zero lines of bespoke code when an MCP server exposes the data.
• Developers who hate YAML. MCP clients read a JSON config once and then you are in natural language forever.

Where MCP is the wrong tool

• Unattended, scheduled workloads. There is no "cron triggers Claude Desktop".
• Multi-tenant SaaS. MCP is one-developer-one-agent by design. You cannot put it between your customers and your API.
• Hard-SLA workflows. Token budgets, reasoning steps and tool retries are all non-deterministic.

What REST is good at

The REST API is the boring, reliable, completely deterministic option. It exposes the exact same capabilities as the MCP server — POST /api/tests, GET /api/tests/:id, etc — but over HTTP, with idempotency keys, rate limit headers, and without an LLM in the loop.

Where REST shines:

• CI/CD gates. On every deploy that ships a template change, fire a placement test and block the pipeline if inbox rate drops below 85%. Deterministic, cheap, fast.
• Scheduled monitoring. A cron job that tests your production sender every 6 hours and alerts Slack on regression. The LLM would add cost and latency for no benefit.
• Dashboards. Your ops page shows inbox rate over time. You query the REST API from a Grafana datasource or your internal admin.
• Customer-facing features. Your product offers deliverability checks to your users. Your backend calls REST on their behalf. MCP cannot do this at all.

A minimal REST example

# ci-check.sh — run as a blocking step in GitHub Actions
set -euo pipefail

TEST_ID=$(curl -s -X POST https://check.live-direct-marketing.online/api/tests \
  -H "Authorization: Bearer $INBOX_CHECK_API_KEY" \
  -H "Content-Type: application/json" \
  -d @- <<JSON | jq -r '.id'
{
  "from_domain": "news.mybrand.com",
  "subject": "CI gate test",
  "html": $(jq -Rs '.' < build/email.html)
}
JSON
)

# Poll up to 3 minutes.
for i in $(seq 1 18); do
  STATUS=$(curl -s https://check.live-direct-marketing.online/api/tests/$TEST_ID \
    -H "Authorization: Bearer $INBOX_CHECK_API_KEY" | jq -r '.status')
  [ "$STATUS" = "complete" ] && break
  sleep 10
done

INBOX=$(curl -s https://check.live-direct-marketing.online/api/tests/$TEST_ID \
  -H "Authorization: Bearer $INBOX_CHECK_API_KEY" | jq -r '.inbox_rate')

awk -v v="$INBOX" 'BEGIN { exit (v >= 0.85 ? 0 : 1) }'

That is the whole thing. No LLM tokens, no reasoning, no recursion limits. Just a shell script that exits 0 or 1.

The overlap zone

Some workflows sit in the middle and either tool works. The biggest one: pull request validation. When a marketer pushes a template change to Git, you want a comment on the PR saying "inbox rate 18/20, SPF pass, DKIM pass, safe to merge".

• REST path: GitHub Action runs on PR open, calls REST, posts a comment with the verdict.
• MCP path: a LangChain agent triggered from a webhook, running MCP calls through langchain-mcp-adapters, then posting the comment.

Pick REST if the verdict template is fixed. Pick MCP (or an agent calling MCP) if you also want natural-language explanations and proposed fixes.

Both share the same backend

This is important and often missed: the MCP server is a thin wrapper over the REST API. Same rate limits, same quotas, same test data. Tests started through MCP show up in the dashboard exactly the same as tests started through REST. An API key is an API key.

Concretely, the Inbox Check MCP server does roughly this:

// inside ldm-inbox-check-mcp (simplified)
server.tool(
  "start_test",
  {
    description: "Start a placement test",
    inputSchema: { /* ... */ },
  },
  async ({ from_domain, subject, html }) => {
    const res = await fetch(API_BASE + "/api/tests", {
      method: "POST",
      headers: {
        "Authorization": `Bearer ${process.env.INBOX_CHECK_API_KEY}`,
        "Content-Type": "application/json",
      },
      body: JSON.stringify({ from_domain, subject, html }),
    });
    return { content: [{ type: "text", text: await res.text() }] };
  }
);

No magic. That means:

• One billing ledger. You don't pay twice for tests just because one was started through MCP.
• One set of rate limits. MCP-initiated calls count against the same bucket.
• Audit logs are uniform. You can see "who ran this test" regardless of protocol.

A recommended stack for a serious team

For a team shipping cold email or transactional mail at non-trivial volume:

1. REST for CI. Every PR that touches email templates runs a blocking placement test. Below 85% inbox rate, the build fails.
2. REST for monitoring. Cron job every 6 hours on each production sender. Alerts to Slack or PagerDuty on regression.
3. MCP for ops. Claude Desktop and Cursor are wired to the MCP server for all humans on the team. On-call uses it to triage.
4. MCP inside an agent (optional) for PR auto-comments with natural-language fix suggestions — LangChain or LangGraph on a schedule.

Example: cold email team using both

A hypothetical 10-person cold outreach team:

• SDRs use Claude Desktop + Inbox Check MCP. They paste a sequence template, ask "is this going to land?", and get a plain-English answer. No dashboard, no training.
• Deliverability engineer runs a scheduled monitor via REST that tests every live sender domain every 4 hours. Sends a Slack digest every morning.
• Ops team runs a REST-backed dashboard that shows inbox rate per sender, per provider, over time. Plugs into their Datadog stack.

Total spend on MCP-specific infrastructure: zero. Claude Desktop already exists on every developer's laptop.

How to decide, in one question

Ask: "Will a human be present when this runs?"

• Yes → MCP (probably through an interactive client).
• No → REST.
• Sometimes → both, sharing the same backend.

Frequently asked questions