Übersetzen Sie den folgenden Markdown-Artikel ins Deutsche.

Wenn Sie in diesem Jahr aufgepasst haben, haben Sie wahrscheinlich bemerkt, dass das Model Context Protocol (MCP) von einer "interessanten Spezifikation von Anthropic" zu einem "Ding, das jedes ernsthafte SaaS-Produkt unterstützen muss" geworden ist. Und das mit gutem Grund. MCP gibt AI-Agenten -- Claude, GPT-basierte Assistenten, benutzerdefinierte Agenten -- einen standardisierten Weg, Ihre API zu entdecken und aufzurufen. Stellen Sie sich das als OpenAPI für das Zeitalter der Agenten vor, aber mit echter bidirektionaler Echtzeitkommunikation.

In den letzten Monaten habe ich MCP-Server für mehrere SaaS-Produkte entwickelt, und ich möchte teilen, was wirklich funktioniert, was die Dokumentation nicht verrät, und welche architektonischen Entscheidungen wichtig sind. Dies ist keine Wiederholung der Spezifikation. Dies ist das Handbuch, das ich mir gewünscht hätte, als ich anfing.

Inhaltsverzeichnis

Was ist das Model Context Protocol (MCP)?

MCP ist ein offenes Protokoll, das ursprünglich von Anthropic erstellt wurde und definiert, wie KI-Modelle mit externen Tools und Datenquellen kommunizieren. Es wurde Ende 2024 veröffentlicht und erreichte Anfang 2025 die v1.0-Stabilität. Es wird jetzt von Claude Desktop, Cursor, Windsurf, dem OpenAI Agents SDK und Dutzenden anderen AI-Clients unterstützt.

Die Kernidee: Statt dass jede AI-Integration ein benutzerdefiniertes Plugin mit proprietärem Format ist, bietet MCP ein einziges Protokoll, das jeder kompatible Client verwenden kann, um zu entdecken, was Ihr Service anbietet, und damit zu interagieren.

Hier ist, was MCP definiert:

  • Tools -- Funktionen, die die KI aufrufen kann (wie create_ticket, search_users, generate_report)
  • Resources -- Daten, die die KI lesen kann (wie Dokumentation, Datenbankeinträge, Konfigurationsdateien)
  • Prompts -- Wiederverwendbare Prompt-Vorlagen, die Ihr Server verfügbar machen kann
  • Sampling -- Die Möglichkeit für Ihren Server, LLM-Vervollständigungen vom Client anzufordern

Die Transportschicht verwendet JSON-RPC 2.0 über entweder stdio (für lokale Server) oder HTTP mit Server-Sent Events (SSE) für Remote-Server. Der neuere Streamable HTTP Transport, der in der Spezifikationsrevision 2025-03 eingeführt wurde, ist das, was Sie für jede Produktions-SaaS-Bereitstellung möchten.

Warum Ihr SaaS-Produkt einen MCP-Server benötigt

Lassen Sie mich direkt sein: Wenn Ihr SaaS-Produkt eine API hat, sollten Sie jetzt einen MCP-Server entwickeln. Hier ist warum.

AI-Agenten werden zu den primären API-Verbrauchern. Im Q1 2025 berichtete Anthropic, dass Claude Desktop-Benutzer MCP-Tools über 2 Millionen Mal pro Tag aufrufen. Diese Zahl wächst schnell. Ihre Kunden versuchen bereits, AI-Agenten zur Interaktion mit Ihrem Produkt zu verwenden -- die Frage ist, ob Sie das einfach oder frustrierend machen.

Es ist ein Vertriebskanal. Wenn jemand Claude Desktop installiert und "Hilf mir, meine Projekte zu verwalten" tippt, kann die KI MCP-Server entdecken und verwenden, die der Benutzer konfiguriert hat. Ihr Produkt wird über natürliche Sprache zugänglich. Das ist kein Marketing-Gag -- es ist eine echte neue Oberfläche für Ihr Produkt.

Ihre Konkurrenten machen es. Stripe, Linear, Notion, GitHub, Sentry und Supabase haben alle MCP-Server in der ersten Hälfte von 2025 deployed. Wenn Sie in B2B-SaaS tätig sind und keinen haben, fallen Sie zurück.

Faktor Nur REST-API REST-API + MCP-Server
AI-Agent-Zugänglichkeit Erfordert benutzerdefinierte Integration pro Agent Jeder MCP-Client funktioniert automatisch
Entdeckung Entwickler lesen Docs KI entdeckt Fähigkeiten zur Laufzeit
Zeit bis zur ersten Integration Stunden bis Tage Minuten
Interaktion in natürlicher Sprache Ohne Wrapper nicht möglich Eingebaut
Wartungsaufwand Eine Codebasis Zwei Codebases (aber MCP umhüllt REST)

MCP-Architektur: Wie es wirklich funktioniert

Bevor wir Code schreiben, lassen Sie uns die Architektur klären. Eine MCP-Bereitstellung hat drei Teile:

  1. MCP-Client -- Die AI-Anwendung (Claude Desktop, Cursor, Ihr benutzerdefinierter Agent). Er entdeckt die Fähigkeiten Ihres Servers und ruft diese auf.
  2. MCP-Server -- Ihr Code. Er stellt Tools, Ressourcen und Prompts über das MCP-Protokoll verfügbar. Das ist, was wir entwickeln.
  3. Ihre SaaS-API -- Das eigentliche Backend, das Ihr MCP-Server aufruft, um Dinge zu erledigen.

Der Ablauf sieht so aus:

Benutzer → AI-Client → MCP-Client → MCP-Server → Ihre SaaS-API
                                           ↓
                                   Antwort fließt zurück

Ihr MCP-Server ist im Wesentlichen ein Protokolladapter. Er übersetzt zwischen dem MCP-Protokoll (das AI-Clients sprechen) und Ihrer vorhandenen REST/GraphQL-API. Dies bedeutet, dass Sie Ihre vorhandene API überhaupt nicht ändern müssen. Der MCP-Server sitzt daneben.

Transportoptionen

Für SaaS-Produkte haben Sie zwei realistische Transportoptionen:

  • Streamable HTTP (empfohlen): Verwendet Standard-HTTP-Anfragen mit optionalem SSE zum Streamen. Funktioniert hinter Load Balancern, CDNs und Standardinfrastruktur. Das möchten Sie für Remote/gehostete MCP-Server.
  • SSE (veraltet): Der ursprüngliche Remote-Transport. Funktioniert immer noch, aber die Spezifikation empfiehlt Streamable HTTP für neue Implementierungen.

Stdio-Transport ist großartig für lokale Tools, ist aber nicht anwendbar für den MCP-Server eines SaaS-Produkts.

Einrichten Ihres MCP-Server-Projekts

Bauen wir das mit TypeScript. Das offizielle @modelcontextprotocol/sdk-Paket ist gut gepflegt und ist die richtige Wahl für den Produktionseinsatz. Python hat mcp (das offizielle Python SDK), falls das Ihr Stack ist, aber ich werde mich auf TypeScript konzentrieren, da die meisten SaaS-Backends, mit denen ich arbeite, Node.js verwenden.

mkdir my-saas-mcp-server
cd my-saas-mcp-server
npm init -y
npm install @modelcontextprotocol/sdk zod express
npm install -D typescript @types/node @types/express tsx

Richten Sie Ihre tsconfig.json ein:

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "Node16",
    "moduleResolution": "Node16",
    "outDir": "./dist",
    "rootDir": "./src",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true
  },
  "include": ["src/**/*"]
}

Erstellen wir nun die Grundstruktur des Servers:

// src/server.ts
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StreamableHTTPServerTransport } from "@modelcontextprotocol/sdk/server/streamableHttp.js";
import express from "express";

const app = express();
app.use(express.json());

const server = new McpServer({
  name: "my-saas-mcp",
  version: "1.0.0",
  description: "MCP server for My SaaS Product",
});

// Wir werden hier Tools, Ressourcen und Prompts hinzufügen

app.post("/mcp", async (req, res) => {
  const transport = new StreamableHTTPServerTransport({
    sessionIdGenerator: () => crypto.randomUUID(),
  });
  
  await server.connect(transport);
  await transport.handleRequest(req, res);
});

app.get("/mcp", async (req, res) => {
  // SSE-Endpunkt für Streaming-Antworten
  const transport = new StreamableHTTPServerTransport({
    sessionIdGenerator: () => crypto.randomUUID(),
  });
  
  await server.connect(transport);
  await transport.handleRequest(req, res);
});

const PORT = process.env.PORT || 3001;
app.listen(PORT, () => {
  console.log(`MCP server running on port ${PORT}`);
});

Das ist Ihr Gerüst. Füllen wir es.

Definieren von Tools, Ressourcen und Prompts

Tools

Tools sind das wichtigste primitive Element. Jedes Tool ist eine Funktion, die die KI mit strukturierten Parametern aufrufen kann. So definieren Sie eine:

import { z } from "zod";

server.tool(
  "create_project",
  "Create a new project in the workspace",
  {
    name: z.string().describe("The project name"),
    description: z.string().optional().describe("Project description"),
    team_id: z.string().describe("ID of the team that owns this project"),
  },
  async ({ name, description, team_id }) => {
    // Rufen Sie Ihre SaaS-API hier auf
    const project = await apiClient.createProject({ name, description, team_id });
    
    return {
      content: [
        {
          type: "text",
          text: JSON.stringify(project, null, 2),
        },
      ],
    };
  }
);

Einige Dinge, die ich über Tool-Design gelernt habe:

Seien Sie spezifisch mit Beschreibungen. Die KI verwendet Ihre Tool-Beschreibung und Parameterbeschreibungen, um zu entscheiden, wann und wie sie aufgerufen wird. Vage Beschreibungen führen zu falscher Tool-Auswahl. "Ein neues Projekt erstellen" ist okay. "Erstellen Sie ein neues Projekt im Workspace des Benutzers. Erfordert eine team_id, die vom Tool list_teams abgerufen werden kann" ist viel besser.

Halten Sie die Tool-Anzahl handhabbar. Ich habe Menschen gesehen, die 50+ Tools aussetzen und sich wundern, warum die KI verwirrt wird. Beginnen Sie mit 10-15 Kernoperationen. Sie können später immer mehr hinzufügen.

Geben Sie strukturierte Daten zurück. Geben Sie immer JSON in Ihrem Textinhalt zurück. Die KI parsed es besser als Prosa.

Ressourcen

Ressourcen machen lesbare Daten verfügbar. Stellen Sie sich diese als GET-Endpunkte für AI-Verbrauch vor:

server.resource(
  "project-list",
  "projects://list",
  "List of all projects in the workspace",
  async () => {
    const projects = await apiClient.listProjects();
    return {
      contents: [
        {
          uri: "projects://list",
          mimeType: "application/json",
          text: JSON.stringify(projects, null, 2),
        },
      ],
    };
  }
);

Prompts

Prompts sind wiederverwendbare Vorlagen. Sie werden untergenutzt, aber sind leistungsstarke:

server.prompt(
  "weekly-report",
  "Generate a weekly status report for a project",
  {
    project_id: z.string().describe("The project ID to report on"),
  },
  async ({ project_id }) => {
    const stats = await apiClient.getProjectStats(project_id);
    return {
      messages: [
        {
          role: "user",
          content: {
            type: "text",
            text: `Generate a weekly status report based on this data: ${JSON.stringify(stats)}. Include completed tasks, blockers, and upcoming deadlines.`,
          },
        },
      ],
    };
  }
);

Verbindung zu Ihrer SaaS-API

Ihr MCP-Server muss mit Ihrer vorhandenen API kommunizieren. Ich empfehle, eine typisierte API-Client-Klasse zu erstellen:

// src/api-client.ts
class SaaSApiClient {
  private baseUrl: string;
  private apiKey: string;

  constructor(baseUrl: string, apiKey: string) {
    this.baseUrl = baseUrl;
    this.apiKey = apiKey;
  }

  private async request<T>(path: string, options?: RequestInit): Promise<T> {
    const response = await fetch(`${this.baseUrl}${path}`, {
      ...options,
      headers: {
        "Authorization": `Bearer ${this.apiKey}`,
        "Content-Type": "application/json",
        ...options?.headers,
      },
    });

    if (!response.ok) {
      const error = await response.text();
      throw new Error(`API error ${response.status}: ${error}`);
    }

    return response.json() as T;
  }

  async createProject(data: CreateProjectInput): Promise<Project> {
    return this.request<Project>("/api/v1/projects", {
      method: "POST",
      body: JSON.stringify(data),
    });
  }

  async listProjects(): Promise<Project[]> {
    return this.request<Project[]>("/api/v1/projects");
  }

  // ... mehr Methoden
}

Halten Sie diesen Client dünn. Es ist ein Durchgang, keine Geschäftslogik-Schicht.

Authentifizierung und Multi-Mandantenfähigkeit

Hier wird es interessant -- und hier überspringen die meisten Tutorials die schwierigen Teile.

Ihr MCP-Server muss Anfragen auf zwei Arten authentifizieren:

  1. Der MCP-Client authentifiziert sich bei Ihrem MCP-Server ("Ist das ein gültiger Benutzer?")
  2. Ihr MCP-Server authentifiziert sich bei Ihrer SaaS-API ("Handeln Sie im Namen dieses Benutzers")

OAuth 2.0 (Empfohlen für Produktion)

Die MCP-Spezifikation enthält ein Autorisierungs-Framework basierend auf OAuth 2.1. Für ein SaaS-Produkt ist das der richtige Ansatz:

// Middleware zum Extrahieren und Validieren des OAuth-Tokens
app.use("/mcp", async (req, res, next) => {
  const authHeader = req.headers.authorization;
  if (!authHeader?.startsWith("Bearer ")) {
    return res.status(401).json({ error: "Missing authorization" });
  }

  const token = authHeader.slice(7);
  
  try {
    const user = await validateOAuthToken(token);
    req.user = user;
    next();
  } catch {
    return res.status(401).json({ error: "Invalid token" });
  }
});

Dann übergeben Sie den Benutzerkontext an Ihre Tool-Handler. Dies ist kritisch für Multi-Mandantenfähigkeit -- jeder API-Aufruf sollte auf den Workspace des authentifizierten Benutzers beschränkt sein.

API-Schlüssel-Ansatz (Einfacher, für Intern/Frühes Stadium)

Wenn Sie im frühen Stadium sind oder dies intern ist, funktionieren API-Schlüssel gut:

const apiKey = req.headers["x-api-key"] as string;
const client = new SaaSApiClient(process.env.API_BASE_URL!, apiKey);

Der Benutzer gibt seinen API-Schlüssel an, wenn der MCP-Server in seinem Client konfiguriert wird, und dieser wird an Ihre API weitergegeben.

Fehlerbehandlung und Validierung

AI-Agenten benötigen klare Fehlermeldungen. Wenn ein Tool fehlschlägt, muss die KI verstehen, warum, damit sie entweder die Eingabe beheben oder das Problem dem Benutzer erklären kann.

server.tool(
  "get_project",
  "Get project details by ID",
  { project_id: z.string().uuid().describe("The project's UUID") },
  async ({ project_id }) => {
    try {
      const project = await apiClient.getProject(project_id);
      return {
        content: [{ type: "text", text: JSON.stringify(project, null, 2) }],
      };
    } catch (error) {
      const message = error instanceof Error ? error.message : "Unknown error";
      return {
        isError: true,
        content: [
          {
            type: "text",
            text: `Failed to get project: ${message}. Make sure the project_id is a valid UUID and the project exists in your workspace.`,
          },
        ],
      };
    }
  }
);

Beachten Sie das isError: true Flag. Dies teilt dem AI-Client mit, dass der Tool-Aufruf fehlgeschlagen ist, damit er ihn angemessen handhaben kann. Fügen Sie in Fehlermeldungen immer verwertbare Anleitungen ein.

Testen Ihres MCP-Servers

Das Testen von MCP-Servern ist 2025 viel einfacher geworden. Hier sind Ihre Optionen:

MCP Inspector

Der offizielle MCP Inspector ist Ihr bester Freund während der Entwicklung:

npx @modelcontextprotocol/inspector

Dies gibt Ihnen eine Web-UI, in der Sie eine Verbindung zu Ihrem Server herstellen, Tools/Ressourcen durchsuchen und diese interaktiv aufrufen können. Verwenden Sie es ständig.

Automatisierte Tests

Für CI/CD testen Sie Ihre Tools als reguläre asynchrone Funktionen:

import { describe, it, expect } from "vitest";

describe("create_project tool", () => {
  it("should create a project with valid input", async () => {
    const result = await createProjectHandler({
      name: "Test Project",
      team_id: "team-123",
    });

    expect(result.isError).toBeUndefined();
    const data = JSON.parse(result.content[0].text);
    expect(data.name).toBe("Test Project");
  });

  it("should return error for missing team_id", async () => {
    // Zod-Validierung sollte dies vor dem Handler fangen
    // Testen Sie die Validierungsebene
  });
});

Integrationstests mit Claude Desktop

Sobald Ihr Server läuft, fügen Sie ihn zur Konfiguration von Claude Desktop hinzu:

{
  "mcpServers": {
    "my-saas": {
      "url": "http://localhost:3001/mcp",
      "headers": {
        "Authorization": "Bearer your-test-token"
      }
    }
  }
}

Sprechen Sie dann einfach mit Claude und versuchen Sie, Ihre Tools natürlich zu verwenden. Sie werden schnell Edge Cases finden, die die automatisierten Tests verpassen.

Bereitstellung und Überlegungen zur Produktion

Wo wird bereitgestellt?

Ihr MCP-Server ist nur eine Express-App. Stellen Sie ihn überall bereit, wo Sie Node.js-Services bereitstellen. Einige gute Optionen:

Plattform Kalter Start Kosten (geschätzt) Am besten für
Railway Keiner ~$5-20/Mo Kleine bis mittlere SaaS
Fly.io <500ms ~$5-15/Mo Globale Verteilung
AWS ECS/Fargate Keiner ~$15-50/Mo Enterprise, bestehendes AWS
Vercel (Edge) <100ms $0-20/Mo Falls Sie bereits auf Vercel sind
Cloudflare Workers <5ms $0-5/Mo Performance-kritisch

Ratenbegrenzung

AI-Agenten können chattativ sein. Ein einzelnes Benutzer-Gespräch könnte 20-30 Tool-Aufrufe auslösen. Implementieren Sie eine Ratenbegrenzung, die großzügig genug für normale KI-Nutzung ist, aber Missbrauch verhindert:

import rateLimit from "express-rate-limit";

const limiter = rateLimit({
  windowMs: 60 * 1000, // 1 Minute
  max: 60, // 60 Anfragen pro Minute pro Benutzer
  keyGenerator: (req) => req.user?.id || req.ip,
});

app.use("/mcp", limiter);

Überwachung

Protokollieren Sie jeden Tool-Aufruf mit der Benutzer-ID, dem Tool-Namen und der Latenz. Sie möchten Sichtbarkeit haben, welche Tools am meisten verwendet werden, welche am häufigsten fehlschlagen und wo die Latenz-Engpässe sind. Datadog, Axiom oder auch strukturierte JSON-Logs zu CloudWatch funktionieren gut.

Versionierung

Ihr MCP-Server wird sich weiterentwickeln. Verwenden Sie das Feld version in Ihren Server-Metadaten und erwägen Sie, während Übergängen mehrere Versionen hinter einem Pfad-Präfix (/mcp/v1, /mcp/v2) auszuführen.

Echtbeispiel: Erstellen eines MCP-Servers für ein Projektmanagement-SaaS

Lassen Sie mich ein echtes Beispiel durchgehen. Angenommen, Sie erstellen einen MCP-Server für ein Projektmanagement-Tool (denken Sie an ein vereinfachtes Linear oder Asana).

Hier ist die Tool-Menge, die ich bereitstellen würde:

// Kern-CRUD-Tools
server.tool("list_projects", ...);
server.tool("get_project", ...);
server.tool("create_project", ...);
server.tool("update_project", ...);

// Aufgabenverwaltung
server.tool("list_tasks", ...);  // mit Filtern für Status, Assignee, Projekt
server.tool("create_task", ...);
server.tool("update_task", ...); // Status, Assignee, Priorität aktualisieren
server.tool("add_comment", ...);

// Suche und Reporting
server.tool("search", ...);      // Volltext-Suche über Projekte und Aufgaben
server.tool("get_project_stats", ...); // Zusammenfassungsstatistiken für ein Projekt

// Ressourcen
server.resource("workspace-info", ...); // Workspace-Konfiguration, Team-Mitglieder

// Prompts
server.prompt("standup-report", ...);   // Standup aus letzten Aktivitäten generieren
server.prompt("sprint-planning", ...);  // Sprint-Planung unterstützen

Das sind 12 Tools, 1 Ressource und 2 Prompts. Genug, um wirklich nützlich zu sein, ohne die Tool-Auswahl der KI zu überlasten.

Das Benutzererlebnis sieht so aus: Jemand öffnet Claude Desktop und sagt: "Welche Aufgaben sind im Backend-Rewrite-Projekt überfällig?" Claude ruft list_tasks mit einem Statusfilter und Projektnamen auf, erhält die Ergebnisse und präsentiert sie in natürlicher Sprache. Der Benutzer sagt "Weisen Sie die Auth-Migration-Aufgabe Sarah zu und erhöhen Sie die Priorität auf Hoch." Claude ruft update_task auf. Es fühlt sich magisch an, und es ist wirklich nur Protokoll-Plumbing.

Wenn Sie etwas Ähnliches bauen und Hilfe mit dem Next.js-Frontend oder der Headless-CMS-Schicht möchten, die oft mit diesen Projekten einhergeht, das ist etwas, das wir bei Social Animal oft machen. Aber der MCP-Server selbst? Das können Sie mit diesem Handbuch absolut intern entwickeln.

Häufig gestellte Fragen

Was ist der Unterschied zwischen MCP und Function Calling? Function Calling (wie OpenAIs Function Calling oder Claudes Tool Use) ist die Art und Weise, wie ein KI-Modell entscheidet, eine Funktion innerhalb eines einzelnen API-Aufrufs aufzurufen. MCP ist das Protokoll, das einem AI-Client ermöglicht zu entdecken, welche Funktionen von externen Servern verfügbar sind. Sie arbeiten zusammen -- der AI-Client nutzt Function Calling intern, um zu entscheiden, wann ein MCP-Tool aufgerufen wird. Stellen Sie sich MCP als die Plumbing zwischen Systemen vor, und Function Calling als den Entscheidungsprozess des Modells.

Wie viel kostet es, einen MCP-Server zu bauen und zu betreiben? Der Server selbst ist leicht. Für ein typisches SaaS-Produkt mit 10-20 Tools benötigen Sie ein paar hundert Zeilen TypeScript. Die Hosting-Kosten betragen je nach Traffic und Plattform $5-50/Monat. Die echten Kosten sind Entwicklerzeit -- rechnen Sie mit 2-4 Wochen für einen produktionsgerecht MCP-Server mit Auth, Fehlerbehandlung, Überwachung und Tests. Falls sich das viel anfühlt, haben wir Teams geholfen, diese schneller zu verschiffen. Schauen Sie sich unsere Preisseite für Details an.

Kann ich stattdessen Python verwenden? Absolut. Das offizielle Python SDK (pip install mcp) ist ausgezeichnet und hat möglicherweise sogar bessere Ergonomie für Tool-Definitionen. Verwenden Sie das, was Ihr Team kennt. Das Protokoll ist sprachenunabhängig. Wenn Ihr SaaS-Backend Python ist (Django, FastAPI), ist das Bauen des MCP-Servers in Python noch sinnvoller, da Sie Modelle und Validierungslogik teilen können.

Muss ich meine vorhandene API ändern? Nein. Ihr MCP-Server ist ein separater Service, der Ihre vorhandene API aufruft. Es ist eine Adapter-Schicht. Das heißt, Sie könnten sich selbst wünschen, ein paar API-Endpunkte speziell für AI-Verbrauch hinzuzufügen -- wie einen Search-Endpunkt, der mehr Kontext zurückgibt als Ihre UI benötigt. Das ist in Ordnung. Aber es ist additiv, nicht eine Änderung.

Wie handhabe ich lang laufende Operationen? Einige Tools könnten Operationen auslösen, die Minuten dauern (wie das Generieren eines Reports oder das Verarbeiten eines großen Imports). Verwenden Sie die Fortschrittsbenachrichtigungsfunktion von MCP, um den Client informiert zu halten. Ihr Tool-Handler kann Fortschrittsaktualisierungen ausstrahlen, während er wartet, dass die Operation abgeschlossen ist. Für sehr lange Operationen (>30 Sekunden) erwägen Sie, sofort mit einer Job-ID zurückzukehren und ein separates check_job_status Tool bereitzustellen.

Ist MCP stabil genug für Produktion? Ja, ab Mitte 2025. Die Spezifikation erreichte v1.0 im März 2025, und die Revision 2025-03-26 (die Streamable HTTP hinzugefügt hat) ist das, was große Clients übernommen haben. Anthropic, Microsoft, Google und OpenAI investieren alle in das Protokoll. Es wird nicht verschwinden. Das heißt, halten Sie Ausschau nach Spezifikations-Updates -- es gibt aktive Vorschläge für bessere Auth-Flows und Server-zu-Server-Kommunikation.

Was ist die beste Weise, Pagination in MCP-Tools zu handhaben? Geben Sie standardmäßig eine angemessene Seite mit Ergebnissen (20-50 Elemente) zurück, und akzeptieren Sie cursor oder page Parameter. Fügen Sie Pagination-Metadaten in Ihre Antwort ein, damit die KI weiß, dass es mehr Ergebnisse gibt. Etwa so: { results: [...], next_cursor: "abc123", total_count: 342 }. Die KI wird natürlich die nächste Seite anfordern, wenn der Benutzer mehr Daten benötigt.

Kann ein MCP-Server mehrere AI-Clients gleichzeitig unterstützen? Ja, und sollte es tun. Ihr MCP-Server ist nur ein HTTP-Server, der gleichzeitige Anfragen behandelt. Jede Anfrage enthält das Auth-Token des Benutzers, also beschränken Sie alles auf den richtigen Mandanten. Es gibt keinen Client-spezifischen Zustand, um den Sie sich kümmern müssen, wenn Sie den Streamable HTTP Transport korrekt verwenden. Behandeln Sie es wie jeden anderen zustandslosen API-Server.