MCP-Server

MCP-Server, über die Agenten dein Produkt nutzen, innerhalb deiner Grenzen.

Ein KI-Agent kann nur, was deine Tools erlauben. Wir entwerfen die Tools, binden sie an deinen Identity Provider an, legen fest, was jeder Aufrufer lesen und ändern darf, und testen den Server mit den MCP-Clients, die deine Nutzer wirklich verwenden.

MCP-Server besprechen →

KURZ ERKLÄRT

MCP-Server-Entwicklung macht dein Produkt oder interne Tools über das Model Context Protocol für KI-Agenten nutzbar. Der Auftrag umfasst Tool-Design, Autorisierung, Berechtigungsgrenzen, Versionierung und Tests mit echten MCP-Clients, geliefert als Code in deinem Repository.

Passt für

  • SaaS-Teams, deren Kunden das Produkt aus Claude, ChatGPT, Cursor oder eigenen Agenten heraus nutzen wollen
  • Unternehmen, deren interne Agenten mit klar begrenzten Rechten auf interne Systeme zugreifen sollen

Eine andere Leistung passt besser

  • Datensätze zwischen zwei Business-Systemen synchronisieren, ganz ohne Agent
  • Ein unabhängiger Missbrauchs- und Berechtigungstest eines bestehenden MCP-Servers

Eine Schnittstelle für Agenten, keine weitere Integration

Dieser Service baut die Schnittstelle, die ein KI-Agent aufruft. Datensätze zeit- oder ereignisgesteuert zwischen zwei Business-Systemen bewegen gehört zur API-Integration. Ein unabhängiger Berechtigungs- und Missbrauchstest des fertigen Servers gehört zu KI-Sicherheit. Das Agenten-Produkt selbst, also Prompts, Modelle und Nutzererlebnis, gehört zu KI-Agenten & Produkte. Wenn du noch zwischen MCP, Retrieval und Agent Skills wählst, lies zuerst MCP, RAG, Agent Skills oder Custom GPTs?

Tools um Ergebnisse herum entwerfen, die der Agent prüfen kann

Ein Tool ist ein Vertrag, den ein Modell liest. Namen, Beschreibungen, Eingabeschemas und Fehlermeldungen entscheiden, ob ein Agent es richtig aufruft. Wenige, klar begrenzte Tools schlagen ein Abbild jedes API-Endpunkts.

Lesen und Schreiben getrennt

Lesende Tools bleiben getrennt von Tools, die Daten ändern, Geld ausgeben oder Menschen kontaktieren. Destruktive Aktionen brauchen eine Bestätigung oder einen engeren Scope.

Schemas und Fehler

Typisierte Eingaben, begrenzte Ergebnisgrößen und Fehler, die dem Agenten sagen, was er ändern soll, statt eines Stacktraces.

Expliziter Anwendungszustand

Warenkörbe, Freigaben und lange Jobs bekommen eigene IDs und eigenen Speicher, damit jede Serverinstanz die nächste Anfrage bearbeiten kann.

Metadaten für Discovery

Eine Server Card und Tool-Annotationen, damit Clients und Prüfer vor dem Verbinden sehen, was der Server anbietet.

Autorisierung über deinen Identity Provider, begrenzt je Aufrufer

Nach der aktuellen MCP-Spezifikation ist ein Remote-Server ein OAuth-2.1-Resource-Server: Er prüft Tokens, die dein Identity Provider ausstellt, statt ein eigenes Login zu betreiben. Tokens sind an den Server als Audience gebunden und werden nie an nachgelagerte APIs durchgereicht. Lokale STDIO-Server beziehen Zugangsdaten stattdessen aus ihrer Umgebung. Die Enterprise-MCP-Autorisierungsarchitektur zeigt das Multi-Tenant-Design, von dem wir ausgehen. Prüfungen auf Datenebene bleiben in deinem Backend, weil das Protokoll allein keine Sicherheitsgrenze ist.

Versionierung, die Protokoll- und Produktänderungen übersteht

Mit Revision 2026-07-28 ist MCP zustandslos: kein Initialize-Handshake, kein Session-Header, und jede Anfrage trägt Protokollversion und Client-Fähigkeiten selbst mit. Wir bauen auf die Revision, die deine Ziel-Clients unterstützen, halten Tool-Änderungen wo möglich abwärtskompatibel und dokumentieren, was bricht, wenn es sich nicht vermeiden lässt. Der Leitfaden zur Migration auf zustandsloses MCP beschreibt die Transportänderungen im Detail.

Entwerfen, bauen und mit echten Clients testen

Umfang und Angebot werden je Phase vor Beginn vereinbart. Du kannst mit dem Entwurf selbst weiterarbeiten oder die abgestimmte Umsetzung beauftragen.

  1. Tool- und Zugriffsdesign

    Liste der Tools mit Ein- und Ausgaben, nötigen Scopes, Mandantenmodell und den Aktionen, die außer Reichweite bleiben.

  2. Umsetzung und Client-Tests

    Der Server in deinem Repository, automatisierte Tests und protokollierte Läufe mit den vereinbarten MCP-Clients.

  3. Weiterentwicklung

    Neue Tools, Protokoll-Updates und Client-Änderungen, separat vereinbart. Daraus entstehen keine 24/7-Abdeckung und kein Uptime-SLA.

Wir betreiben selbst einen MCP-Server in Produktion

Wavect betreibt einen öffentlichen MCP-Endpunkt unter wavect.io/mcp auf der zustandslosen Revision 2026-07-28. Lesende Tools für Services und Case Studies sind getrennt von Kaufaktionen, die nur bei aktiviertem Commerce sichtbar sind und einen ausdrücklichen Zahlungsschritt verlangen. Außerdem veröffentlichen wir den kostenlosen MCP Install Risk Scanner, der riskante Muster in MCP-Installationsbefehlen markiert, bevor jemand sie ausführt. Das ist unser eigenes Produkt, kein Kundenprojekt. Im Trust Center stehen unsere Zuständigkeiten und Service-Level.
// beweise

Angrenzende Engineering-Arbeit

Einen veröffentlichten MCP-Server-Fall für einen Kunden haben wir noch nicht, und wir behaupten auch keinen. Aniron dokumentiert angrenzende Arbeit: Wavect war Hauptbeitragender am Developer-Portal einer KI-Inferenz-API, mit API-Keys, Prepaid-Credits, Nutzungsübersicht und Integrationen. Unseren eigenen MCP-Endpunkt in Produktion beschreibt der Abschnitt oben. Beides ist keine Ergebnisgarantie für ein anderes System.

Aniron

Live
Entwicklerportal Kunden-Onboarding, API-Schlüsselverwaltung, Guthabenaufladung und Nutzungsübersicht umgesetzt.

Wavect war Hauptmitwirkender an Anirons Entwickleranwendung: API-Schlüssel, Guthaben, Nutzungsübersicht und Integrationen.

TypeScript Next.js React
AI 2026

Das sind ausgewählte Projekte, nicht unser gesamtes Portfolio. Seit 2018 haben wir 100+ Produkte ausgeliefert.

Fragen vor dem Start

Wenn Agenten nur wenige Endpunkte von einer einzigen Plattform aus aufrufen, kann Function Calling gegen deine API reichen. MCP lohnt sich, wenn mehrere Agenten-Clients dieselben Tools mit einheitlicher Autorisierung und Discovery nutzen sollen.
Remote-Server über HTTP passen zu SaaS-Produkten und gemeinsam genutzten internen Tools, mit OAuth über deinen Identity Provider. Lokale STDIO-Server passen zu Entwickler-Tools auf dem Rechner der Nutzer. Die Wahl bestätigen wir beim Scoping.
Mit den Clients deiner Nutzer, festgelegt im Angebot. Die Unterstützung für Protokollrevisionen und Autorisierung unterscheidet sich je Client, deshalb nennt das Angebot die einbezogenen Clients und Versionen.
Nur wenn du das so entscheidest. Solche Aktionen halten wir getrennt, eng begrenzt und bestätigungspflichtig, und die Berechtigung wird in deinem Backend durchgesetzt, nicht nur in der Tool-Beschreibung.
Autorisierungsdesign und Tests der vereinbarten Scopes gehören zum Build. Ein unabhängiger Missbrauchs- und Berechtigungstest des fertigen Servers wird separat als KI-Sicherheit gescopet.

Der passende nächste Schritt

MCP-Server besprechen

Beschreib das Produkt oder interne System, welche Aktionen ein Agent ausführen soll und wer sich verbindet. Für das erste Gespräch reicht ein kurzer Überblick ohne vertrauliche Details.

MCP-Server besprechen →