MCP-FAQ: Die 12 häufigsten Einwände – ehrlich beantwortet

Warum dieser Artikel?

Ich führe jede Woche mehrere Gespräche mit CTOs und Engineering-Leads über MCP. Die Fragen sind erstaunlich konsistent – und die Antworten verdienen mehr als Marketing-Phrasen. Wir haben die strategische Einordnung und die Bauanleitung bereits geschrieben. Hier kommt der dritte Teil: die echten Einwände.

Auf einen Blick: MCP vs. REST-API vs. Function Calling

Bevor wir in die 12 Einwände gehen – die wichtigste Tabelle des Artikels:

Dimension	REST-/GraphQL-API	Function Calling	MCP
Primäre Zielgruppe	Entwickler	Ein LLM-Anbieter	Jeder Agent (Claude, ChatGPT, Cursor, …)
Standardisiert über Anbieter	–	Nein (pro Anbieter eigener Adapter)	Ja (offenes Protokoll)
Discovery (Tools auffindbar)	OpenAPI optional	Manuell pro Call deklariert	Eingebaut (tools/list)
Selbstbeschreibende Tool-Semantik	Nein	Teilweise (JSON-Schema)	Ja (Name, Description, Schema, Hints)
Resources mit URIs (zitierbar)	–	–	Ja (resource://…)
Prompts / Templates	–	–	Ja (server-seitig vorgefertigt)
Auth-Standard	API-Keys / OAuth (frei)	Nicht definiert	OAuth 2.1 + Dynamic Client Registration
Confirmation-Dialog für destruktive Aktionen	App-spezifisch	–	Native Client-Unterstützung
Transport	HTTP	Inline im LLM-Call	HTTP / SSE / stdio
Marketplaces & Discovery-Layer	–	–	Claude, ChatGPT, Cursor, mcp.so, glama.ai
Lock-in beim Anbieterwechsel	Niedrig	Hoch (Adapter neu schreiben)	Niedrig
Aufwand für ersten produktiven Einsatz	Stunden bis Tage	Stunden	1–3 Tage pro Server

Faustregel: REST ist die Tür für Entwickler. Function Calling ist eine Feature pro LLM. MCP ist das Protokoll, das beides für Agenten nutzbar und anbieterunabhängig macht. Du brauchst typischerweise alle drei – aber MCP ist die Schicht, die deine Investition vor dem nächsten Anbieterwechsel schützt.

1. „Wir haben doch schon eine REST-API. Was bringt MCP zusätzlich?"

Eine REST-API ist eine Maschine-zu-Maschine-Schnittstelle für Entwickler. MCP ist eine Maschine-zu-Agent-Schnittstelle für Sprachmodelle.

Eine REST-API ist eine Maschine-zu-Maschine-Schnittstelle für Entwickler. MCP ist eine Maschine-zu-Agent-Schnittstelle für Sprachmodelle.

Konkret fehlt deiner REST-API für Agenten:

• Selbstbeschreibende Tools mit semantischen Namen und Nutzungshinweisen
• Standardisierte Discovery (jeder MCP-Client weiß, wie er deine Tools findet)
• Strukturierte Resources mit URIs, die Agenten zitieren können
• Einheitliche Auth-Standards über OAuth 2.1 mit Dynamic Client Registration

Dein OpenAPI-Schema hilft Entwicklern. Ein MCP-Server hilft Agenten direkt – ohne dass jemand einen Custom-Adapter zwischen ChatGPT und deiner API bauen muss.

Kurzform: REST = Tür für Entwickler. MCP = Tür für Agenten. Du brauchst beide.

2. „Können wir nicht einfach Function Calling nutzen?"

Kannst du. Aber dann baust du den Adapter für jeden Anbieter (OpenAI, Anthropic, Google, …) selbst und pflegst ihn. MCP ist genau die Standardisierungsschicht, die diesen Code überflüssig macht.

	Function Calling	MCP
Pro Anbieter implementieren	Ja	Nein
Discovery-Standard	Nein	Ja
Auth-Standard	Nein	Ja (OAuth 2.1)
Resources & Prompts	Nein	Ja
Native Marketplaces	Nein	Ja (Claude, ChatGPT, Cursor)

Function Calling ist eine Feature. MCP ist ein Protokoll. Du brauchst beides – aber das Protokoll überlebt den Anbieterwechsel.

3. „Was kostet uns das – Initial und laufend?"

Realistische Zahlen aus unseren Projekten:

Posten	Aufwand	Externe Kosten/Monat
Erster MCP-Server (3–5 Tools)	1–3 Entwicklertage	0 €
OAuth-Layer (wenn nicht vorhanden)	3–10 Tage	0–50 € (Auth0/Clerk)
Hosting (Cloudflare/Railway/Supabase)	–	0–50 € bis ~10k Calls/Tag
Logging & Observability	1–2 Tage	0–100 € (OTel + Grafana Cloud)
Listing in Marketplaces	0,5 Tage	0 €

Realistisch starten kannst du mit unter 100 € im Monat und einem einzigen Engineer für 1–2 Wochen. Der Hauptkostenfaktor ist nicht Infrastruktur, sondern gutes Tool-Design.

4. „Wie sicher ist MCP wirklich? Geben wir damit nicht alle Daten an OpenAI?"

Nein. Drei Punkte, die oft missverstanden werden:

1. Du entscheidest, was der Server exponiert. MCP ist nur ein Protokoll – wenn du nur ein search_customers-Tool ohne Email-Adressen baust, sieht der Agent auch nichts anderes.
2. OAuth scoped die Permissions pro User. Der Agent erbt die Rechte des authentifizierten Users, nicht mehr.
3. Daten verlassen deinen Server nur dann an den Modell-Anbieter, wenn der User sie aktiv im Chat verwendet. Bei selbst-gehosteten Modellen oder lokalen Clients (Claude Desktop, lokale LLMs) verlassen sie deine Infrastruktur gar nicht.

Wer wirklich nichts an OpenAI/Anthropic schicken will, betreibt MCP-Server hinter SSO nur für Claude Code im eigenen VPN oder kombiniert sie mit einem Privacy Router, der sensible Felder maskiert.

5. „Wer darf was? Wie funktionieren Permissions?"

MCP definiert das Protokoll, nicht das Berechtigungsmodell. Das ist Feature, nicht Bug – du nutzt das, was du eh schon hast:

• Pro User: OAuth-Scopes oder dein bestehendes RBAC
• Pro Tool: Im Server-Code prüfen, welche Tools welcher User aufrufen darf
• Pro Aktion: Der MCP-Client zeigt dem User vor jeder destruktiven Aktion einen Bestätigungsdialog (Anthropic, OpenAI und Cursor unterstützen das nativ)

Best Practice aus unseren Implementierungen:

Read-only Tools  → ohne Bestätigung erlaubt
Schreib-Tools    → Confirmation-Dialog im Client
Lösch-Tools      → Confirmation + Audit-Log mit User-ID

6. „Was, wenn der Agent etwas Falsches macht – wer haftet?"

Drei Schichten, die du bauen solltest:

1. Idempotency-Keys in jedem schreibenden Tool – verhindert Doppelausführung bei Retries
2. Soft-Delete + Audit-Log mit User-ID, Tool-Name, Input und Timestamp
3. Confirmation-Pflicht für alles, was nicht trivial reversibel ist

Haftungsmäßig: Der User löst die Aktion aus, der Agent führt sie in seinem Namen aus, dein Server validiert. Das ist die gleiche Logik wie bei jeder anderen API – nur mit einem Sprachmodell als Client.

7. „Was muss mein Team können, um das zu bauen?"

Erstaunlich wenig Neues. Wenn dein Team eine REST- oder GraphQL-API bauen kann, kann es auch einen MCP-Server bauen.

Skill	Schon da?	Lernkurve
TypeScript oder Python	meist ja	–
HTTP-Server (Node, Hono, FastAPI)	ja	–
OAuth 2.1 / OIDC	oft halbgar	1–2 Wochen
Zod / Pydantic Schemas	ja	–
MCP-SDK selbst	nein	1–2 Tage
Prompt-Design für Tool-Beschreibungen	nein	1 Woche bewusste Übung

Das eigentliche Skill-Upgrade ist nicht die Library, sondern: Wie schreibe ich Tool-Beschreibungen so, dass der Agent sie korrekt nutzt? Das ist die neue Disziplin – Prompt-Engineering für API-Surfaces.

8. „Müssen wir jetzt alle Engineers umschulen?"

Nein. Du brauchst eine Person, die MCP wirklich versteht und intern sauber dokumentiert. Den Rest des Teams ziehst du via Pairing nach.

Was du schon heute in jeder Stellenausschreibung ergänzen solltest:

• „Erfahrung mit OAuth 2.1, OIDC und Dynamic Client Registration"
• „Bonus: Erfahrung mit MCP, LangGraph oder Agent-Tooling"

In zwölf Monaten wird der Bonus zum Pflichtkriterium. Wer jetzt einstellt, hat es leichter, weil das Skillset noch unterbewertet ist.

9. „Lohnt sich das für uns – wir haben nur 50 interne Mitarbeiter, kein SaaS?"

Gerade dann. Interne MCP-Server sind oft lukrativer als externe, weil:

• Sie nur hinter dein SSO müssen, kein OAuth 2.1 für Fremde
• Du den Workflow deiner Mitarbeiter kennst – die ersten 3 Tools sind offensichtlich
• Der ROI sofort messbar ist (Zeitersparnis pro Mitarbeiter × 50)

Beispiel aus einem aktuellen Projekt: Ein interner MCP-Server für ein ERP, gebaut in 5 Tagen, spart dem 40-Personen-Operations-Team ~60 Minuten pro Person und Tag. Rechnung: 40 × 1h × 200 Tage = 8.000 Stunden pro Jahr.

10. „Was, wenn MCP in zwei Jahren wieder weg ist?"

Mögliches Risiko, aber unwahrscheinlich. Drei Gründe:

1. Anthropic, OpenAI, Google, Microsoft haben es alle adoptiert – das war 2024 noch nicht so. Wenn ein Standard von vier Hyperscalern getragen wird, stirbt er nicht leise.
2. Die Investition ist klein und reversibel. Dein MCP-Server ist ein dünner Adapter um deine bestehende API. Falls etwas Besseres kommt, ersetzt du den Adapter, nicht das Backend.
3. Selbst wenn das Protokoll ersetzt wird, behalten Tool-Design, OAuth-Setup und Logging ihren Wert für jeden Nachfolger.

Asymmetrie: Wenn MCP bleibt, bist du gewinner. Wenn MCP wechselt, verlierst du 1–2 Wochen. Klassisches Positive-EV-Spiel.

11. „Müssen wir jetzt sofort alles MCP-fähig machen?"

Nein – das wäre der schnellste Weg, das Projekt zu killen. Empfehlung:

1. Drei Workflows identifizieren, die deine Nutzer am häufigsten anfassen
2. Genau diese drei als MCP-Tools bauen, sonst nichts
3. Mit echten Nutzern testen (intern oder ein einziger Pilot-Kunde)
4. Erst dann breit ausrollen

Lemlist macht das mit nur 3 Tools. Linear macht das mit 5. Du musst nicht 50 bauen.

12. „Wie messen wir, ob es funktioniert?"

Konkrete KPIs aus unseren Projekten:

Metrik	Sinnvoller Zielwert nach 3 Monaten
Aktive Nutzer mit verbundenem MCP-Server	5–15 % deiner Bestandskunden
Tool-Calls pro aktivem User pro Woche	> 10
Tool-Success-Rate (kein isError)	> 95 %
Häufigste 3 Tools	sollten 60–80 % der Calls ausmachen
Avg. Latenz pro Tool-Call	< 800 ms

Wenn diese Zahlen stimmen, hast du einen MCP-Server, der echten Wert schafft. Wenn nicht, sind meist die Tool-Beschreibungen oder die Auswahl der ersten 3 Tools schuld.

Kein Einwand mehr übrig?

Wenn du diese 12 Fragen beantworten kannst, hast du intern alle Argumente, um in Woche 1 anzufangen. Wenn nicht: Nimm die Fragen mit ins nächste Engineering-Meeting und sieh, welche bei euch wirklich offen sind.

Wir helfen Unternehmen genau in dieser Phase – von „Sollten wir das machen?" bis „Wie sieht der Server in Production aus?". Wenn du das nicht alleine angehen willst:

→ MCP-Sparring mit uns buchen

---

Weiterlesen: Warum kein Unternehmen mehr an MCP vorbeikommt · Schritt-für-Schritt: MCP-Server für REST/GraphQL bauen · MCP für Einsteiger