Eigene MCP-Server bauen: KI-Agenten mit domänenspezifischen Tools erweitern

Die meisten Teams, die KI-Coding-Agenten nutzen, beginnen mit den Tools, die sofort verfügbar sind. Damit kommt man überraschend weit: Dateizugriff, Terminal-Befehle, Websuche, Dokumentationsabfrage. Aber irgendwann stößt man an die Grenze. Ihre Agenten können Ihre internen Datenbanken nicht abfragen. Sie können Ihr Ticketsystem nicht prüfen. Sie können Ihre Deployment-Pipeline nicht auslösen oder Kundenkontext aus Ihrer proprietären API abrufen.

Diese Lücke füllen eigene MCP-Server. Anstatt darauf zu warten, dass jemand anderes eine Integration für Ihre internen Systeme baut, bauen Sie sie selbst. Sie definieren die Tools, kontrollieren die Berechtigungen, setzen die Sicherheitsgrenzen durch und geben Ihren Agenten genau die Fähigkeiten, die sie brauchen, um in den spezifischen Workflows Ihrer Organisation nützlich zu sein.

Das ist nicht theoretisch. Teams, die Agenten mit internen Tools verbinden, erleben einen qualitativen Wandel in dem, was diese Agenten leisten können. Ein Agent, der Ihr Datenbankschema lesen, aktuelle Deployments abfragen und den Status eines Jira-Tickets prüfen kann, ist grundlegend nützlicher als einer, der nur Dateien auf der Festplatte sehen kann. Der zusammengesetzte Wert kommt davon, Agenten Zugang zum selben Kontext zu geben, den Ihre Ingenieure bei Entscheidungen nutzen.

Wenn Sie bereits damit vertraut sind, wie MCP auf hoher Ebene funktioniert, aus unserem Überblick über KI-Coding-Agenten und MCP, geht dieser Leitfaden tiefer. Er behandelt Architekturentscheidungen, Sicherheitsmuster, Produktionsbelange und eine Referenzimplementierung, die Sie forken und anpassen können.

MCP-Architektur im Überblick

Bevor wir bauen, hilft es, die Architektur klar zu haben. MCP folgt einem Client-Server-Modell mit drei Schichten:

Host: Die Anwendung, mit der der Benutzer interagiert (eine IDE wie VS Code, Claude Desktop oder ein eigener Agent-Runner)
MCP Client: Lebt innerhalb des Hosts, verwaltet Verbindungen zu einem oder mehreren MCP-Servern
MCP Server: Stellt dem Client Fähigkeiten bereit, verbindet sich mit Ihren Backend-Systemen

Der Server ist der Ort, an dem Ihr Code lebt. Er empfängt Anfragen vom Client, führt Logik gegen Ihre Tools und Datenquellen aus und gibt strukturierte Ergebnisse zurück.

Transport-Optionen

MCP unterstützt zwei primäre Transportmechanismen:

stdio: Der Server läuft als Unterprozess des Hosts. Einfach, keine Netzwerkkonfiguration, ideal für lokale Entwicklung und Einzelbenutzer-Setups.
Streamable HTTP (ehemals HTTP/SSE): Der Server läuft als eigenständiger HTTP-Dienst. Erforderlich für Mehrbenutzer-Deployments, Remote-Zugriff und Produktionsumgebungen, in denen Sie ordentliche Authentifizierung und Load Balancing brauchen.

Für lokale Entwicklung und Tests ist stdio der schnellste Weg. Für alles, was Sie an ein Team deployen wollen, brauchen Sie HTTP-Transport mit ordentlicher Auth davor.

Kernprimitive

MCP-Server stellen drei Arten von Fähigkeiten bereit:

Tools: Funktionen, die der Agent aufrufen kann (eine Datenbank abfragen, ein Ticket erstellen, einen Build ausführen). Das sind die häufigsten und leistungsfähigsten Primitive.
Resources: Nur-Lese-Daten, auf die der Agent zugreifen kann (Datenbankschemata, Konfigurationsdateien, Dokumentation). Betrachten Sie diese als Kontext, den der Agent einziehen kann, bevor er entscheidet, was zu tun ist.
Prompts: Wiederverwendbare Prompt-Vorlagen, die den Agenten zu bestimmten Workflows leiten.

Bei den meisten eigenen Server-Projekten werden Sie 90% Ihrer Zeit damit verbringen, Tools und die Sicherheitsgrenzen drum herum zu definieren.

Wenn Sie praktische Erfahrung mit dem Verbinden zu bestehenden MCP-Servern sammeln möchten, bevor Sie Ihren eigenen bauen, starten Sie mit unserem Tutorial zum Einrichten von MCP-gestützten Coding-Agenten oder GitHub Copilot mit MCP-Tools erweitern.

Das richtige MCP-Server-Muster wählen

Nicht jeder MCP-Server braucht dieselbe Komplexitätsstufe. Das richtige Muster hängt davon ab, was Sie bereitstellen und welches Risikoprofil diese Operationen haben.

Nur-Lese-Datenzugriff

Das ist das einfachste und risikoärmste Muster. Ihr Server stellt Tools bereit, die Datenbanken abfragen, API-Antworten abrufen oder Dokumentation durchsuchen, aber nie etwas verändern.

Beispiele:

Eine Nur-Lese-Replik Ihrer Produktionsdatenbank abfragen
Interne Dokumentation oder Wissensbasen durchsuchen
Deployment-Status aus Ihrem CI/CD-System abrufen
Kundenkontext aus einer CRM-API nachschlagen

Nur-Lese-Server sind der beste Startpunkt. Sie liefern sofortigen Wert bei minimalem Risiko, weil der schlimmste Fall ist, dass der Agent Daten sieht, die er nicht sehen sollte, was Sie durch Autorisierung und Ausgabefilterung kontrollieren.

Zustandsverändernde Operationen

Sobald Sie über Lesezugriffe hinausgehen, steigen die Einsätze. Zustandsverändernde Operationen umfassen das Erstellen von Tickets, das Aktualisieren von Datensätzen, das Auslösen von Deployments oder das Ändern von Konfiguration.

Diese erfordern sorgfältiges Berechtigungsdesign:

Explizites Allowlisting der erlaubten Operationen
Bestätigungs-Workflows für destruktive Aktionen
Audit-Logging für jede Schreiboperation
Rollback-Fähigkeiten wo möglich

Das Schlüsselprinzip ist, dass Ihr MCP-Server strengere Grenzen durchsetzen sollte, als Sie es für einen menschlichen Benutzer tun würden. Ein Agent kann schneller und in größerem Volumen Fehler machen als eine Person. Ihr Server ist die Durchsetzungsschicht.

Multi-Tool-Komposition

Die nützlichsten MCP-Server stellen einen zusammenhängenden Satz verwandter Tools bereit, typischerweise fünf bis zehn, die als Toolkit zusammenarbeiten. Ein Datenbank-Server könnte list_tables, get_schema, query_database und explain_query bereitstellen. Ein Projektmanagement-Server könnte search_tickets, get_ticket, create_ticket, update_status und add_comment bereitstellen.

Die Komposition ist wichtig, weil Agenten besser denken, wenn Tools logisch gruppiert und gut dokumentiert sind. Ein Server mit drei fokussierten Tools ist nützlicher als einer mit dreißig lose verwandten.

Entscheidungsrahmen

Starten Sie nur lesend. Beweisen Sie den Wert. Fügen Sie dann Schreiboperationen einzeln hinzu, jede mit ihrer eigenen Berechtigungsprüfung und ihrem Audit-Trail. Das ist nicht um der Vorsicht willen vorsichtig. Es geht darum, Vertrauen in das System schrittweise aufzubauen, damit Sie später schneller vorankommen können.

Sicherheitsarchitektur für MCP-Server

Sicherheit ist kein nachträglicher Aspekt für MCP-Server. Sie ist die zentrale Designbeschränkung. Ihr MCP-Server sitzt zwischen einem KI-Agenten und Ihren internen Systemen. Wenn der Server permissiv ist, erbt der Agent diese Permissivität, und der Schadensradius eines Fehlers oder Angriffs skaliert entsprechend.

Authentifizierung

Wie der Server verifiziert, wer eine Anfrage stellt:

API Keys: Einfachste Option. Gut für interne Tools, Single-Tenant-Setups und Entwicklung. Keys in Umgebungsvariablen speichern, nie im Code. Regelmäßig rotieren.
OAuth2: Die richtige Wahl, wenn Ihr MCP-Server im Namen bestimmter Benutzer mit deren Berechtigungen handeln muss. Komplexer zu implementieren, aber notwendig für Mehrbenutzer-Produktions-Deployments.
mTLS: Mutual TLS für Service-to-Service-Kommunikation. Nutzen Sie dies, wenn Ihr MCP-Server von anderen Diensten aufgerufen wird statt direkt von Agent-Hosts.

Für die meisten Teams, die starten, ist API-Key-Authentifizierung mit Per-Key-Berechtigungs-Scoping die richtige Balance aus Sicherheit und Einfachheit.

Autorisierung

Authentifizierung sagt Ihnen, wer aufruft. Autorisierung sagt Ihnen, was sie tun dürfen.

Effektive MCP-Server-Autorisierung umfasst:

Per-Tool-Berechtigungen: Nicht jeder authentifizierte Benutzer sollte Zugang zu jedem Tool haben. Ein Nur-Lese-API-Key sollte keine Schreib-Tools aufrufen können.
Rollenbasierter Zugriff: Ordnen Sie API-Keys oder OAuth-Tokens Rollen zu (Reader, Writer, Admin) und setzen Sie Rollenprüfungen in jedem Tool-Handler durch.
Mandantenisolierung: Wenn Ihr Server mehrere Teams oder Kunden bedient, stellen Sie sicher, dass Abfragen auf die Daten des Aufrufers beschränkt sind. Verlassen Sie sich nie darauf, dass der Agent die richtige WHERE-Klausel hinzufügt.

Eingabevalidierung

Jede Eingabe von einem Agenten sollte als nicht vertrauenswürdig behandelt werden. Agenten können Parameter halluzinieren, und ein kompromittierter Prompt kann Injection-Angriffe versuchen.

import { z } from "zod";

const QueryToolSchema = z.object({
  table: z
    .string()
    .refine((t) => ALLOWED_TABLES.includes(t), {
      message: "Table not in allowlist",
    }),
  columns: z
    .array(z.string())
    .max(20, "Too many columns requested"),
  where: z
    .record(z.string(), z.union([z.string(), z.number()]))
    .optional(),
  limit: z
    .number()
    .int()
    .min(1)
    .max(100)
    .default(25),
});

Wichtige Validierungsmuster:

Schema-Durchsetzung für jede Tool-Eingabe mit Zod oder einer ähnlichen Bibliothek
SQL-Injection-Prävention durch parametrisierte Abfragen (nie String-Konkatenation)
Parameter-Bereinigung zum Entfernen oder Ablehnen gefährlicher Muster
Tabellen- und Spalten-Allowlisting zur Verhinderung des Zugriffs auf sensible Daten

Ausgabefilterung

Was von Ihren Backend-Systemen zurückkommt, kann Daten enthalten, die der Agent nicht sehen oder an den Benutzer zurückgeben sollte.

PII-Redaktion: E-Mail-Adressen, Telefonnummern, Sozialversicherungsnummern und andere sensible Felder maskieren, bevor Ergebnisse zurückgegeben werden
Sensible Spalten ausschließen: Spalten definieren, die unabhängig von der Abfrage nie zurückgegeben werden
Row-Level-Security: Ergebnisse basierend auf den Berechtigungen des Aufrufers filtern

Das ist wichtig, weil MCP-Tool-Antworten Teil des Agentenkontexts werden, und dieser Kontext kann für den Endbenutzer sichtbar oder in Weisen protokolliert sein, die Sie nicht vollständig kontrollieren.

Rate Limiting

Agenten können viel schneller Anfragen stellen als Menschen. Ohne Rate Limits kann ein falsch konfigurierter Agent Ihre Datenbank überlasten oder Ihre API-Kontingente in Minuten aufbrauchen.

Implementieren Sie Per-User- und Per-Tool-Rate-Limits. Geben Sie klare, strukturierte Fehler zurück, wenn Limits erreicht werden, damit der Agent intelligent zurückweicht, anstatt in einer engen Schleife erneut zu versuchen.

Für eine tiefergehende Behandlung von Sicherheitsmustern für agenten-verbundene Systeme siehe unseren Leitfaden zur Absicherung agentischer KI-Anwendungen und API-Sicherheits-Best-Practices für KI-integrierte Apps.

Wenn Ihr MCP-Server in Coding-Agent-Workflows verwendet wird, siehe auch unseren Leitfaden zur Absicherung von KI-Coding-Agent-Pipelines, der Erkennung, Richtlinienkontrollen und risikostufenbasierte Review-Gates auf CI/CD-Ebene behandelt.

Produktionsbelange

Ein Tool lokal zum Laufen zu bringen, ist der einfache Teil. Es zuverlässig, beobachtbar und wartbar in der Produktion zu machen, ist die eigentliche Engineering-Arbeit.

Fehlerbehandlung

Agenten können keine Stack-Traces lesen. Sie brauchen strukturierte Fehlerantworten, die beschreiben, was schiefgelaufen ist und was, wenn überhaupt, dagegen getan werden kann.

import { McpError, ErrorCode } from "@modelcontextprotocol/sdk/types.js";

function handleToolError(error: unknown): never {
  if (error instanceof ValidationError) {
    throw new McpError(
      ErrorCode.InvalidParams,
      `Invalid input: ${error.message}. Check the tool schema for valid parameters.`
    );
  }

  if (error instanceof AuthorizationError) {
    throw new McpError(
      ErrorCode.InvalidRequest,
      `Permission denied: your API key does not have access to this operation.`
    );
  }

  if (error instanceof QueryTimeoutError) {
    throw new McpError(
      ErrorCode.InternalError,
      `Query timed out after ${error.timeoutMs}ms. Try a more specific query with fewer results.`
    );
  }

  // Never expose internal details
  throw new McpError(
    ErrorCode.InternalError,
    "An unexpected error occurred. Contact the platform team if this persists."
  );
}

Die Fehlermeldungen sollten dem Agenten helfen, sich selbst zu korrigieren. „Ungültiger Tabellenname” ist besser als „Fehler.” „Tabelle nicht in Allowlist, gültige Tabellen sind: users, projects, deployments” ist noch besser.

Logging und Audit-Trails

Jeder MCP-Tool-Aufruf sollte einen strukturierten Log-Eintrag erzeugen, der erfasst:

Zeitstempel
Authentifizierte Identität (API-Key-ID, Benutzer oder Dienst)
Tool-Name und Eingabeparameter
Antwortzusammenfassung (Erfolg/Fehler, Zeilenanzahl, Dauer)
Jegliche Validierungsfehler oder blockierte Operationen

Das ist für den Produktionsbetrieb nicht optional. Wenn etwas schiefgeht, und das wird es, müssen Sie genau rekonstruieren, was der Agent angefordert hat und was der Server zurückgegeben hat. Behandeln Sie MCP-Server-Logs mit derselben Sorgfalt, die Sie auf API-Gateway-Logs oder Datenbank-Audit-Trails anwenden.

Testing

MCP-Server brauchen drei Testebenen:

Unit Tests für einzelne Tool-Handler: Gibt der Handler bei diesen Eingaben die richtige Ausgabe zurück und setzt die richtigen Beschränkungen durch?
Integrationstests mit einem Mock-MCP-Client: Funktioniert der gesamte Request/Response-Zyklus korrekt, einschließlich Auth, Validierung und Fehlerbehandlung?
Sicherheitstests: Lehnt der Server unautorisierte Anfragen korrekt ab, blockiert SQL-Injection-Versuche und maskiert sensible Daten?

Das MCP SDK bietet Hilfsmittel zum Erstellen von Test-Clients, was Integrationstests unkompliziert macht.

Deployment

Containerisieren Sie Ihren MCP-Server von Anfang an. Ein Multi-Stage-Docker-Build hält das Image klein, und Docker Compose ermöglicht es, den Server zusammen mit seinen Abhängigkeiten (Datenbank, Cache usw.) für die lokale Entwicklung zu betreiben.

Produktions-Deployments sollten umfassen:

Health-Check-Endpunkte
Graceful-Shutdown-Handling
Umgebungsbasierte Konfiguration (keine hartcodierten Geheimnisse)
Ressourcenlimits (Speicher, CPU)
Horizontale Skalierung für HTTP-Transport-Deployments

Versionierung

Wenn Ihr MCP-Server sich weiterentwickelt, werden Sie Tools hinzufügen, Schemata ändern und Verhalten modifizieren. Agenten, die von Ihrem Server abhängen, werden brechen, wenn Sie Tool-Schemata ohne Koordination ändern.

Best Practices:

Tool-Schemata als öffentlichen API-Vertrag behandeln
Neue Tools hinzufügen statt bestehende zu modifizieren, wenn möglich
Semantische Versionierung für Ihren Server verwenden
Breaking Changes dokumentieren und Migrationsanleitungen bereitstellen
Erwägen, mehrere Server-Versionen parallel während Übergängen zu betreiben

Die mcp-enterprise-starter-Referenzimplementierung

Um all dies konkret zu machen, haben wir mcp-enterprise-starter gebaut, eine Referenzimplementierung, die jedes in diesem Leitfaden besprochene Muster demonstriert.

Architektur

Das Repo ist als TypeScript-MCP-Server strukturiert, der sich mit PostgreSQL verbindet:

mcp-enterprise-starter/
  src/
    server.ts              # MCP-Server-Setup und Transport-Konfiguration
    tools/
      query-database.ts    # Sicheres Datenbank-Abfrage-Tool
      list-tables.ts       # Tabellenlisten-Tool
      get-schema.ts        # Schema-Inspektions-Tool
    resources/
      schema.ts            # Datenbankschema als MCP-Ressource
    middleware/
      auth.ts              # API-Key-Authentifizierung
      validation.ts        # Eingabevalidierung und -bereinigung
      rate-limit.ts        # Per-User-Rate-Limiting
    utils/
      db.ts                # PostgreSQL-Connection-Pool
      sanitize.ts          # Query-Bereinigungshelfer
      errors.ts            # Strukturierte Fehlertypen
  tests/
  docker-compose.yml
  Dockerfile

Server-Setup

Die Server-Initialisierung verbindet Transport, Authentifizierung und Tool-Registrierung:

import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import {
  CallToolRequestSchema,
  ListToolsRequestSchema,
} from "@modelcontextprotocol/sdk/types.js";
import { requireAuth } from "./middleware/auth.js";
import { checkRateLimit } from "./middleware/rate-limit.js";

const server = new Server(
  { name: "mcp-enterprise-starter", version: "1.0.0" },
  { capabilities: { tools: {}, resources: {} } },
);

// Register tool listing
server.setRequestHandler(ListToolsRequestSchema, async () => ({
  tools: [queryDatabaseTool, listTablesTool, getSchemaTool],
}));

// Handle tool calls with auth and rate limiting
server.setRequestHandler(CallToolRequestSchema, async (request) => {
  const { name, arguments: args } = request.params;
  const apiKey = process.env.MCP_API_KEY || process.env.API_KEYS?.split(",")[0];
  const authCtx = requireAuth(apiKey);
  checkRateLimit(authCtx.apiKey);

  switch (name) {
    case "query_database":
      return await handleQueryDatabase(args);
    case "list_tables":
      return await handleListTables();
    case "get_schema":
      return await handleGetSchema(args);
    default:
      throw new Error(`Unknown tool: ${name}`);
  }
});

// Start with stdio transport for local dev
const transport = new StdioServerTransport();
await server.connect(transport);

Sichere Datenbankabfragen

Das query_database-Tool demonstriert, wie man einem Agenten nützlichen Datenbankzugriff gibt, ohne ihm uneingeschränkte SQL-Ausführung zu geben:

Abfragen sind validierte SQL-Strings mit parametrisierten Werten, keine ungefilterte Rohausführung
Tabellen- und Spaltennamen werden gegen eine Allowlist validiert
Alle Werte werden als parametrisierte Abfrageargumente übergeben
Ergebnisse sind standardmäßig begrenzt mit einem konfigurierbaren Maximum
Sensible Spalten werden in der Ausgabe maskiert
Destruktive Schlüsselwörter (DROP, DELETE, UPDATE, ALTER) werden für Nur-Lese-Keys komplett blockiert

Auth-Middleware

Die Authentifizierungsschicht ordnet API-Keys Berechtigungssets zu:

import { McpToolError } from "../utils/errors.js";

export interface AuthContext {
  apiKey: string;
  permissions: "read" | "read-write";
}

function getApiKeys(): Map<string, AuthContext> {
  const keys = new Map<string, AuthContext>();
  const envKeys = process.env.API_KEYS || "";

  for (const key of envKeys.split(",").map((k) => k.trim()).filter(Boolean)) {
    keys.set(key, { apiKey: key, permissions: "read" });
  }
  return keys;
}

export function requireAuth(apiKey: string | undefined): AuthContext {
  if (!apiKey) {
    throw new McpToolError("auth_error", "Missing API key.", false);
  }
  const validKeys = getApiKeys();
  const context = validKeys.get(apiKey);
  if (!context) {
    throw new McpToolError("auth_error", "Invalid API key.", false);
  }
  return context;
}

API-Keys werden aus der API_KEYS-Umgebungsvariable als kommagetrennte Liste geladen (z.B. dev-key-1,dev-key-2). Jeder Key wird einem Berechtigungslevel zugeordnet. Für Produktionssysteme würden Sie dies mit Per-Key-Tool-Einschränkungen, rollenbasiertem Zugriff erweitern oder es komplett durch OAuth2 ersetzen.

Verwendung

Der schnellste Weg vom Klonen zum funktionierenden Server:

Klonen Sie das Repo und kopieren Sie .env.example nach .env
Führen Sie docker compose up aus, um PostgreSQL mit geseedeten Beispieldaten und den MCP-Server zu starten
Kopieren Sie die bereitgestellte mcp-config.json in Ihre Claude Desktop- oder VS Code-MCP-Konfiguration
Stellen Sie Ihrem Agenten Fragen: „Welche Tabellen sind verfügbar?”, „Zeige mir das Schema der Projekttabelle”, „Finde alle Benutzer in der Engineering-Abteilung”

Die Beispieldatenbank enthält realistische Tabellen (users, departments, projects) mit genügend Daten, um Abfrageerstellung, Filterung und Maskierung sensibler Spalten zu demonstrieren.

Anpassung für eigene Systeme

Das Repo ist zum Forken und Modifizieren gedacht. Um es mit Ihren eigenen internen Tools zu verbinden:

Ersetzen Sie die Datenbankverbindung durch Ihre Datenquelle
Definieren Sie neue Tools in src/tools/ nach den bestehenden Mustern
Aktualisieren Sie die Tabellen- und Spalten-Allowlists in Ihrer Konfiguration
Fügen Sie Ihre eigenen API-Keys und Berechtigungs-Scopes hinzu
Schreiben Sie Tests für Ihre spezifische Tool-Logik

Die Muster für Auth, Validierung, Fehlerbehandlung und Logging übertragen sich unabhängig davon, mit welchem Backend Sie sich verbinden. Das ist der Sinn der Referenzimplementierung: Sie gibt Ihnen eine produktionsreife Hülle, die Sie mit Ihrer eigenen Domänenlogik füllen.

Wie es weitergeht

Wenn Sie einen eigenen MCP-Server Schritt für Schritt bauen und deployen möchten, folgen Sie unserem Begleittutorial: Einen eigenen MCP-Server bauen, absichern und deployen. Es führt durch jede Phase vom Scaffolding bis zum containerisierten Deployment mit funktionierendem Code bei jedem Schritt.

Wenn Sie noch keine MCP-gestützten Agenten eingerichtet haben, starten Sie mit den Grundlagen:

MCP-gestützte Coding-Agenten einrichten für die anfängliche Konfiguration
GitHub Copilot mit MCP-Tools erweitern zum Hinzufügen von Tools zu Copilots Agent-Modus

Die breitere Entwicklungsrichtung für MCP geht in Richtung Multi-Server-Orchestrierung, bei der eine einzelne Agenten-Sitzung sich gleichzeitig mit mehreren MCP-Servern verbindet, wobei jeder eine andere Fähigkeitsdomäne bereitstellt. Server-Registries und Discovery-Protokolle entstehen, um diese Koordination handhabbar zu machen. Teams, die jetzt gut strukturierte, sichere MCP-Server bauen, werden in der stärksten Position sein, wenn dieses Ökosystem reift.

Der grundlegende Wandel ist unkompliziert: Ihre internen Tools sind nicht mehr nur für Menschen. Sie werden zu Fähigkeiten, die KI-Agenten nutzen können, unter Ihrer Kontrolle, mit Ihren Sicherheitsgrenzen, innerhalb Ihrer Workflows. Einen eigenen MCP-Server zu bauen ist, wie Sie das Wirklichkeit werden lassen.

Holen Sie sich das MCP Enterprise Starter Kit →