MCP vs. API: Was AI-Agenten für Systemintegration verändern – und was klassische Schnittstellen weiterhin besser können

„MCP ersetzt APIs“ klingt gut – ist aber die falsche Diskussion

Kaum ein Begriff ist 2026 im AI-Umfeld so schnell aufgestiegen wie MCP – Model Context Protocol.

MCP verbindet AI-Anwendungen mit externen Datenquellen, Tools und Workflows. Anthropic beschreibt es anschaulich als eine Art standardisierte Schnittstelle für AI-Anwendungen. Microsoft stellt inzwischen eigene MCP-Server unter anderem für Business Central bereit. Die MCP-Spezifikation wurde Ende Juli 2026 erneut aktualisiert und enthält unter anderem einen stateless Protocol Core für bessere Skalierbarkeit und Zuverlässigkeit.

Bei so viel Dynamik entsteht schnell die These:

„Brauchen wir künftig überhaupt noch klassische APIs?“

Meine Antwort: Ja – wahrscheinlich mehr denn je.

MCP und API lösen unterschiedliche Probleme.

Was eine API gut kann

Eine klassische API beschreibt eine technische Schnittstelle zwischen Systemen.

Beispiel:

Ein CRM sendet einen freigegebenen Auftrag an Business Central. Die Integration kennt:

• Endpoint
• Authentifizierung
• Datenmodell
• Pflichtfelder
• Antwortcodes
• Retry-Verhalten
• Fehlerbehandlung

Der Ablauf soll möglichst deterministisch sein.

Bei gleichem Input erwartet man ein vorhersehbares Verhalten.

Das ist für stabile Business-Prozesse ideal.

Was MCP zusätzlich bringt

MCP standardisiert, wie ein AI Client Fähigkeiten eines Servers entdecken und verwenden kann.

Die Spezifikation kennt unter anderem:

Tools

Funktionen, die ein Modell aufrufen kann – beispielsweise eine Datenbank abfragen, einen API-Call ausführen oder eine Berechnung starten.

Resources

Kontextquellen wie Dateien, Datenbankschemas oder anwendungsspezifische Informationen.

Prompts

Wiederverwendbare strukturierte Prompt-Vorlagen.

Für einen AI Agent bedeutet das: Er muss nicht für jede Anwendung individuell lernen, wie Tools beschrieben und bereitgestellt werden. Ein MCP-kompatibler Client kann die angebotenen Fähigkeiten entdecken.

Das ist besonders interessant für interaktive und agentische Workflows.

Ein einfaches Beispiel

Ein Vertriebsmitarbeiter fragt einen internen Agent:

„Welche meiner Kunden haben offene Angebote über CHF 50'000, gleichzeitig überfällige Forderungen und in den letzten 30 Tagen keinen CRM-Kontakt?“

Diese Frage kombiniert mehrere Systeme.

Der Agent könnte:

1. CRM-Tool aufrufen.
2. ERP-Tool aufrufen.
3. Ergebnisse kombinieren.
4. Geschäftsregeln berücksichtigen.
5. Eine priorisierte Liste erstellen.

MCP kann dabei die Werkzeugschicht standardisieren.

Die eigentlichen Daten kommen jedoch weiterhin häufig über bestehende APIs, Datenbanken oder Services.

MCP sitzt damit häufig über APIs – nicht an ihrer Stelle.

Vier Integrationsmuster, die Unternehmen unterscheiden sollten

1. API – direkte synchrone Integration

Gut für:

• klar definierte Transaktionen
• Echtzeit-Abfragen
• deterministische Business-Prozesse
• System-to-System-Kommunikation

Beispiel: Auftrag aus Webshop an ERP senden.

2. Events / Messaging

Gut für:

• entkoppelte Architekturen
• hohe Skalierung
• asynchrone Prozesse
• mehrere Konsumenten

Beispiel: „CustomerUpdated“ Event löst Aktualisierungen in mehreren Systemen aus.

3. Batch / ETL

Gut für:

• grosse Datenmengen
• periodische Synchronisation
• Reporting und Data Warehouse

Beispiel: nächtlicher Export von Finanzdaten.

4. MCP – agentische Werkzeug- und Kontextschicht

Gut für:

• dynamische AI-Interaktion
• toolübergreifende Aufgaben
• natürliche Sprache als Einstieg
• flexible Orchestrierung
• Agenten, die je nach Kontext unterschiedliche Werkzeuge auswählen

Diese Muster konkurrieren nicht zwingend. Sie ergänzen sich.

Warum die neue MCP-Spezifikation 2026 relevant ist

Die MCP-Spezifikation vom 28. Juli 2026 führt unter anderem einen stateless Protocol Core ein. Das ist technisch interessant, weil MCP damit stärker in Richtung robuster, skalierbarer Serverarchitekturen entwickelt wird.

Für Unternehmen ist jedoch etwas anderes wichtiger:

MCP entwickelt sich von einem Experimentierstandard zu einer Integrationsoption, die immer mehr Plattformen aufgreifen.

Microsoft dokumentiert beispielsweise einen Business Central MCP Server und einen separaten AL MCP Server. Dadurch können AI Clients Business-Central-Funktionen beziehungsweise Entwicklungswerkzeuge über standardisierte MCP-Schnittstellen ansprechen.

Das macht MCP für Business-Application-Landschaften sehr konkret.

Wo MCP stark ist

Discovery

Ein Agent kann verfügbare Tools erkennen, statt dass jede Fähigkeit hart in den Prompt programmiert wird.

Kontextabhängige Orchestrierung

Der Agent entscheidet je nach Frage, welche Systeme er benötigt.

Menschliche Sprache als Interface

Der Anwender muss nicht wissen, welche API oder Tabelle angesprochen werden muss.

Cross-System Tasks

Ein Agent kann mehrere Tools kombinieren.

Erweiterbarkeit

Neue Tools können über einen MCP Server verfügbar gemacht werden, ohne den Client für jede Fähigkeit komplett neu zu bauen.

Wo ich weiterhin klassische APIs bevorzugen würde

Finanzbuchungen

Wenn ein definierter Prozess 100'000 Transaktionen verarbeitet, möchte ich keinen Agent, der jedes Mal kreativ entscheidet, welchen Tool-Pfad er verwendet.

Hochvolumige Synchronisation

MCP ist keine bessere ETL-Pipeline.

Kritische Echtzeit-Prozesse

Deterministische Schnittstellen, klare SLAs und vorhersehbares Fehlerverhalten bleiben zentral.

Datenreplikation

Wenn Systeme Daten laufend synchron halten müssen, sind Events, APIs oder Data-Plattformen passender.

Klare Machine-to-Machine-Workflows

Wenn A immer exakt B aufrufen soll, braucht es keine agentische Entscheidungsschicht.

Das wichtigste Architekturprinzip: Agentische Flexibilität oben, deterministische Stabilität unten

Ich würde eine moderne Architektur häufig in zwei Ebenen denken.

Deterministische Integrationsschicht

• APIs
• Events
• Queues
• Datenverträge
• Authentifizierung
• Monitoring
• Retry
• Idempotenz

Agentische Interaktionsschicht

• MCP Tools
• Resources
• Agent Logic
• Human Approval
• Prompt/Policy
• Context

Der Agent arbeitet mit stabilen Werkzeugen. Er ersetzt deren technische Qualität nicht.

Illustrativer Business Case: Account Manager Agent

Ein Unternehmen nutzt:

• CRM für Aktivitäten und Opportunities
• Business Central für Aufträge und offene Posten
• SharePoint für Verträge
• Ticket-System für offene Kundenprobleme

Der Wunsch lautet:

„Vor jedem Kundentermin möchte ich automatisch ein 360°-Briefing.“

Eine rein klassische Integration würde dafür wahrscheinlich ein neues Datenmodell oder einen zentralen Report bauen.

Ein agentischer Ansatz könnte anders aussehen:

Schritt 1

Agent erhält Kundennummer und Meeting-Kontext.

Schritt 2

Über definierte Tools werden aktuelle Informationen aus CRM, ERP und Tickets abgefragt.

Schritt 3

Relevante Vertragsdokumente werden als Resource bereitgestellt.

Schritt 4

Der Agent erstellt ein Briefing:

• Umsatzentwicklung
• offene Angebote
• offene Forderungen
• letzte Kontakte
• aktuelle Probleme
• mögliche Gesprächspunkte

Schritt 5

Der Nutzer kann nachfragen:

„Warum ist Auftrag 4711 blockiert?“

Jetzt nutzt der Agent nur das dafür passende Tool.

Das ist ein sehr guter MCP-Use-Case, weil die benötigten Daten dynamisch von der Nutzerfrage abhängen.

Die Synchronisation von Aufträgen zwischen CRM und ERP würde ich trotzdem weiterhin klassisch lösen.

Security: Ein Tool ist eine Berechtigung

Mit MCP bekommt ein Agent Zugriff auf Werkzeuge. Das sollte sicherheitstechnisch genau so ernst genommen werden wie API-Berechtigungen.

Wichtige Prinzipien:

• Least Privilege
• getrennte Read- und Write-Tools
• klare Identität
• Umgebungsgrenzen
• Logging
• Human Approval für kritische Aktionen
• Tool-Allowlisting
• Secrets nicht im Prompt
• begrenzte Datenrückgabe

Ein Agent, der nur lesen muss, sollte keine Update- oder Delete-Tools sehen.

Das klingt selbstverständlich. In frühen Agent-Prototypen wird es trotzdem schnell vergessen, weil Bequemlichkeit im Vordergrund steht.

Monitoring wird schwieriger – und wichtiger

Eine klassische Integration hat einen klaren Pfad.

Agentische Systeme können je nach Kontext unterschiedliche Tools verwenden. Deshalb muss Observability nicht nur technische Fehler, sondern auch Entscheidungen sichtbar machen:

• welches Tool wurde gewählt?
• mit welchen Parametern?
• welches Ergebnis kam zurück?
• wurde eine Aktion freigegeben?
• wie lange dauerte die Kette?
• was kostete der AI-Aufruf?

Ohne diese Transparenz werden Agents im Betrieb schwer steuerbar.

Eine einfache Entscheidungshilfe

Nimm eine API, wenn …

… der Ablauf klar, wiederholbar und deterministisch ist.

Nimm Events, wenn …

… mehrere Systeme auf Änderungen reagieren sollen und lose Kopplung wichtig ist.

Nimm Batch/ETL, wenn …

… grosse Datenmengen periodisch bewegt werden.

Prüfe MCP, wenn …

… ein AI Agent dynamisch zwischen mehreren Tools, Datenquellen oder Aktionen wählen soll.

Und sehr häufig lautet die richtige Architektur:

API + Events + MCP.

Nicht entweder/oder.

Wie ich MCP in einer Enterprise-Architektur einführen würde

Nicht mit 30 Servern gleichzeitig.

Schritt 1 – Ein Read-only-Use-Case

Ein Agent soll Informationen aus zwei Systemen zusammenstellen. Noch keine Write-Aktionen.

Schritt 2 – Tool Contracts definieren

Jedes Tool bekommt einen klaren Zweck, minimale Parameter und begrenzte Rückgabe.

Schritt 3 – Identity und Authorization

Der Agent erhält nicht einfach einen technischen Superuser. Zugriff sollte dem Nutzer- oder Prozesskontext entsprechen.

Schritt 4 – Observability

Tool-Aufruf, Laufzeit, Fehler, Datenmenge und Freigaben sichtbar machen.

Schritt 5 – Human Gate für Writes

Erst Entwürfe, dann ausgewählte Aktionen. Kritische Transaktionen bleiben kontrolliert.

Schritt 6 – Wiederverwendbarkeit prüfen

Ein gutes MCP Tool sollte nicht nur für einen Demo-Prompt funktionieren, sondern eine fachlich verständliche Fähigkeit darstellen.

Was gute MCP Tools auszeichnet

Ein Tool sollte klein genug sein, damit ein Modell seine Wirkung versteht.

Schlecht:

`executeAnything(action, payload)`

Besser:

`getCustomerOpenItems(customerId)`

`getSalesOpportunities(customerId)`

`createInternalFollowUp(customerId, dueDate, note)`

Klare Tools reduzieren Interpretationsspielraum, verbessern Logging und erleichtern Berechtigungen.

Die nächste Integrationsschuld könnte „Tool Sprawl“ heissen

MCP vereinfacht das Bereitstellen von Agent-Fähigkeiten. Dadurch kann schnell eine neue Form von Wildwuchs entstehen: mehrere Server für dieselben Systeme, unterschiedlich benannte Tools, unklare Owners und doppelte Berechtigungen.

Deshalb braucht auch die MCP-Schicht Governance:

• zentraler Katalog
• Naming
• Owner
• Versionierung
• Deprecation
• Security Review
• Testfälle
• Monitoring

Sonst lösen wir API-Spaghetti ab und bauen MCP-Spaghetti.

Drei Fragen vor jedem MCP-Projekt

1. Braucht der Use Case wirklich dynamische Agent-Entscheidungen oder reicht ein normaler Workflow?
2. Welche bestehenden APIs können als stabile Grundlage wiederverwendet werden?
3. Wie verhindern wir, dass ein flexibles Agent-Interface geschäftskritische Integrationen unnötig nondeterministisch macht?

Wenn diese Fragen sauber beantwortet sind, wird MCP zu einer wertvollen Ergänzung – statt zum nächsten Buzzword-Layer.

Fazit: MCP verändert die Benutzeroberfläche zur Systemlandschaft

APIs haben Systeme miteinander verbunden.

MCP kann AI Agents eine standardisierte Möglichkeit geben, diese Systeme als Werkzeuge zu verwenden.

Das ist ein grosser Schritt, weil Nutzer künftig weniger wissen müssen, wo eine Information liegt oder welche Anwendung sie bedienen müssen.

Aber unter dieser neuen Interaktionsschicht braucht es weiterhin dieselben Dinge wie vorher:

saubere Daten, klare Ownership, sichere Berechtigungen, stabile APIs und gutes Monitoring.

MCP beseitigt Integrationsarbeit nicht.

Es macht gute Integration für AI wertvoller.