MCP vs API for support automation: which to choose

Every few weeks a builder on a support team asks whether they should skip the API and ship an MCP server, or the reverse. The question is framed as a technology choice, and that framing is why it takes so long to answer. The better question is who is in charge of the sequence of calls.

This guide is written for builders. It assumes you can write code, you own an integration between a help desk and other systems, and you want a rule you can apply in five minutes. It uses Communicate's own REST API and MCP server as a worked example, because both are small enough to describe exactly.

The rule is simple to state. Your code drives, so call the API. An AI client drives, so publish an MCP server.

The sections below test that rule against sign-in, reliability, cost and maintenance, and the actions API guide covers the API side in more depth.

The question that decides it

An API is a set of endpoints that a program calls on purpose. The programmer chooses the endpoint, the order and the retry rules. The same input produces the same sequence of calls every time the job runs.

An MCP server describes similar capabilities in a form a language model can read. The model reads the descriptions, decides which tool fits the request, fills in the inputs and calls it. The same request can produce different sequences on different days, because a model is making the choices.

So the deciding question is who chooses the next call. If you can write the sequence down in advance, a program should run it. If the sequence depends on reading a conversation and judging what it needs, a model should choose, and MCP is how you give it a safe menu.

The MCP specification describes tools as model-controlled, meaning the language model can discover and invoke them automatically based on its understanding of the context and the user's prompts. That sentence from the MCP tools specification is the cleanest statement of the difference. An API is program-controlled, and an MCP tool is model-controlled.

What an API call looks like when your code is in charge

Take a nightly job that finds tickets waiting on the customer for seven days and closes them. The steps never change. Query the tickets, filter by status and age, post a closing message, set the status.

A script does this with four calls, and the output is the same every night.

This is the machine layer. It runs unattended at three in the morning, costs no model tokens, and fails in ways you can predict. When something breaks, you read a stack trace, not a transcript of a model's reasoning.

APIs also win when the volume is high and the value per call is low. Syncing ten thousand contact records into a data warehouse does not need judgment. It needs a loop, a rate limiter and a retry policy, and a model in the middle would only add cost and variance.

Teams who start from this angle often find that most of their automation is already API work. The customer support automation guide maps the common workflows, and a large share of them are scheduled and rule-based.

What an MCP call looks like when a model is in charge

Now take a request from a team lead, typed into an AI assistant. Find the three most urgent open tickets for our biggest accounts and draft a status note for each. No script can run this without someone first deciding what urgent means, and a model can interpret it from context.

The assistant reads the MCP server's menu, calls a search tool, reads the results, calls a ticket-detail tool for each, and writes the drafts. A person reads the drafts before anything is sent. The sequence was chosen by the model, on the spot.

This is the judgment layer. It handles requests that cannot be written as a fixed script, and it does so with a person steering. The server's job is to make a small set of safe actions discoverable and to enforce who the assistant is acting as.

Drag, a Gmail-based shared inbox that publishes its own MCP server, frames the split in a decision guide as using the API for the machine layer and MCP for the judgment layer. That is the practical version of the rule above, from Drag's MCP versus API guide, and I agree with it as a rule of thumb.

A worked example from Communicate

Communicate offers both routes, and I read the source to describe them accurately. The REST API lives under app.communicate.so/api/v1 and lets a program list agents and send a chat message to an agent. A program signs in with OAuth client credentials, receives a bearer token that lasts one hour, and uses the scopes agents:read and chat:write, or it uses a workspace key.

Your code decides every call, which is the API pattern in its simplest form, and the actions feature covers the reverse direction where the agent calls your systems.

The MCP server is separate and much smaller. It is named communicate-docs, it is public and read-only, and it exposes three tools that return the developer guide, an OpenAPI summary and support contact details. Each tool is marked read-only, non-destructive and idempotent, and its instructions say it does not access workspaces, customer data or product actions.

Why build the MCP server so small? Because its job is different. An AI coding assistant that needs to write an integration can read the documentation from the server and then write code that calls the API.

The model drives the reading, and your code drives the production calls.

That pairing is worth copying. MCP helps the model learn what exists, and the API does the work at run time. The build or buy guide covers when to build that kind of plumbing yourself.

Sign-in and identity differ in practice

An API integration usually runs as a service account. It has a client ID and secret, a set of scopes, and no human behind it. Everything it does is attributed to the integration, which is fine for a nightly job and awkward when you need to know which person asked for a change.

A well-built MCP server runs as the person who signed in. Plain's documentation says its server authenticates through OAuth with the user's own Plain account, uses no API keys, and shows replies as that user. Pylon's says the server cannot return data the user cannot already see or perform writes the user cannot already make.

That identity model is a feature. It means the assistant's reach is limited to the person's reach, and the log shows a named human. Salesforce takes the same approach, and its announcement states the servers run as the authenticated user with object permissions, field-level security and sharing rules applied, in the Salesforce hosted MCP announcement.

The trade-off is that per-user sign-in does not suit unattended jobs. A job that runs at night has no person to sign in. If you try to run scheduled automation through an MCP server with a borrowed login, you recreate the shared-key problem under a different name.

Reliability, testing and cost

APIs are easier to test. You send a request and assert the response. You can run the same test in CI a thousand times and expect the same result.

When a call fails, the failure is deterministic and the fix is a code change.

Model-driven calls need a different kind of testing. You check whether the assistant picks the right tool for a set of realistic requests, and whether it supplies correct inputs. Accuracy is a rate, and the rate changes when you change the tool list, the descriptions or the model.

Anthropic's engineers put the point plainly in their guide to writing tools for agents. They say you need to measure how well Claude uses your tools by running an evaluation, and the writing effective tools for agents post walks through how. The same discipline applies to a support assistant, and the evaluation and testing guide shows a support-specific version.

Cost also differs. An API call costs the request. An MCP interaction costs the request plus the tokens the model spends reading tool definitions, choosing and interpreting results.

Anthropic's code execution post by Adam Jones and Conor Kelly says most clients load all tool definitions upfront into context, and it reports a Google Drive to Salesforce example falling from about 150,000 tokens to about 2,000 with a code execution approach, a 98.7 percent reduction.

That figure comes from one example and one approach, so read it as an illustration of scale. It shows that the tool surface has a price, paid in context on every conversation. A repetitive task that touches many tools is the case where an API script is both cheaper and safer.

Maintenance and ownership

An API integration has an owner. When the vendor changes an endpoint, that person updates the code. The work is predictable and shows up in release notes, so you can plan for it.

An MCP server shifts some of that work. If the vendor hosts the server, the vendor keeps the tool definitions current, and your AI clients pick up changes at the next connection. The cost is that tool lists can change without a code change on your side, so a tool you relied on may be renamed or removed.

The MCP specification includes a list-changed notification so that servers can tell clients when the tool list changes. That helps clients stay current. It does not tell you whether a new tool is safe, so keep a review date for every server you approve.

If you host your own server, you carry the maintenance. Keep it small. The tool curation guide argues for a short list of task-shaped actions, and a short list is also cheaper to maintain than a mirror of your entire API.

Five support tasks, sorted by who drives

Sorting real tasks makes the rule concrete. The list below uses the question from the start of this guide. For each task, ask whether the sequence can be written down in advance.

• Close tickets that have waited seven days on the customer. The sequence is fixed, so an API script fits.
• Sync new contacts from the help desk into the CRM every hour. The volume is high and nothing needs judgment, so use the API.
• Summarize an account's last month of tickets for a quarterly review. The request needs interpretation, so a model-driven MCP session fits, with a person reading the output.
• Draft a reply to an unusual complaint using the customer's history. A model chooses what to look up, so MCP fits, and a person sends the reply.
• Answer a customer's question about an order in a public chat. A customer-facing agent calls a fixed set of backend actions with its own limits, which is neither of the first two routes.

The fifth case is easy to miss. A public chat agent calls your systems through a defined, scoped action layer, and it should never inherit a staff member's login. The AI chatbot versus AI agent guide explains why customer-facing and staff-facing assistants need different controls.

A decision table you can print

The table summarizes the trade-offs. A tick means the route handles that need well. A cross means it handles it poorly or not at all.

Use it as a starting point and adjust for your own risk tolerance.

Notice that the two columns mirror each other. What one does well, the other does poorly. That is the argument for using both rather than choosing one forever.

Using both without making a mess

Use the API for anything scheduled, high-volume or latency-sensitive. Use MCP for anything exploratory or judgment-heavy that a person supervises. Keep the two in separate code paths, with separate credentials, so a problem on one side cannot silently spread to the other.

Share the underlying business rules. If both routes can issue a refund, both should call the same refund function with the same limits. Duplicate rules drift apart, and the route with weaker checks becomes the route attackers and accidents find.

A good pattern is to put a thin MCP server in front of the same service layer your API already uses. The server adds descriptions and per-user sign-in, and the service layer enforces limits. Aizawa and colleagues note that a single tool can consolidate functionality, handling multiple discrete operations or API calls under the hood, which is exactly what a task-shaped tool does.

You can read the wording in their Anthropic engineering guide.

Avoid mirroring every endpoint as a tool. A server with one tool per endpoint recreates your API surface and hands the sequencing problem to the model. That is how teams end up with lists of fifty or ninety tools and unreliable behavior.

Security differences that change the choice

An API key is a secret that works wherever it is pasted. If it leaks, the attacker has whatever scopes the key has. Good practice is short-lived tokens, narrow scopes and rotation, which is how Communicate's client credentials flow works with a one-hour bearer token.

An MCP server adds a new risk, because the model reads text from tool results and may treat it as instructions. A ticket body can contain a malicious request aimed at the assistant. The MCP specification tells servers to sanitize tool outputs and tells clients to validate results before passing them to the model.

The same specification tells servers to validate all inputs, implement access controls and rate limit tool invocations, and tells clients to prompt for confirmation on sensitive operations and log tool usage for audit purposes. These are listed in the security considerations section of the MCP tools specification. Treat that list as your minimum, and read the MCP security guide for the threats behind it.

If a workflow involves untrusted text and powerful writes, think twice before putting a model in the loop. Use the API with fixed logic, or require a human confirmation on each write. The cost of a human click is small compared with the cost of an assistant that was talked into the wrong action.

Build the route yourself or buy it

Building an API integration is a normal engineering task with predictable costs. Building a good MCP server is harder than it looks, because you must design the menu, the descriptions, the sign-in and the tests. Many of the problems come from the menu design, not from the protocol.

Buying means using a vendor's official server. That is attractive when the vendor already hosts one, signs people in with their own accounts and documents its scopes. It is less attractive when the vendor's server offers write tools you cannot disable.

The build or buy decision for the AI agent itself follows the same logic. If your need is a customer-facing agent that answers questions and takes scoped actions, buying one is usually faster than assembling it from an API and a model. The build versus buy guide compares the costs, and the AI agents page shows what Communicate ships out of the box.

A short decision procedure

Use these steps in order. They take about five minutes for a single workflow. Stop at the first step that gives a clear answer.

• Write the steps of the workflow on one page. If you can, and they rarely change, use the API.
• If the steps depend on reading and judging text, note who will supervise. If nobody supervises, do not use a model-driven route.
• If a person supervises, check that the server runs as that person and that writes ask for confirmation.
• Pick the shortest tool list that covers the workflow, and plan to measure accuracy.
• Log every call with the user, the tool and the result, and set a review date.

If you complete the steps and still feel unsure, run the workflow as an API job first. You can add an MCP front later, when you understand which requests people actually make. The hub guide to MCP in support lists the other pieces to check before you do.

Tool descriptions are the documentation a model reads

When you write an API, the documentation is for people. When you write an MCP tool, the description is for a model, and it is the main thing the model uses to decide whether the tool fits. A vague description produces wrong choices that no amount of clean code can fix.

Write each description as an instruction to a new colleague. Say what the tool does, when to use it, when not to use it, and what each input means. Name the output in plain terms, so the model can tell whether the result answers the question.

Names matter too. Two tools with similar names and similar descriptions invite the model to guess. If you need both a search and a lookup, make the difference obvious in the first sentence of each description, and keep the names distinct.

This is the same craft that goes into writing prompts for a customer-facing agent. The guide on support agent prompt engineering applies, because both tasks are about telling a model exactly what is allowed and what good looks like.

Errors, retries and runaway loops

An API returns a status code, and your code decides what to do. A good client retries on a timeout, backs off on a rate limit and stops on a validation error. You wrote that logic, so you can reason about it.

In MCP, the specification separates protocol errors from tool execution errors. Execution errors come back inside the result with an error flag, and the spec says they carry actionable feedback that language models can use to self-correct and retry with adjusted parameters. That is useful for a wrong date format.

It is risky for a write that may have half-succeeded.

A model that retries after an unclear outcome can duplicate an action. Issuing the same credit twice is the classic example. Defend against it on the server with idempotency keys and a cap on repeated calls, rather than trusting the model to remember what it already did.

Rate limits are the other safeguard. Pylon's documentation states that limits apply per tool and per organization, and that clients receive a standard 429 response when a limit is hit. The MCP specification likewise tells servers to rate limit tool invocations.

The runtime authorization guide goes deeper on budgets and idempotency.

Versions and change over time

Both routes change, in different ways. An API usually versions its endpoints, and old versions stay available for a period. Your code keeps working until you choose to move.

MCP has protocol versions as well as tool changes. Communicate's own public server declares a current protocol version of 2026-07-28 and still supports 2025-11-25 for older clients, according to its source. Clients and servers negotiate, so older clients keep working, but you should know which version each of your clients speaks.

Plan for both kinds of change. Pin the versions you test against, record them in your runbook, and rerun your accuracy checks when either side upgrades. A change in a tool description can shift the model's choices even when no code changed.

What the vendors themselves document

Reading the vendor pages is the fastest way to see how the two routes coexist. Intercom publishes a developer guide for its MCP server with tool lists and scopes, next to its normal REST documentation. Plain documents its MCP server in its integrations section and also maintains a public API.

Plain also published a launch post for its server, linked as the Plain MCP server announcement. In the pages I read, each vendor keeps its API as the foundation and adds MCP as a second door for AI clients that signs people in as themselves.

For you as a builder, that means the API knowledge you already have still applies. The new work is designing the menu, deciding which actions to expose, and testing how a model chooses among them.

A four-week rollout for a builder

In the first week, write the one-page workflow list. Sort each task by who drives, using the five-case exercise above. Pick one API job and one supervised model-driven task, and ignore the rest until those two work.

In the second week, build the API job. Give it a service account with the narrowest scopes that work, add logging, and run it in a staging workspace first. Treat it like any other production integration, with alerts for failures.

In the third week, connect the supervised task through a vendor's hosted MCP server or your own small one. Use one named person, read tools only, and a written list of prompts to try. Record which tool the assistant picked each time and whether the answer was correct.

In the fourth week, review the logs together. Count wrong tool choices, repeated calls and anything the assistant tried to do that you did not expect. Decide which tools to remove, which descriptions to rewrite, and whether the supervised task is worth extending to a second person.

This pace feels slow, and it is deliberate. Teams that ship a large tool list on day one spend the following months explaining surprises. The launch guide for your first AI agent makes the same argument for customer-facing agents.

Mistakes that show up again and again

The first mistake is mirroring the API one for one. It feels complete, and it produces a long menu that models handle badly. Group endpoints into a handful of jobs and name each job in plain words.

The second is sharing one login across the whole team. A single token behind an MCP connection hides who did what and makes revocation painful. Give each person their own sign-in or do not connect them.

The third is skipping the write confirmation because it slows the demo. Demos are not where the damage happens. The damage happens on a Friday afternoon when a model misreads a request and a customer receives a message nobody approved.

The fourth is treating the choice as permanent. Your needs change as you learn which requests people actually make. Keep the service layer clean, keep the two doors separate, and you can move work from one route to the other without a rewrite.

Counting the real cost of each route

Engineering time is the biggest line for an API integration. You pay once to build it and then a smaller amount to maintain it. The run cost is close to zero, which is why high-volume jobs belong here.

An MCP route has a smaller build cost when the vendor already hosts the server, since you only configure access. It has a higher run cost, because every conversation spends model tokens on tool definitions, choices and results. It also has a review cost, because someone must read logs and check accuracy.

Vendors that meter MCP usage add a third cost. Freshdesk's support article describes rate limits and monthly action allowances for its integration, with add-on packs for more. Read those limits in the Freshdesk MCP article before you plan a high-volume use, because a busy assistant can use an allowance quickly.

The cheapest option in many cases is a mix. Let the API do the volume work for pennies, and keep MCP for the few high-value requests where judgment saves a person real time. Measure both, and move work between them when the numbers change.

When neither route is the right answer

Some tasks need neither. If a human can do the job in ten seconds and it happens twice a week, an integration costs more than it saves. Keep it manual and spend the effort elsewhere.

Other tasks belong in the help desk's own automation. Rules, macros and triggers already do many repetitive jobs with no code and no model. Check what the platform offers before you build, since a built-in rule is the cheapest thing to maintain.

If the job is answering customers, a purpose-built agent is often a better answer than assembling one. The comparison of macros versus AI support helps you decide which jobs to hand to which tool.

Frequently asked questions

What is the main difference between MCP and an API?

An API is called by code that a programmer wrote, in a sequence the programmer chose. An MCP server describes tools to an AI model that decides which to call. The first is program-controlled, and the second is model-controlled.

Does MCP replace APIs?

No. MCP servers usually sit on top of an existing API or service layer. The API still does the work, and MCP adds a self-describing, per-user entry point for AI clients.

Most vendor servers are built this way.

When should I use an API instead of MCP?

Use an API when the sequence is known, the job runs without a person, or the volume is high. Nightly cleanups, data syncs and webhooks fit. These jobs are cheaper and easier to test without a model in the loop.

When should I use MCP instead of an API?

Use MCP when requests are open-ended and a person supervises, such as summarizing an account or drafting a reply. It is also useful when you want many AI clients to reach the same tools without separate integrations.

Can I use both in the same support stack?

Yes, and most teams do. Keep the two routes in separate code paths and credentials, and have them call the same service layer so business rules stay identical. That avoids two sets of refund limits.

Is MCP more secure than an API?

Neither is secure by default. MCP can be safer when it runs as the signed-in user and logs each call. It also adds risks such as untrusted text in tool results.

Judge a specific server by its sign-in, scopes and logging.

Does MCP cost more than an API call?

Usually yes, because the model spends tokens reading tool definitions and results. Anthropic reports clients often load all tool definitions upfront into context. A short tool list keeps that overhead small.

Can an MCP server run unattended jobs?

It can, but it is a poor fit. Per-user sign-in assumes a person is present, and a model choosing calls adds variance. Scheduled work belongs in an API script with a service account and narrow scopes.

What does Communicate offer, an API or MCP?

Both, with different purposes. The REST API under app.communicate.so/api/v1 lets your code list agents and chat with them. The public MCP server is read-only and returns developer documentation.

See the MCP hub guide for the details.

Do I need an MCP server to connect my help desk to Claude?

Not necessarily. Your help desk vendor may already host one, which is the easiest route. If the vendor has none, a community server or your own small server are options, with the governance costs described above.

How do I decide who drives the conversation?

Ask whether the sequence of steps can be written down in advance. If it can, your code drives. If the next step depends on reading and judging the conversation, a model drives, and you should publish a safe menu for it.

What is a tool in MCP terms?

A tool is an action a server exposes, with a name, a description and a schema for its inputs. The model reads these and chooses. Good tools are task-shaped, which means each one completes a meaningful job.

Should every API endpoint become an MCP tool?

No. Mirroring endpoints hands sequencing to the model and bloats the tool list. Group endpoints into task-shaped actions, as the tool curation guide describes.

How do I test an MCP integration?

Build a set of realistic requests and record which tool the assistant picks and what inputs it supplies. Score the results and rerun after each change. Accuracy is a rate, so compare before and after numbers.

Who is responsible when an AI client makes a bad change?

The organization whose user account the assistant used. That is why per-user sign-in, confirmations on writes and call logs matter. Set those up before you give write access to anyone.

What if my help desk has no official MCP server?

Check the vendor comparison for the latest status. If none exists, use the API for automation and consider whether a staff-facing assistant is worth the governance work of a community or custom server.

Can a customer-facing chatbot use MCP?

A customer-facing agent should call a scoped action layer owned by your team, not a staff login. Some teams expose that layer through MCP internally. The key is that the public agent has its own limits and cannot inherit staff permissions.

How often should I review the tools an AI can call?

Review them when the vendor ships a change and on a fixed schedule, such as every quarter. Tool lists grow over time, and a review keeps unneeded write tools from staying switched on.

Is MCP only for chat assistants?

No. Coding assistants, workflow builders and desktop agents use MCP too. The protocol only describes how a client discovers and calls tools, so any AI application can act as a client.

What is a good first project?

Pick one read-only workflow with a supervising person, such as summarizing long threads. Measure accuracy and time saved for a month. Then decide whether to add writes.

The guide to connecting Claude and ChatGPT to your inbox walks through a setup.

The short answer

Ask who drives. When your code does, use the API. When a model does and a person watches, publish an MCP server with a short, task-shaped menu.

If you want a customer-facing agent that already handles scoped actions, confirmations and handoff, try Communicate at communicate.so.