MCP vs API vs iPaaS: three surfaces to your product

Your product already has an inside. The question is how many outsides it should have. A public API is how developers build. An iPaaS connector is how operators wire you to the other apps they already run. An MCP server is how an AI assistant uses you on a user's behalf. Those are not three implementations of the same integration. They are three surfaces, with different audiences, different discovery paths, and different ways of breaking.

Teams collapse them anyway. They wrap the API, call it a connector, then paste the same endpoints into an MCP tool list and wonder why none of the three feels finished. The work is to keep the surfaces distinct, share the contract underneath, and pick the next one to ship based on who is actually trying to reach you.

It sits next to native vs iPaaS vs embedded and connectors, agents, and third-party workflows. The unit here is the surface: audience, discovery, interaction, and maintenance.

The 60-second version

If you only read one section, read this one:

• Three surfaces, one product. API for developers, iPaaS for operators wiring apps, MCP for agents acting for a user.
• Do not ship the same endpoint list on all three. Each surface needs its own shape, even when they share the API underneath.
• Audience decides the interface. A developer wants a spec and errors. An operator wants triggers and actions. A model wants five to ten named jobs.
• Discovery is different. Developers find docs. Operators find connector catalogs. Agents find registries, client catalogs, and your listings.
• Interaction is different. Request-response, event recipes, and tool calls with approval are not one UX.
• Maintenance is different. You own the API. The iPaaS platform owns a lot of the connector runtime. MCP is yours again, including tool descriptions.
• Most products eventually want all three. Sequence them by customer pull, not by novelty.
• MCP is not a replacement for the API or for iPaaS. It is a new consumer of the same product.

Three surfaces, one product

Public API. HTTP and webhooks that a developer calls from their code. The consumer is a person writing an integration, a script, or your own connector. The interface is paths, schemas, auth, errors, and a changelog. This is the foundation. The other two surfaces almost always sit on it. A partner-ready API is what makes that foundation usable.

iPaaS connector. A packaged set of triggers, actions, and searches on an automation platform, so a non-developer or a lightly technical operator can wire your product to other apps in a recipe. You publish one connector. The platform's users assemble the rest. Zapier-style platforms are the usual example; the shape is bigger than any one vendor. See Zapier's platform docs for a concrete builder model, and treat it as one instance of the category.

MCP server. A Model Context Protocol server that exposes tools, resources, and prompts to AI clients. The consumer is a language model acting for a connected user. The interface is names, descriptions, and schemas the model reads at runtime. See what MCP is and the MCP specification.

Native in-app integrations, marketplace apps, and embedded iPaaS are delivery choices for partner-specific connections, not a fourth protocol. They are how you might build on the API. See native vs iPaaS vs embedded.

The shared core should be the API and the data model. The mistake is to share the shape. An operator does not want your pagination grammar. A model does not want eighty endpoints.

Audience and discovery

If you remember one column, remember the audience. Everything else follows from who is holding the other end.

API: developers, including partner engineers. They read docs, copy an example, and file an issue about a 400. They expect a spec, a sandbox, and a versioning policy. Time to first call is the metric. See developer onboarding.

iPaaS: operators and admins. They live in the automation product. They think in "when this happens, do that." They will not read your OpenAPI file. They will look for a trigger that matches an event they already understand, and an action named in business language.

MCP: a model, plus the user who connected it. The user speaks in jobs ("pull overdue invoices"). The model must map that onto tools. Security reviewers, not the user, will ask about scopes and approvals.

Same company can contain all three people. That is a reason to offer more than one surface, not a reason to merge them.

Discovery follows the same split. API discovery is your docs and changelog. iPaaS discovery is the platform's catalog. MCP discovery is still forming: client catalogs, registries, GitHub, and your own docs. Users install a server, then the model only sees what that server listed. Write the iPaaS listing in operator language. Write the MCP listing in job language.

Interaction and maintenance

The call pattern is the other hard difference. API interaction is request-response, plus webhooks if you have events. iPaaS interaction is event and action in a recipe, with fields the platform can render as a form. Depth is capped by the platform, which is why native still wins for the deepest workflows. MCP interaction is: the client lists tools, the model chooses, the user may approve, the server runs. There is no recipe. Descriptions are the interface. Writes should pause. Unbounded lists are a bug. That is why "just generate MCP tools from OpenAPI" produces a bad surface. Generation is a start. Scoping is the product, as in MCP for SaaS and MCP tool definitions.

Maintenance decides staffing. API maintenance is yours forever: spec, docs, versions, deprecations, uptime, rate limits, error catalog. iPaaS maintenance is split. You own the connector mapping and listing. The platform owns the runtime and a lot of retry behavior. Read platform policy from the vendor. Do not invent it. MCP maintenance is yours again. Tool descriptions are copy you have to test against real clients, because a wording change can alter which tool the model picks. Security is closer to a public API than to a recipe. See MCP security. If you can only staff one queue, staff the API. The other two surfaces inherit it.

How they sit in a portfolio

A healthy SaaS integration strategy uses more than one surface on purpose.

• API for anyone who will write code, including you and the MCP server's implementation.
• iPaaS for the long tail of app-to-app wiring you will never build natively.
• MCP for the assistants your customers already opened.

Native still exists for deep in-product partner workflows. Embedded iPaaS still exists if you want that catalog inside your UI. MCP adds a port. It does not replace those.

Conflicts to avoid: telling developers to use MCP instead of the API; telling operators to abandon their recipes for a protocol; letting three teams ship three auth models. One OAuth app, many surfaces. One error shape, one object model, one changelog. Different front doors, same house.

A decision framework for the next build

When a request comes in, ask where the work already happens.

They have engineers and a repo. Ship or improve the API. Maybe an SDK. Not an MCP server as the answer to a partner integration.

They have an automation admin and a list of apps. Ship or deepen the iPaaS connector for the platforms they name. Do not start with a custom native build for a long-tail app.

They have an assistant and a job they run in chat. Ship a scoped MCP server for that job. Do not dump the API into tools.

They are a named strategic partner with a joint workflow in your UI. That is native, or a marketplace app, per native vs iPaaS vs embedded.

Customer pull first. Then staffing. A connector you cannot update is worse than no connector. An MCP server with eighty untested tools is worse than no server. Sequence for most B2B SaaS: partner-ready API first; one iPaaS connector if operators are already asking; MCP when customers are using assistants against your category, scoped to one job; native only for deep, repeated partner workflows. You cannot skip the API if you want the others to be sane.

What not to do: collapsing three into one

Three anti-patterns show up in roadmaps.

"The OpenAPI spec is the MCP server." Generation can draft tools. It cannot choose the job, write descriptions a model can route on, or refuse dangerous operations. Scope by hand.

"The iPaaS actions are the API." A connector with eighty actions is unusable in a form UI. Operators want a short list named after jobs. Same discipline as MCP, different consumer.

"We will only do MCP, it is the future." It is a surface. The API remains how partners, your own connectors, and the server itself talk to the product. iPaaS remains how a large class of customers automate. Novelty is not a sequencing rule.

When someone proposes a single layer for developers, operators, and agents, ask them to fill audience, discovery, interaction, and maintenance. If the answers are identical, the proposal has not met the surfaces yet.

Common mistakes, and the fix

Treating MCP as a nicer API. The fix: different consumer. Developers get a spec. Models get a small set of jobs. The server wraps the API, it does not replace it.

Publishing an iPaaS connector that is a thin wrap of every endpoint. The fix: triggers and actions named for operator jobs, tested in the platform's UI, versioned when your API versions.

Staffing three surfaces before the API is ready. The fix: partner-ready API first. Docs, auth, errors, changelog. Then connectors and servers.

One listing copy reused everywhere. The fix: developer language on the API site, operator language in the catalog, job language on the MCP listing.

No shared object model. The fix: one resource names and ids across API, connector, and tools, so a customer who uses two surfaces is not learning two products.

Skipping maintenance in the estimate. The fix: count connector revisions, tool-description tests, and API deprecations as ongoing work, not launch work.

FAQ

Is MCP a replacement for a public API? No. MCP is a small, described surface, usually implemented on top of your API. Developers, native connectors, and the server itself still need the HTTP contract.

Is MCP a replacement for iPaaS? No. iPaaS is how operators wire apps in recipes. MCP is how an assistant runs a job in conversation. The buyers and the interaction models stay different.

If we can only ship one, which should it be? The API, if it is not already partner-ready. After that, pick the surface where customers already work: iPaaS, MCP, or native for a named partner that needs depth.

Can we generate all three from OpenAPI? You can generate docs, SDKs, and a draft MCP tool list from a spec. iPaaS actions and MCP tools still need human scoping, naming, and a never list.

How do native integrations fit this comparison? Native is a delivery choice for a specific partner workflow you own end to end, usually built on the API. Use it when depth and in-product UX matter more than reach.

Who should own MCP versus the API versus the connector? One person should own the integration portfolio so the surfaces do not drift. Engineering owns the API and the MCP server. Product decides which jobs each surface exposes.

The short version

API, iPaaS, and MCP are three surfaces to the same product. Developers get a versioned HTTP contract. Operators get triggers and actions in a catalog. Agents get a small set of tools, resources, and prompts. Discovery, interaction, and maintenance all differ, so the endpoint list should not be copied from one to the next.

Share the API and the object model. Staff the API first. Add iPaaS for operator reach and MCP for assistant reach when customers are already on those surfaces. Native stays the deep, expensive option for a few partners. None of the three replaces the others.

If you want a clear call on which surface to ship next, and how to keep them from becoming three copies of the same mess, that is exactly what a Partner Audit is for. We review the product, the API, and where your customers already work, then define the portfolio and the first build.

Further reading

• Model Context Protocol specification: the official protocol for MCP servers, tools, resources, and prompts.
• Zapier platform documentation: one major iPaaS builder model, useful as a concrete instance of triggers, actions, and catalog listing.
• Model Context Protocol: current guides and the spec index.