MCP Server: The Complete Guide for German Companies (2026)

What is an MCP server?

An MCP server is a software component that works according to the Model Context Protocol and gives AI agents standardised, controlled access to business systems. It provides three things: tools (functions the agent can execute), resources (data it may read) and prompts (templates for common interactions). MCP servers are the bridge between language models such as Claude, GPT, Gemini or Copilot and your internal IT, from the CRM through accounting to your own data warehouse.

The Model Context Protocol itself was published as an open standard by Anthropic, the company behind Claude, at the end of 2024. Within twelve months, Google (Gemini), OpenAI (GPT), Microsoft (Copilot) and developer tools such as Cursor, Windsurf and Zed adopted the protocol. MCP has thus become the de facto industry standard for AI integrations, comparable to what HTTP is for the web or USB-C for devices: a universal connector that works everywhere.

For German companies, this classification matters: MCP servers run in your infrastructure, not at the AI provider. You control which data is released, which tools the AI agent may execute and who has audit access to the logs. That makes MCP not only technically future-proof but also attractive from a data protection perspective. You will find more in the GDPR & EU hosting section further down.

You will find a detailed, beginner-friendly explanation with more examples on the guide page What is an MCP server? Explained in detail. This guide assumes somewhat more prior knowledge and goes deeper in each section.

Architecture & how it works

MCP follows a classic client-server model with clearly separated responsibilities. On one side is the MCP client, usually the AI agent or a host such as Claude Desktop, ChatGPT or a custom agent stack. On the other side is the MCP server, which encapsulates the interface to your systems. Communication between the two runs over JSON-RPC 2.0: lightweight, proven and independent of the transport.

If you want to understand the protocol itself in more depth (handshake, capability negotiation, versioning and why Google and Microsoft adopted it), read our MCP protocol guide for companies. This section deliberately stays at the architecture level.

The five building blocks of an MCP server

• Tools: Callable functions with typed parameters and docstrings. Example: create_invoice(customer_id, amount, due_date). The model decides at runtime whether and when to call a tool.
• Resources: Readable data endpoints with a URI scheme. Example: crm://contacts/12345. The model can load this data into its context without being able to change it.
• Prompts: Predefined prompt templates that the client can offer to the user, e.g. “Summary of the last customer conversation” or “Generate quarterly report”.
• Transport: How client and server talk to each other. stdio for local setups, HTTP+SSE for remote servers, WebSocket for bidirectional communication.
• Capabilities: A self-description of the server stating which functions it supports (tools? resources? prompts? logging? sampling?). The client adapts its behaviour accordingly.

Typical request flow

This is what a concrete tool execution looks like, step by step:

Minimal example in TypeScript

This is what a simple MCP server in TypeScript looks like that provides a tool for creating Pipedrive deals:

import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new Server({ name: "pipedrive-bridge", version: "1.0.0" });

server.setRequestHandler("tools/list", async () => ({
  tools: [{
    name: "create_deal",
    description: "Legt einen neuen Deal im Pipedrive-CRM an.",
    inputSchema: {
      type: "object",
      properties: {
        title:  { type: "string", description: "Deal-Titel" },
        value:  { type: "number", description: "Wert in EUR" },
        person: { type: "string", description: "Pipedrive Person-ID" }
      },
      required: ["title", "value"]
    }
  }]
}));

server.setRequestHandler("tools/call", async (req) => {
  const { title, value, person } = req.params.arguments;
  const res = await fetch("https://api.pipedrive.com/v1/deals", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ title, value, person_id: person })
  });
  return { content: [{ type: "text", text: JSON.stringify(await res.json()) }] };
});

await server.connect(new StdioServerTransport());

In production you would add: OAuth token refresh, retry logic, logging, validation of the fields against the Pipedrive schema and a mapping between Pipedrive pipelines and sensible default values. But the basic skeleton is already visible here: compact, readable, typed.

MCP vs. REST API vs. function calling vs. plugins

These four concepts are often confused. They solve different problems, though. The quick overview:

In short: MCP is not a replacement for REST APIs but an AI-native abstraction on top of them. An MCP server typically encapsulates one or more REST APIs and exposes them in a form that any MCP-capable model understands without adaptation. Function calling and plugins are the vendor-specific predecessors of MCP; anyone building something new today should choose MCP.

Top 12 use cases in German mid-sized companies

From over 24 months of projects in mid-sized companies in Germany, Austria and Switzerland (DACH), these applications emerge as the ones where MCP servers create real value particularly quickly:

Common to all use cases: one MCP server per domain, clearly defined tools, granular permissions. Anyone who builds the layered model cleanly can extend it later as needed (new tools, new models, new use cases) without touching the foundation.

Which systems can be connected?

Rule of thumb: if the system has an API, a database or a command line, it can be connected via MCP. In practice this lets us cover practically every relevant German business system, from DATEV and SAP through HubSpot and Personio to Shopware and Microsoft 365. We maintain dedicated in-depth guides for the most important DACH platforms; the directory below is sorted by area, DACH tools first. The list grows continuously.

For every integration: an existing REST or SOAP API is the ideal case, and GraphQL works too. If the system has no API, it can be done via CSV export/import or, as a last resort, via RPA. You will find a complete strategy and selection guide in the overview of MCP integration by an agency; a categorised list of all detailed guides is collected in the MCP cluster index.

Setting up an MCP server in 6 steps

This is how we structure a typical pilot project, from the first workshop to productive use. We set the timeline after the AI Check.

1. Define the use case

   Choose a concrete, measurable bottleneck, e.g. "Receipt capture in accounting costs 18 hrs/week". Define 2–3 tools that the AI agent should execute, and clarify the necessary permissions per role.

2. Choose architecture and hosting

   Decide on EU hosting (Hetzner Falkenstein/Nuremberg, IONOS Karlsruhe, the the Azure Germany West Central region West Central region (Frankfurt)), transport layer (stdio for local agents, HTTP+SSE for remote), auth model (OAuth2, API key, mTLS) and the database layer for audit logs.

3. Develop the MCP server

   Implementation with the official MCP SDK in Python or TypeScript. Every tool gets a clear docstring, typed parameters and parameterised queries against the target system. Code is versioned and continuously tested.

4. Harden security

   Authentication, granular permissions per role, rate limiting, input validation against prompt injection, sandboxed execution of critical tools and full audit logging. Before go-live: a pen test by external specialists.

5. Start a pilot with real data

   Connection to the AI model (Claude, GPT, Gemini). Start with a small pilot group of 3–5 power users, measuring time-to-task, error rate and adoption rate. Weekly retro sessions for fine-tuning.

6. Scale and extend

   After the pilot: extend the tools, connect more systems, set up a maintenance contract.

Security & permissions

An MCP server is a privileged component: it has access to business systems, and an AI model calls it. Without a sound security architecture, you create an open flank. These six principles are the foundation (in more depth: MCP server security & GDPR: guide for SMEs):

• Client authentication: Every MCP client identifies itself, preferably via OAuth2 with short-lived tokens, alternatively an API key with mTLS. There are no anonymous connections.
• Role-based permissions: A tool is not "always callable". It is released per role. The support agent sees no salary data, and the marketing agent may not execute postings.
• Input validation against prompt injection: Tool arguments are checked against a strict schema. There is no free-form SQL; all queries are parameterised. Data fields that an agent gets back are neutralised before reuse.
• Rate limiting and quotas: A limit applies per client and per tool (e.g. 50 calls/minute, 5,000/day). Anomalies trigger alerts.
• Human-in-the-loop for critical tools: Postings, orders, sending email or deleting data are not executed fully automatically but presented to the user for approval. The agent prepares, a human confirms.
• Audit logging: Every tool call is logged with timestamp, user, arguments and result. Logs are tamper-proof (append-only, ideally on a separate system). The audit team can trace every transaction.

GDPR & EU hosting

For German companies, the data protection side is often the deciding point. The good news: MCP is GDPR-friendly by architecture, because business data does not have to leave your infrastructure. The MCP server gives the AI agent only what it needs for the current task.

EU hosting options compared

• Hetzner Cloud (Falkenstein, Nuremberg): Good value for money, German data centres, ISO 27001 certified. Our recommendation for standard setups.
• IONOS Cloud (Karlsruhe, Berlin): German provider with classic enterprise support, BSI C5 attestation (the German Federal Office for Information Security's cloud standard), familiar to many mid-sized customers.
• Azure Germany West Central region (Frankfurt): A good fit if a Microsoft stack is already in use (M365, Dynamics, AAD). Region-bound services keep the data in that region.
• OVHcloud (Frankfurt, Limburg): European provider with SecNumCloud qualification, a good option for highly sensitive industries.
• On-premise on your own hardware: Maximum control. Makes sense for banks, insurers, clinics; maintenance and scaling effort is higher.

Data residency and third-country transfers

The MCP server itself runs in the EU, which is the easy part. It gets more complex as soon as the AI model is located outside the EU: Claude (Anthropic, US), GPT (OpenAI, US), Gemini (Google, US/global). Three levers help here:

• Data processing agreement (DPA) with the AI provider. All major models offer GDPR-compliant DPAs, often including EU standard contractual clauses (SCC).
• Use EU endpoints where available. Anthropic offers an EU region, Azure OpenAI has EU hosting, and so does AWS Bedrock.
• Pseudonymisation of sensitive fields in the MCP server before they go to the model: customer names become IDs, and re-mapping happens locally.

For deeper topics such as TIA (transfer impact assessment), the record of processing activities and data processing, we recommend coordinating with your data protection officer or a law firm specialised in AI data protection. Further reading: our guide GDPR-compliant AI in mid-sized companies.

Costs

Every project looks different, so we only name costs once we know your systems and use cases. The costs are made up of these components:

• Audit + design (interface mapping, use cases, permission model).
• First productive MCP server with 2–3 tools, EU hosting, auth, logging, pen test: individually calculated, depending on complexity, number of systems, data classification and compliance requirements.
• Extension per additional tool or use case, much smaller than the initial setup because the server, sign-in and audit log are already in place.
• Ongoing operation (hosting, monitoring, updates), depending on load and availability requirements.
• Maintenance contract with defined response times and update rhythm: optional, depending on the SLA required.

Choosing a provider: what to look for

The market for "AI consulting" and "MCP implementation" is growing rapidly, and with it the number of providers who use MCP more as a buzzword than as a real architectural discipline. This checklist helps with the selection:

• check_circleProven MCP experience: Concrete projects, not just pitch decks. Ask: "Show me the code structure of one of your MCP servers". Good providers have answers.
• check_circleEU hosting expertise: Practical experience with Hetzner, IONOS, the Azure Germany West Central region, not just AWS slides.
• check_circleGDPR competence: Familiar with DPAs, TIA, pseudonymisation, and able to talk to your data protection officer as an equal.
• check_circleIndustry understanding: A tax firm has different requirements from an online retailer. Good providers recognise that within the first 15 minutes.
• check_circleMaintenance contract with SLA: Response times, update rhythm and escalation paths defined in writing.
• check_circleClean handover documentation: You must be able to keep operating the server without the provider. Architecture diagrams, runbooks and recovery instructions are part of that.
• check_circleRealistic promises: Anyone who pitches "full automation in 2 weeks" either does not understand the problem or has no scruples. A pilot and iterative scaling are credible.

FAQ: the 20 most common questions