MCP Connectors Explained: How to Connect AI Agents to ERP, CRM and SharePoint in 2026

An AI agent is only as useful as the systems it can reach. The smartest model in the world is worthless to your business if it cannot see your CRM, read a contract in SharePoint, or post an invoice to your ERP. For two years the answer was a pile of custom integrations, each one built for a single tool and a single AI, each one breaking when an API changed. The Model Context Protocol was designed to end that. By 2026 it has, and the connector landscape is real enough to plan around.

MCP is the open standard Anthropic released in November 2024 and then handed to the Linux Foundation in 2025^1,2. People call it the “USB-C of AI integrations” because it does exactly what USB-C did for cables: replace a drawer full of incompatible connectors with one shape that fits everything. Build one MCP server for a system, and any protocol-aware AI can use it. By March 2026, the MCP SDKs were being downloaded 97 million times a month, and more than 10,000 public MCP servers were live⁶.

This guide is for the CTO, IT lead, or Geschaeftsfuehrer at a German SME who keeps hearing “just connect it with MCP” and wants to know what actually exists, what is safe, and where the real work is. No hype. An honest map of the 2026 connector landscape, the vendors that shipped, the gaps middleware still fills, and how to connect an AI employee to the systems you already run.

What MCP Actually Is (and What It Is Not)

The term gets used loosely, so let us be precise. The Model Context Protocol is a shared language between an AI agent and the tools it uses. An MCP server describes a system as a set of callable tools, each with a name, a description, an input schema, and a permission scope. The AI reads those descriptions and decides which tool to call to finish a task. The protocol handles the handshake, the request, and the response.

• An open standard, not a product - Anthropic published MCP in November 2024 and contributed it to the Linux Foundation’s new Agentic AI Foundation in 2025, alongside the goose agent and the AGENTS.md convention^2,4. No single vendor owns it.
• A wrapper over your existing API, not a replacement - Most enterprise MCP servers sit on top of the system’s REST API. The Sage Intacct server, for example, is built on Sage’s existing REST APIs and simply presents them as agent-ready tools¹⁴.
• Client and server, like the web - The AI application is the MCP client. The connector is the MCP server. One client can talk to many servers, and one server can serve many clients. That is why a single HubSpot server works for Claude, ChatGPT, and Copilot alike.
• Tools, resources, and prompts - A server can expose actions the agent takes (tools), data it reads (resources), and reusable instructions (prompts). For business use, tools and resources are what matter.
• Model-agnostic by design - Because the protocol is standard, you are not locked to one AI vendor. Swap the model underneath and your connectors keep working. This is the same argument behind a model-agnostic Company Brain.

MCP is not an API, an iPaaS, or an agent

The clearest way to understand MCP is to separate it from the three things people confuse it with.

Why Connectors Matter Now

The shift from chatbots to agents that take real actions is what turned connectors from a nice-to-have into the whole game. An agent that cannot reach your systems can only talk. An agent with connectors can work.

1. Agents moved from talk to action - Gartner projects that 40 percent of enterprise applications will feature task-specific AI agents by the end of 2026, up from less than 5 percent in 2025²⁵. Those agents need to read and write across CRM, ERP, and ticketing to finish work.
2. The standard won fast - MCP SDK downloads hit 97 million a month by March 2026, a jump of nearly three orders of magnitude in 18 months, and roughly 28 percent of Fortune 500 companies had deployed MCP⁶.
3. Every major AI vendor speaks it - Anthropic, OpenAI, Google, and Microsoft all support MCP, so a connector you build is not a bet on one model^5,7.
4. SaaS vendors started shipping - HubSpot, Salesforce, Oracle, Sage, and Microsoft moved from watching to publishing official connectors within a year^{8,10,12,14,16}.
5. Integration cost is the real bottleneck - For most Mittelstand AI projects, the model was never the hard part. Getting the agent safely into SAP, DATEV, or a 15-year-old warehouse system is. That is the integration tax, and MCP is the first serious attempt to lower it.

The 2026 Connector Landscape

Here is an honest map of what actually shipped, grouped by the kind of system. These are real connectors from real vendors, with their real limits. Names are named so you can verify them yourself.

CRM connectors

CRM was the first category to get serious native support, because sales and service teams were the loudest early adopters.

• HubSpot - Shipped the first native CRM connector for Claude and a public-beta MCP server⁸. Claude can read and update contacts, companies, deals, tickets, line items, and products, plus the full engagement history of calls, emails, meetings, notes, and tasks. It cannot reach custom objects, sensitive-data properties, or workflows, cannot delete anything, and binds one HubSpot account to one Claude account⁹.
• Salesforce - Made hosted MCP servers generally available in April 2026 across Enterprise Edition and above, and turned Agentforce into a native MCP client^10,11. It built several layers, including MuleSoft’s API-to-MCP conversion and an AgentExchange for partner connectors, so agents can work with Salesforce data from Slack, Claude, or ChatGPT without switching context.
• Microsoft Dynamics and Dataverse - Reachable through Microsoft’s broader agent tooling and Agent 365 interoperability, letting Copilot and external MCP clients act on customer records under existing tenant governance¹⁷.

ERP connectors

ERP is where the value is highest and the ground is hardest. Cloud ERPs got official servers; older on-premise systems did not.

• Oracle NetSuite - Oracle built an official MCP server for NetSuite, so agents can query and act on financial and operational records directly¹².
• Sage Intacct - Sage shipped an official MCP server built on its REST APIs, part of the Sage AI Gateway, letting third-party agents including Claude integrate directly into the Sage ecosystem^13,14.
• SAP - SAP leans on the complementary A2A protocol for agent-to-agent collaboration through Joule, while agents use MCP to discover and consume tools from MCP servers on SAP BTP¹⁵. General availability of the enhanced interoperability is scheduled for late 2026, so today most SAP access still runs through middleware. Our deeper take is in AI agents for SAP.
• Microsoft Dynamics 365 Finance and Operations - Reachable through Microsoft’s agent stack and, for anything not natively exposed, through an iPaaS layer.
• Legacy and on-premise ERPs - SAP ECC, older Infor, Sage 100, and custom systems rarely ship a native server. These reach agents through the middleware covered in the next section. See also connecting an AI agent to your ERP.

Collaboration and document connectors

This is where most tacit company knowledge actually lives, in files, sites, and threads, which makes these connectors quietly the most valuable for a Company Brain.

• Microsoft SharePoint and OneDrive - Microsoft offers a SharePoint and OneDrive MCP server for uploading files, reading metadata, searching, and managing lists. Employees can connect Claude, ChatGPT, Copilot, or Cursor to SharePoint without bypassing IT governance^16,17. This is the backbone of a SharePoint knowledge base an AI can actually use.
• Microsoft Teams and Outlook - Reachable through Microsoft 365 agent tooling and Agent 365, so an agent can read threads and email in context under tenant controls¹⁷.
• Google Workspace - Drive, Gmail, and Calendar are covered by both Google’s own tooling and a large field of community and iPaaS servers.
• Confluence, Notion, and Slack - All have widely used MCP servers, official or community, for knowledge and communication.

Databases, e-commerce, and ticketing connectors

Beyond the headline CRM and ERP names, most of the work an AI employee does touches the long tail of business systems. This is where the ecosystem is broadest and least standardised, so read each connector’s limits carefully.

• Databases - PostgreSQL, MySQL, SQL Server, and Snowflake are reachable through official and community servers, often via CData, letting an agent query operational data directly. Grant read access first, and treat any write path to a production database as a high-risk action.
• E-commerce - Shopify and other storefronts have widely used MCP servers for orders, products, and customers, useful for agents that reconcile orders against fulfilment or answer stock questions.
• Ticketing and ITSM - Jira, ServiceNow, and Zendesk all have connectors, so a service agent can read a ticket, pull the related record from the CRM, and draft or post a response in one pass.
• German finance and payroll - DATEV and similar systems rarely ship a native MCP server, so for a Mittelstand finance workflow you almost always go through an iPaaS layer or a private server. Our take on this is in AI bookkeeping with DATEV.
• Communication - Slack, Gmail, and Outlook servers let an agent read and send messages in context, which is what turns a silent back-office agent into one that actually closes the loop with people.

MCP vs A2A: Connectors Are Not the Whole Story

As soon as you have more than one agent, a second protocol enters the picture. MCP connects an agent to tools. A2A, the Agent2Agent protocol, connects agents to each other. Confusing the two leads teams to reach for the wrong standard, so it is worth being clear.

• MCP is agent-to-tool - It lets a single agent read your CRM, write to your ERP, or search SharePoint. This is what nearly every Mittelstand project needs first.
• A2A is agent-to-agent - Google introduced A2A in 2025 and contributed it to the Linux Foundation, with version 1.0 announced in April 2026. It standardises how agents built by different vendors delegate work to each other.
• They are complementary, not rivals - SAP is the clearest example: Joule acts as an A2A client to talk to external agents, while those agents use MCP to discover and consume tools from MCP servers¹⁵.
• Start with MCP - You get value from a single agent doing real work across your systems long before you need agents talking to agents. Add A2A when you genuinely have multiple specialised agents that must coordinate.
• Both are open and Linux-Foundation-governed - Neither locks you to a vendor, which is the whole reason to build on them rather than on a proprietary integration layer.

iPaaS and Middleware for Legacy ERPs

Most Mittelstand companies do not run only cloud SaaS. They run a mix, and somewhere in that mix is a system too old, too custom, or too critical to have a native MCP server. This is where integration platforms earn their place, and in 2026 they all grew an MCP face.

• Workato - Offers a cloud-native platform with more than 1,200 connectors, including SAP, EDI, and IoT, and now exposes them for agent use¹⁹. Strong where you need many pre-built connectors fast.
• Boomi - Shipped a managed MCP service in May 2026 that connects Claude, Gemini, ChatGPT Enterprise, and Copilot to more than 1,000 enterprise tools, plus Agentstudio for designing and governing agents at scale¹⁸. Strong for hybrid setups with legacy systems.
• MuleSoft - Bought when a company wants a durable API operating model across Salesforce, SAP, Oracle, and legacy applications, with API-to-MCP conversion built into the Salesforce stack^11,19.
• CData - Provides MCP servers for hundreds of systems, from Sage Cloud Accounting to Intacct, with read-only servers for quick starts and full CRUD through its managed Connect AI platform¹³. Strong for reaching databases and long-tail business apps.
• n8n and Zapier - Lighter-weight options that added MCP support, useful for simpler automations and smaller workflows.

Private and Internal MCP Servers

No vendor will ever ship a connector for your homegrown quoting tool, your Access database from 2011, or the internal API only three people understand. Because MCP is an open standard, you build those yourself, and you keep them private.

• Wrap any internal API - If a system has an API, a script, or even a database, you can expose a controlled slice of it as an MCP server that only your agents reach.
• Data stays in your network - A self-hosted server means the connection lives inside your own infrastructure, which matters for DSGVO and for anything you would never send to a public endpoint.
• Scope down, not up - The right internal server exposes the few tools a workflow needs, not the whole system. A read tool and one narrow write tool beat full database access every time.
• Encode process, not just data - The best internal servers expose actions that match how your company actually works, for example “create a quote from these line items using our standard discount rules,” not raw table access.
• Own the maintenance - A private server is yours to keep working. That is a real cost, and it belongs in your connector governance from day one.

When to build a private server

What Connectors Cannot Do Yet

An honest map has to include the gaps. MCP connectors are real and useful, but they are not magic, and a few limits catch teams by surprise after go-live.

• Coverage is uneven - The official servers cover the biggest cloud systems. Older on-premise software, niche vertical tools, and most German-specific systems still need middleware or a private server.
• Write access is often narrow - Many connectors ship read-first. The HubSpot server cannot delete, several CData servers are read-only, and vendors are deliberately cautious about what an agent can change.
• Deep permissions rarely map cleanly - A system’s fine-grained role model does not always translate into MCP scopes, so you sometimes get coarser access than you want and have to compensate with your own controls.
• No connector fixes bad data - If your CRM is full of stale records, an agent with a perfect connector will act on stale records. Connectivity is not data quality. See why CRM data decays.
• Connectors move data, they do not remember - A connector gives an agent access in the moment. It does not retain the decisions, context, or people-knowledge that make the access useful over time. That is a job for a Company Brain, not a connector.
• Maintenance never ends - APIs change, servers break, and someone has to keep each connection working. This is real operational cost, whoever owns it.

Governance and Security

This is the section most connector guides skip, and it is the one that decides whether your project survives contact with your security team. MCP is a young ecosystem, and the data on public servers is sobering.

• Most public servers have flaws - Independent scans in 2026 repeatedly found that between 30 and 82 percent of public MCP servers carry exploitable weaknesses^20,21.
• Almost none use OAuth - Only about 8.5 percent of scanned servers use OAuth, despite the spec recommending OAuth 2.1 with PKCE²⁰.
• Tool poisoning is real - Malicious instructions hidden in tool descriptions or returned data can hijack an agent. One scan found tool-poisoning indicators in roughly 5.5 percent of servers, and a majority of servers had some security finding²¹.
• Injection is common - Command injection affected about 43 percent of tested servers, and path traversal affected 82 percent of those doing file operations²¹.
• A real CVE at scale - CVE-2025-6514, scored 9.6, hit the widely used mcp-remote proxy across more than 437,000 installed environments²⁰. This is not theoretical.

The attack classes to know

The controls that actually matter

Microsoft, OWASP, and the Cloud Security Alliance all published MCP-specific guidance in 2026, and the consensus is consistent: treat MCP servers as OAuth 2.0 resource servers, enforce consent and authorization per client and per user, and monitor every invocation^20,22,23,24. None of this is exotic. It is the same discipline you already apply to any system with write access to your data.

How to Choose Connectors: A Practical Sequence

The mistake teams make is starting from the connector catalogue instead of the workflow. Do it the other way around. Pick the job first, then connect only what that job touches.

1. Start from one workflow, not the system list - Name a single task an AI employee should own end to end, for example “draft the quote, log it in the CRM, and file the PDF in SharePoint.” The connectors follow from the task.
2. Map the systems that task touches - Usually two to four: an inbox, the CRM, a file store, one line-of-business system. Ignore everything the workflow does not need.
3. Check for an official connector first - If the system is HubSpot, Salesforce, NetSuite, Intacct, or SharePoint, use the vendor server. Least maintenance, cleanest permissions.
4. Fall back to iPaaS for legacy - For SAP ECC, custom databases, or on-premise apps, reach them through Workato, Boomi, MuleSoft, or CData rather than waiting for a native server that may never come.
5. Build private servers for the rest - For homegrown tools and sensitive processes, wrap a narrow slice of the internal API yourself.
6. Decide read vs write per connector - Grant read widely, write narrowly. Every write path needs a scope and, for anything irreversible, a human checkpoint.
7. Wire in governance before go-live - OAuth, logging, and approval flows are part of the build, not a later hardening phase.
8. Prove one workflow, then expand - Get a single agent finishing a real task with real data before adding the next connector. Value compounds from working workflows, not from connector count.

A worked example: a quote-to-CRM agent

To make the sequence concrete, take a common Mittelstand task: a sales assistant drafts a quote, logs it in the CRM, and files the PDF where the team can find it. Here is how the connector decisions play out.

1. Name the task - “Turn an inbound RFQ email into a drafted quote, a logged CRM deal, and a filed PDF.” One sentence, one owner.
2. List the systems it touches - Outlook or Gmail for the email, the CRM for the deal, an internal pricing tool for the numbers, and SharePoint for the PDF. Four systems, no more.
3. Match each to a connector - Email and SharePoint use Microsoft’s servers, the CRM uses its official server if it is HubSpot or Salesforce, and the pricing tool, being homegrown, needs a private MCP server exposing one “price these line items” tool.
4. Set read and write per connector - Read the email, read the pricing tool, write a draft deal to the CRM, and write the PDF to a single SharePoint library. No delete anywhere.
5. Add the human checkpoint - The agent drafts the quote and the deal, but a person approves before the quote goes to the customer. The write to the CRM is fine to automate; the send is not.
6. Turn on logging - Every tool call is recorded, so if a quote is wrong, you can see exactly which record and which price the agent used.
7. Prove it, then widen - Once this runs cleanly, the same four connectors already cover order confirmations and renewals. The second workflow costs a fraction of the first.

How Superkind Fits

Superkind builds a Company Brain and AI employees that connect to the real systems a company already runs, through exactly these kinds of connectors. We are one option among many, and we work best when the goal is an AI employee doing real work inside your stack, not a chatbot bolted on the side.

• Connectors as means, not the product - MCP servers are how we reach your email, Teams, SharePoint, CRM, and ERP. The product is an AI employee that finishes work, and a Company Brain that remembers how your company operates.
• Official connectors where they exist - When HubSpot, Salesforce, NetSuite, Intacct, or SharePoint ship a native server, we use it. Less to maintain, cleaner permissions, faster to live.
• Middleware and private servers for the rest - For legacy ERPs and homegrown systems, we use an iPaaS layer or build private MCP servers so your specific tools become reachable without a rip-and-replace.
• The Company Brain sits above the connectors - Connectors move data. The Company Brain retains the decisions, process context, and people-knowledge that no CRM field or file holds, and it survives staff turnover. This is the difference a Copilot-style assistant does not close.
• Learns from daily feedback - Your team corrects the AI employee in the flow of work, and it gets sharper. The connectors stay the same; the judgement improves.
• Governance built in - Scoped access, human-in-the-loop for sensitive writes, and full logging of every action, because we treat connectors as privileged software.
• Model-agnostic - Because everything runs on the open protocol, you are not locked to one AI vendor. Swap the model underneath and the connectors and Company Brain keep working.
• Outcomes, not connector counts - We connect what a workflow needs and prove it on real work, rather than selling a catalogue of integrations you will never use.

Decision Framework: Which Path for Each System?

Use this to decide how to connect any given system, without over-engineering or waiting for a connector that may never ship.

Frequently Asked Questions

Henri Jung

Co-founder of Superkind, where he helps SMEs and enterprises deploy custom AI agents that actually fit how their teams work. Henri is passionate about closing the gap between what AI can do and the value it creates in real companies. Before Superkind, he spent years working with mid-sized businesses on digital transformation and saw first-hand how many AI projects stall not on the model but on the integration. He believes the Mittelstand has everything it needs to lead in AI - it just needs the right approach.