What Integration Teams Need to Know Before Building an MCP Server

Key Takeaways

• Understanding MCP for enterprise
• Deciding what to expose to AI agents and what to protect
• Why iPaaS is an ideal MCP management platform

Enterprise AI has left the sandbox with agents reading live records, calling production APIs, and setting off the business processes that make or break a company. But how those agents connect to business systems is a trap that snares many organizations.

The Model Context Protocol (MCP) is the standard the industry is settling on for those connections. So how do you build MCP servers to meet your goals? At first glance, it looks like a limited engineering job you could scope in a sprint. In practice, a Model Context Protocol implementation that your users can depend on becomes long-lived infrastructure you have to secure, scale, watch, and keep alive for years.

What Building an MCP Server for Enterprise Actually Takes

The project to build MCP servers is really two jobs: deciding which of your systems an agent gets to reach and then running the server that lets it reach them. Coming to grips with the protocol itself is the most straightforward part; the work that calls for thorough consideration and sufficient time is everything else around the code.

Let’s start by looking more closely at MCP, because that’s what influences how you proceed. MCP is a shared standard that lets an agent reach tools, data, and actions across your systems without a hand-built connection for every pairing.

While it sounds like yet another API, it’s actually an interface layer. It doesn’t replace existing approaches like REST or GraphQL; it operates above them, allowing the APIs you already run to be wrapped as tools and join an agent workflow with no change to how they’re designed underneath.

An MCP server for enterprise exposes three kinds of capability, and every agent interaction is built from them:

• Tools: functions the agent calls to act (look up an order, create an invoice, or run a query), each with a name, a plain-language description, and an input and output schema.
• Resources: the data and context an agent reads rather than changes, from files to database contents to saved state.
• Prompts: reusable instructions that steer the agent toward the right approach for a given job.

One MCP server build can cover both local tools and cloud services because it uses JSON-RPC 2.0 over channels like standard I/O, HTTP, and WebSocket, and that uniformity is a strong driver of its rapid, widespread adoption.

Another reason is the efficiency it brings to integration, cutting the number of connections you have to build and keep running. If you want to give four agents access to a dozen tools, you’re looking at 48 point-to-point connections. But if you route them through MCP, the work shrinks to setting up four agent-to-protocol connections plus 12 tool-to-protocol ones, leaving you with 16 to maintain rather than 48.

These features also explain why MCP is invariably impressive in proof-of-concept demos. Hand an agent the docs, describe the one tool you want, and you can have a process answering over standard I/O the same afternoon.

A deployed enterprise server is another animal entirely, from the moment live users and real agents start acting on it. It becomes fixed infrastructure someone has to own, with monitoring, tuning, and support for internal teams and outside partners alike. If your custom-built MCP server fails, it disrupts agent access across the entire organization, and if it exposes data, you bear full responsibility.

The mission to build MCP servers for enterprise production succeeds or fails on how you answer four questions:

1. What do you expose, and what do you protect?
2. How do you authenticate the agents calling in?
3. How do you keep tool schemas from breaking the agents that use them?
4. Should you build from scratch at all?

Addressing each one gets tougher as you add more systems, more agents, and more users. Let’s address them in turn.

6 Considerations: Deciding What to Expose and What to Protect

Before you decide what your agent should do, it’s worth taking a step back and being intentional about what you allow it to access. The choices you make here will shape not just its usefulness, but also its reliability and risk profile. A smaller, well-structured set of capabilities often outperforms a sprawling one, especially when paired with careful sequencing, disciplined access control, and thoughtful use of the systems you already trust.

Here’s how to strike that balance without overcomplicating your design:

1. Scope: expose the minimum: This first choice is one teams often rush past. The usual instinct is to expose as much as possible, on the basis that more capability is always better. In practice, the opposite is true, because every tool you publish is one more thing the model can misfire on and one more attack surface to defend. So the best approach is to map the minimum set of actions the agent legitimately needs and stop there. Treat every exposed function as both a usability and a security decision.

2. Tool design and packaging: How you package those actions is as important as how many there are. Mirroring your API with one endpoint per tool floods the agent with fine-grained options and leaves it to its own devices to assemble them correctly. To avoid this, sort related steps into a few purposeful tools that each finish a meaningful unit of work, so the model has less to reason about and fewer opportunities to go wrong.

3. Sequencing and trust building: Begin in read-only mode: let the agent retrieve information, watch how it behaves, and let it earn trust before you grant any power to write or change state.

4. Access control and identity: Grant only the rights a task needs, and have the agent act with the calling user’s permissions rather than a broad service account’s. When it inherits the user’s identity, what it can access reflects who’s actually asking, and an agent working for a contractor doesn’t suddenly gain a full-time employee’s reach.

5. Schema and data design: Keep input and output schemas lean, with shallow structures and no heavy, irrelevant data an agent would only have to wade through.

6. Governance and API reuse: Wrap the APIs you already govern rather than routing around them, so your tools rest on the policy, authentication, and validation you’ve spent years putting in place instead of opening a side door past all of it.

Handling Authentication and Access at Scale

While MCP does a good job of connecting AI agents with external tools, databases, and other data sources, it isn’t built to do so safely.

A standard Model Context Protocol implementation still misses out on the mature security and governance of proven enterprise platforms, with many deployments relying on weak identity, static secrets, and limited authorization or isolation controls. A default MCP server build is an open port anything can reach, with no way to tell a real workflow from a rogue agent siphoning data. Without a dependable answer to who is calling, every other control you add is cosmetic.

The current MCP approach rests on OAuth 2.1 with PKCE and defers trust to an identity provider rather than baking custom logic into each server. That lets a service act on a user’s behalf without sharing a password, which is precisely what an agent invoking tools on their behalf needs.

If an agent calls a tool without valid credentials, the server answers with a 401 and attaches metadata telling the client which authorization server to use, which scopes to request, and what kind of token to bring back. The client runs the OAuth flow, generates a PKCE challenge, sends the user to the identity provider, and returns with an access token tailored for that specific server. The server checks the signature, the audience, the scopes, and the expiration before it lets anything through.

Tokens should be short-lived, logged, and scoped to one server with a defined set of actions via Resource Indicators. This prevents a token minted for one server from being replayed against another. And because the token carries the user’s identity, the agent accesses only what that user is allowed to reach.

The spec requires all of this of every individual server, and each needs to be correctly configured to return the right metadata, point at the correct authorization server, and advertise the proper scopes, every time.

Across dozens or hundreds of servers, many of them just wrapping existing APIs, that setup is repetitive, inconsistent, and easy to get wrong. The weakest server can quickly become a way in for bad actors.

The better pattern is a platform layer that acts as an authentication gateway, running the handshake once, attaching the right token, and forwarding the call, so policy stays consistent, logging and auditing appear in one place, and your server teams don’t have to become OAuth experts. It’s the same approach API gateways and service meshes already adopt for REST and gRPC.

How to Version Tool Schemas Without Breaking Agents

Agents don’t read your source code to use a tool; they make decisions based on the tool’s description and its input and output schema. Change that schema, and you can break the agent’s behavior without tripping an error and with no obvious trace, since a renamed parameter or a reshaped response can derail a workflow that ran fine last time.

The key is to treat schemas as moving targets from day one. Over its life, a tool will gain fields, rename parameters, and retire functions, and each shift echoes out to every agent that depends on it. The technique that governs this is called staleness tracking. When a connected server updates a tool, its description, or its parameters, the imported tools get flagged as out of date, so a human can review and accept the change before it reaches production.

That flagging only helps when it’s supported by real lifecycle governance: clear ownership of each tool, versioning, and a deprecation path. That way, builders always know which version to trust. Skip these steps, and schema drift turns into broken automations that are slow to diagnose, because the failure shows up as an agent behaving oddly, not as a stack trace on the line that changed.

Why an iPaaS Beats a Hand-Rolled Node.js Server

Once you stack up the design decisions around what to expose, how to authenticate, and how to version schemas, the case against hand-building your way to production is clear.

A custom Node.js server is quick to stand up and difficult to ever put down, and never stops being yours to support. Once it’s in production, you handle monitoring, scaling, patching, logging, and incident response on top of what the server does, so you’re not simply enabling AI anymore; you’re running a critical service with all the on-call weight that carries.

The cost of this burden escalates with each system you connect. Every time you add an integration, you’re introducing extra authentication models, permissions, quirks, and things that can break, plus the work of mapping access, handling errors, managing rate limits, and keeping everything auditable. What began as two systems grows into many, and the work mounts with each one rather than flattening out.

The most serious challenge is the security and governance layer, and you can’t retrofit it later. Role-based access control, audit trails, and single sign-on reach into authentication, permissions, logging, and data exposure all at once, so they have to be designed in from the start. And because MCP itself is still maturing, the ground keeps shifting, so a do-it-yourself build means tracking spec changes, retesting integrations, and reworking code just to stay compatible.

Set against those commitments, Integration Platform as a Service (iPaaS) makes Model Context Protocol implementation effortless.

An iPaaS solution lets you build on what you already have by:

• Reusing the APIs and integrations you’ve assembled, instead of rebuilding logic for every new AI use case.
• Inheriting the security and policy controls you already run, rather than reimplementing them server by server.
• Exposing tools without wrapping or translating what works today.

The iPaaS payoff shows up in where your engineers spend their hours: on the workflows and outcomes that push your business ahead rather than on the protocol infrastructure multiple other teams are also handling.

Let Boomi Handle the Hard Parts of MCP

Boomi brings Model Context Protocol implementation inside the platform your integration team already uses, so exposing tools to agents augments current work rather than becoming a standalone project.

The Boomi Enterprise Platform combines integration, API management, data management, and AI agent management in one place, and MCP draws on the identity, policy, and observability controls already on board.

Boomi handles the hard parts of every MCP server for enterprise by:

• Turning existing APIs into MCP tools through the API Control Plane: publish an API product, toggle “Expose as Tool,” add a description and any constraints, and Boomi parses the OpenAPI schema and registers it as an MCP-compliant tool, with no wrapper and no rebuild.
• Exposing integration processes as callable tools with the MCP Server Connector: add the connector at the start of a process, define the input and output the agent will use, and deploy, with the underlying queries, filters, and joins preserved. This connector is in Tech Preview today.
• Discovering, importing, and attaching tools in Agent Designer: point an MCP source at a server, test the connection, pull in the tools you want, and attach them to agent tasks. When a connected server’s schema changes, Agent Designer flags the affected tools as stale so builders can review the changes before agents rely on them.
• Governing connections with the MCP Registry and Server Catalog: platform admins keep a curated list of approved servers drawn from the official Anthropic registry and Boomi’s own, and selecting one pre-populates its connection details, which cuts manual setup and the misconfiguration that comes with it.
• Matching authentication to the caller: options span token, basic, Platform JWT, and OAuth 2.0/2.1, so an agent acts within each user’s real permissions, and every action it takes is logged.

Ready to let your AI agents work from the integrations you already trust, with your existing identity and policy controls doing the guarding? See how Boomi makes MCP enterprise-ready.