MCP Server for Enterprise Source Systems — Closing the 100-System Connector Gap

The connector gap is real. 100 European industrial systems, and every single one is missing.

Microsoft 365 Copilot lists over 100 connectors. Claude's Connectors Directory lists around 440 curated and roughly 2,500 including community. Both catalogues cover Salesforce, ServiceNow, Jira, Confluence, Box, SharePoint, Zendesk — the familiar SaaS world. Neither catalogue lists a single one of the niche ERP, MES, PLM, CAQ or EAM systems that European manufacturers and energy utilities actually run their operations on.

That is a 100-system connector gap, verified through web research in September 2026 across the DACH region, France, the UK, the Nordics and Benelux. The systems exist, they have APIs — and no AI platform has built a connector for them.

Why the gap exists — and why it is not accidental

The gap is structural, not a vendor oversight. On-premise ERP systems from proALPHA, Abacus, BMD, Divalto or Sylob — each serving thousands of industrial companies — do not fit the SaaS connector model. They run inside the customer's data centre, have custom permission models, and their API documentation lives behind partner logins. A connector marketplace needs standardised cloud APIs, and these systems do not offer them.

The manufacturers themselves lack the team to build one. A company with 200 employees and a specialist ERP product has no AI platform team. Their customers, meanwhile, are asking the question that matters: 'Can I connect this to Claude?' — and the answer today is no.

On-premise systems from manufacturers without an AI team, without a cloud product, without a connector catalogue. Write-capable, role-based, under a maintenance contract — not a read-only community experiment. Pexon builds and operates MCP servers for source systems whose vendors will never build one.

What an MCP server for a source system actually does

An MCP server is not an ERP adapter. It is a thin service that exposes a named tool list — search orders, get batch record, check stock — each with a typed schema and a documented result. The LLM calls those tools through the Model Context Protocol, and the server executes them against the source system using its existing API.

The critical detail is that the user authenticates with their own source-system credentials and permissions. A query returns exactly what that person could already read in the source system — no more, no less. This is what makes an MCP server deployable in a regulated environment, and it is the part most community builds skip.

An MCP server exposes a tool list, not a database

The server publishes typed operations; the LLM calls them through the protocol.

// MCP server tool definition for an ERP system
{
  "name": "get_order",
  "description": "Retrieve an order by ID with line items and status",
  "inputSchema": {
    "type": "object",
    "properties": {
      "orderId": { "type": "string", "description": "ERP order number" },
      "includeItems": { "type": "boolean", "default": true }
    },
    "required": ["orderId"]
  }
}

// The server authenticates the user, not itself
// User's credentials → source system's permissions → filtered results

Three layers that make the position work

The product has three layers, and each is necessary to survive a security review.

• The tool list — a small, explicit set of named operations per system. Reviewable by someone who does not read code, which is what makes approval possible without a security audit per tool.
• The permission model — the end user's source-system identity carried through to every query. Not a service account, not all-or-nothing access.
• The operations contract — monitoring, alerts, upgrades and a runbook. The server is operated, not just built. This is the difference between a prototype and a production system.

The question every IT security team asks — 'who sees what' — has exactly one answer at the protocol level. Carrying the user's existing permissions through to the source system. Any other answer stops the project.

Build on the foundation

• MCP server development for Claude — How Pexon builds MCP servers that carry the user's identity through to the source system.
• SAP data layer for AI — One governed semantic layer over SAP, with authorisations carried into the retrieval layer.
• Permission-aware retrieval — Why access control has to happen before generation, not after it.