MCP for Enterprise: The Complete Guide to Agent Infrastructure

Every enterprise AI project hits the same wall. The model can reason. It can draft emails, analyze data, summarize documents. But it can’t do anything in your actual systems. It can’t update a CRM record, process an invoice, route a support ticket, or query your production database. The gap between “AI that thinks” and “AI that acts” is the integration layer. And until recently, that layer was a mess of custom code, fragile API wrappers, and months of engineering work for every new connection.

The Model Context Protocol (MCP) closes that gap. It is the standard protocol for connecting AI agents to enterprise tools and systems, a universal interface that replaces the bespoke integration code that makes every AI project take longer than it should. NimbleBrain has built 21+ production MCP servers, launched mpak.dev as the open registry for discovering and distributing them, and authored the MCP Trust Framework for enterprise security. This guide covers everything a technical leader needs to evaluate, adopt, and deploy MCP infrastructure.

1. What MCP Is and Why It Matters

The simplest way to understand MCP: it’s USB for AI.

Before USB, every peripheral needed a custom driver. Printers, scanners, keyboards, mice. Each device had its own proprietary connection, its own installation process, its own set of compatibility issues. When USB arrived, it didn’t make peripherals better. It made connecting them trivially easy. One port. One protocol. Any device.

MCP does the same thing for AI agents. Before MCP, every AI integration needed custom code. Connecting an agent to Salesforce required building a Salesforce integration. Connecting it to Slack required a separate Slack integration. Connecting it to a PostgreSQL database required yet another custom adapter. Each integration was its own engineering project, authentication, error handling, data formatting, maintenance. Ten integrations meant ten projects.

MCP standardizes the connection between agents and tools. An MCP server exposes a set of tools: structured capabilities that agents can discover, understand, and invoke. A CRM server might expose tools like search_contacts, create_deal, update_record. A database server might expose query, list_tables, describe_schema. The agent connects to the server, discovers what tools are available, reads their descriptions, and uses them as needed.

Three properties make MCP fundamentally different from previous integration approaches.

Persistent connections. REST APIs are stateless. Every request starts from zero. MCP maintains a persistent connection between the agent and the server. The agent connects once and maintains access to all tools for the duration of the session. No reconnecting. No re-authenticating. No re-discovering capabilities on every call.

Runtime tool discovery. With REST, you need to read API documentation, understand the endpoints, and hardcode the integration. With MCP, the agent discovers available tools at runtime. Connect to a server, call list_tools, and the server tells you everything it can do, with structured descriptions that agents can interpret without human intervention. This is how agents scale to dozens of integrations without drowning in configuration.

Structured capability descriptions. Every MCP tool comes with a machine-readable description: what it does, what inputs it accepts, what outputs it returns. These descriptions are not just documentation. They are the interface contract. An agent reads the tool description, constructs the right input, invokes the tool, and processes the structured result. No parsing HTML. No scraping API responses. No guessing at data formats.

The practical impact is dramatic. An integration that took weeks of custom engineering now takes hours. Not because the underlying APIs changed. Salesforce’s REST API is still there. But because the MCP server wraps that API in a standardized interface that any agent can use immediately. The integration work shifts from “build a custom adapter from scratch” to “connect to a pre-built server.”

This is the architecture shift that makes production AI practical. Agents need tool access the way employees need system access. MCP makes that access standardized, discoverable, and manageable, not a custom engineering project for every system you touch.

2. MCP vs. REST: The Architecture Shift

The difference between MCP and REST is not incremental. It’s structural. Understanding why matters for making the right infrastructure decisions.

Consider a concrete example: connecting an AI agent to your CRM to qualify leads.

The REST approach. Your engineering team reads the CRM’s API documentation. They write authentication code (OAuth token management, refresh logic, error handling). They build functions for each endpoint they need, search contacts, get deal history, update lead status. They write data transformation code to convert API responses into formats the agent can process. They handle pagination, rate limiting, and API versioning. When the CRM vendor updates their API, they update the integration. Total: 2-3 weeks of engineering for one system. Multiply by every system the agent needs.

The MCP approach. You install an MCP server for your CRM from mpak.dev. You configure authentication credentials. The agent connects to the server, discovers tools like search_contacts, get_deal_pipeline, and update_lead_score, reads their structured descriptions, and starts using them. Total: hours, not weeks.

The deeper difference is in how agents interact with these systems over time.

REST is endpoint-specific. The developer decides which endpoints the agent needs, builds integrations for those specific endpoints, and the agent uses exactly what was built. If the agent needs a capability that wasn’t anticipated, say, accessing a custom field that was added to the CRM last week, someone has to update the integration code.

MCP is capability-driven. The server exposes whatever tools it has. When the server gets updated to support new features, the agent discovers them automatically on the next connection. No code changes on the agent side. No deployment. The server exposes the new tool, and the agent can use it.

REST is stateless. Every API call is independent. If the agent needs to search for a contact, then update that contact’s record, it makes two completely separate HTTP requests. The second request has no awareness of the first. Context lives entirely in the agent’s code.

MCP is session-aware. The persistent connection means the server can maintain state across tool invocations within a session. A CRM server can track which records have been accessed, maintain cursor positions for paginated searches, and provide contextually relevant tool suggestions based on what the agent has done so far.

This is not an argument that REST is bad. REST served the industry well for twenty-five years. But REST was designed for a world where software talked to other software in discrete request-response cycles triggered by human actions. Click a button, call an API, render the response. AI agents don’t work that way. They operate in continuous loops, reasoning about what to do, selecting tools, invoking them, processing results, reasoning again. That workflow maps to persistent connections and runtime discovery, not to stateless request-response.

The migration from REST to MCP is not a rewrite. MCP servers wrap existing REST APIs. The Salesforce MCP server still calls Salesforce’s REST API under the hood. But the interface the agent sees is standardized, discoverable, and designed for how agents actually operate.

3. Enterprise Security: The MCP Trust Framework

Here is the biggest enterprise concern with MCP, and it’s legitimate: the protocol has no built-in security model.

MCP defines how agents connect to servers and invoke tools. It does not define how agents authenticate, what they’re authorized to do, how data should be encrypted, or how to verify that a server is trustworthy. Out of the box, an MCP connection is a trust-everything model. The agent trusts the server. The server trusts the agent. There’s no verification, no access control, no audit trail.

For a developer running an MCP server locally to test a personal project, this is fine. For an enterprise connecting AI agents to production CRM data, financial systems, and customer records, it’s a non-starter.

This is why NimbleBrain created the MCP Trust Framework (MTF), an open security standard for evaluating and certifying MCP servers across five domains.

Domain 1: Authentication. How does an agent prove its identity to an MCP server? The MTF defines requirements for authentication mechanisms: API keys for simple deployments, OAuth for delegated access, and mutual TLS (mTLS) for zero-trust environments. Each mechanism is scored based on strength, key rotation support, and credential management. A server that accepts unauthenticated connections scores zero. A server that supports mTLS with automatic certificate rotation scores highest.

Domain 2: Authorization. Authentication proves who the agent is. Authorization defines what it can do. The MTF specifies per-tool permission models, an agent might have access to search_contacts but not delete_contact. It covers data scope restrictions, an agent can read records from its own department but not from finance. And it defines human-in-the-loop approval workflows, certain actions (financial transactions above a threshold, customer data exports, configuration changes) require human sign-off before execution.

Domain 3: Data Handling. How does the server handle the data that flows through it? The MTF evaluates encryption in transit (TLS 1.3 minimum), encryption at rest for any cached data, data minimization (the server shouldn’t store data it doesn’t need), and retention policies (cached data gets purged on a defined schedule). For regulated industries, this domain also covers data residency, can you prove the data stays in a specific geographic region?

Domain 4: Supply Chain Integrity. Where did this MCP server come from, and can you trust it? The MTF evaluates source code availability (open-source vs. proprietary), dependency scanning (are there known vulnerabilities in the server’s dependencies?), build provenance (can you verify the binary matches the source code?), and publisher verification (is the entity publishing the server who they claim to be?). This domain exists because MCP servers are code that runs on your infrastructure and touches your data. You need to vet them like any other software supply chain component.

Domain 5: Runtime Security. How does the server behave while it’s running? The MTF evaluates monitoring and logging (every tool invocation should be logged), rate limiting (prevent runaway agents from hammering systems), resource sandboxing (servers shouldn’t have access to resources beyond their scope), and anomaly detection (flag unusual invocation patterns). Runtime security is the layer that catches problems in production, a compromised server, a malfunctioning agent, an unexpected data access pattern.

Each domain produces a score. The composite is the server’s MTF trust score, a single number that tells you how safe the server is for enterprise deployment. These scores are integrated into mpak.dev, so when you search for an MCP server, you can see its security posture alongside its functionality.

The MTF is not a certification that lives in a PDF. It’s automated scanning built into the mpak registry. When a server is published to mpak, it undergoes automated security analysis against all five domains. The results are visible to anyone evaluating the server. This is the difference between “we reviewed this server’s security” and “here’s the auditable evidence of its security posture.”

4. The MCP Server Ecosystem

The practical value of MCP depends on what servers are available. A protocol is only as useful as the tools built on it.

The ecosystem today covers the major categories enterprise teams need.

CRM and sales. Servers for Salesforce, HubSpot, and other CRM platforms. These expose tools for contact management, deal pipeline operations, activity logging, and report generation. An agent connected to a CRM server can search for contacts by any field, create and update deals, log emails and calls, and pull pipeline metrics, all through structured tool invocations.

Productivity and communication. Servers for Slack, Google Workspace, Microsoft 365, and calendar systems. These let agents send messages, search conversation history, create documents, manage calendar events, and process email. The communication servers are typically among the first enterprise teams deploy because they connect agents to the tools people use every day.

Databases. PostgreSQL, MySQL, and other database servers that expose query tools, schema introspection, and data management capabilities. A database server lets an agent query your data directly. No intermediate API layer, no data export. The agent describes what it needs, the server translates that into a query, and the structured results come back.

Developer tools. Servers for GitHub, Jira, Linear, and CI/CD systems. These connect agents to engineering workflows, issue management, code review, deployment pipelines, and project tracking.

Custom integrations. For internal systems, proprietary databases, and domain-specific tools that don’t have pre-built servers. Building a custom MCP server is typically a 1-2 day effort (covered in Section 8).

mpak.dev is the registry for finding, evaluating, and installing MCP servers. Think of it as npm for MCP, a searchable catalog where every server has a trust score (from the MTF scanning), source code links, installation instructions, and documentation. The registry is open-source. Any publisher can submit a server. Every submitted server undergoes automated security analysis.

When evaluating a server from the registry, follow this process.

Check the MTF score. The trust score tells you the server’s security posture across all five MTF domains. A server with a high score has been vetted for authentication, authorization, data handling, supply chain integrity, and runtime security. A low score means gaps that you’ll need to address.

Review the source. Every server on mpak is open-source. Read the code. Verify that the server does what it claims and nothing more. Look at how it handles credentials, what data it caches, and what external calls it makes.

Test in a sandbox. Install the server locally, connect it to a test environment (never production on first run), and exercise its tools. Verify that tool descriptions are accurate, error handling is graceful, and the server doesn’t leak data or credentials in its outputs. Stdout must be clean JSON-RPC only, any server that leaks debug information, banners, or logs to stdout is a red flag.

Check the dependency tree. Use the MTF supply chain analysis to review the server’s dependencies. A server with pinned, scanned, known dependencies is safer than one pulling latest from public registries.

NimbleBrain maintains 21+ production MCP servers. All are published on mpak.dev. All have undergone MTF scanning. All run in production client environments daily. This is not a theoretical registry with untested entries. It’s a curated set of servers backed by the team that built the protocol tooling.

5. Deployment Patterns

How you deploy MCP infrastructure depends on your regulatory environment, security requirements, and operational capacity. Three models cover the range.

Self-Hosted

MCP servers run on your infrastructure. Kubernetes clusters, Docker hosts, or bare metal. You control everything: the network, the compute, the data, the access.

When to use it. Regulated industries (finance, healthcare, defense) where data residency is non-negotiable. Organizations with strict air-gap requirements. Environments where compliance mandates that no data leaves the corporate network.

Architecture. MCP servers deploy as containers in your Kubernetes cluster. Each server gets its own pod with defined resource limits (CPU, memory, network). A service mesh (Istio, Linkerd) handles mTLS between the agent runtime and MCP servers. Secrets (API keys, OAuth tokens) live in your vault (HashiCorp Vault, AWS Secrets Manager, Kubernetes Secrets with envelope encryption).

Operational requirements. Your team manages deployment, scaling, monitoring, and upgrades for every MCP server. This means maintaining container images, running health checks, handling version upgrades, and managing the lifecycle of 10-30+ server instances. The operational burden is real but manageable for teams with existing Kubernetes experience.

Scaling. Horizontal pod autoscaling based on connection count or tool invocation rate. Most MCP servers are lightweight, a single pod handles hundreds of concurrent connections. Scaling is rarely the bottleneck.

Managed

NimbleBrain-hosted MCP infrastructure with SLAs. Your agents connect to managed MCP servers over encrypted channels. The data still flows through your systems (MCP servers call your APIs), but the server lifecycle is our responsibility.

When to use it. Teams that want to move fast without building operational capacity for MCP infrastructure. Organizations where the ops team is already stretched. Early-stage MCP adoption where proving value matters more than controlling every layer.

Architecture. Managed MCP servers run in NimbleBrain’s infrastructure with dedicated tenancy. Connections are encrypted end-to-end. Your agents connect over mTLS. Your credentials for downstream systems (CRM API keys, database passwords) are stored in your vault and passed to the managed servers at connection time. They never persist in our environment.

Operational requirements. Minimal. You configure which servers you need, provide credentials for your downstream systems, and connect your agents. We handle deployment, scaling, monitoring, upgrades, and incident response.

Hybrid

The model most enterprise teams converge on after initial adoption. Critical servers (database access, financial systems, anything touching PII) run self-hosted. Commodity servers (Slack, calendar, project management) run managed.

Decision framework. Does this server touch regulated data? Self-host. Does this server access systems with strict compliance requirements? Self-host. Is this server connecting to a SaaS tool where the data is already in a third-party cloud? Managed is fine, the data residency ship already sailed.

Architecture. Your agent runtime connects to both self-hosted servers (in your cluster) and managed servers (in NimbleBrain’s infrastructure). A unified configuration layer handles routing, the agent doesn’t need to know which servers are self-hosted and which are managed. The connection protocol is the same either way.

Regardless of deployment model, the MCP Trust Framework security requirements apply. Self-hosted doesn’t mean less secure. Managed doesn’t mean more risky. The MTF evaluates the server’s security properties independent of where it runs.

6. Authentication and Authorization

The security model for MCP in enterprise environments has two layers: proving identity (authentication) and defining permissions (authorization). Getting both right is the difference between “MCP is ready for production” and “MCP is a security incident waiting to happen.”

Authentication

Three mechanisms, each for a different context.

API keys. The simplest approach. Each agent gets a unique key that it presents when connecting to an MCP server. The server validates the key against a registry. Good for internal deployments where agents are trusted and the network is controlled. Limitations: keys don’t expire automatically, rotation is manual, and a leaked key grants full access until revoked. Use API keys for development and testing. For production, use one of the next two.

OAuth 2.0. The agent authenticates through your identity provider (Okta, Azure AD, Auth0) and receives a scoped token with defined permissions and expiration. The MCP server validates the token on each connection. OAuth provides scoped access (the token defines what the agent can do), automatic expiration (tokens expire and must be refreshed), and centralized revocation (disable an agent’s access from your identity provider). This is the production standard for most enterprise deployments.

Mutual TLS (mTLS). Both the agent and the server present certificates, and each validates the other’s identity. This is zero-trust authentication, neither party trusts the other without cryptographic proof. Required for air-gapped environments, defense applications, and any deployment where network-level security isn’t sufficient. mTLS adds operational complexity (certificate management, rotation, revocation lists) but provides the strongest identity assurance.

Authorization

Authentication gets the agent in the door. Authorization defines which rooms it can enter.

Per-tool permissions. The most granular level. An agent might have permission to invoke search_contacts and get_deal but not delete_contact or export_all_data. Per-tool permissions are defined in a policy file that maps agent identities to allowed tools. When the agent tries to invoke a restricted tool, the server returns an authorization error.

Data scope restrictions. Even when an agent has permission to use a tool, the data it can access through that tool may be limited. A regional sales agent can search contacts in its territory but not other regions. A department-level agent can query its own cost center but not the company-wide financial data. Data scopes are enforced at the server level, the agent sends a query, and the server applies scope filters before returning results.

Human-in-the-loop approval. For high-stakes actions, no amount of automated authorization is sufficient. The system needs a human checkpoint. Financial transactions above a defined threshold. Customer data exports. Configuration changes to production systems. Termination of service agreements. The approval flow works like this: the agent invokes the tool, the server pauses execution, a notification goes to the designated approver, and the tool completes only after human approval. Denied actions get logged with the reason.

Audit Trails

Every tool invocation in a production MCP environment gets logged. The audit record captures: which agent invoked the tool, which tool was invoked, what inputs were provided, what outputs were returned, when the invocation occurred, and whether it succeeded or failed. For actions that went through human-in-the-loop approval, the record also captures who approved and when.

These audit trails serve multiple purposes. Compliance teams use them to demonstrate that AI agents operate within defined boundaries. Security teams use them to detect anomalous patterns. Operations teams use them to debug issues and optimize performance. And when someone asks “what did the AI do and why?”, the answer is in the audit log, not reconstructed from memory.

Store audit logs in an append-only system (like an immutable object store or a write-ahead log) that agents cannot modify or delete. This is a compliance requirement for SOC 2, ISO 27001, and most enterprise security frameworks.

7. Migration from REST

If you have existing REST-based integrations (and every enterprise does) the path to MCP is additive, not destructive. You don’t rip out working APIs. You wrap them.

The Wrapper Pattern

An MCP server is, architecturally, a translation layer. It receives tool invocations over the MCP protocol and translates them into API calls against the underlying system. A Salesforce MCP server receives search_contacts(query="acme") and translates it into GET /services/data/v59.0/query?q=SELECT+Id,Name+FROM+Contact+WHERE+Account.Name+LIKE+'%25acme%25'. The REST API doesn’t change. The MCP server adds a layer on top that makes it agent-accessible.

This is why migration is measured in days, not months. The underlying systems and APIs remain exactly as they are. The MCP server is new code, but it’s a thin translation layer, not a reimplementation.

The Migration Sequence

Step 1: Inventory your integrations. List every system your AI agents need to touch. For each, note: the system name, the API type (REST, GraphQL, gRPC, database), the operations agents need (read, write, both), and the authentication mechanism. This inventory is your migration roadmap.

Step 2: Check the registry first. Search mpak.dev for each system on your list. If a pre-built MCP server exists with an acceptable MTF trust score, install it. Don’t build what you can reuse. For the 21+ servers NimbleBrain maintains, this step is complete, install, configure credentials, connect.

Step 3: Build servers for the gaps. For systems without pre-built servers (typically internal tools, legacy systems, and custom databases), build custom MCP servers. Section 8 covers how. A typical REST-to-MCP wrapper server takes 1-2 days to build and test.

Step 4: Run parallel. Don’t cut over from REST to MCP in one shot. Run both paths simultaneously. The MCP server wraps the same REST API, so the data source is identical. Compare results between the legacy integration and the MCP path to verify correctness. Once you’re confident the MCP path produces identical outcomes, decommission the legacy integration code.

Step 5: Expand. Each successful migration builds confidence and pattern knowledge. The first server takes 2 days. The second takes 1 day. By the fifth, your team has a template and the work is routine. Most enterprise teams complete a 10-system migration in 2-3 weeks.

What Not to Migrate

Not every REST API needs an MCP server. Internal service-to-service communication (microservice mesh traffic) stays REST. Webhook endpoints that receive inbound data stay REST. High-frequency data streams (real-time market data, IoT telemetry) are better served by purpose-built streaming protocols. MCP is for agent-to-tool communication, systems that agents need to discover, reason about, and invoke. If no agent is interacting with the system, there’s no reason to wrap it.

8. Building Custom MCP Servers

Pre-built servers cover the major SaaS platforms and common tools. But every enterprise has internal systems, proprietary databases, and domain-specific applications that need custom servers. Building one is straightforward.

Language Choice

Python (FastMCP). The fastest path for most teams. FastMCP provides decorators that turn Python functions into MCP tools with zero boilerplate. If your team writes Python and the underlying system has a Python client library, choose this.

from fastmcp import FastMCP

mcp = FastMCP("inventory-system")

@mcp.tool()
def check_stock(sku: str, warehouse: str) -> dict:
    """Check available stock for a SKU at a specific warehouse.

    Args:
        sku: The product SKU to check
        warehouse: Warehouse code (e.g., 'US-WEST-1', 'EU-CENTRAL')
    """
    # Call your internal inventory API
    result = inventory_client.get_stock(sku=sku, location=warehouse)
    return {
        "sku": sku,
        "warehouse": warehouse,
        "available": result.quantity,
        "reserved": result.reserved,
        "last_updated": result.timestamp.isoformat()
    }

if __name__ == "__main__":
    mcp.run()

TypeScript (MCP SDK). For teams with a Node.js stack or when the underlying system provides a TypeScript client. The MCP SDK provides the same structured approach, define tools, implement handlers, export the server.

Architecture Rules

One server per system. Don’t build a mega-server that connects to five different systems. Each MCP server should own one integration domain: one for the inventory system, one for the billing system, one for the employee directory. This keeps servers focused, testable, and independently deployable.

Clean stdout. MCP communicates over JSON-RPC on stdout. Any log messages, debug output, banners, or print statements that leak to stdout will break the protocol. Route all non-protocol output to stderr. This is the most common mistake in new MCP server development and the easiest to prevent.

Thorough tool descriptions. The agent reads your tool descriptions to decide which tool to use and how to invoke it. A description that says “searches contacts” is inadequate. A description that says “Search the CRM for contacts matching a query string. Searches across name, email, company, and phone fields. Returns up to 50 results per page. Use the cursor parameter for pagination” gives the agent everything it needs.

Input validation. Validate all inputs before making downstream API calls. An agent might send malformed data, unexpected types, or values outside acceptable ranges. The server should catch these and return structured error responses, not crash, not pass garbage to the downstream system.

Error handling. Return structured errors that agents can understand and act on. “Authentication failed, token expired” tells the agent to refresh its credentials. “Rate limit exceeded, retry after 30 seconds” tells the agent to wait. “Contact not found” tells the agent the query returned no results. “Internal server error” tells the agent nothing useful.

Packaging with mcpb

The mcpb (MCP Bundle) format is the standard for packaging and distributing MCP servers. A bundle contains the server code, its dependencies, a manifest describing the server’s capabilities, and metadata for the registry.

For Python servers, the bundle uses module execution:

{
  "mcp_config": {
    "command": "python",
    "args": ["-m", "inventory_system.server"]
  }
}

Bundle your server, publish it to your internal registry (or to mpak.dev if it’s useful to others), and any agent can install and connect to it with a single command. The bundle format handles dependency management, version pinning, and environment setup, the user doesn’t need to know Python or Node.js to install and run the server.

9. Governance and Monitoring

Running MCP infrastructure in production is an operational discipline, not a one-time setup. The tools are deployed. The agents are connected. Now you need to keep the system healthy, compliant, and improving.

Monitoring

Tool invocation metrics. Track invocation count, success rate, error rate, and latency for every tool on every server. These are your operational health indicators. A sudden spike in error rate on the CRM server might mean an API key expired. A gradual increase in latency might mean the downstream system is under load. A drop in invocation count might mean the agent’s routing logic changed.

Cost tracking. Many downstream systems charge per API call. The MCP server wraps those calls, but the costs still accrue. Track the cost per tool invocation and the total cost per server per day. This prevents surprise bills and enables cost-per-automation metrics that justify the infrastructure investment.

Agent behavior monitoring. Beyond server health, monitor how agents use the tools. Which tools does each agent invoke most frequently? Are there tools that agents repeatedly invoke and fail on? Are there agents making unusual tool combinations that might indicate a reasoning error? Agent behavior monitoring catches problems that server metrics alone miss.

Governance Policies

Tool access policies. Define which agents can access which tools, reviewed and updated quarterly. A tool access policy is a mapping from agent identity to permitted tools, enforced at the server level. New agents start with minimal permissions and expand based on demonstrated need. This is the principle of least privilege applied to AI agents.

Approval workflows. For sensitive operations, define approval chains: who can approve, how fast do they need to respond, and what happens if they don’t. Approval workflows should have timeouts. If no human responds within the defined window, the action is denied by default. Never auto-approve on timeout.

Compliance reporting. Monthly reports that summarize: total tool invocations by agent and server, actions that went through human-in-the-loop approval (and the approval/denial ratio), security events (authentication failures, authorization denials, anomaly detections), and data access patterns (what data was accessed, by which agents, for what purpose). These reports serve audit requirements for SOC 2, ISO 27001, GDPR, HIPAA, and industry-specific frameworks.

Incident Response

Server failure. When an MCP server goes down, agents that depend on it need a degradation path. Options: queue the work and retry when the server recovers. Escalate to a human with the context of what the agent was trying to do. Fall back to a secondary server (if available). Never silently fail. Every failed invocation should be logged and visible.

Agent misbehavior. An agent invoking tools in unexpected patterns, at unusual rates, or on data outside its normal scope triggers an investigation. The monitoring layer flags the anomaly. The governance policy defines the response: alert the operations team, throttle the agent’s access, or suspend the agent pending review. Automated circuit breakers prevent a malfunctioning agent from causing damage while the team investigates.

Security events. Authentication failures, authorization denials, and data access anomalies trigger the security incident response process. The MTF runtime security domain defines the detection and response expectations. At minimum: log the event, notify the security team, and restrict the involved agent’s access until the event is cleared.

Compliance Alignment

MCP infrastructure can satisfy the technical controls required by major compliance frameworks, but only if governance is built in from the start, not bolted on after deployment.

SOC 2. The audit trail requirements (Section 6) directly satisfy SOC 2’s logging and monitoring controls. Tool access policies satisfy access control requirements. The MTF’s data handling domain satisfies data protection controls.

ISO 27001. The MTF maps to ISO 27001’s information security controls. Authentication and authorization (Section 6) map to access management. Monitoring and incident response satisfy operational security requirements. Supply chain integrity (MTF Domain 4) maps to supplier relationship security.

GDPR. Data minimization requirements in the MTF align with GDPR’s data minimization principle. Data residency controls (self-hosted deployment) satisfy requirements for data not leaving specific jurisdictions. The right to erasure requires that MCP servers and their audit logs can purge PII on request, build this capability from day one.

10. Getting Started: A 90-Day Adoption Plan

Here is a practical path from “we’re evaluating MCP” to “MCP is part of our production infrastructure.” Three phases, each building on the last.

Days 1-30: Evaluate and Prove

Week 1: Inventory. List every system your AI agents interact with or need to interact with. For each, document the current integration approach (custom code, REST API wrapper, direct database connection, manual process). Identify the top 3-5 highest-impact integration gaps, the systems where agents are blocked today.

Week 2: Install and test. Go to mpak.dev. Search for servers that match your top integration gaps. Install one server, the one that matches your most painful integration gap. Connect it to a development agent in a sandbox environment. Run it through real scenarios. Evaluate: does it work? Does it cover the operations you need? What’s its MTF trust score?

Weeks 3-4: Security assessment. Evaluate the MCP Trust Framework against your organization’s security requirements. Map MTF domains to your compliance framework. Identify gaps between what the server provides and what your security posture requires. This assessment produces your MCP security policy, the set of requirements every MCP server must meet before connecting to production systems.

Days 31-60: Pilot with Governance

Deploy 3-5 MCP servers to a staging environment with the governance layer in place from day one. Authentication, authorization, audit logging, monitoring, all active before the first agent connects.

Connect production agents to the staging MCP infrastructure. Run real workflows through the MCP path alongside existing integration paths. Compare results. Measure latency, reliability, and agent accuracy.

Build one custom MCP server for an internal system that doesn’t have a pre-built server. This builds internal capability and validates that your team can extend the infrastructure independently.

Days 61-90: Production and Scale

Promote to production. Move validated MCP servers from staging to production. Cut over agent integrations from legacy paths to MCP paths. Decommission legacy integration code as confidence builds.

Expand server coverage. Add MCP servers for the next tier of integrations, the systems that weren’t critical enough for the pilot but would benefit from standardized access.

Establish operational rhythm. Weekly monitoring reviews. Monthly compliance reports. Quarterly security re-assessments. Continuous skill and schema refinement as agents discover new patterns through MCP tool usage.

At the end of 90 days, you have production MCP infrastructure with governance, a team that can build and deploy custom servers, and a clear path to expanding coverage across your tool environment.

Accelerating the Timeline

NimbleBrain’s 4-week sprint includes full MCP infrastructure setup, server deployment, security configuration, governance, monitoring, and knowledge transfer. If 90 days is too slow, the sprint compresses the evaluation, pilot, and production phases into four weeks with an embedded team. At the end, you own everything: the servers, the configuration, the governance policies, the monitoring, and the knowledge to operate and extend it independently. That’s The Embed Model, embed, build, transfer, leave.

Or start on your own. Browse mpak.dev. Install a server. Connect an agent. See what’s possible when integration isn’t the bottleneck.

The tools are open-source. The registry is free. The trust framework is published. Everything you need to evaluate MCP for your enterprise is available today. The question isn’t whether MCP is ready. It’s whether you’re ready to stop building custom integration code for every system your agents need to touch.