MCP überall -- Wie das Model Context Protocol die M365-Entwicklung verändert

Wenn du dieses Jahr irgendetwas im Microsoft 365 Ecosystem gebaut hast, ist dir wahrscheinlich ein Muster aufgefallen. Jedes große Announcement – Teams SDK, Copilot Studio, Declarative Agents – erwähnt ständig die gleichen drei Buchstaben: MCP.

Ich bin zum ersten Mal auf das Model Context Protocol gestoßen, als Anthropic die Spec Ende 2024 veröffentlicht hat. Interessante Idee, dachte ich mir. Ein Standard, wie AI-Modelle mit externen Systemen reden. Cool. Abgeheftet unter “Dinge die ich beobachte.” Simon Doy hat im August einen super Deep Dive in MCP Grundlagen für M365 Copilot geschrieben, der lesenswert ist, wenn du die Protokoll-Basics im M365 Kontext abgedeckt haben willst. Neun Monate vorspulen, und Microsoft hat voll drauf gesetzt. MCP ist kein Nice-to-have mehr. Es wird zum Standard-Integrationsprotokoll für alles, was mit Agents in Microsoft 365 zu tun hat.

Hier ist, was passiert ist, wo MCP jetzt überall auftaucht, und was das bedeutet wenn du auf M365 aufbaust.

Was MCP eigentlich ist

Model Context Protocol ist ein offener Standard – ursprünglich von Anthropic – der definiert, wie AI-Anwendungen mit externen Datenquellen und Tools kommunizieren. Die vollständige MCP Specification ist lesenswert, wenn du die Protokoll-Details willst. Stell es dir als Universal-Adapter zwischen einem AI-Modell und der Außenwelt vor.

Vor MCP war jede Integration maßgeschneidert. Du willst, dass dein Copilot Agent mit deinem ERP-System redet? Bau einen Custom Connector. Du willst eine Datenbank abfragen? Noch eine Custom Integration. Jede neue Datenquelle bedeutete neues Plumbing. Anthropic hat das das “N x M Problem” genannt – N AI-Anwendungen mal M Datenquellen, jede braucht ihre eigene individuelle Integration.

MCP löst das mit einem standardisierten Protokoll basierend auf JSON-RPC 2.0. Ein MCP Server stellt Capabilities über drei Primitive bereit:

Tools – Funktionen, die das AI-Modell aufrufen kann (model-controlled)
Resources – Daten, die die Anwendung lesen kann, wie Files oder API Responses (application-controlled)
Prompts – wiederverwendbare Prompt Templates (user-controlled)

Die Transport-Schicht unterstützt sowohl lokale Verbindungen (via stdio) als auch Remote-Verbindungen (via HTTP mit Server-Sent Events, oder dem neueren Streamable HTTP Transport). Für M365 Szenarien wirst du fast immer den Remote HTTP Ansatz verwenden.

Der Punkt ist: Bau einen MCP Server für dein Business System, und jeder MCP-kompatible Client – Copilot Studio, ein Declarative Agent, ein Teams Bot – kann ihn nutzen. Ohne zusätzliche Integrationsarbeit.

MCP im Teams SDK

Die aktualisierte Teams AI Library (wird später dieses Jahr in “Teams SDK” umbenannt) ist im September als GA für JavaScript und C# erschienen, mit Python in Developer Preview. Microsofts offizielle Ankündigung deckt den vollen Umfang ab, aber der Kernpunkt ist: MCP Support ist direkt eingebaut.

Das SDK liefert optionale Packages, die deinen Teams Agent als MCP Client, MCP Server oder beides agieren lassen. Als MCP Client kann dein Agent sich mit externen MCP Servern verbinden und deren Tools dynamisch entdecken. Als MCP Server kann dein Agent seine eigenen Capabilities für andere Agents bereitstellen.

Hier wird es interessant: Tool Definitions laden dynamisch. Wenn ein MCP Server ein neues Tool hinzufügt, nimmt dein Agent das automatisch auf. Kein Redeployment. Kein Manifest Update. Der Server deklariert, was er kann, und der Client passt sich an.

Das klingt unspektakulär, ist aber in der Praxis enorm wichtig. Stell dir einen Teams Agent vor, der mit drei verschiedenen MCP Servern verbunden ist – dein CRM, dein Ticketing System, interne Docs. Jedes Server-Team wartet seine eigenen Tools unabhängig, und dein Agent bleibt aktuell, ohne dass du eine Zeile Code anfasst.

Dazu noch die SDK-Unterstützung für Agent-to-Agent (A2A) Kommunikation und Agentic Memory (persistenter Kontext über Konversationen hinweg), und das Ganze fängt an, sich sehr anders anzufühlen als die Chatbot-Frameworks, die wir vor einem Jahr verwendet haben.

MCP in Copilot Studio

Copilot Studio hat MCP Support seit Mai 2025, und es hat Ende Mai General Availability erreicht. Aber die September Updates runden es richtig ab.

Das Setup ist simpel. In deinem Agent gehst du auf Tools, dann Add Tool, dann New Tool, und wählst MCP. MCP Server URL reinkopieren. Das war’s. Copilot Studio entdeckt die verfügbaren Tools von deinem Server und macht sie für deinen Agent nutzbar. Du brauchst Generative Orchestration aktiviert, aber das ist sowieso der Default für neue Agents.

Was im September gelandet ist, ist MCP Resource Support in Public Preview. Vorher konnte Copilot Studio nur MCP Tools aufrufen – also im Grunde Funktionen triggern. Jetzt können Agents auch MCP Resources lesen: Files, API Responses, Datenbankeinträge. Das ist wichtig, weil dein MCP Server jetzt sowohl Actions als auch Daten über einen einzigen Endpoint bereitstellen kann.

Das Tracing und die Analytics sind auch besser geworden. Die Activity Map zeigt jetzt genau, welcher MCP Server und welches Tool zur Laufzeit aufgerufen wurde. Wenn du debuggst, warum ein Agent eine komische Antwort gegeben hat, spart es dir enorm viel Rätselraten, wenn du siehst, welches externe Tool er aufgerufen hat (und was zurückkam).

Noch etwas das erwähnenswert ist: Copilot Studio reflektiert Änderungen an deinem MCP Server dynamisch. Tool hinzufügen, Tool entfernen, Beschreibung updaten – der Agent nimmt die Änderungen automatisch auf. Kein manueller Sync nötig.

MCP in Declarative Agents

Das kommt auf der Ignite im November 2025 als Public Preview, aber es lohnt sich, das jetzt schon zu verstehen, weil es die letzte Lücke schließt.

Declarative Agents sind die Art, wie du Microsoft 365 Copilot für spezifische Business-Szenarien anpasst. Sie sitzen innerhalb der Copilot Experience und können auf M365 Daten zugreifen, aber bisher bedeutete die Anbindung an externe Systeme, API Plugins mit OpenAPI Specs zu bauen. Hat funktioniert, aber war verbose und brauchte viel manuelle Konfiguration.

Mit MCP Support fällt das meiste davon weg. Das Microsoft 365 Agents Toolkit in VS Code wird einen geführten Flow anbieten:

Neues Declarative Agent Projekt erstellen
“Add Action” auswählen und dann “Start with an MCP server”
Deine MCP Server URL eingeben
Das Toolkit holt die verfügbaren Tools und lässt dich wählen, welche du einbinden willst
Authentifizierung konfigurieren (SSO und OAuth 2.0 werden unterstützt)
Das Toolkit generiert das gesamte Scaffolding – manifest.json, ai-plugin.json, declarativeAgent.json – automatisch

Du musst keine JSON Manifests von Hand editieren oder Funktionsdefinitionen manuell schreiben. Das Toolkit liest das MCP Schema und generiert alles.

Hier klickt das “einmal bauen, überall nutzen” Versprechen von MCP richtig. Der gleiche MCP Server, der deinen Copilot Studio Agent antreibt, kann auch deinen Declarative Agent in M365 Copilot antreiben. Gleicher Server, gleiche Tools, andere Oberfläche.

Einen MCP Server für M365 bauen

Wie schaut also ein MCP Server tatsächlich aus? Es ist ein HTTP Endpoint, der die MCP Specification implementiert. Es gibt offizielle SDKs für TypeScript, Python, C#, Java und mehr – alle verfügbar von der Model Context Protocol GitHub Organization.

Hier ist ein minimales konzeptuelles Beispiel in TypeScript:

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

const server = new McpServer({
  name: "contoso-inventory",
  version: "1.0.0",
});

// Define a tool
server.tool(
  "getProductStock",
  "Check current stock level for a product",
  { productId: { type: "string", description: "The product SKU" } },
  async ({ productId }) => {
    const stock = await inventoryDb.getStock(productId);
    return {
      content: [
        { type: "text", text: `Product ${productId}: ${stock.quantity} units in stock` }
      ],
    };
  }
);

// Define a resource
server.resource(
  "product-catalog",
  "products://catalog",
  async () => ({
    contents: [
      { uri: "products://catalog", text: JSON.stringify(await inventoryDb.getCatalog()) }
    ],
  })
);

Der Server deklariert seine Tools mit Namen, Beschreibungen und Input Schemas. Das AI-Modell nutzt die Beschreibungen, um zu entscheiden, wann es ein Tool aufruft, und das Schema, um die richtigen Parameter zusammenzubauen. Gute Beschreibungen sind wichtig – sie sind im Grunde dein Prompt Engineering für die Tool Selection.

Für M365 Copilot im Speziellen musst du deinen MCP Server als Agent Connector im Microsoft 365 App Manifest registrieren. So entdeckt die Plattform deinen Server und handhabt die Authentifizierung. Das Agents Toolkit übernimmt diese Verdrahtung für dich, aber es ist gut zu wissen, was unter der Haube passiert.

Authentifizierung ist der Teil, der am meisten Überlegung braucht. Für Enterprise-Szenarien wirst du typischerweise OAuth 2.0 mit Azure AD Tokens verwenden. Dein MCP Server validiert den Token, extrahiert die User-Identität und gibt Daten zurück, die auf die Berechtigungen des Users zugeschnitten sind. Die Plattform unterstützt SSO out of the box, damit User sich nicht separat anmelden müssen.

Der A2A Begleiter – Agents die Agents aufrufen

MCP handhabt die Verbindung zwischen einem AI Agent und einem Tool oder einer Datenquelle. Aber was ist mit Agents, die miteinander reden?

Da kommt das Agent2Agent (A2A) Protocol ins Spiel. Google hat A2A im April 2025 vorgestellt, und Microsoft hat es fast sofort unterstützt – mit der Ankündigung von Support in Azure AI Foundry und Copilot Studio im Mai. Das Protokoll ist jetzt unter der Linux Foundation, mit über 50 Technologiepartnern an Bord.

Stell dir MCP und A2A als komplementäre Schichten vor:

MCP = Agent zu Tool (vertikale Integration)
A2A = Agent zu Agent (horizontale Kollaboration)

A2A lässt Agents einander über “Agent Cards” (JSON Metadaten die Capabilities beschreiben) entdecken, Tasks mit definierten Lifecycle States austauschen und Kontext teilen. Denk an Einkaufs- und Lager-Agents, die bei einer Bestellung zusammenarbeiten müssen, ohne dass ein Mensch sie miteinander verdrahtet.

Das Teams SDK unterstützt A2A Communication Patterns bereits. Kombinier das mit MCP für Tool-Zugriff, und du kannst ziemlich aufwendige Multi-Agent Workflows innerhalb von M365 zusammenbauen.

Praktisches Szenario – dein Business System anbinden

Machen wir es konkret. Sag du hast ein internes Inventory Management System mit einer REST API. Wenn du heute willst, dass M365 Copilot User Lagerbestände prüfen oder Nachbestellungen per natürlicher Sprache aufgeben können, würdest du ein API Plugin mit einer OpenAPI Specification bauen, Authentifizierung konfigurieren, detaillierte Funktionsbeschreibungen schreiben und es als Declarative Agent deployen.

Mit MCP verschiebt sich der Ansatz:

Bau einen MCP Server, der deine Inventory API wrappt. Definiere Tools wie getProductStock, searchProducts, createReorderRequest. Definiere Resources wie den Produktkatalog.
Verbinde ihn mit Copilot Studio, indem du die URL reinkopierst. Dein Low-Code Team kann sofort Agents darauf aufbauen.
Verbinde ihn mit einem Declarative Agent über das Agents Toolkit. Dein Pro-Dev Team bekommt ihn mit ein paar Klicks in M365 Copilot.
Verbinde ihn mit einem Teams Bot über den MCP Client des Teams SDK. Gleicher Server, dritte Oberfläche.
Stell ihn anderen Agents via A2A bereit, damit ein Procurement Agent von einem anderen Team deinen Lagerbestand als Teil seines Workflows abfragen kann.

Ein Server, mehrere Consumer. Wenn deine Inventory API einen neuen Endpoint bekommt, fügst du ein Tool zum MCP Server hinzu, und jeder verbundene Agent nimmt es auf. Du redeployst keine Clients, du updatest keine Manifests, du koordinierst nicht über Teams hinweg.

Das ist es, was das Ganze so interessant macht. Dein Business System wird zu etwas, das jeder Agent im Ecosystem selbstständig entdecken und nutzen kann.

Wohin das führt

Die Art, wie M365 Integrationen funktionieren, ändert sich. Das alte Modell – einen spezifischen Connector für eine spezifische Oberfläche bauen – weicht etwas Looserem. Bau eine Capability einmal, stell sie über ein Standardprotokoll bereit, lass jeden Agent sie nutzen.

Die September 2025 Welle (Teams SDK GA, Copilot Studio MCP Resources, A2A Support) bringt die meisten Puzzleteile zusammen. Die Ignite Announcements im November (Declarative Agents mit MCP) füllen den Rest. Anfang 2026 erwarte ich, dass MCP die Default-Empfehlung für jedes neue M365 Integrationsprojekt sein wird.

Wenn du heute eine neue Integration startest, bau einen MCP Server. Auch wenn du ihn jetzt nur mit einer Oberfläche verbindest, wirst du dir später selbst danken, wenn ein zweites Team nach Zugriff fragt.

Weiterlesen

MCP Specification – die vollständige Model Context Protocol Spec von Anthropic
Simon Doys MCP Grundlagen für M365 Copilot – super Primer zu MCP Protokoll-Basics im M365 Kontext
Announcing the updated Teams AI Library and MCP support – Microsoft DevBlog zum Teams SDK mit MCP und A2A
Build declarative agents for Microsoft 365 Copilot with MCP – Microsoft DevBlog zur Agents Toolkit MCP Integration

Enjoyed this post? Let's connect on LinkedIn:

Follow on LinkedIn →