Every plan to deploy a conversational tool into an enterprise starts with the same sentence. "We will integrate with their systems." That sentence hides the first real architecture decision, and teams skip past it to the demo. There are four common ways your agent reaches a client system, a direct API, the Model Context Protocol, a prebuilt connector, and an embed, and the one you pick per edge sets how much you build, how much control you keep, how fast the call is, and how much surface the client's security team has to review. Choose it on purpose, edge by edge, and write down the option you rejected.
The four ways in
A direct API is you calling the client's endpoint, or exposing your own, with your own code holding the contract. It gives you the most control and leaves you the most to build and test. Function calling is the model-facing version of the same idea. Anthropic frames tool use as the model returning a structured call your application executes, with a clean split between client tools that run in your app and server tools that run on the provider side.
The Model Context Protocol is the newer option and the one changing the default. MCP is an open standard for connecting AI applications to external systems, introduced by Anthropic in November 2024 and built around one idea, that a system exposes its data and actions through a server the model can reach the same way every time. Its own documentation calls it a USB-C port for AI applications. What made it matter is who picked it up. OpenAI's Agents SDK speaks MCP across transports, Microsoft publishes a catalog of official MCP servers for Azure and Fabric, and Google Cloud announced managed remote MCP servers across its services in December 2025. A standard three of the largest platforms agree on is a standard you can build an integration around.
Least privilege is the connection decision, not a setting after it
A connection that can take actions is a connection that can take the wrong action. The MCP specification is blunt about this. It names tool safety as a core principle, warns that tools represent arbitrary code execution and must be treated with appropriate caution, and requires explicit user consent before a tool runs. The protocol's authorization layer is built on OAuth 2.1, so access is scoped rather than a shared key that can do anything.
Carry that into how you scope each edge. Anthropic's MCP connector lets you allowlist and denylist the tools a server exposes, and it recommends denylisting write or destructive tools when you are building a read-only assistant or when you want a human confirmation step before any change to state. Start every edge read only, allowlist the exact tools the agent needs, and gate the writes behind a person until the review clears.
When each one still earns it
A direct API still wins when you need exact control over what data moves and when, or when the system has no MCP server yet. A connector or iPaaS wins when a well-worn integration to that system already exists and speed matters more than control, and it is weakest exactly where you need to say precisely what crosses. An embed, your tool dropped into the client's screen as a widget or SDK, wins the user experience because the person never leaves the client app, and it costs you control, because the embed now lives inside the host page's content security policy, its authentication, and its latency.
None of these is the right answer everywhere. The right answer is one method per edge, with the reason it beat the alternative written down. A method with no rejected alternative is a default nobody chose, and defaults are what a security review picks apart.
The connection is the review surface
Whatever you pick, the connection is the thing the client's security team actually reviews. They are not reviewing your model. They are reviewing which of their systems you touch, whether you read or write, what the tool is allowed to do, and how the access is scoped and revoked. A direct API is a broad surface you own. MCP narrows the surface to a declared set of tools with consent built into the protocol. A connector moves the surface to a third party. An embed inherits the client's surface and their rules.
Choose per edge, then move to the boundary
Map the systems you touch, pick the connection for each one, and record what you rejected. That is the first artifact of a deployment plan, and it is where the run-your-own workshop starts. The next question is harder and it is where most enterprise deals are won or lost, which is where the data is allowed to live once these connections start moving it.
Sources and further reading
Work with Hunter Green