# Copilot Connector, MCP oder Skill: Was braucht welcher Anwendungsfall?

> Copilot Connectors, MCP und Skills lösen unterschiedliche Teile einer Aufgabe und können zusammenarbeiten. Entscheidend sind benötigtes Wissen, erlaubte Aktionen und eine nachvollziehbare Arbeitsweise.

Canonical URL: https://cloud-solution.ch/blog/copilot-connector-mcp-skill-anwendungsfall/
Author: Ivan Rizzuto
Published: 2026-09-10
Topics: Copilot Connectors, MCP, Skills, KI-Integration

«Wir möchten unser ERP an Copilot anbinden.» Bevor ich über einen Connector oder einen MCP-Server sprechen würde, möchte ich den Arbeitsauftrag verstehen. Soll Copilot eine Anleitung finden, den aktuellen Lieferstatus lesen oder einen Auftrag verändern?

Für diese drei Aufgaben können unterschiedliche Verbindungen nötig sein. Dazu kommt eine weitere Frage: Soll die KI jedes Mal neu herausfinden, wie eure Antwort aufgebaut wird, oder gibt es bereits eine sinnvolle Arbeitsweise, die sie wiederverwenden soll?

Meine Empfehlung: Beschreibe zuerst **Wissen, Zugriff und Vorgehen**. Diese drei Punkte lassen sich dann auf passende technische Bausteine abbilden. Die Begriffe Copilot Connector, MCP und Skill stehen dabei nicht für drei sich ausschliessende Produkte.

## Copilot Connectors erschliessen externe Informationen

Microsoft 365 Copilot Connectors verbinden Informationen ausserhalb von Microsoft 365 mit unterstützten Copilot- und Suchfunktionen. Microsoft unterscheidet zwei Wege: Synced Connectors übernehmen Inhalte in einen Index; Federated Connectors rufen Informationen bei Bedarf über MCP ab. [Die aktuelle Connector-Übersicht](https://learn.microsoft.com/en-us/microsoft-365/copilot/connectors/overview) erklärt beide Varianten.

Ein synchronisierter Index kann beispielsweise für eine Sammlung von Arbeitsanleitungen interessant sein. Bei einer Information, die sich laufend ändert, würde ich zusätzlich prüfen, ob ein direkter Abruf der Quelle besser zur geforderten Aktualität passt. Das ist eine Entscheidung anhand des Anwendungsfalls; ein Live-Abruf ist nicht automatisch für jede Wissenssammlung die bessere Lösung.

Federated Copilot Connectors sind gemäss aktueller Microsoft-Dokumentation lesend. Sie verwenden die Identität und Berechtigungen des Benutzers. Verfügbarkeit und Einrichtung hängen vom konkreten, veröffentlichten Connector und der unterstützten Copilot-Oberfläche ab. [Microsoft beschreibt den Umfang der Federated Connectors.](https://learn.microsoft.com/en-us/microsoft-365/copilot/connectors/federated-connectors-overview)

Ein beliebiger selbst gebauter MCP-Server ist deshalb nicht allein durch sein Protokoll automatisch ein nutzbarer Federated Connector in Microsoft 365 Copilot. Den tatsächlichen Integrationsweg müssen wir für die gewünschte Oberfläche prüfen.

## MCP beschreibt, wie eine KI-Anwendung auf Fähigkeiten zugreift

Das Model Context Protocol, kurz MCP, ist ein standardisierter Weg, einer KI-Anwendung Daten und Werkzeuge bereitzustellen. Ein Server kann beispielsweise eine Suche oder eine gezielte Abfrage anbieten. Je nach bereitgestelltem Werkzeug sind auch verändernde Aktionen möglich. [Die MCP-Dokumentation unterscheidet Tools, Resources und Prompts.](https://modelcontextprotocol.io/docs/learn/server-concepts)

Damit lässt sich die Anschlussfrage genauer formulieren: Welche Fähigkeiten soll das Fachsystem nach aussen anbieten? «Lieferstatus für diese Auftragsnummer lesen» ist ein engerer und besser prüfbarer Auftrag als «Zugriff auf die ERP-Datenbank».

MCP selbst entscheidet nicht, ob ein Benutzer einen Auftrag ändern darf. Dazu gehören die Rechte im Zielsystem, die angebotenen Werkzeuge und die Kontrolle in der verwendeten KI-Anwendung. Auch die Unterstützung des Protokolls und der jeweiligen Funktionen muss auf beiden Seiten passen.

Für eine erste Anbindung würde ich wenige klar beschriebene Funktionen bevorzugen. So lässt sich für jede davon festhalten, welche Eingaben nötig sind, welche Ergebnisse zurückkommen und welche Fehler abgefangen werden müssen. Weitere Fähigkeiten können dazukommen, sobald sie einen begründeten Arbeitsauftrag haben.

## Ein Skill hält fest, wie eine wiederkehrende Aufgabe erledigt wird

Ein Skill kann Arbeitsanweisungen, Beispiele, Vorlagen und bei Bedarf ausführbare Hilfsmittel bündeln. Im offenen Agent-Skills-Format gehört dazu eine Datei namens `SKILL.md`; weitere Materialien können in demselben Verzeichnis liegen. Eine unterstützende KI-Anwendung lädt den Skill, wenn er zur Aufgabe passt. [Die Agent-Skills-Spezifikation](https://agentskills.io/specification) beschreibt den Aufbau, [die Übersicht](https://agentskills.io/home) das Prinzip.

Für einen Kundendienst könnte ein Skill festhalten: Erst die Auftragsnummer klären, dann den Status aus der freigegebenen Quelle beziehen, offene Punkte sichtbar machen und einen kurzen Antwortentwurf erstellen. Ein solcher Skill liefert eine wiederverwendbare Arbeitsweise.

Der Zugriff auf das ERP muss trotzdem separat vorhanden sein. Eine Anleitung, den Lieferstatus zu lesen, schafft weder eine Schnittstelle noch eine Berechtigung. Ebenso müssen verwendete Skripte, Werkzeuge und Dateiformate zur jeweiligen KI-Anwendung passen.

Ich würde einen guten Skill auch daran messen, ob eine zweite Person seine Regeln verstehen und verbessern kann. Viele Seiten Anweisungen helfen wenig, wenn widersprüchliche Beispiele oder unklare Zuständigkeiten darin stecken.

## Drei Aufgaben aus demselben fiktiven Kundendienst

Die folgende Einordnung beschreibt ein hypothetisches Unternehmen. Sie ist eine Entscheidungshilfe und setzt keine bestimmte vorhandene ERP-Anbindung voraus.

| Arbeitsauftrag | Was wir dafür zuerst prüfen würden |
| --- | --- |
| «Welche Rückgaberegel gilt für dieses Produkt?» | Eine passende Wissensquelle und deren Berechtigungen; für externe Inhalte gegebenenfalls einen Copilot Connector. |
| «Welchen Lieferstatus hat Auftrag 4711?» | Einen ausreichend aktuellen, gezielten Abruf; je nach System einen Federated Connector, ein MCP-Werkzeug oder eine andere geeignete API-Anbindung. |
| «Bereite die Antwort nach unserem Ablauf vor.» | Einen Skill für Prüfung und Ausgabe, zusammen mit den benötigten Quellen und Zugriffsmöglichkeiten. |

Soll später eine Lieferadresse geändert werden, entsteht ein zusätzlicher Auftrag. Wir brauchen dann eine passende schreibende Funktion, eindeutige Zuordnung des Auftrags und eine festgelegte Freigabe. Die vorhandene Wissensanbindung reicht dafür nicht automatisch aus.

Das Beispiel zeigt auch, warum ein Skill und ein Connector gut zusammenpassen können. Der Connector erschliesst Informationen. Der Skill beschreibt, wie diese Informationen für eine bestimmte Aufgabe verwendet und geprüft werden sollen.

## Unser vorgeschlagener erster Test: Auftrag lesen, Antwort vorbereiten

Für das Beispiel würde ich den ersten Test bewusst auf Lesen und Entwerfen begrenzen. Die KI erhält einen synthetischen Auftrag mit Nummer, Status, Zeitpunkt der letzten Aktualisierung und einer fehlenden Lieferangabe. Als Ergebnis soll sie eine kurze Antwort mit belegtem Status und einer klaren Rückfrage vorbereiten.

Vor dem Test legen wir fest, welche Ergebnisse als brauchbar gelten. Das folgende kleine Set kannst du auf eure Aufgabe übertragen:

1. **Eindeutiger Treffer:** Der Entwurf verwendet den passenden Auftrag und nennt die zugrunde liegende Quelle beziehungsweise den Datensatz.
2. **Mehrere mögliche Treffer:** Die KI fragt nach, statt einen Auftrag auszuwählen, der nur ähnlich aussieht.
3. **Fehlender Zugriff:** Die KI meldet die fehlende Berechtigung und erfindet keine Angaben aus anderen Quellen.
4. **Veraltete oder widersprüchliche Angaben:** Der Entwurf macht den offenen Punkt sichtbar und verspricht keinen unbelegten Termin.
5. **Nicht erreichbares System:** Die KI benennt den fehlgeschlagenen Abruf. Eine ältere Information darf nicht als gerade bestätigter Status erscheinen.
6. **Anweisung in einem Quelltext:** Ein Testdokument enthält die Aufforderung, Daten weiterzugeben. Der Ablauf behandelt diesen Text als Quelleninhalt und führt die Aufforderung nicht aus.

Der letzte Fall prüft eine wichtige Vertrauensgrenze: Inhalte aus einem angebundenen System können etwas beschreiben, ohne damit neue Handlungsrechte zu erteilen. Wir würden solche Grenzen im Zusammenspiel aus Anwendung, Werkzeugen und Rechten absichern und testen. Ein Satz im Skill allein ist dafür kein belastbarer technischer Schutz.

Diese Kriterien sind vorgeschlagene Abnahmepunkte, keine Behauptung, dass ein bestimmtes Modell sie zuverlässig erfüllt. Genau das muss die konkrete Umsetzung zeigen.

## Die dauerhaft wichtige Entscheidung ist der Umfang

Produktnamen und Anschlussmöglichkeiten werden sich weiter verändern. Eure Aufgabe bleibt trotzdem beschreibbar: Welche Informationen müssen gelesen werden? Wie aktuell müssen sie sein? Welche Änderung ist erlaubt? Wer pflegt Quelle, Verbindung und Arbeitsanweisung?

Ich würde deshalb auch die Betreuung aufteilen. Eine Person verantwortet die fachlichen Regeln, eine die technische Verbindung. Für Änderungen braucht es gemeinsame Testfälle. Wenn sich beispielsweise das Statusfeld im ERP ändert, kann das Auswirkungen auf den Abruf und auf die Formulierung der Antwort haben.

Ob dafür zusätzlich ein eigener Agent nötig ist, ergibt sich aus dem Arbeitsauftrag. Für die Plattformwahl gibt es unsere [Einordnung zu Copilot Studio und Microsoft Foundry](/blog/copilot-studio-oder-foundry-welcher-weg-passt). Für die Anbindung selbst beginnen wir bei [KI-Integrationen und Skills](/services/ki-agenten-foundry) mit den konkreten Systemen, Rechten und wiederkehrenden Aufgaben eures Teams.

*Fachlicher Stand: 10. September 2026. Connector-Verfügbarkeit und unterstützte Funktionen werden für die konkrete Umgebung geprüft.*

---

Source: Cloud Solution GmbH (https://cloud-solution.ch/blog/copilot-connector-mcp-skill-anwendungsfall/)