The first team that wrapped the ticketing API did the right thing. So did the second. By the fourth, someone was in a steering committee asking why three different agents had three different ideas of what “close the ticket” means.

The argument over how agents connect to enterprise systems usually centers on the protocol: Model Context Protocol (MCP) versus direct REST API. That is the wrong argument. The protocol is the last decision. The first decisions are where the credential lives, who reads the audit log, and who gets paged at 2 a.m. Those answers pick the implementation shape for you.

There are three shapes: consume the vendor’s hosted MCP server, run your own internal MCP server in front of the API, or let the agent call the API directly through a thin client.

The Thin Client

A direct API client is a sound long-term choice when the boundary is narrow.

Consider a support agent that reads incident records from a single platform. The owning team already operates the application, stores the credential in the platform secret store, and can trace each API call to a specific request. They ship a direct client in four days. Building an MCP server would have taken three weeks and created a permanent operational animal for no reason.

A thin client keeps the integration close to the workflow. It is the right answer when one team owns the workflow, the endpoints are stable, no cross-team reuse is on the roadmap, and your existing infrastructure already handles secrets, logging, and authorization.

The trigger to abandon the thin client is the second consumer. When a second team builds a finance agent against the same platform, they will copy the first team’s wrapper, paste the credential into their own configuration, and write their own retry logic. That is the signal. A shared client library is just a server that hasn’t admitted it yet.

The Internal MCP Server

You build an internal MCP server to centralize the blast radius. Direct API access pulls credentials to the edge, distributing API keys and service accounts across every agent framework and orchestration script your teams build. An internal server pulls those credentials to the center.

This shape solves problems that only appear at scale.

Agents are aggressive clients. If an agent hallucinates a parameter and receives a generic 400 error, it might retry with slight variations 800 times in three minutes. If three teams have direct wrappers, one tight retry loop triggers a global rate limit. The vendor only sees identical OAuth clients and cannot attribute the traffic. An internal server buffers the rate limits, enforces per-team quotas, and translates a 429 error into a clean instruction for the agent to pause.

It also solves the context budget problem. Vendor APIs are built for deterministic software. They return massive JSON payloads with hundreds of fields. Tool schemas are prompt tokens. Fifty tools at 300 tokens each is 15,000 tokens before the agent reads the user’s request. An internal server translates raw endpoints into narrow, LLM-friendly tools, stripping out nulls and irrelevant metadata. It exposes eight curated tools and routes internally, preserving the model’s context window for the actual task.

The operational cost of an internal server is a new trust boundary. It terminates authentication, so the authorization bugs live there. It is the most privileged thing in the chain. You must decide how identity flows through it. The agent can act as itself using a service account, as the user via token exchange, or as a hybrid. The hybrid approach is where the confused deputy problem lives: the server accepts a user token from the client, then calls downstream with its own service account. If the server does not map the user’s identity to the backend request, the audit log will only show that the server modified the record. When legal asks which employee authorized the write, you will not have an answer.

If you build this server, you must staff it. It needs a service level objective, secrets rotation, monitoring, and a named owner. If the answer to “who is on call” is “nobody,” it is a prototype. Label it as such and do not let a production agent depend on it.

The Vendor-Hosted MCP Server

SaaS vendors are shipping their own MCP servers to make their platforms AI-ready. This shifts the compute and maintenance burden off your team. It is an attractive option, but a vendor MCP server is a product decision they made for all their customers, including the ones who aren’t you.

Consuming a vendor-hosted server is a dependency. Depending on it is a commitment.

It works when the server is generally available, named in your support contract, and covered by the SLA you actually signed. It works when their authentication model supports user delegation and produces an exportable log that integrates with your security information and event management system. It works when the tool surface matches what you need, including write operations, without requiring a broad catch-all tool.

It fails in predictable ways.

The first trap is the read-only beta. A vendor ships an MCP server with six read tools. Your reconciliation agent needs to post a correction. The server is in a beta SKU, not in the support contract, and the roadmap says write capabilities are “coming soon.” You either run your own server in front of the same API, or you ship an agent missing the only operation that pays for it.

The second trap is the identity gap. The vendor’s MCP server connects via a single, highly privileged service account. All writes appear in the vendor audit log under one integration account. Your security team cannot tell which employee initiated a change. This is a reason to limit the vendor server to read-only operations, not a reason to reject MCP generally.

The third trap is schema lock-in. The protocol isn’t the lock-in; the tool schema is. A REST API can be re-wrapped. Tool names and descriptions are embedded in prompts and evaluation sets. If the vendor renames a tool or changes a description in their next release, it is a breaking change with no semantic versioning. Your agent’s behavior is coupled to their roadmap.

Decision Rules

The choice depends on the count of consuming teams, the sensitivity of the data, and the maturity of the vendor’s offering. Check these conditions to pick the shape.

Consume the vendor-hosted server when:

  • It is generally available, named in the support contract, and covered by your SLA.
  • The authentication model supports user delegation and produces an exportable log.
  • The tool surface matches your needs, including writes, without exposing a broad catch-all tool.
  • You have no unusual data residency, personally identifiable information, or egress constraints the vendor will not meet.
  • You are in evaluation and speed beats control, provided you accept that you will re-decide before production.

Run your own server when:

  • Two or more consuming teams need the same enterprise system, or two or more systems sit behind one capability.
  • Any write operation touches money, human resources, health records, or a regulated dataset.
  • You need a kill switch, per-team quota, or a single audit line.
  • The downstream API is legacy, lacks a clean REST surface, or returns massive payloads that blow out the context budget.
  • You need to curate the tool surface to preserve context budget and tool-selection accuracy.
  • The agent runtime lives outside your network and must not hold the downstream credential.

Use a thin API client when:

  • One team owns the workflow and the integration, with a small, stable set of endpoints.
  • No cross-team reuse is on the roadmap.
  • Existing infrastructure, like an API gateway, already handles secrets, logging, egress, and authorization.
  • You are prototyping, and you have written down the promotion trigger before starting.

Choose the thinnest integration that gives each consequential operation an owner, an enforceable permission boundary, and a usable audit trail. Before you build the server, name the team that will handle a failed vendor call at 2 a.m. and the team that can approve a new write tool.