MCP vs API: a practical guide for business integrations

MCP and APIs usually work together

An application programming interface (API) lets software request information or perform an operation using an agreed interface. Model Context Protocol (MCP) standardises how an AI application discovers and uses tools, resources and prompts supplied by connected servers. In many business systems, an MCP tool calls an existing API behind the scenes.

That distinction matters when you commission an integration. A customer portal might call your CRM API whenever a customer updates their details. An AI assistant might use an MCP tool to find that customer and propose a change during a conversation. Both routes still need authentication, permissions, validation and a dependable underlying system.

You can also connect AI applications directly to APIs through custom function tools. MCP is one integration approach, rather than a prerequisite for every AI feature. Nor does every MCP client need to be a language model: ordinary software can call the protocol too.

For an operational process with a fixed trigger and predictable steps, conventional systems integration may be sufficient. When users need an assistant to choose among connected capabilities during a conversation, MCP integration becomes useful.

What changes when you add MCP?

An API describes the operations a system supports. A developer normally decides which operation to call, supplies the parameters and handles the response. That developer may build a scheduled job, website, mobile application or AI tool around it.

MCP gives compatible applications a common way to discover available tools and their input descriptions, request a tool call and receive a result. A server can also expose resources that provide context. The AI host decides how to present those capabilities, whether to request approval and what material enters the model's context.

The useful commercial benefit is a more consistent connection surface across compatible hosts. It does not remove the implementation work underneath. Someone still needs to understand the CRM's fields, the finance system's rules and the consequences of a failed operation.

An MCP description saying “create an invoice” is therefore insufficient on its own. The business action needs defined customer identifiers, permitted values, approval rules and a way to prevent unintended repeated actions. The tool should report what actually happened, including uncertainty or failure.

Three lessons from Google's MCP guidance

Google's documentation provides useful examples of how the two layers fit together.

Existing APIs can become agent tools

Google's Apigee MCP quickstart shows how an OpenAPI description and a dedicated proxy can expose existing API operations as MCP tools. The API remains part of the system; MCP supplies another access route.

Our take: review the operations before exposing them. A technically valid API endpoint may be too broad for an assistant, or may leave the caller to assemble several steps whose order matters. A carefully scoped business tool can make the permitted action clearer.

Tool selection affects usability and cost

Google's Cloud MCP overview describes toolsets that restrict which capabilities an agent loads, alongside administrative and access controls.

Our take: exposing everything is rarely a useful starting brief. A sales assistant probably needs a narrower set of tools than an infrastructure administrator. Fewer relevant choices can simplify evaluation, while permissions must still be enforced by the system rather than by the wording of a prompt.

An MCP server can supply context as well as actions

The Developer Knowledge MCP reference describes a proxy between external services and an AI application. Its documentation-access use case illustrates why an MCP connection need not change business records.

Our take: separate tools that retrieve information from tools that commit changes. Reading an order and approving a payment deserve different controls. That separation makes it easier to give an assistant useful access without granting unnecessary authority.

Where direct API integration is the better starting point

Suppose every approved order must enter the finance system, using the same mappings and approval rules each time. A conventional integration can respond to that event, validate the record, create the required entry and reconcile the outcome. The process does not need a conversational choice at every step.

Direct integration can also be appropriate for bulk migration, scheduled synchronisation and application features that must execute a defined action consistently. The application decides when the call occurs; users do not need to describe the task in natural language.

MCP can still sit alongside that workflow. An assistant might inspect an exception queue and explain why three records need attention, while conventional software handles the underlying transfer. The decision is often about which layer owns each responsibility.

Our recommendation is to use the simplest route that meets the requirement. Adding an AI decision to an already well-defined operation can introduce evaluation and supervision work without improving the outcome. An API-driven workflow can be the right answer even within an ambitious AI programme.

Where MCP adds a useful conversational interface

Consider a hypothetical project manager asking: “Which jobs have slipped, who owns the next action, and can you prepare a follow-up?” The assistant may need to find jobs, inspect milestones and create drafts using several capabilities.

A compatible MCP connection can expose those capabilities together, with structured inputs and results. The application should check the person's access to each record, show which actions completed and distinguish preparing a message from sending it.

The integration should also preserve business rules. An assistant may propose a changed deadline, but that does not automatically authorise it to alter contractual commitments. Sensitive or irreversible actions need an explicit approval route implemented outside the model's judgement.

This scenario is illustrative, not a client case study. It explains the distinction between connected assistance and the AI workflow planning needed to decide what authority the assistant should have.

File transfers: identify which layer sets the limit

Files are a practical example of why an MCP connection and an API connection can behave differently in use. There are several separate constraints: the chat application's attachment limit, the MCP client's tool-message limit, the server's request limit and the destination service's upload limit. A model's context capacity is another constraint, and is not measured in the same way as file size.

MCP's resource specification permits binary resource contents encoded as base64. Its tool specification also supports resource links. An implementation therefore does not have to put every file's bytes into a chat tool result.

Base64 increases the encoded payload by roughly one third, before JSON and other overhead. For example, 30 MB of raw bytes becomes about 40 MB of base64 data. This arithmetic does not mean every host measures its limit against the encoded size; that depends on the particular implementation.

As checked on 30 September 2026, Claude's upload documentation lists 500 MB per file for chat uploads and 30 MB per file for project files. These are product limits, not a universal MCP rule, and the documentation may change. Connector behaviour and content-processing limits also need their own checks.

Let the server move the bytes when appropriate

For a large permitted transfer, a tool can accept an authorised file identifier or controlled storage reference, move the file server-side through the destination API and return a small receipt. The assistant triggers the operation; it does not need the entire binary file in its context.

Another design may use a resumable upload or a background job, where the destination supports it. The tool returns a job identifier and later reports completion. These are application design choices, not automatic features of every MCP connection.

An API key alone does not solve a payload constraint. It authenticates the caller. The transfer route must also change if the problem is that the current client is carrying too many bytes. Likewise, an authorised storage reference is different from a credential: the two should not be confused.

Moving bytes server-side avoids an unnecessary chat-mediated route; it does not override the receiving service's size ceiling, access controls or processing restrictions. It also does not mean the model has read the file. If analysis is required, the system needs an appropriate extraction or processing stage.

Design tools around business actions and recovery

Our preference is to expose clearly bounded actions with useful names, precise inputs and structured results. A tool should make the intended effect understandable to the user and leave the server responsible for enforcing the rules.

For a hypothetical invoice workflow, separate searching invoices, preparing a draft and committing an approved change. Define what happens when a request times out after the receiving system has already saved the record. Repeating the call blindly can create duplicate effects; recovery needs agreed identifiers and receiving-system support.

Keep credentials out of model-visible descriptions and responses. Apply permissions to the signed-in person and the requested resource. Treat retrieved documents and external tool results as data that may contain misleading instructions, rather than authority to change the workflow.

Monitoring should record tool inputs and outcomes at a level appropriate to your data policies. Include failure paths in testing: expired access, unavailable services, partial completion, oversized files and contradictory requests. A successful demonstration covers far less than an operational acceptance test.

How to choose the right approach

Start with five questions:

• Is the task a fixed workflow, an interactive application feature or conversational assistance?
• Which systems and business operations must be available, and to whom?
• Does the assistant need the content, or only to trigger a controlled transfer or action?
• Where do approval, validation, retry and reconciliation belong?
• Who will maintain the integration when tools, APIs or business rules change?

Those answers may lead to direct APIs, MCP, or a combination. They should also define the operating cost and the handover: documentation, access ownership, monitoring and an exception-handling route.

Scorchsoft builds MCP connections, systems integrations and AI agents and automation. We can assess the workflow first and recommend a connection approach that fits the work, including a conventional integration where that is sufficient. Book a strategy call to discuss one process and the systems it needs to reach.