Wie wir MCP-Server bauen: Architektur, Autorisierung und Sicherheit für Unternehmenssysteme

Kurz gesagt (Stand: November 2026). Ein produktiver MCP-Server ist eine dünne Protokollschicht über Code, den Sie ohnehin schreiben würden: typisierte Tools, die Eingaben prüfen und Services mit der Geschäftslogik aufrufen, die wiederum über Adapter mit ERP, CRM, Datenbank oder Dokumentenablage sprechen. Bauen Sie Tools um Aufgaben, nicht um jeden API-Endpunkt. Entscheiden Sie früh, für wen der Server handelt: ein Servicekonto mit engen Rechten für Automationen oder der einzelne Nutzer per OAuth 2.1, wie es die aktuelle MCP-Spezifikation (2026-07-28) mit Protected Resource Metadata, Resource Indicators und Audience-Prüfung festlegt. Reichen Sie nie das Token eines Clients an das Backend durch, geben Sie einem Modell nie ein generisches „SQL ausführen“-Tool auf einem Admin-Schlüssel, und behandeln Sie jede Tool-Beschreibung und jeden zurückgegebenen Text als nicht vertrauenswürdig. Ergänzen Sie Audit-Logs, Ausgabelimits und Tests, und prüfen Sie, welche personenbezogenen Daten mit jedem Tool-Ergebnis das Unternehmen verlassen.

Bei SDH haben wir MCP-Schichten für ein Field-Service-ERP, eine Berechnungs-Engine und eine Plattform für Musikvertrieb gebaut und das Bewährte in eine interne Projektvorlage überführt. Dieser Artikel beschreibt die Architektur, die Optionen für die Autorisierung, die Angriffe auf reale MCP-Server und eine Checkliste für den Weg in die Produktion.

Wo wir MCP einsetzen

• FieldHub, ein SaaS-ERP für Field-Service- und Sicherheitsintegratoren in den USA: CRM, Lager, Einsatzplanung, Buchhaltung. Seine API ist zu groß für ein Tool je Endpunkt, deshalb haben wir die MCP-Schicht als eigene Engine zwischen Agent und API gebaut, statt Hunderte Tools von Hand zu schreiben.
• Ein Server für astrologische Berechnungen: Der Server berechnet Geburtshoroskope und Planetenpositionen exakt, das Modell interpretiert nur. Er läuft über Standardein- und -ausgabe für Desktop-Clients und per HTTP auf Google Cloud Run für eine n8n-Automation, die Nutzern in einem Telegram-Bot antwortet.
• Eine Plattform für Musikvertrieb (in Entwicklung): eine MCP-Schicht über den Abläufen für Releases, Metadaten und Lizenzerlöse, die die Plattform gegen die APIs der Distributoren ausführt.
• Unsere Vorlage: die Struktur, die sich in diesen Projekten bewährt hat – Schichten, Fehlerbehandlung, Authentifizierung für HTTP, Deployment mit Docker und Cloud Run, End-to-End-Tests –, so verpackt, dass jeder neue Server auf derselben Basis startet.

MCP Ende 2026: was sich geändert hat

Das Protokoll hat sich schnell entwickelt; vieles, was 2025 über MCP geschrieben wurde, ist überholt.

• Aktuell ist die Spezifikation 2026-07-28. Sie macht das Protokoll zustandslos: Handshake und Session-IDs entfallen, jede Anfrage trägt ihre Version und Fähigkeiten, und Zustand über mehrere Aufrufe wird als Handle in Tool-Argumenten übergeben. Der alte HTTP+SSE-Transport und die dynamische Client-Registrierung sind veraltet (Changelog).
• Die Autorisierung basiert auf OAuth 2.1. Ein MCP-Server ist ein OAuth-Resource-Server: Er veröffentlicht Protected Resource Metadata (RFC 9728), Clients müssen den Server benennen, für den sie ein Token wollen (Resource Indicators, RFC 8707), und der Server muss prüfen, dass ein Token für ihn ausgestellt wurde (Autorisierung). Clients registrieren sich jetzt über Client-ID-Metadatendokumente.
• Single Sign-on für Unternehmen kam im Juni 2026 als offizielle Erweiterung: Der Zugang zu MCP-Servern wird zentral über den Identity Provider des Unternehmens vergeben (MCP-Blog).
• Neutrale Governance. MCP ist im Dezember 2025 der Agentic AI Foundation unter dem Dach der Linux Foundation beigetreten, mitgegründet von Anthropic, Block und OpenAI (MCP-Blog).
• Breite Unterstützung bei Clients: Claude, die OpenAI Responses API und ChatGPT, Microsoft Copilot Studio und Windows, VS Code, Google Cloud und die JetBrains-IDEs sprechen MCP. Die offiziellen SDKs kommen auf fast eine halbe Milliarde Downloads im Monat; Python und TypeScript sind SDKs der ersten Stufe.
• Die öffentliche Registry ist noch eine Vorschau – bauen Sie produktive Discovery noch nicht darauf (Registry).

Die Architektur

Unsere Server folgen derselben Struktur:

1. Tools sind der einzige Teil, der MCP kennt. Ein Tool prüft seine Eingabe gegen ein typisiertes Modell, ruft eine Service-Funktion auf und wandelt Fehler um. Hier liegt keine Geschäftslogik.
2. Services enthalten die Logik als einfache Funktionen ohne MCP-Importe. Sie werden getestet wie jeder andere Code und lassen sich von einer REST-API oder einem Hintergrundjob wiederverwenden.
3. Adapter sprechen mit den Systemen dahinter: ERP-API, CRM, Datenbank, Dokumentenablage. Zugangsdaten und Wiederholversuche liegen hier.
4. Der Rand übernimmt Transport (Standardein- und -ausgabe für Desktop-Clients, Streamable HTTP für entfernte), Authentifizierung, Rate-Limits und Audit-Logging.

Die Eingabemodelle sind Teil des Prompts. Das Modell liest Tool-Namen, Beschreibung und jede Feldbeschreibung, um zu entscheiden, was es mit welchen Argumenten aufruft; der Großteil der Qualität beim Tool-Einsatz kommt daher. Wir schreiben sie wie Dokumentation für eine neue Kollegin.

Fehler müssen dem Modell sagen, wie es den Aufruf korrigiert. „customer_id nicht gefunden; zuerst mit find_customer nach Namen suchen“ lässt den Agenten weitermachen. Ein Stacktrace verrät Interna und lehrt ihn nichts.

Ein minimales Beispiel

Ein Tool nur zum Lesen, das die offenen Rechnungen eines Kunden aus einem ERP auflistet, in Python mit FastMCP, so strukturiert wie in unserer Vorlage:

# models.py: the field descriptions are read by the model
from pydantic import BaseModel, Field

class OpenInvoicesInput(BaseModel):
    customer_id: str = Field(
        description="ERP customer number, for example C-10234. Use find_customer to look it up.")
    limit: int = Field(default=20, ge=1, le=100,
                       description="Maximum number of invoices to return")


# services/invoices.py: business logic, no MCP imports, unit-tested on its own
class DomainError(Exception):
    """The message must tell the model how to fix the call."""

def open_invoices(erp, data: OpenInvoicesInput) -> list[dict]:
    customer = erp.get_customer(data.customer_id)
    if customer is None:
        raise DomainError(
            f"Customer {data.customer_id} not found. Search with find_customer first.")
    invoices = erp.list_invoices(customer.id, status="open", limit=data.limit)
    # Only the fields the task needs: no bank details or personal notes leave the company
    return [{"number": i.number, "due": i.due_date.isoformat(),
             "amount": str(i.amount), "currency": i.currency}
            for i in invoices]


# tools/invoices.py: thin MCP layer
from fastmcp import FastMCP
from fastmcp.exceptions import ToolError

def register(mcp: FastMCP, erp) -> None:
    @mcp.tool(annotations={"readOnlyHint": True})
    def list_open_invoices(data: OpenInvoicesInput) -> list[dict]:
        """List a customer's unpaid invoices with number, due date and amount."""
        try:
            return open_invoices(erp, data)
        except DomainError as exc:
            raise ToolError(str(exc)) from exc
        except Exception as exc:
            raise ToolError(
                f"Internal error ({type(exc).__name__}); check the server logs.") from exc

Und ein Test, der den echten Server im Speicher ausführt, ohne Netzwerk, in der CI:

import pytest
from fastmcp import Client
from fastmcp.exceptions import ToolError

async def test_unknown_customer_explains_the_fix(server):
    async with Client(server) as client:
        with pytest.raises(ToolError, match="find_customer"):
            await client.call_tool("list_open_invoices",
                                   {"data": {"customer_id": "C-0"}})

Beachten Sie den readOnlyHint: Er hilft Clients zu entscheiden, wann sie den Nutzer um Bestätigung bitten, ist aber nur ein Hinweis. Ein bösartiger oder fehlerhafter Server kann ihn setzen und trotzdem Daten löschen (MCP-Blog); der eigentliche Schutz ist, dass der Adapter dieses Tools keine Schreibrechte hat.

Große APIs: Abläufe statt Endpunkte

Jeden Endpunkt als Tool abzubilden, scheitert, sobald eine API mehr als einige Dutzend Operationen hat: Das Modell muss jede Tool-Beschreibung lesen, wählt öfter das falsche, und der Kontext ist voll, bevor die Arbeit beginnt. Anthropic empfiehlt dasselbe: weniger Tools um vollständige Aufgaben, nur aussagekräftige Felder zurückgeben, paginieren und kürzen (Anthropic Engineering).

Für eine API in der Größe eines ERP reicht das nicht, deshalb haben wir die MCP-Schicht von FieldHub als eigene Engine gebaut. Die allgemeinen Optionen:

• Kuratierte Aufgaben-Tools für die 10–⁠30 Abläufe, auf die es ankommt („Auftrag für einen Kunden anlegen“, „überfällige Rechnungen auflisten“), die jeweils mehrere API-Aufrufe bündeln.
• Ein Discovery-Muster für den Rest: ein Tool, das den API-Katalog durchsucht, eines, das eine Operation beschreibt, und eines, das sie ausführt – beschränkt auf eine Allowlist und die Rechte des Aufrufers.
• Mehrere kleinere Server nach Fachbereich (CRM, Lager, Buchhaltung), damit ein Agent nur lädt, was seine Aufgabe braucht.

Für wen handelt der Server?

Wir nutzen beides. Unsere Vorlage bringt eine Bearer-Token-Prüfung für den HTTP-Endpunkt mit – richtig für einen Server, den eine einzelne Automation aufruft. Sobald Menschen mit unterschiedlichen Rechten einen Server nutzen, braucht er eine Autorisierung je Nutzer, und dann ist die Spezifikation eindeutig: prüfen, dass das Token für den eigenen Server ausgestellt wurde, und kein anderes Token annehmen oder durchreichen (Security Best Practices). Braucht das Backend ein eigenes Token, tauscht oder beschafft der Server es; er reicht nicht das des Clients weiter.

Was bei realen MCP-Einsätzen schiefging

Hinter den meisten steckt die Kombination, die Simon Willison die „tödliche Dreifaltigkeit“ nennt: ein Agent, der private Daten lesen kann, nicht vertrauenswürdige Inhalte sieht und Daten nach außen senden kann (Simon Willison). Prompt-Injection lässt sich vom Modell nicht vollständig verhindern; sie muss durch das begrenzt werden, was die Tools erlauben. OWASP pflegt inzwischen eine MCP Top 10 (im Inkubator) mit denselben Themen: offene Tokens, schleichende Rechteausweitung, Tool Poisoning, Lieferkette, Command Injection, fehlendes Audit.

Unsere Regeln für produktive Server

1. Enge Tools um Aufgaben. Kein generisches „SQL ausführen“, „beliebigen Endpunkt aufrufen“ oder „Shell ausführen“.
2. Minimale Rechte im Backend. Lesen und Schreiben in getrennten Tools, möglichst mit getrennten Zugangsdaten; die Zugangsdaten der Lese-Tools können nicht schreiben.
3. Deterministische Bestätigung für destruktive Aktionen. Löschen, Bezahlen oder externer Versand braucht einen ausdrücklichen Bestätigungsschritt, den der Servercode erzwingt – keinen Hinweis an das Modell.
4. Identität je Nutzer, wenn Menschen mit unterschiedlichen Rechten den Server nutzen. Servicekonten nur für feste Automationen, mit festen Scopes.
5. Kein Durchreichen von Tokens, Audience-Prüfung bei jedem Token, minimale Scopes, keine Wildcards.
6. Tool-Ausgaben als nicht vertrauenswürdige Eingaben behandeln. Text aus Tickets, E-Mails oder Dokumenten kann Anweisungen enthalten; er darf nicht von selbst Aktionen auslösen.
7. Nur zurückgeben, was die Aufgabe braucht, mit Paginierung und Größenlimits. Claude Code etwa kürzt Tool-Ausgaben standardmäßig bei 25.000 Tokens.
8. Handlungsleitende Fehler, keine Stacktraces.
9. Jeden Aufruf protokollieren: wer, welches Tool, welche Argumente, welche Ergebnisgröße; Trace-IDs bis ins Backend (die Spezifikation von 2026 transportiert OpenTelemetry-Kontext).
10. Abhängigkeiten und fremde Server pinnen und prüfen; sicherstellen, dass sich Tool-Definitionen nicht unbemerkt ändern.
11. In der CI testen – mit einem In-Memory-Client und Evaluationssätzen aus echten Aufgaben; für manuelle Prüfungen MCP Inspector ab Version 0.14.1.
12. Tool-Schemata versionieren und ändern wie eine öffentliche API.

Gateways helfen, wenn mehrere Server und Teams beteiligt sind: zentrale Authentifizierung, Richtlinien, Logs an das SIEM und Schutz vor Datenabfluss. Zu den Optionen gehören die MCP-Server-Portale von Cloudflare (seit September 2026 allgemein verfügbar), der AI-MCP-Proxy von Kong, AWS Bedrock AgentCore Gateway und Azure API Management.

Die europäische Perspektive

• Mit jedem Tool-Ergebnis verlassen personenbezogene Daten das Haus. Was ein Tool zurückgibt, landet im Kontext des Sprachmodells beim Modellanbieter. Felder minimieren (Art. 5 DSGVO), einen Auftragsverarbeitungsvertrag mit dem Anbieter schließen und die Grundlage der Übermittlung sowie den Ort der Modellausführung prüfen. In der EU gehostete Modelle gibt es über Cloud-Anbieter; prüfen Sie das aktuelle regionale Angebot, bevor Sie sich darauf verlassen.
• Wo der Client läuft, zählt. Claude etwa ruft entfernte MCP-Server aus der Cloud von Anthropic auf; ein interner Server muss also aus dem Internet erreichbar sein oder hinter einem Gateway liegen (Claude-Hilfe). Für viele deutsche Unternehmen entscheidet das die Architektur.
• Die Transparenzpflichten des AI Act gelten seit dem 2. August 2026: Nutzer müssen wissen, wenn sie es mit einem KI-System zu tun haben. Treibt Ihr MCP-Server einen Assistenten für Kunden an, muss dieser das offenlegen.
• NIS2. Für die rund 29.500 erfassten Unternehmen in Deutschland ist ein MCP-Server mit Zugriff auf Kernsysteme Teil der Angriffsfläche, die ihr Risikomanagement abdecken muss.
• Eine eigene Empfehlung des BSI zu MCP gibt es noch nicht; die Security Best Practices der Spezifikation und die OWASP-Liste sind die besten Referenzen.

Die Fristen rund um diese Regeln finden Sie in unserem Compliance-Kalender für Software.

Wie wir helfen

SDH konzipiert und baut MCP-Server und Integrationen für ERP, CRM, Datenbanken und Dokumentenablagen, als Teil unserer KI-Softwareentwicklung: Tool-Design, Autorisierung je Nutzer, Audit und Deployment in Ihrer oder unserer Cloud. Wenn Sie zwischen MCP und einer klassischen API-Integration abwägen, lesen Sie MCP vs. API: die wichtigsten Unterschiede und warum MCP zum Standard für KI-Integration wird. Sprechen Sie uns an, wenn Sie Ihre Systeme sicher an KI-Agenten anbinden möchten.

FAQ

Welche MCP-Spezifikation ist aktuell?

Aktuell ist die Revision 2026-07-28. Sie macht das Protokoll zustandslos, entfernt Sessions und den Handshake, erklärt den HTTP+SSE-Transport und die dynamische Client-Registrierung für veraltet und definiert die Autorisierung auf Basis von OAuth 2.1 mit Protected Resource Metadata und Resource Indicators.

Wie sollte sich ein MCP-Server bei Nutzern authentifizieren?

Für Server, die Menschen mit unterschiedlichen Rechten nutzen, mit OAuth 2.1 je Nutzer, wie die Spezifikation es beschreibt: Der Server ist ein OAuth-Resource-Server, prüft, dass jedes Token für ihn ausgestellt wurde, und ruft Backends mit den eigenen Rechten des Nutzers auf. Für eine feste Automation genügt ein Servicekonto mit engen, festen Rechten.

Sollte jeder API-Endpunkt ein MCP-Tool werden?

Nein. Bauen Sie Tools um Aufgaben und geben Sie nur die Felder zurück, die die Aufgabe braucht. Bei sehr großen APIs kombinieren Sie Aufgaben-Tools mit einem Discovery-Muster oder teilen den Server nach Fachbereichen.

Was sind die größten Sicherheitsrisiken von MCP-Servern?

Prompt-Injection über Daten, die der Agent liest, Tools mit mehr Rechten als nötig, durchgereichte Tokens, fehlende Mandantenprüfungen, Command Injection über Tool-Argumente sowie bösartige oder veränderte fremde Server. Die meisten bisherigen Vorfälle verbanden Zugriff auf private Daten, nicht vertrauenswürdige Inhalte und einen Weg, Daten nach außen zu senden.

Ist MCP mit der DSGVO vereinbar?

Das kann es sein. Tool-Ergebnisse landen im Kontext des Modellanbieters; minimieren Sie daher personenbezogene Daten in den Ausgaben, schließen Sie einen Auftragsverarbeitungsvertrag mit dem Modellanbieter, prüfen Sie, wo das Modell läuft, und protokollieren Sie den Zugriff.

Quellen

• Model Context Protocol, Spezifikation 2026-07-28: Changelog, Autorisierung und Security Best Practices
• MCP-Blog, Release 2026-07-28, MCP tritt der Agentic AI Foundation bei, Tool-Annotationen
• Anthropic Engineering, Writing effective tools for agents, September 2025
• Invariant Labs, GitHub MCP exploited, Mai 2025
• General Analysis, Supabase MCP can leak your entire SQL database, Juli 2025
• Equixly, MCP servers: the new security nightmare, März 2025
• OWASP, MCP Top 10
• Simon Willison, Supabase MCP and the lethal trifecta, Juli 2025

Categories

Über den Autor

Pavlo Yablonskyi

CTO & Co-Founder

Vollständiges Profil ansehen

CTO & Mitbegründer von Software Development Hub. Software-Ingenieur mit 20+ Jahren Erfahrung. Python/Django-Fan, Software-Architekt und IT-Teamleiter. Stets auf dem Laufenden mit technischen Trends. Ausgeprägte technische Fähigkeiten und vielfältiges Fachwissen in den Bereichen Software-Strukturdesign, Entwicklung, Teammanagement und Cybersicherheit.

Vollständiges Profil ansehen