MCP für Anfänger: Erstellen Sie einen Server und einen Client und setzen Sie diese anschließend in Unternehmen ein.
MCP für Anfänger: Das N x M-Problem, die Kernideen in einfachen Worten, ein TypeScript-Helpdesk-Server und -Client in Node.js sowie der Übergang zu sicheren HTTP-Deployment-Verfahren.
Quellen: MCP Tools Inside Enterprise Applications: A Beginner-Friendly Deep Dive
Jeder, der kürzlich mit KI-Agenten gearbeitet hat, ist auf MCP, das Model Context Protocol, gestoßen. Es kommt in Claude Desktop, in IDE-Plugins, in internen Unternehmens-„KI-Portalen“-Projekten sowie zunehmend in produktiven Unternehmenssoftware-Anwendungen zum Einsatz.
Es handelt sich um eine Einführung für Anfänger, ohne Vorkenntnisse zu MCP vorauszusetzen. Der Einstieg erfolgt mit dem Problem, das das Protokoll löst, anschließend wird die Architektur erläutert, ein echter Server und Client in TypeScript auf Node.js erstellt, und zuletzt werden die Aspekte Sicherheit, Governance und Überwachbarkeit betrachtet, die Unternehmen um all das herum implementieren. Die Diagramme sind in reinem ASCII-Text dargestellt, sodass sie direkt in Notizen oder Code-Dokumentation eingefügt werden können.
1. Das Problem, das MCP löst
Vor MCP bedeutete es, einen Agenten dazu zu bringen, etwas Reales zu tun – wie beispielsweise ein CRM-Datensatz zu lesen, ein ITSM-Ticket zu öffnen oder ein Datenlager abzufragen – genau eines: den Anfertigen von maßgeschneidertem, einmaligem Integrationsscode für diesen Agenten und dieses System.
Das ist noch erträglich, solange es nur wenige Agenten gibt (einen Support-Bot, einen Programmierassistenten, einen internen Wissenshelfer) sowie einige Systeme (Salesforce, Jira, eine HR-Datenbank, ein Lager). Das Ergebnis ist dann eine kombinatorische Menge von handgefertigten Verbindern.
BEFORE MCP — the N x M integration problem
┌───────────┐ ┌─────────────┐
│ Agent A │───────▶│ CRM API │ (custom connector #1)
└───────────┘ └─────────────┘
┌───────────┐ ┌─────────────┐
│ Agent A │───────▶│ Ticketing │ (custom connector #2)
└───────────┘ └─────────────┘
┌───────────┐ ┌─────────────┐
│ Agent B │───────▶│ CRM API │ (custom connector #3 -
└───────────┘ └─────────────┘ yes, AGAIN, for a different agent)
┌───────────┐ ┌─────────────┐
│ Agent B │───────▶│ Data │ (custom connector #4)
└───────────┘ │ Warehouse │
└─────────────┘
N agents x M systems = N x M custom, non-reusable integrations.
Every new agent re-implements auth, retries, schemas, error handling.
USB löste das gleiche Problem bei Hardware-Peripheriegeräten, und ODBC sowie JDBC taten dies bei Datenbanken: zu viele benutzerdefinierte Anschlüsse ohne gemeinsamen Standard. MCP ist die Lösung von Anthropic – es wird als offenes Protokoll veröffentlicht und ist keine Funktion, die nur für Claude gilt, sodass jede KI-Anwendung sowie jedes Backend eine gemeinsame Sprache verwenden können.
AFTER MCP — one protocol, many servers, many clients
┌───────────┐ ┌───────────────────┐
│ Agent A │──┐ ┌─▶│ MCP Server: CRM │
└───────────┘ │ ┌───────────┐ │ └───────────────────┘
├───▶│ MCP │───┤ ┌───────────────────┐
┌───────────┐ │ │ (shared │ ├─▶│ MCP Server: Ticket │
│ Agent B │──┘ │ protocol)│ │ └───────────────────┘
└───────────┘ └───────────┘ │ ┌──────────────────┐
└─▶│ MCP Server: DW │
└──────────────────┘
Any MCP-compatible agent can now talk to any MCP server.
Build the connector once, reuse it everywhere.
Die Zusammenfassung passt in einen Satz. MCP bietet KI-Anwendungen eine einheitliche Methode, um Tools zu finden, sie aufzurufen, Daten zu lesen und Prompt-Vorlagen zu verwenden, sodass die Integration nur einmal erstellt werden muss und jeder kompatible Client sie wiederverwenden kann.
2. Kernkonzepte in einfachen Worten
Vier Begriffe werden locker verwendet, daher werden sie vor dem Schreiben des Codes definiert.
- Host. Die von KI angetriebene Anwendung, mit der der Endnutzer tatsächlich arbeitet – beispielsweise ein interner Chat-Assistent, ein IDE-Plugin oder ein Support-Copilot – und sie enthält das LLM.
- MCP-Client. Ein Komponente innerhalb des Hosts, die eine einzelne Verbindung zu einem einzigen MCP-Server verwalten wird. Ein Host, der mit drei Backend-Systemen kommuniziert, läuft in der Regel drei Clients, einen pro Server.
Im Grunde verwenden alle Nachrichten JSON-RPC 2.0, ein einfaches und etabliertes Format für Anfragen, Antworten und Benachrichtigungen. Das SDK erstellt diesen Format für Sie, doch das Verständnis des Übertragungsformats erklärt, warum MCP-Debugging-Tools den API-Tools ähneln, die Sie bereits verwenden – mit einer Anfrage-ID, Methodennamen, Parametern sowie einem Ergebnis oder Fehler.
Was ein Server anbieten kann: drei Primitiven
- Tools sind aufrufbare Funktionen, die es dem Modell ermöglichen, Aktionen auszuführen oder berechnete Ergebnisse abzurufen; das Modell entscheidet selbst, wann sie aufgerufen werden sollen, je nachdem, was der Benutzer anfragt. Beispiele:
create_support_ticket,get_employee_details. - Resources sind nur zum Lesen zugängliche Daten, die der Host als Kontext hinzufügen kann, wie z. B. Dateien oder Datensätze. Die Anwendung oder der Benutzer entscheidet, was hinzugefügt wird. Beispiele: ein Artikel aus einer Wissensdatenbank, ein PDF mit Richtlinien, eine Protokolldatei.
In den meisten Unternehmensintegrationen übernehmen die Tools etwa 90 Prozent der anspruchsvollen Arbeit, weshalb sie zuerst entwickelt werden.
3. Die Architektur – drei Schichten zusammen
┌─────────────────────────── HOST APPLICATION ───────────────────────────┐
│ e.g. an internal AI assistant, IDE plugin, support copilot │
│ │
│ ┌───────────────┐ ┌───────────────┐ ┌───────────────┐ │
│ │ MCP Client 1 │ │ MCP Client 2 │ │ MCP Client 3 │ │
│ └───────┬───────┘ └───────┬───────┘ └───────┬───────┘ │
└───────────┼────────────────────────┼───────────────────────┼───────────┘
│ JSON-RPC over │ JSON-RPC over │ JSON-RPC over
│ stdio / HTTPS │ stdio / HTTPS │ stdio / HTTPS
▼ ▼ ▼
┌──────────────────┐ ┌──────────────────┐ ┌─────────────────┐
│ MCP Server │ │ MCP Server │ │ MCP Server │
│ wraps HR system │ │ wraps Ticketing │ │ wraps Data │
│ (tools: lookup, │ │ (tools: create, │ │ Warehouse │
│ update) │ │ status, close) │ │ (tools: query) │
└──────────────────┘ └──────────────────┘ └─────────────────┘
Jeder MCP-Server soll klein und fokussiert sein, wobei für jedes Backend-System ein eigener Server vorhanden ist und es keinen einzigen riesigen Server gibt, der alles abdeckt. Dieser Ansatz lehnt sich an Microservices an, bei denen der Einflussbereich begrenzt ist, die Deployment-Prozesse unabhängig sind, die Skalierung ebenfalls unabhängig erfolgt und die Verantwortung beim jeweiligen Team liegt, das das Backend betreut.
4. Erstellung eines ersten MCP-Servers (Node.js und TypeScript)
Das Arbeitsbeispiel ist ein IT-Helpdesk-MCP-Server mit zwei Tools – einem zur Erstellung eines Support-Tickets und einem zur Überprüfung des Status eines Tickets. Er spiegelt ein sehr gängiges Unternehmensmuster wider, bei dem eine interne Ticketing- oder ITSM-API abgebildet wird.
4.1 Projekt-Einrichtung
mkdir helpdesk-mcp-server && cd helpdesk-mcp-server
npm init -y
npm install @modelcontextprotocol/sdk zod
npm install -D typescript tsx @types/node
npx tsc --init
@modelcontextprotocol/sdk ist das offizielle Paket. Es kümmert sich um JSON-RPC im Übertragungsweg, die Transportmechanismen sowie die Primitiven, sodass man sich niemals direkt mit rohem JSON-RPC beschäftigen muss. zod ist eine Bibliothek zur Schema-Validierung. Die Eingaben der MCP-Tools werden vor dem Ausführen des Handler-Codes gegen ein Schema überprüft, was in Unternehmensumgebungen von großer Bedeutung ist, da fehlerhafte oder bösartige Aufrufe bereits an der Quelle abgewehrt werden.
4.2 Der Servercode
// src/server.ts
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";
// --- A stand-in for a real internal ticketing API client ---
// In a real enterprise server this would call your ITSM system
// (ServiceNow, Jira Service Management, Zendesk, an internal API, etc.)
const ticketStore = new Map<string, { status: string; subject: string }>();
let nextId = 1000;
// 1. Create the server instance.
// "name" and "version" identify this server to any client that connects.
const server = new McpServer({
name: "helpdesk-mcp-server",
version: "1.0.0",
});
// 2. Register a tool: create_support_ticket
server.registerTool(
"create_support_ticket",
{
title: "Create Support Ticket",
description:
"Creates a new IT helpdesk ticket for the requesting employee.",
inputSchema: {
subject: z.string().describe("Short summary of the issue"),
priority: z.enum(["low", "medium", "high", "urgent"]),
employeeId: z.string().describe("Requesting employee's ID"),
},
outputSchema: {
ticketId: z.string(),
status: z.string(),
},
},
async ({ subject, priority, employeeId }) => {
const ticketId = `TCK-${nextId++}`;
ticketStore.set(ticketId, { status: "open", subject });
const output = { ticketId, status: "open" };
// MCP tool results return a "content" array (what a human/LLM reads)
// and, optionally, "structuredContent" (typed data other code can use).
return {
content: [
{
type: "text",
text: `Created ticket ${ticketId} (priority: ${priority}) for employee ${employeeId}.`,
},
],
structuredContent: output,
};
}
);
// 3. Register a second tool: get_ticket_status
server.registerTool(
"get_ticket_status",
{
title: "Get Ticket Status",
description: "Looks up the current status of an existing support ticket.",
inputSchema: {
ticketId: z.string(),
},
outputSchema: {
status: z.string(),
},
},
async ({ ticketId }) => {
const ticket = ticketStore.get(ticketId);
if (!ticket) {
// Returning isError lets the model know the call failed
// WITHOUT crashing the whole conversation.
return {
content: [{ type: "text", text: `No ticket found with ID ${ticketId}.` }],
isError: true,
};
}
return {
content: [{ type: "text", text: `Ticket ${ticketId} is currently "${ticket.status}".` }],
structuredContent: { status: ticket.status },
};
}
);
// 4. Wire the server to a transport and start listening.
// stdio is perfect for local development and desktop-hosted tools.
const transport = new StdioServerTransport();
await server.connect(transport);
4.3 Was jede Komponente bewirkt
- Die
McpServer-Instanz. Dieses Objekt ist das Herzstück des Servers. Es verfolgt alle registrierten Tools, Ressourcen und Anfragen und kümmert sich um den MCP-Handshake (Fähigkeitsverhandlung), wenn ein Client sich verbindet. Eine Liste der Tools wird niemals manuell erstellt, da das SDK sie aus denregisterTool-Aufrufen generiert. inputSchemamit Zod. Mehr als nur Dokumentation. Das SDK verwendet es, um ein JSON Schema zu erzeugen, das dem Client und dem LLM mitteilt, welche Argumente gültig sind, und um jeden eingehenden Aufruf zu überprüfen. Ein Client, derpriority: „banana“übermittelt, wird bereits vor Erreichen des Verarbeitungsfunktion abgewiesen. Für Unternehmen stellt diese schema-basierte Validierung eine echte Sicherheitsmaßnahme dar und ist keine bloße Zusatzfunktion.
outputSchema und structuredContent. Ein Tool kann eine für Menschen lesbare Zusammenfassung (content) sowie ein für Maschinen lesbares Objekt (structuredContent) zurückgeben. Der Text erscheint in einer Chat-Transkript, während eine aufrufende Anwendung die strukturierten Daten verarbeiten kann, um eine Benutzeroberfläche oder weitere Logik zu steuern.isError: true. MCP bietet ein eigenständiges Konzept für Fehler auf Tool-Ebene, das sich von Fehlern auf Protokoll-Ebene unterscheidet. Das bedeutet, die Operation ist fehlgeschlagen, doch das Gespräch sollte fortgesetzt werden. Dadurch kann das Modell den Fehler lesen und entscheiden, ob es es erneut versuchen, den Benutzer fragen oder ein anderes Tool nutzen soll. Man möchte schließlich nicht, dass eine gesamte Agenten-Sitzung wegen fehlender Ticket-IDs abstürzt.StdioServerTransport). Der Bestandteil, der Bytes überträgt. Für lokale Tools wie die IDE eines Entwicklers oder einen Desktop-Assistenten ist Stdio am einfachsten, da der Host den Server als Kindprozess startet. Alles, was zentral in einem Unternehmen läuft, verwendet den auf HTTP basierenden Transport, der in Abschnitt 6 erläutert wird.4.4 Ausführen
npx tsx src/server.ts
Der Server zeigt für sich allein nichts an, da er darauf wartet, dass ein Client über stdin und stdout verbunden wird. Als Nächstes kommt der Client.
5. Ein Client in einer Unternehmensanwendung
Anfänger bauen oft einen Server und fragen sich anschließend, was eigentlich mit ihm kommuniziert. Hier ist ein minimaler Client, der als Teil eines internen Node.js-Backends betrachtet werden kann, das den KI-Assistenten eines Unternehmens antreibt.
// src/client.ts
import { Client } from "@modelcontextprotocol/sdk/client/index.js";
import { StdioClientTransport } from "@modelcontextprotocol/sdk/client/stdio.js";
async function main() {
// 1. Describe how to launch the server. Here we spawn it as a
// local subprocess - in production you'd more commonly point
// this at a remote HTTP-based server instead (see Section 6).
const transport = new StdioClientTransport({
command: "npx",
args: ["tsx", "src/server.ts"],
});
// 2. Create a client and connect. This performs the MCP
// handshake and capability negotiation automatically.
const client = new Client({ name: "internal-ai-assistant", version: "1.0.0" });
await client.connect(transport);
// 3. Discover what tools this server offers - this is the same
// mechanism an LLM uses to "learn" what it can do.
const { tools } = await client.listTools();
console.log("Available tools:", tools.map((t) => t.name));
// 4. Call a tool, just like the LLM would.
const result = await client.callTool({
name: "create_support_ticket",
arguments: {
subject: "VPN keeps disconnecting",
priority: "high",
employeeId: "E-4821",
},
});
console.log(result.content);
await client.close();
}
main();
Warum dies konzeptionell wichtig ist
Die zentrale Idee ist die Entdeckung. Der Client ruft listTools() auf und erhält ein maschinenlesbares Verzeichnis aller Funktionen, die der Server anbietet, wobei jede Funktion mit ihrem Schema dargestellt wird. Das macht MCP dynamisch: Ein vom LLM angetriebener Host benötigt keine fest in seine Anfragen integrierten Tools. Zum Zeitpunkt der Verbindung fragt er den Server, was dieser leisten kann, und die Antwort wird Teil dessen, was dem Modell mitgeteilt wird, was es in diesem Gespräch tun darf.
Die Unternehmenssteuerung basiert genau auf diesem Mechanismus. Wenn ein Tool für einen bestimmten Benutzer oder eine bestimmte Umgebung nicht verfügbar sein soll, ist die sauberste Kontrollmöglichkeit, es aus dem Ergebnis von listTools() auszulassen, anstatt zu hoffen, dass das Modell es nicht aufruft.
6. Vom lokalen Prototypen zur Unternehmensimplementierung
Die stdio-Einrichtung eignet sich zum Lernen sowie für lokale Entwicklerwerkzeuge, entspricht aber nicht der Art und Weise, wie die meisten Unternehmen ihre Infrastruktur betreiben: zentral gehostet, hinter Authentifizierung geschützt, protokolliert und gleichzeitig von vielen Host-Anwendungen erreichbar. Genau da kommen der Streamable HTTP-Transport sowie ein API-Gateway ins Spiel.
Hier ist derselbe Helpdesk-Server angepasst, um über HTTP zu laufen und hinter einer einfachen Express-Anwendung zu stehen:
// src/httpServer.ts
import express from "express";
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StreamableHTTPServerTransport } from "@modelcontextprotocol/sdk/server/streamableHttp.js";
const app = express();
app.use(express.json());
app.post("/mcp", async (req, res) => {
// In a real enterprise deployment, authentication middleware would
// run BEFORE this point - verifying a bearer token, checking scopes,
// and attaching the caller's identity to the request.
const server = buildHelpdeskServer(); // same registerTool calls as before
const transport = new StreamableHTTPServerTransport({
sessionIdGenerator: undefined, // stateless mode: simplest to scale horizontally
});
res.on("close", () => transport.close());
await server.connect(transport);
await transport.handleRequest(req, res, req.body);
});
app.listen(3000, () => console.log("MCP server listening on :3000"));
Der wesentliche Wandel betrifft weniger den Code als vielmehr wo die Verantwortung liegt. Drei Aspekte, die bei stdio implizit waren, werden über HTTP zu expliziten Unternehmensanforderungen.
- Die Authentifizierung erfolgt vor dem Server, in der Regel in Middleware oder einem Gateway, wodurch der Server davon ausgehen kann, dass
reqbereits eine überprüfte Identität enthält. - Statelessness ist eine bewusste Entscheidung. Mit
sessionIdGenerator: undefinedspeichert der Transport keine Sitzung pro Verbindung, sodass jede Instanz hinter dem Load Balancer auf jede Anfrage antworten kann, und man wie bei jeder stateless API skalieren kann. - Die Beobachtbarkeit ist nicht mehr optional. Jede Aufrufung eines Tools ist eine echte Netzwerkanfrage, weshalb sie genauso protokolliert, nachverfolgt und mit einer Rate-Limitierung versehen werden sollte wie jeder interne API-Aufruf.
7. Überprüfungskartei für Unternehmensaspekte
Den MCP-Server zum Laufen zu bringen, ist nur der einfache fünfte Teil der Arbeit. Die verbleibenden vier Fünftel bestehen darin, ihn gegen Produktivsysteme zu sichern, die echte Daten von Mitarbeitern oder Kunden enthalten – und dieser Teil sieht so aus.
- Authentifizierung und Autorisierung. Verwenden Sie am Gateway OAuth2 oder OIDC. Übertragen Sie die Identität des aufrufenden Benutzers oder der Service-Konto auf spezifische, eingeschränkte Berechtigungen, damit nicht jedes Tool von jedem Aufrufer verwendet werden kann.
- Entwurf von Tools mit minimalem Berechtigungsgrad. Wählen Sie lieber enge Tools wie
get_ticket_statusstatt umfassenderer Tools wierun_sql_query. Ein Tool, das eine klar definierte Aufgabe erledigt, ist weitaus einfacher zu verstehen und zu prüfen.
8. Wo dies in echten Unternehmen vorkommt
- IT und interne Unterstützung. Beispiel Helpdesk: Erstellung und Abfrage von Tickets, Zurücksetzung von Passwörtern, Überprüfung des Systemzustands.
- Vertrieb und CRM-Assistenten. Abruf von Kontoinformationen und Erstellung von Nachfolgee-Mails, die auf echten CRM-Daten basieren und nicht auf Schätzungen des Modells.
- Daten- und Analyse-Assistenten. Eine nur zum Lesen geeignete, im Voraus genehmigte Reihe von Abfruhtools für Datenlagern anstelle von unbeschränktem SQL.
- Gesundheitswesen-Workflows. Tools, die Termine abfragen, die Versicherungseignung überprüfen oder Mängel in der Versorgungskoordination aufzeigen – stets unter strenger rollenbasierter Zugriffskontrolle sowie Audit-Protokollen aufgrund der Sensibilität der Daten. Hier sind die Prinzipien des eng gefassten Tool-Einsatzes, der menschlichen Überwachung sowie vollständiger Audit-Logs aus Abschnitt 7 oft eine Compliance-Anforderung.
- Entwicklerwerkzeuge. IDE-Hilfen, die interne Dokumentation abrufen, einen CI-Pipeline-Prozess starten oder überprüfen, wer für einen Dienst erreichbar ist.
Was sie gemeinsam haben: MCP macht ein Modell nicht intelligenter. Was sich ändert, ist, dass die KI grundierten, überprüfbaren Zugriff auf reale Systeme erhält und nicht mehr plausible Antworten erfinden muss.
9. Häufige Fehler bei Anfängern
- Ein riesiger „Alleskönner“-Server. In Backend-Systeme oder Domänen aufgeteilt. Das spiegelt gute Mikroservice-Grenzen wider und hält den Auswirkungsbereich klein.
- Auslassen der
description-Felder. Das Modell stützt sich stark auf Beschreibungen von Tools und Parametern, um zu entscheiden, wann und wie etwas aufgerufen werden soll. Unklare Beschreibungen führen zum falschen Tool oder zum richtigen Tool mit den falschen Argumenten. - Vergessen von
isError. Eine rohe Ausnahme, die aus einem Tool-Handler geworfen wird, kann die gesamte Client-Verbindung lahmlegen, obwohl dem Modell eigentlich mitgeteilt werden sollte, dass dies fehlgeschlagen ist, und es sollte etwas anderes ausprobieren. - Verwendung von Stdio in der Produktion. Stdio eignet sich gut für die lokale Entwicklung und Desktop-Hosts. Produktionssysteme mit mehreren Nutzern benötigen den HTTP-Transport hinter einer echten Gateway-Lösung.
10. Die Kurzfassung
Wenn man die Schlagworte weglässt, ist die Kernidee von MCP erfrischend einfach: eine gemeinsame Methode für KI-Anwendungen, um Tools zu finden und aufzurufen, Daten abzurufen sowie Prompt-Vorlagen wiederverwenden zu können – das bedeutet, dass die Integration nur einmal durchgeführt werden muss und allen konformen Kunden dient. Für Unternehmen ist genau diese Standardisierung der Schlüssel, um KI-Agenten von auffälligen Demos zu etwas zu machen, das gesteuert, gesichert und neben allen anderen Systemen in der Produktion eingesetzt werden kann.
Für Anfänger ist ein sinnvoller Weg:
- Bauen Sie lokal einen kleinen MCP-Server über stdio auf, wie im Helpdesk-Beispiel.
- Fügen Sie einen Client hinzu, der diese Tools aufruft, damit der gesamte Ablauf sichtbar ist.
- Platzieren Sie den Server hinter einer mit Authentifizierung versehenen HTTP-Schicht oder einem Gateway davor.
- Nur danach sollten Sie zu Audit-Logging, Rate-Limits sowie menschlicher Freigabe für schädigende Aktionen übergehen.
Fangen Sie klein und lokal an und integrieren Sie die Anforderungen für Unternehmensumgebungen nach und nach. Versuchen, bereits am ersten Tag den perfekten Produktionsserver zu entwerfen, ist ein weitaus unsichererer Weg dorthin.