MCP vs. custom integration: what actually changes
Both approaches get an AI system reading and writing data in SAP, Salesforce, Workday, or whatever else runs the business. The difference isn't whether it works the first time — a well-built custom integration works fine for exactly the use case it was written for. The difference shows up the second time you need that same system connected to something new.
The custom integration path
This is a point-to-point job: pick the fields a specific workflow needs, write the auth and query logic against that system's API, and wire the result into that one prompt or application. It's the right default for a single, well-scoped use case, and there's no protocol tax to pay for it. The cost shows up later — the second consuming use case usually can't reuse the first one's integration, because it was shaped around a workflow, not around the system itself.
What MCP changes
MCP (Model Context Protocol) inverts the shape of the work: you build a tool server for the system — get_pending_invoices, get_employee_data, get_pipeline — not around any one workflow. Any MCP-aware model can call those tools, decide which ones it needs for a given question, and chain them. The live MCP demo on this site shows the actual tool-server code for SAP, Workday, and Salesforce connectors written this way.
Side by side
| Dimension | Custom integration | MCP |
|---|---|---|
| What you build | A bespoke code path per (system, use case) pair — a Salesforce-for-forecasting integration is a different artifact from a Salesforce-for-support-triage one. | One tool server per system. Any use case, and any MCP-aware AI client, calls the same tools. |
| Adding a second use case | Usually a second integration, even against the same system — the first one was wired to one workflow's shape. | Usually zero new integration work — the new use case calls tools that already exist. |
| Where the logic lives | Spread across whichever app or script needed that data at the time it was built. | Centralized in the tool server, versioned and reviewed like the rest of your codebase. |
| What the model can do | Only whatever a human wired up in advance — the model consumes data it's handed, it doesn't request more. | The model decides which tools to call and in what order, based on what the question actually needs. |
| Auth & access boundary | Defined per integration — easy for scope to drift wider than the original use case needed. | Defined once per tool server, so every consumer of that server inherits the same boundary. |
| Switching AI providers | Integration code is usually written against one model's function-calling format. | MCP is a protocol, not a vendor's format — the tool server doesn't change if the client does. |
Where custom integration is still the right call
A protocol layer is only worth its overhead if something is actually going to reuse it. If there's exactly one AI use case against a given system, with no second one on the roadmap, a direct integration is simpler to build and easier to reason about — MCP's advantage compounds with the number of use cases sharing a system, and it isn't free at n=1.
See the pattern applied to a real workflow in the Migration Assessment writeup →
Try the live MCP demo →