MCP for enterprises: how to design a private MCP server

MCP (Model Context Protocol) is an open protocol, published by Anthropic in late 2024 and since adopted by the main model providers and development tools, that standardises how an AI agent accesses external tools, data and capabilities. In an enterprise, MCP solves a very concrete problem: that every agent does not have to carry its own integration with every system.

The problem without MCP: one integration per agent

Without a shared layer, the typical architecture is: the customer-service agent has its Salesforce connector, the order agent has another, the sales copilot a third. Three integrations with the same system, three ways of authenticating, three places to review permissions and three points of failure when Salesforce changes. It is slow, expensive and hard to govern.

The proposal: Company Systems → Enterprise MCP Layer → authorised agents

With an enterprise MCP layer, each system is connected once and exposed as a set of capabilities with an explicit contract: "look up customer", "find order", "check availability", "create booking", "look up invoice", "update CRM". Agents, whether Twinny’s, corporate copilots or partner agents, invoke capabilities; they do not touch tables. It is the "connect once, use everywhere" principle.

How to design a private MCP server: six decisions

• Capabilities, not tables: model business verbs (find order) instead of exposing free queries over the database.
• A contract per capability: inputs, outputs, errors and side effects documented; a capability that writes is distinguished from one that only reads.
• Identity and scopes: each agent and, where applicable, each end user invokes with its own identity and a bounded scope (their orders, not other customers’).
• Human approval: critical actions (a refund, a cancellation) go through confirmation before executing.
• Flexible data origin: the capability can rest on the system’s API, on the already unified Company Memory or, in legacy systems without an API, on wrapped RPA or browser automation.
• Audit: every invocation is logged with who, what, when, with which data and with which result.

Example: MCP over Salesforce for a sales digital worker

A digital worker that qualifies leads needs four capabilities: find account and contact, look up open opportunities, create a follow-up task and update the lead status. They are exposed as four MCP tools with read-only scopes for the first two and bounded write scopes for the other two. The same server later serves the customer-service agent, which only gets permission on the two read capabilities. The Salesforce connection was built once.

Example: MCP over SAP with no API available

In many ERPs the operation needed is not exposed or API access is not authorised. The "look up order status" capability is then implemented with RPA over the SAP interface, wrapped exactly as if it were an API call. The agent does not notice the difference, and when the API is enabled later on, the capability is reimplemented inside without touching the agents.

An enterprise MCP does not expose databases: it exposes controlled capabilities.

Where MCP fits in the AI Operating Layer

MCP is the interface between the company’s systems and data (including the Company Memory) and the agents that execute. Above it, the Agent Gateway applies identity, permissions, limits and audit to authorised external agents too. Below it, the Data Lake and the Company Memory guarantee that capabilities return the right context. It is the piece that makes Twinny infrastructure rather than a closed ecosystem.