Was ist ein MCP-Server?

Ein KI-Modell ohne Zugang zu deinen Systemen ist wie ein brillanter neuer Kollege, dem du am ersten Tag keinen Schlüssel gibst, keinen Login, keine Telefonliste. Klug ist er. Nur kommt er an nichts ran. Genau das war jahrelang der Normalzustand bei KI-Tools — und ein MCP-Server ist der Schlüsselbund.

Also die Kurzfassung, falls du es eilig hast. Ein MCP-Server ist ein kleines Programm, das ein einzelnes System — dein CRM (Pipedrive, HubSpot), deine Datenbank, dein Buchhaltungstool (DATEV, sevDesk) — für KI-Apps wie Claude Desktop, ChatGPT oder Cursor erreichbar macht. Über einen offenen Standard, das Model Context Protocol. Du baust den Zugang einmal, und jede KI-App, die MCP spricht, kann ihn sofort nutzen.

Für die großen Standard-Tools gibt es solche Server schon fertig. Anschließen, läuft. Selbst bauen musst du nur für das, was nur dir gehört — und das ist ein Nachmittag, kein Projekt. Der Rest des Artikels erklärt, warum das so ist. Schritt für Schritt, von vorne.

Was man vor MCP gemacht hat

Bevor wir zu MCP kommen, muss eine andere Frage geklärt sein: Wie kommt ein KI-Modell überhaupt an Antworten? Daran hängt alles, was danach gebaut wurde. Vier Stufen — jede hat ein Problem der vorigen gelöst, und jede hatte ihre eigene Grenze.

1. Das eingefrorene Gehirn — die Trainingsdaten. Ein Sprachmodell wie GPT-4 oder Claude wird auf einem riesigen Datenberg trainiert, der bis zu einem festen Stichtag reicht — dem Cutoff-Date. Alles, was nach diesem Datum passiert ist, kennt das Modell schlicht nicht. Frag mal ein älteres Modell „Was ist das neueste Claude-Modell?” — und es nennt dir mit voller Überzeugung einen Versionsnamen, der seit Monaten veraltet ist. Nicht aus Dummheit, sondern weil das neuere schlicht nicht in seinem Wissen steckt. Das ist, als würdest du heute mit einer Landkarte von 1970 durch Deutschland fahren. Alte Infos, mehr nicht.

Und mit deinem Firmenwissen sieht es noch schlimmer aus — das stand in keinem Trainings-Datensatz, nirgends.

2. Werkzeuge in die Hand — Function Calling. Der erste Schritt aus der Box war Function Calling (OpenAI Mitte 2023, Anthropic kurz danach als Tool Use). Damit konnte das Modell zum ersten Mal Werkzeuge selber rufen — eingebaut kamen Web Search, Code Interpreter und Calculator. Plötzlich konnte die KI googeln, rechnen, in einer Tabelle nachsehen. Wie das technisch genau läuft, würde hier zu weit gehen — dazu kommt noch ein eigener Artikel.

Die Grenze: Diese Tools sind generisch. Web Search kennt nicht deinen internen Wiki-Eintrag.

3. Eigene Daten reinholen — RAG und Embeddings. Für das Firmenwissen kam die nächste Stufe: RAG (Retrieval-Augmented Generation). In einem Satz: Bevor das Modell antwortet, holt das System die relevanten Stücke aus deinen Dokumenten — PDFs, Tickets, Wiki — und legt sie ihm direkt in den Prompt. Möglich gemacht über Embeddings und eine Vektordatenbank. Auch das ist ein eigenes Thema, das ich in einem separaten Artikel aufmache.

Die Grenze: RAG ist passives Lesen. Etwas tun kann das Modell damit immer noch nicht.

4. Echte Anbindungen — und das Chaos. Was wirklich fehlte, war Zugang zu echten Tools: in Asana ein Ticket öffnen, in Pipedrive einen Lead anlegen, in GitHub einen Pull Request kommentieren. Das geht prinzipiell genauso wie jede andere Software-zu-Software-Kommunikation: über eine API. Du schickst eine Anfrage an einen Server („Hol mir alle offenen Tickets”), authentifizierst dich mit einem Token, kriegst die Antwort als JSON zurück. Standard-Webkram.

Das Modell konnte das technisch — sobald Function Calling existierte, konnte jede KI-Anwendung ihrem Modell Asana-Tools, Pipedrive-Tools, was auch immer in die Hand geben. ChatGPT bekam 2023 seine Plugins. Cursor wob Tool-Integrationen direkt in die IDE. Microsoft baute Copilot-Connectoren.

Und genau hier fängt das eigentliche Problem an.

Jede dieser Anbindungen war proprietär. Eine Asana-Integration, die für ChatGPT gebaut war, lief nicht mit Claude. Eine für Claude lief nicht in Cursor, eine für Cursor nicht in Microsoft Copilot. Jedes KI-Produkt und jedes Tool, das mitspielen wollte, musste sich mit jedem anderen einzeln verkabeln.

Rechne das kurz durch: Drei KI-Apps — sagen wir Claude Desktop, Cursor und ein selbstgebauter Bot — die an drei Firmensysteme sollen, etwa dein Pipedrive, dein GitHub und dein Notion. Das sind neun Verbindungen. Bei sechs Apps und zehn Systemen sind es schon sechzig. Der Aufwand wächst nicht mit jedem neuen Tool, er wächst mit jeder neuen Kombination.

Ein Fass ohne Boden.

Wenn man die vier Stufen mal nebeneinander stellt, sieht der Stand vor MCP so aus:

Was hier fehlte, war keine neue Fähigkeit, sondern eine gemeinsame Sprache für diese letzte Stufe — eine, auf die sich alle einigen, statt dass jeder seine eigene baut. Und für so eine gemeinsame Sprache gibt es ein Wort.

Was ein Protokoll ist — kurz

Ein Protokoll ist nichts weiter als eine Vereinbarung, wie zwei Seiten miteinander reden. Eine feste Umgangsform. Das bekannteste Beispiel benutzt du täglich, ohne es zu merken: HTTP. Jedes Mal, wenn du eine Website öffnest, einigen sich dein Browser und der fremde Server über HTTP darauf, wer was in welcher Reihenfolge schickt. Niemand handelt das pro Website neu aus — alle halten sich an dasselbe Protokoll. Genau das ist der Witz daran: Einer legt die Regeln fest, alle anderen hängen sich dran.

Ein Protokoll speziell für KI-Anwendungen und Tools wäre der Generalschlüssel, den die ganze proprietäre Brückenbauerei aus Stufe 4 obsolet macht. Und genau das ist MCP.

Was ein MCP-Server dann genau ist

MCP — das Model Context Protocol — ist dieses gemeinsame Protokoll. Ende 2024 von Anthropic veröffentlicht, und zwar bewusst als offener Standard. Offen heißt: Er gehört niemandem, jeder darf ihn benutzen, keiner muss um Erlaubnis fragen. Deshalb haben die anderen KI-Anbieter ihn übernommen, statt dagegen anzukämpfen — OpenAI in ChatGPT, Microsoft in Copilot, Cursor in seiner IDE, JetBrains in den eigenen Entwicklungstools. Ein offener Standard, dem alle folgen, ist für jeden mehr wert als die eigene Insellösung.

Dasselbe ist mal mit USB passiert. Früher hatte jedes Gerät seinen eigenen Stecker, jeweils ein anderes Kabel, jeweils ein eigener Krampf. Dann kam USB, ein Stecker für alles. Du baust nicht mehr pro Kombination, du baust pro Gerät einmal.

So weit das Protokoll. Der MCP-Server ist jetzt die konkrete Seite davon: ein kleines Programm, das genau ein System nach diesem Standard bereitstellt.

Die Aufteilung ist bewusst simpel. Auf der einen Seite die KI-Anwendung — Claude Desktop, Cursor, was du nutzt. Auf der anderen ein kleines Programm direkt vor deinem System. Das Modell redet nie direkt mit deiner Datenbank — immer über dieses Zwischenstück. Eine Schicht dazwischen, mit Absicht.

Diese Schicht stellt dem Modell drei Dinge bereit:

• Tools — Aktionen, die das Modell auslösen kann. „Lege einen Lead in Pipedrive an”, „Verschicke eine Rechnung über Stripe”, „Erstelle ein Ticket in Linear”.
• Ressourcen — Daten, die es lesen darf. Ein Notion-Dokument, ein Eintrag in deiner Postgres, der letzte GitHub-Commit.
• Vorlagen — fertige Befehle, die ein Mensch per Klick auslöst.

Und der wichtigste Punkt, den die meisten halt überlesen: Du entscheidest, was die KI tun darf — nicht die KI selbst. Sie sieht nur die Aktionen, die du im Server-Code freigibst, und kann nur das tun, was dort steht.

Die KI fragt. Der MCP-Server antwortet — oder eben nicht.

Wie das in echt aussieht

Genug Theorie — schauen wir uns zwei echte Stücke an. Eins von außen, eins von innen.

Das von außen ist die Konfiguration: die Stelle, an der du deiner KI-Anwendung sagst, welchen Server sie überhaupt starten soll. Mehr ist es nicht — ein Eintrag mit einem Namen und dem Startbefehl:

{
  "mcpServers": {
    "firmen-crm": {
      "command": "node",
      "args": ["./mcp-server/index.js"]
    }
  }
}

Das war die Anmeldung. Ab hier weiß die KI-Anwendung: Es gibt einen Server namens firmen-crm, und so starte ich ihn.

Das von innen ist der Server selbst. Hier wird ein Tool definiert — und „definieren” heißt: Du gibst ihm einen Namen, eine Beschreibung in normalem Deutsch, die erwarteten Eingaben, und die Funktion, die am Ende läuft:

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { z } from "zod";

const server = new McpServer({ name: "firmen-crm", version: "1.0.0" });

server.tool(
  "kunde-suchen",
  "Sucht einen Kunden im CRM nach Name oder Kundennummer",
  { suche: z.string() },
  async ({ suche }) => {
    const kunde = await crm.find(suche); // deine bestehende API
    return { content: [{ type: "text", text: JSON.stringify(kunde) }] };
  },
);

Schau auf die Beschreibung in der zweiten Zeile. Die ist kein Kommentar fürs Archiv — die Beschreibung ist die eigentliche Schnittstelle. Das Modell liest genau diesen Satz und entscheidet daran, ob das Tool zur Frage des Nutzers passt. Du schreibst sie für einen Kollegen, der schnell verstehen soll, wofür das gut ist — nicht für einen Computer. Der Rest darunter ist normaler Code, der deine bestehende API aufruft. Nichts Magisches.

Wann du selbst einen baust

So, und jetzt die ehrliche Antwort auf die Frage, die zählt: Musst du das selbst bauen? Meistens nicht.

Für die großen Standard-Systeme gibt es fertige MCP-Server, oft direkt vom Anbieter — GitHub, Slack, Notion, Linear, Asana, Stripe, Cloudflare, dazu Google Drive, Postgres und so weiter. Anschließen, läuft, kostet dich nichts außer der einen Konfigurationszeile von oben.

Selbst bauen lohnt sich für das, was es nur bei dir gibt: deine interne Postgres mit den Custom-Feldern, dein selbstgebauter Lead-Bewertungs-Ablauf, dein Warenwirtschaftssystem (etwa DATEV oder Microsoft Dynamics) mit den drei Eigenheiten, die kein Standard kennt. Und der Aufwand bleibt klein — weil ein MCP-Server kein Produkt ist, sondern eine dünne Übersetzungsschicht. Deine bestehende API auf der einen Seite, ein paar sauber beschriebene Tools auf der anderen.

“

Ein MCP-Server ist kein neues System. Er ist die Klinke an einer Tür, die du längst gebaut hast.

Daniel Schmilinski

Die Logik dahinter ist klassisch: Standard kaufst du, den eigenen Kern erschließt du selbst. Nur dass „selbst” hier wirklich ein Nachmittag ist und kein Quartal.

Fazit

Nochmal von oben, in einem Atemzug: KI-Modelle saßen in einer Box. Die Anbieter haben Anbindungen gebaut, aber jeder seine eigene — das skalierte nicht. Ein Protokoll ist eine gemeinsame Sprache, eine API die Tür eines Systems, und MCP ist das Protokoll, das beide Seiten endlich zusammenbringt. Der MCP-Server ist das kleine Programm, das eine dieser Türen aufmacht — kontrolliert, mit dir als Türsteher.

Was sich wirklich verändert hat, ist nicht die KI. Es ist die Verkabelung drumherum. KI an die eigenen Systeme zu hängen war jahrelang ein Projekt mit eigenem Budget. Jetzt ist es eine Konfigurationszeile und ein Nachmittag. Und ich glaube, das ist der eigentlich große Schritt — nicht das nächste, noch klügere Modell.