Was ist MCP (Model Context Protocol)?

MCP ist ein offener Standard, mit dem KI-Anwendungen über ein einziges Protokoll auf externe Tools und Daten zugreifen statt über eigene Integrationen. Im November 2024 von Anthropic vorgestellt und binnen eines Jahres zum Industriestandard geworden, leistet es für KI-Agenten ungefähr das, was ein gemeinsamer Anschluss für Peripheriegeräte leistete – daher der Satz vom “USB-C für KI”, zu dem jede Erklärung greift. Die schärfere Sicht für Backend-Entwickler: ein MCP Server ist ein API-Adapter. Ihr bestehendes Backend weiß bereits, wie es Anfragen beantwortet; MCP ist der Weg, es auffindbar und aufrufbar zu machen – für ein KI-Modell statt für handgeschriebenen Client-Code.

Das Wichtigste in Kürze

Ein MCP Server, der ein vorhandenes Backend umhüllt

// JavaScript / Node.js — an MCP server wrapping an existing backend API
import { McpServer } from '@modelcontextprotocol/server';
import { z } from 'zod';

const server = new McpServer({ name: 'tasks', version: '1.0.0' });

// A tool is a described, discoverable wrapper over the API you already have
server.registerTool(
  'query_tasks',
  { description: 'List tasks by status', inputSchema: z.object({ status: z.string() }) },
  async ({ status }) => {
    const res = await fetch(`${BASE}/classes/Task?where=${q({ status })}`, {
      headers: { 'X-Parse-Application-Id': APP_ID, 'X-Parse-REST-API-Key': KEY },
    });
    return { content: [{ type: 'text', text: await res.text() }] };
  }
);
// The agent discovers this tool at runtime and decides when to call it —
// same backend, same ACLs and rate limits; just a new kind of client.

// Flutter / Dart — Back4app Flutter SDK
// One backend, two kinds of consumers: your app via the SDK…
final tasks =
    await QueryBuilder<ParseObject>(ParseObject('Task')).query();
// …and AI agents via an MCP server wrapping the SAME REST/GraphQL API,
// exposing "query_tasks" and "run_function" as tools the model can call.
// Same data, same ACLs, same rate limits — a new client type, not a new backend.

// iOS / Swift — Back4app Swift SDK
// One backend, two kinds of consumers: your app via the SDK…
let tasks = try await Task_.query().find()
// …and AI agents via an MCP server wrapping the SAME REST/GraphQL API,
// exposing "query_tasks" and "run_function" as tools the model can call.
// Same data, same ACLs, same rate limits — a new client type, not a new backend.

// Android / Kotlin — Back4app Android SDK
// One backend, two kinds of consumers: your app via the SDK…
val tasks = ParseQuery.getQuery<ParseObject>("Task").find()
// …and AI agents via an MCP server wrapping the SAME REST/GraphQL API,
// exposing "query_tasks" and "run_function" as tools the model can call.
// Same data, same ACLs, same rate limits — a new client type, not a new backend.

Der JavaScript-Tab enthält die ganze Idee in fünfzehn Zeilen: Ein Tool query_tasks ist ein beschriebener, auffindbarer Wrapper um einen REST-Aufruf, den das Backend ohnehin bedient. Der Agent liest die Beschreibung zur Laufzeit, entscheidet, wann das Tool passt, und ruft es auf – und trifft dabei dieselben Endpoints, ACLs und Rate Limits wie Ihre Anwendung. Ein neuer Typ von Client, kein neues Backend.

Wie MCP das N×M-Integrationsproblem löst

Vor MCP bedeutete das Verdrahten von N KI-Clients mit M Tools bis zu N × M Einzelintegrationen. Ein gemeinsames Protokoll bringt das auf N + M herunter: Jeder Client und jeder Server setzt MCP einmal um. Die offizielle Architektur benennt drei Rollen – der Host ist die KI-Anwendung; er startet pro Verbindung einen Client; jeder Server liefert eine Fähigkeit – über JSON-RPC, mit stdio für lokale Server auf derselben Maschine und Streamable HTTP für entfernte (der ursprüngliche Transport HTTP+SSE gilt inzwischen als veraltet).

Die drei Primitive

Ein einzelner Datenbankserver stellt typischerweise alle drei bereit: ein query-Tool, eine schema-Resource und einen Few-Shot-prompt für häufige Fragen – “das kann ich, das weiß ich, und so fragen Sie mich.”

MCP vs. API vs. Function Calling

Die beiden Vergleiche lösen sich sauber auf. Gegenüber einer API: MCP ersetzt sie nicht – es umhüllt sie und ergänzt die Entdeckung zur Laufzeit, sodass das Modell den Aufruf wählt statt Ihres Anwendungscodes. Gegenüber Function Calling: Function Calling ist das Modell, das eine strukturierte Anfrage ausgibt; MCP standardisiert, wie diese Anfrage über Anwendungen und Anbieter hinweg entdeckt und ausgeführt wird. MCP ergänzt Standardisierung und Portabilität, keine Fähigkeit – alles, was MCP tut, könnte maßgeschneidertes Function Calling für eine einzelne Integration auch tun; MCP sorgt dafür, dass es ohne Umschreiben überall funktioniert.

Die Sicherheitsfläche, ehrlich betrachtet

Der Abschnitt, den neutrale Seiten auslassen und Sicherheitsanbieter überverkaufen. Nicht das Protokoll ist die Bedrohung, sondern das Vertrauensmodell. Prompt Injection reist über Tool-Ausgaben herein – ein Dokument, das ein Tool zurückgibt, kann Anweisungen enthalten, denen das Modell anschließend folgt. Tool Poisoning versteckt schädliche Anweisungen in der Beschreibung eines Tools, die das Modell liest, bevor ein Mensch sie zu Gesicht bekommt – inzwischen bei OWASP erfasst. Rug Pulls: Ein einmal freigegebener Server kann seine Tool-Definitionen später ändern. Und der stille Punkt: die Lieferkette der Community-Server – es gibt Tausende davon, und wer einen installiert, gewährt ihm einen Brückenkopf im Kontext seines Agenten. Die Gegenmaßnahmen sind gewöhnliche Sicherheitsdisziplin, angewandt auf eine neue Fläche: Scopes nach dem Prinzip der geringsten Rechte pro Server, menschliche Freigabe für Tool-Aufrufe mit Wirkung, das Pinnen und Allowlisten der Server, denen Sie vertrauen, echte Authentifizierung auf entfernten Servern – und einem MCP Server niemals weiter reichende Zugangsdaten geben, als die Aufgabe verlangt.

Die Spezifikation heute

MCP bewegt sich schnell, und die meisten Erklärtexte sind Mitte 2025 eingefroren – ein Aktualitätshinweis, den es zu pflegen lohnt. Der Transport hat sich auf Streamable HTTP verdichtet (HTTP+SSE ist veraltet); entfernte Server haben sich auf Authentifizierung im OAuth-Stil geeinigt; die Revision vom 2026-07-28 machte das Protokoll zustandslos – kein Handshake, keine Sessions, Metadaten pro Anfrage, ein server/discover-Aufruf – und erklärte Roots, Sampling und Logging für veraltet. Das größere Signal ist die Steuerung: Ende 2025 wurde das Protokoll an eine herstellerneutrale Open-Source-Stiftung übergeben – das strukturelle Kennzeichen eines echten Standards und nicht der Konvention eines einzelnen Anbieters. Die praktische Lehre für Entwickelnde: Pinnen Sie eine Spezifikationsversion, lesen Sie vor dem Upgrade das Changelog und behandeln Sie “MCP” als bewegliches Ziel mit stabilem Kern.

Typische Anwendungsfälle

• Coding-Agenten – IDE-Assistenten, die Ihr Repository, Ihre Datenbank und Ihren Issue-Tracker über Server erreichen statt über eigens gebaute Plugins.
• Unternehmensdaten im Chat – ein Assistent, der interne Systeme abfragt, jedes davon als berechtigungsgeprüfter MCP Server umhüllt.
• Backend bereitstellen – eine bestehende REST-/GraphQL-API in agentenaufrufbare Tools verwandeln, ohne sie neu zu bauen.
• Desktop- und Workflow-Automatisierung – lokale stdio-Server, die das Modell mit Dateien und Anwendungen auf einer Maschine verbinden.
• Portabilität über Anbieter hinweg – ein Server für jeden Host, der MCP spricht, sodass eine Integration jede einzelne Modellentscheidung überdauert.

Sollten Sie MCP verwenden? Eine Entscheidungsmatrix

Grenzen und Trade-offs

• Es ist ein bewegliches Ziel. Die schnelle Entwicklung der Spezifikation verlangt von Integrationen Versionspinning und Wachsamkeit beim Changelog; “unterstützt MCP” ist eine Aussage mit Verfallsdatum.
• Das Vertrauensmodell ist neu. Tool-Beschreibungen und -Ausgaben sind Angriffsfläche; Agenten, die auf ungeprüften Servern handeln, sind das curl \| bash dieser Epoche.
• Overhead unterhalb des Umschlagpunkts. Für eine einzelne Integration ergänzt MCP ein Protokoll und einen Serverprozess, wo ein Funktionsaufruf genügt hätte.
• Entdeckung verschiebt die Kontrolle zum Modell. Tool-Auswahl zur Laufzeit ist mächtig und weniger vorhersehbar als fest codierte Aufrufe – Auditing und Freigaben zählen dadurch mehr, nicht weniger.
• Es umhüllt, es repariert nicht. Ein MCP Server über einer schlecht abgesicherten API stellt diese API Agenten nur schneller bereit; die eigentliche Arbeit leisten weiterhin die darunterliegenden Berechtigungen.

MCP mit Back4app

Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Die Sicht vom API-Adapter passt hier von selbst: Eine Back4app-Anwendung stellt bereits die Fläche bereit, die ein MCP Server umhüllt – REST und GraphQL über jede Klasse, dazu Cloud-Code-Funktionen –, sodass es für den Agentenzugriff genügt, find objects, run function und read schema auf Tool-Definitionen abzubilden, wie es die Code-Tabs skizzieren. Der Sicherheitsabschnitt wird damit zu konkreter Anleitung: Geben Sie dem MCP Server einen eingegrenzten Schlüssel, niemals den Master Key; lassen Sie die ACLs und Klassenberechtigungen der Plattform begrenzen, was die Aufrufe eines Agenten berühren dürfen, genau wie sie Ihre Anwendung begrenzen; und legen Sie unumkehrbare Aktionen hinter Cloud Functions mit eigenen Prüfungen statt hinter rohen Tabellenzugriff. Der Agent wird zu einem weiteren Client eines Backends, das bereits weiß, wie man Nein sagt.