Wie das Model Context Protocol (MCP) KI-Systeme kontextfähig macht

Einleitung

Ob Chatbot, Business-Agent oder Automatisierungstool, eines haben viele moderne KI-Anwendungen gemeinsam: Sie brauchen Kontext. Nur wenn ein System weiß, wer was wann getan hat, kann es sinnvoll reagieren. Technologien wie Semantic Kernel, MCP und Remote-Server liefern gemeinsam das Fundament, auf dem solche kontextbasierten Lösungen nicht nur funktionieren, sondern auch skalierbar und unternehmensweit einsetzbar sind.

In diesem Beitrag schauen wir uns an, wie diese Bausteine zusammenspielen und warum sich der (vermeintliche) Aufwand wirklich lohnt.

Grundlagen

Semantic Kernel

Auch wenn der Semantic Kernel (SK) vielen schon ein Begriff sein dürfte, hier nochmal die Basics in Kürze:

Der SK ist ein Open-Source-Toolkit von Microsoft, das es deutlich einfacher macht, KI-Funktionen in bestehende Softwareprojekte zu integrieren. Dabei übernimmt der Kernel die Rolle einer Art Middleware, die klassische Softwarelogik mit modernen KI-Modellen, z. B. GPT, kombiniert.

Schlüsselkomponenten

Die Kernfunktionalitäten des Semantic Kernel lassen sich in vier Hauptkomponenten gliedern:

  • Skills / Plugins: Modularisierte Funktionen, die entweder auf klassischem Code basieren oder aus KI-Prompts bestehen. Sie werden vom Modell bei passenden Anfragen aufgerufen.
  • Planners: Komponenten zur automatisierten Planung von Abläufen. Sie analysieren eine Nutzeranfrage und kombinieren die dazu notwendigen Skills in logischer Reihenfolge.
  • Memory: Ein persistenter Kontextspeicher, lokal oder remote, der es ermöglicht, über längere Zeiträume hinweg personalisierte Interaktionen und Rückbezüge herzustellen.
  • Connectors: Anbindungen an externe Systeme über OpenAPI-Spezifikationen, z. B. Microsoft Graph, CRM-Systeme, Kalenderdienste oder eigene REST-APIs. Damit wird der Semantic Kernel zur Brücke zwischen KI und realer Geschäftsanwendung.

Das Ziel des Semantic Kernel ist es, die klassische Programmierlogik mit semantischer KI zu verbinden. Mithilfe des SK lässt sich eine strukturierte Architektur aufbauen, in der klassische Funktionen, APIs und Geschäftslogik mit der Flexibilität moderner Large Language Models (LLMs) kombiniert werden. Dadurch können komplexe Aufgaben, Workflows und Zustände modelliert werden.

MCP

In KI-Systemen ist Kontext ein zentrales Element für sinnvolle, konsistente und personalisierte Interaktionen. Große Sprachmodelle wie ChatGPT, Claude oder Gemini sind inzwischen in der Lage, beeindruckend natürlich zu kommunizieren, zu analysieren und Aufgaben zu lösen. Doch es gab bislang ein großes Hindernis in der Zusammenarbeit mit diesen Modellen: Kontextverlust. Genau hier setzt das Model Context Protocol (MCP) an.

Also was ist das MCP?

Das Model Context Protocol (MCP) ist ein von Anthropic entwickeltes Open-Source-Protokoll und Framework zur Anbindung von KI-Modellen an externe Tools und Datenquellen. Der Kern von MCP ist einfach: Anstatt für jede Datenquelle oder jedes Tool eine eigene API-Anbindung mit individueller Logik zu entwickeln, stellt MCP ein gemeinsames Kommunikationsmuster bereit. Die KI-Anwendung, der sogenannte Host, interagiert über dedizierte Clients mit verschiedenen externen Servern, die jeweils bestimmte Funktionen oder Daten bereitstellen.

Remote MCP Server

Ein Remote MCP-Server ist eine ausgelagerte Instanz des MCP-Protokolls, die nicht direkt im gleichen Prozess oder auf derselben Maschine wie der KI-Host läuft, sondern über das Netzwerk angebunden ist, etwa in der Cloud oder auf einem internen Server.

Beispielsweise könnte er so genutzt werden:

Ein Vertriebsteam nutzt einen Chatbot, der auf Kundendaten, Angebote und Termine zugreifen soll. Statt die KI direkt in alle Systeme einzubinden, wird ein Remote MCP-Server verwendet. Er kennt die relevanten Systeme (z. B. CRM, Kalender, Produktdatenbank) und stellt dem KI-Agenten nur den gerade nötigen Kontext zur Verfügung.

Architektur und Aufbau

Das Model Context Protocol (MCP) folgt einem klar strukturierten Client–Host–Server-Modell. Im Zentrum steht eine Host-Anwendung (z. B. Claude, ein IDE-Plugin oder ein eigener Service), die über MCP-Clients mit einem oder mehreren MCP-Servern verbunden ist.

Komponenten im Überblick

  1. Host-Anwendung Dieser Prozess lebt das KI-Modell und orchestriert mehrere MCP-Client-Instanzen. Der Host übernimmt die Verwaltung von Zugriffsrechten, Sitzungen und Sicherheitsrichtlinien. Außerdem aggregiert er Kontextdaten aus verschiedenen Clients.
  2. MCP-Client Ein leichtgewichtiger Connector innerhalb des Hosts, der exakt je eine Verbindung zu einem MCP-Server aufbaut. Jeder Client verwaltet eigene JSON-RPC-basierte Sitzungen und ermöglicht bidirektionalen Austausch zwischen Host und Server.
  3. MCP-Server Läuft separat, entweder lokal oder als Remote-Service über HTTP/SSE. Er stellt spezialisierte Funktionen, Tools oder Datenquellen bereit und kommuniziert über das standardisierte JSON-RPC 2.0‑Protokoll mit zustandsbehafteten Sessions.
  4. Datenquellen & Funktionen Hinter dem MCP‑Server befindet sich eine konkrete Ressource, also beeispielsweise lokale Dateien, Datenbanken oder externe APIs sein. Der Server kapselt diese Ressourcen und exponiert über MCP funktionale Endpunkte, sogenannte Tools oder Prompts.

Warum ist das sinnvoll?

Viele aktuelle KI-Anwendungen setzen bereits auf Ansätze wie RAG (Retrieval-Augmented Generation) oder CAG (Context-Augmented Generation), um Sprachmodelle mit zusätzlichem Wissen oder Gesprächskontext zu versorgen. Beide Methoden liefern schnelle und flexible Ergebnisse, aber sie stoßen an Grenzen, wenn es um langfristige, strukturierte und unternehmensweite Nutzung geht.

Grenzen von RAG und CAG

  • RAG konzentriert sich auf den Ad-hoc-Zugriff auf externe Informationen, z. B. aus Dokumenten, Suchindizes oder Datenbanken. Es gibt aber keine zentrale Instanz, die verwaltet, welcher Kontext für welche Session oder welchen Benutzer relevant ist.
  • CAG erweitert Prompts zwar um gespeicherte Daten, aber oft lokal und ohne klaren Standard.

Vorteile durch MCP und Remote-Kontext

Ein Remote MCP-Server schafft hier eine zentrale Schicht für strukturierten, persistenten und geteilten Kontext. Das bietet vor allem im Unternehmens-Umfeld entscheidende Vorteile:

  • Skalierbarkeit: Kontext ist nicht an eine einzelne Instanz gebunden. Mehrere Agenten, Dienste oder Microservices können darauf zugreifen, unabhängig vom Deployment.
  • Wiederverwendbarkeit: Ein einmal erfasster Kontext (z. B. Projektinfos, Kundenpräferenzen) steht systemweit zur Verfügung, z. B. für Chatbots, Automatisierungen oder Benachrichtigungen.
  • Einheitlicher Zugriff auf Daten und Funktionen: Hinter jedem MCP-Server steckt eine konkrete Ressource, also z. B. eine Datenbank, lokale Dateien oder eine externe API. Diese werden über sogenannte Tools oder Prompts als klar definierte Endpunkte verfügbar gemacht.

Anwendungsbeispiel

Nun wollen wir uns ein Beispiel anschauen, bei dem Kundendaten über einen API-Call vom Remote-MCP-Server abgerufen und anschließend per Chat zurückgegeben werden können. Dazu betrachten wir zunächst den grundlegenden Aufbau des MCP-Servers und im Anschluss die Integration des benutzerdefinierten MCP-Tools in das SDK.

Aufbau des Remote MCP Servers mit Beispiel in C#

Für den Aufbau eines Remote-MCP-Servers in C# kann man dem offiziellen Quickstart-Tutorial auf der MCP-Website folgen:

https://modelcontextprotocol.io/quickstart/server#c%23

Dort wird Schritt für Schritt erklärt, wie man das .NET SDK verwendet, einen eigenen Server mit Tools definiert und diesen über verschiedene Transportmethoden, etwa HTTP, verfügbar macht.

var builder = WebApplication.CreateBuilder(args);
builder.Services
    .AddMcpServer()
    .WithTools<ApiCalls>()
    .WithHttpTransport();

var app = builder.Build();
app.MapMcp();
app.Run();
</pre>
Nachfolgend ist ein Beispiel-Tool ApiCalls, das in den MCP-Server eingebunden ist. Dieses Tool bietet eine Funktion zum Abrufen von Kundendaten anhand des Namens.
<pre>[McpServerToolType, Description("Tools for retrieving customer information")]
public class ApiCalls
{
    [McpServerTool, Description("Retrieve customer information by name.")]
    public static async Task<string> GetCustomerByNameAsync(
        [Description("The name of the customer to get the information for")] string customerName,
        [Description("Access token for authentication")] string accessToken)
    {
        string apiUrl = $"https://<your-api>/Customers?$filter=FamilyName eq '{customerName}'";

        using var httpClient = new HttpClient();

        var response = await httpClient.GetAsync(apiUrl);
        response.EnsureSuccessStatusCode();

        return await response.Content.ReadAsStringAsync();
    }
}

Integration des Servers in den SK mit Code Beispiel in C#

Nachdem wir den MCP-Server aufgebaut und unser Tool (z. B. zum Abrufen von Kundendaten) registriert haben, wollen wir nun zeigen, wie man diesen Server mit dem Microsoft Semantic Kernel (SK) verbindet.

In diesem Beispiel wird ein MCP-Client erstellt, der verfügbare Tools vom Server abruft und sie dynamisch in den Kernel als Plugins einbindet. Anschließend kann ein KI-Modell (wie GPT-4) über natürliche Sprache direkt mit diesen Tools interagieren – etwa, um Kundendaten abzufragen.

await using IMcpClient mcpClient = await McpClientFactory.CreateAsync(
        new SseClientTransport(new SseClientTransportOptions
        {
            Name = "MCPSSEServer",
            Endpoint = new Uri("http://localhost:5186/sse"), // Server-URL anpassen
            ConnectionTimeout = TimeSpan.FromSeconds(15)
        })
);

Nach erfolgreicher Verbindung fragen wir alle registrierten Tools ab:

var tools = await mcpClient.ListToolsAsync().ConfigureAwait(false);
foreach (var tool in tools)
{
    Console.WriteLine($"{tool.Name}: {tool.Description}");
}

Nun bauen wir den Semantic Kernel auf – samt Logging und OpenAI-Integration.

var builder = Kernel.CreateBuilder();
builder.Services.AddLogging(c => c.AddDebug().SetMinimumLevel(LogLevel.Trace));

// GPT-Modell (z. B. GPT-4o) integrieren
builder.Services.AddOpenAIChatCompletion(
    modelId: "gpt-4o",
    apiKey: "<your-openai-api-key>"
);
Kernel kernel = builder.Build();

Jetzt wandeln wir die MCP-Tools in Semantic Kernel-Funktionen um und registrieren sie einzeln:

var kernelFunctions = tools.Select(t => t.AsKernelFunction()).ToList();

foreach (var func in kernelFunctions)
{
    var plugin = kernel.CreatePluginFromFunctions(func.Name, new[] { func });
    kernel.Plugins.Add(plugin);
}

Um der KI mitzuteilen, dass Tools verwendet werden dürfen, definieren wir das Verhalten explizit:

OpenAIPromptExecutionSettings executionSettings = new()
{
    Temperature = 0,
    ToolCallBehavior = ToolCallBehavior.AutoInvokeKernelFunctions,
    MaxTokens = 1000
};

Um dies nun zu testen geben wir dem Modell einen Prompt – z. B. eine Kundenanfrage:

var prompt = "What do you know about customer with Family Name KNORKE";
Console.WriteLine($"\nFrage: {prompt}");

var result = await kernel.InvokePromptAsync(prompt, new(executionSettings));
Console.WriteLine($"\nAntwort:\n{result}");

Fazit

Durch die Integration in den Semantic Kernel können KI-Modelle nicht nur auf bestehende Daten und Funktionen zugreifen, sondern diese auch gezielt und automatisch nutzen, etwa um Kundendaten abzufragen, Systeme zu steuern oder Prozessketten zu starten, rein durch Text-/ oder Spracheingaben. Besonders spannend ist dabei die Möglichkeit, die Antworten der Tools strukturiert, z. B. im JSON-Format, zurückzugeben. So lässt sich die KI nicht nur als Chatpartner nutzen, sondern auch als steuernde Instanz für Benutzeroberflächen oder Workflows.