MCP-Server – Onboarding für Claude & Copilot Studio

Version: August 2026 — ergänzt: Delivery-Gate & Versions-Transparenz, get_hierarchy, Microsoft-365-Copilot-Kapitel (Teil D), Claude-Code-Teamsetup, Hinweis zu per Retention entfernten Versionen (version_pruned) Zielgruppe: Entra-/Claude-Administratoren, Data Engineers, Power-Platform-Admins, M365-/Teams-Admins Voraussetzung: Feature MCP-Server ist für Ihren Mandanten aktiviert (Einstellungen → Integrationen → MCP-Server; ist es gesperrt, wenden Sie sich an Ihren MDM-Lite-Administrator)

Dieser Leitfaden beschreibt, wie Sie den read-only MCP-Server von MDM Lite mit den KI-Clients der Anthropic-Claude-Familie, mit Microsoft 365 Copilot und – als sekundären Pfad – mit Microsoft Copilot Studio verbinden.

Der MCP-Server ist ausschließlich lesend: Er beantwortet Fragen zu Datasets, Schema, Versionen, Zeileninhalten, Hierarchien, Audit-Historie und Importen. Änderungen an Daten erfolgen weiterhin nur in der Web-UI oder über die REST-API.

Inhaltsverzeichnis

1. Überblick & Verbindungspfade
2. Der MCP-Endpunkt
3. Verfügbare Werkzeuge
4. Versions- und Auslieferungssemantik für KI-Antworten
5. Verteilungsmodell: eigene App-Registrierung pro Kunde
6. Teil A – claude.ai / Claude Desktop (Custom Connector, OAuth)
7. Teil B – Claude Code (API-Key)
8. Teil C – Copilot Studio (sekundär, API-Key)
9. Teil D – Microsoft 365 Copilot (Declarative Agent)
10. Secret-Rotation & Widerruf
11. Netzwerk & Firewall
12. Fehlerbehebung

1. Überblick & Verbindungspfade

Je nach Client gibt es zwei Authentifizierungswege am selben /mcp-Endpunkt:

Empfehlung: Für hosted Surfaces (claude.ai, Claude Desktop) ist OAuth (Teil A) der verlässliche Weg – statische API-Key-Header sind dort nur in einer eingeschränkten Beta verfügbar. Für Claude Code und Automatisierung ist der API-Key (Teil B) sofort nutzbar. Für Microsoft 365 Copilot ist der Declarative Agent (Teil D) der primäre Pfad – er läuft ohne eigene Copilot-Studio-Lizenz und behält die Rollen des angemeldeten Users bei; Copilot Studio (Teil C) bleibt der sekundäre Pfad für Kunden, die ohnehin Studio-Agenten bauen.

2. Der MCP-Endpunkt

Der Endpunkt Ihres Mandanten lautet:

https://{host}/mcp

Den konkreten Wert für {host} finden Sie in Einstellungen → Integrationen → MCP-Server (dort wird die vollständige Endpunkt-URL angezeigt und ist kopierbar). Der Endpunkt ist ein Streamable-HTTP-MCP-Server; SSE wird nicht unterstützt.

Zusätzlich stellt der Server – anonym und host-weit – die OAuth-Discovery-Metadaten nach RFC 9728 bereit, die Claude beim Verbinden automatisch liest:

GET https://{host}/.well-known/oauth-protected-resource/mcp

Für jede weitere Umgebung gibt es einen eigenen Endpunkt mit eigenen Discovery-Metadaten (https://{host}/mcp/{umgebungs-slug} und https://{host}/.well-known/oauth-protected-resource/mcp/{umgebungs-slug}) – siehe Umgebung (Live vs. Test).

Sie müssen diese URL nicht manuell aufrufen; Claude nutzt sie, um den Authorization Server (Microsoft Entra ID) zu finden.

Umgebung (Live vs. Test)

Jedes Werkzeug ist auf eine Umgebung Ihres Mandanten skaliert. Es gibt zwei Wege, eine Umgebung anzusprechen:

Die URL der aktuell gewählten Umgebung (inklusive Kopieren-Knopf und Discovery-URL) zeigt Einstellungen → Integrationen → MCP-Server. Nennen Pfad und Header unterschiedliche Umgebungen, antwortet der Server mit 400 environment_conflict.

KI-Zugriff je Umgebung freischalten. In derselben Einstellungsseite schaltet ein Mandanten-Administrator den Schalter „KI-Zugriff (MCP) für diese Umgebung erlauben". Ohne ausdrückliche Einstellung gilt:

• Live: erlaubt (bestehende Verbindungen laufen unverändert weiter).
• Jede andere Umgebung (Test, Entwicklung, …): ausgeschaltet. Der Server antwortet dann mit 404 – identisch zu einem Mandanten ohne MCP-Feature, sodass nicht erkennbar ist, ob die Umgebung existiert oder nur gesperrt ist.

Verhaltensänderung für Nutzer des X-Environment-Headers: Wer bisher per Header (z. B. mit Claude Code) eine Nicht-Live-Umgebung angesprochen hat, erhält ab diesem Release 404, bis ein Mandanten-Administrator den KI-Zugriff für diese Umgebung freigeschaltet hat. Die Regel gilt für /mcp/{umgebungs-slug} und für /mcp mit X-Environment gleichermaßen. Live-Verbindungen sind nicht betroffen.

Microsoft 365 Copilot: Richten Sie je Umgebung einen eigenen Agenten mit eigener Endpunkt-URL (/mcp/{umgebungs-slug}) ein; die Umgebung ist Teil der URL, ein Header ist nicht nötig.

Claude Code und andere programmatische Clients können alternativ weiterhin den Header mitschicken:

claude mcp add --transport http rdm https://{host}/mcp \
  --header "Authorization: ApiKey <API-Key>" \
  --header "X-Environment: test"

Der Wert ist der Slug der Umgebung (z. B. test, live) oder ihre Environment-ID; beides sehen Sie in Einstellungen → Umgebungen. Ist der API-Key selbst auf eine Umgebung gescoped, muss der Header (bzw. der Pfad /mcp/{umgebungs-slug}) exakt diese Umgebung benennen – sonst antwortet der Server mit 403 (environment_scope_mismatch). Ein auf test gescopeter Key funktioniert also nur unter /mcp/test, nicht unter /mcp und nicht unter /mcp/{live-slug}.

3. Verfügbare Werkzeuge

Der MCP-Server stellt acht read-only Werkzeuge bereit. Alle geben ein JSON-Ergebnis mit items/total/returned/truncated/hint zurück (bei einzelnen Objekten wie get_dataset_info entfällt die Liste); Zeilen-Werkzeuge tragen zusätzlich den in Kapitel 4 erklärten version-Block.

Keine Schreibwerkzeuge – auch nicht für das Schema: Der MCP-Server ändert weder Daten noch Spalten. Dazu gehört das Zurücksetzen des Schemas auf einen älteren Stand („Schema auf Stand v{n} zurücksetzen…“ im Tab „Verlauf“): Es ist nur in der Web-Oberfläche durch einen Admin des Datasets möglich und per MCP nicht auslösbar. Ein KI-Assistent kann das Ergebnis aber lesen: get_dataset_info zeigt den neuen Spaltenstand, get_version_diff die Schema-Unterschiede und get_audit_history das Ereignis schema_restored. Dasselbe gilt für das gebündelte Speichern im Tab „Spalten": Es erscheint im Änderungsprotokoll als Ereignis schema_changes_saved, die Spaltenänderungen zeigen get_dataset_info und get_version_diff.

Spalten-Projection (columns): get_dataset_rows und get_hierarchy akzeptieren eine Komma-Liste von Spaltennamen (z. B. code,name), um bei breiten Datasets nur die benötigten Attribute zurückzugeben und so Kontext zu sparen. Systemfelder (business_key, valid_from, valid_to, …) sind immer enthalten; eine unbekannte Spalte lässt den Aufruf mit einem invalid_input-Fehler abbrechen, statt sie stillschweigend zu ignorieren.

Hierarchie-Navigation (get_hierarchy): Anders als get_dataset_rows (das ohne as_of_date alle historisierten Zeilen unfiltriert liefert) navigiert get_hierarchy den Baum immer zu einem Stichtag – standardmäßig heute (UTC), sofern kein as_of_date angegeben ist. Jeder Business Key löst so auf genau einen aktuell gültigen Knoten auf, exakt wie in der Web-UI. direction=down liefert den Teilbaum eines Knotens (oder die Root-Ebene, wenn business_key fehlt); direction=up liefert den Vorfahrenpfad von der Wurzel bis zum Knoten. Ein durch depth oder limit gekappter Ast meldet child_count, damit das LLM gezielt nachladen kann.

Berechnete Spalten (get_dataset_info): Mit include_schema kennzeichnet jede Schemaspalte, ob sie berechnet ist. Eine berechnete Spalte trägt read_only: true und das Feld computed mit kind (concat), separator, parts (je Quellspalte column und width, die Stellenzahl oder null) sowie definition (Klartext, z. B. concatenation of Land | Segment | Jahr (zero-padded to 4)) und note. Das LLM erkennt so, dass der Wert aus anderen Spalten entsteht und nicht geschrieben werden kann. Der Wert selbst steht in den Zeilen wie in jeder Text-Spalte. Ist eine Quellspalte für den aufrufenden Nutzer wegen der Klassifizierung nicht sichtbar, enthält computed nur note, nie den Namen der verborgenen Spalte.

4. Versions- und Auslieferungssemantik für KI-Antworten

Jede Antwort eines Zeilen-Werkzeugs (get_dataset_rows, search_rows, get_hierarchy) beruht auf genau einer Dataset-Version. Dieses Kapitel erklärt, welche Version das standardmäßig ist, warum sie von der neuesten Versionsnummer abweichen kann, und wie Nutzer das nachvollziehen.

Das Delivery-Gate

Ohne explizite Versionsangabe erhält ein KI-Client ausschließlich die ausgelieferte Version – dieselbe Regel wie bei GET /api/datasets/{id}/current und beim DWH-Export:

Weil Claude, Copilot, die REST-API und der Fabric-Export dieselbe Regel anwenden, sehen alle Kanäle denselben Stand – außer jemand fragt gezielt nach einer anderen Version.

Der version-Block in jeder Antwort

{
  "version": {
    "number": 3,
    "validation_status": "Valid",
    "is_delivery_version": true,
    "effective_from": "2026-07-01",
    "warning": null
  },
  "items": [ "…" ],
  "total": 842,
  "returned": 50,
  "truncated": true,
  "hint": "…"
}

Warum eine Antwort auf einer älteren Version basiert

Fragt jemand „Zeig mir Version 4“, obwohl v4 nicht ausgeliefert wird, bleibt die Antwort exakt Version 4 – aber is_delivery_version steht auf false und warning nennt den Grund, zum Beispiel:

• v4 ist ungültig: „This version failed delivery validation (3 errors); the delivered version is 3.“
• v4 ist geplant (künftiger Stichtag): „This version is scheduled (effective 2026-09-01) and not yet delivered.“

Ohne explizite Versionsangabe greift dagegen sofort das Delivery-Gate: Claude oder Copilot antworten dann direkt mit der ausgelieferten Version (hier v3) und nennen deren Nummer, wenn nach einem Stand oder Stichtag gefragt wurde. Die im Microsoft-365-Agent hinterlegten Instructions (siehe Teil D) weisen den Agenten ausdrücklich an, die aufgelöste Versionsnummer und einen vorhandenen warning-Text wiederzugeben statt stillschweigend „aktuell“ zu behaupten.

Um die Ursache selbst zu prüfen, öffnen Sie den Tab „Verlauf“ des Datasets (siehe Benutzerhandbuch, Kapitel 10 – Versionierung & Historie): Dort ist die neueste Version mit invalid markiert bzw. mit dem geplanten Stichtag versehen.

Gezielt nach einer bestimmten Version fragen

Sie (oder das LLM in Ihrem Auftrag) können jederzeit explizit fragen:

• „Zeig mir Version 4.“ → get_dataset_rows mit version=4.
• „Wie sah das Dataset am 31.12.2025 aus?“ → get_dataset_rows mit as_of_date=2025-12-31.

Beide Wege liefern eine Antwort samt version-Block, unabhängig davon, ob die angefragte Version ausgeliefert wird oder nicht.

Ist für dieses Dataset ein Limit für die Versionsaufbewahrung konfiguriert (siehe Benutzerhandbuch, Versionsaufbewahrung (Retention)) und wurde die angefragte Version bereits entfernt, liefert das Werkzeug statt der Zeilen den Hinweis version_pruned — version {n} was removed by the retention policy (max versions per dataset). Fragen Sie in diesem Fall nach einer neueren Version oder nach dem aktuellen Stand (ohne version-Parameter).

Wenn keine Version ausgeliefert werden kann

Ist für ein Dataset aktuell keine gültige und wirksame Version vorhanden – etwa weil alle Versionen ungültig sind oder das Dataset noch nie erfolgreich veröffentlicht wurde –, liefern die Zeilen-Werkzeuge ein leeres Ergebnis mit dem Hinweis:

no_valid_version — this dataset has no deliverable version.

Öffnen Sie in diesem Fall das Dataset in der Web-UI, beheben Sie die gemeldeten Validierungsfehler und speichern bzw. veröffentlichen Sie erneut.

Changelog-Hinweis: Feld-Umbenennung

Seit dieser Version melden list_datasets und get_dataset_info latest_version (die höchste Versionsnummer) und delivery_version (die tatsächlich ausgelieferte Version) statt des früheren, mehrdeutigen current_version. Bauen Sie eigene Automatisierungen auf den MCP-Tool-Antworten auf, prüfen Sie an dieser Stelle Ihre Feldnamen.

5. Verteilungsmodell: eigene App-Registrierung pro Kunde

MDM Lite verwendet bewusst ein Per-Customer-OAuth-Modell (Spezifikation §5.1): Jeder Kunde registriert eine eigene Client-App im eigenen Entra-Tenant. Es gibt keine vom Betreiber veröffentlichte, geteilte App.

Warum:

• Das Client-Secret liegt ausschließlich bei Ihnen (in Ihrem Entra + Ihren Claude-Admin-Settings) – kein über Kunden hinweg geteiltes Secret, kein Betreiber-Zugriff.
• Sie kontrollieren Consent, Secret-Rotation und Widerruf vollständig selbst (App löschen = Zugang tot).
• Ihre Conditional-Access-Policies (MFA, Gerätebindung, Standort) greifen auf dem OAuth-Flow.

Trade-off: etwas mehr Ersteinrichtung als bei einer geteilten App – dafür einmalig pro Kunde. Teil A führt Schritt für Schritt durch die Registrierung; Teil D nutzt dasselbe Modell für Microsoft 365 Copilot (dort über das Teams Developer Portal).

6. Teil A – claude.ai / Claude Desktop (Custom Connector, OAuth)

Voraussetzung: Sie sind Entra-Administrator Ihres Tenants und Owner eines Claude-Team-/Enterprise-Arbeitsbereichs (nur Owner können org-weite Connectors hinzufügen; Mitglieder authentifizieren sich anschließend individuell).

Claude Desktop: Claude Desktop nutzt dieselben org-weiten (hosted) Custom Connectors wie claude.ai – es gibt keine eigene Einrichtung für Desktop. Sobald der Connector wie unten beschrieben angelegt ist, steht er allen Mitgliedern sowohl in claude.ai als auch in Claude Desktop zur Verfügung; jedes Mitglied meldet sich beim ersten Verbinden individuell über Entra an.

Schritt 1 – Entra-App-Registrierung im Kunden-Tenant

Im Entra Admin Center → Identität → Anwendungen → App-Registrierungen → Neue Registrierung:

1. Name: z. B. MDM Lite – Claude Connector.

2. Unterstützte Kontotypen: Nur Konten in diesem Organisationsverzeichnis (Single-Tenant genügt).

3. Redirect-URI: Plattform Web, URI:

   https://claude.ai/api/mcp/auth_callback
   

4. Registrieren.

Schritt 2 – Client-Secret erzeugen

Unter Zertifikate & Geheimnisse → Neuer geheimer Clientschlüssel ein Secret anlegen, Ablauf nach Ihrer Richtlinie wählen und den Wert sofort kopieren (er wird später nicht mehr angezeigt). Notieren Sie außerdem die Anwendungs-(Client-)ID von der Übersichtsseite.

Schritt 3 – API-Berechtigung Mcp.Read + Admin-Consent

Unter API-Berechtigungen → Berechtigung hinzufügen → Meine APIs:

1. Wählen Sie die MDM-Lite-API (App-ID-URI z. B. api://rdm-tool-api).
2. Delegierte Berechtigungen → Mcp.Read auswählen und hinzufügen.
3. Administratorzustimmung erteilen für Ihren Tenant (Button oben in der Liste).

Erscheint die MDM-Lite-API nicht unter „Meine APIs", muss der MDM-Lite-Betreiber den Scope Mcp.Read auf der MDM-Lite-API-App-Registrierung noch für Ihren Tenant freigeben. Wenden Sie sich in dem Fall an Ihren MDM-Lite-Ansprechpartner.

Schritt 4 – Custom Connector in Claude anlegen

Als Team-/Enterprise-Owner in claude.ai:

1. Settings → Connectors → Add custom connector.
2. URL: https://{host}/mcp (aus §2).
3. Advanced settings öffnen und eintragen:
   • Client ID: die Anwendungs-(Client-)ID aus Schritt 2
   • Client Secret: den Secret-Wert aus Schritt 2
4. Speichern und Connect. Claude liest die Discovery-Metadaten, leitet zum Entra-Login, Sie stimmen zu (PKCE S256 wird von Entra nativ erfüllt), und der Connector wird verbunden.

Das ausgestellte Token trägt aud = MDM-Lite-API und tid = Ihr Tenant – MDM Lite ordnet Sie darüber automatisch dem richtigen Mandanten zu. Ihre bestehende Rolle (Viewer/Editor/Admin) und Dataset-Berechtigungen gelten unverändert: Sie sehen über Claude genau das, was Sie auch in der REST-API sehen.

Schritt 5 – Testen

Fragen Sie Claude: „Welche Datasets gibt es?" – der Connector ruft list_datasets auf und antwortet mit den Datasets Ihres Mandanten.

7. Teil B – Claude Code (API-Key)

Claude Code (CLI) verbindet sich direkt per API-Key – keine App-Registrierung nötig.

Schritt 1 – API-Key mit read-Scope erstellen

In MDM Lite unter Einstellungen → Sicherheit → API-Keys einen Key anlegen. Die Web-UI erzeugt Keys mit den Scopes read und write ohne Dataset-Beschränkung. Einen reinen read-Key oder einen auf bestimmte Datasets eingeschränkten Key (Dataset-Scoping, Feld datasetIds) legen Sie derzeit über die API an (POST /api/tenants/api-keys, siehe Benutzerhandbuch §16). Der MCP-Server setzt die Einschränkung in allen Tools durch — genauso wie die REST-API. Kopieren Sie den angezeigten Wert sofort — er wird nur einmal angezeigt.

Hat ein Dataset eigene Dataset-Rollen, sieht auch ein Key es nur mit einer eigenen Rolle (Benutzer-ID apikey:{Key-ID}); ohne sie existiert das Dataset für den Key nicht.

Schritt 2 – Server hinzufügen

claude mcp add --transport http rdm https://{host}/mcp \
  --header "Authorization: ApiKey <API-Key>"

Schritt 3 – Testen

In einer Claude-Code-Sitzung z. B. fragen: „Liste die Datasets über den rdm-Server auf." Claude Code ruft die MCP-Tools des rdm-Servers auf.

Tool-Result-Limits: Claude Code begrenzt Ergebnisse auf ca. 25.000 Token. Große Ergebnisse werden serverseitig gekürzt (truncated: true) mit einem Hinweis auf Filter bzw. Pagination – nutzen Sie die Parameter filter, limit, offset.

Team-weite Konfiguration (.mcp.json)

Statt jedes Teammitglied einzeln claude mcp add ausführen zu lassen, legen Sie für ein Projekt eine .mcp.json im Repository-Root an und committen sie:

{
  "mcpServers": {
    "rdm": {
      "type": "http",
      "url": "https://{host}/mcp",
      "headers": {
        "Authorization": "ApiKey ${RDM_API_KEY}"
      }
    }
  }
}

Claude Code expandiert ${RDM_API_KEY} zur Laufzeit aus der Shell-Umgebung des jeweiligen Mitwirkenden. Checken Sie niemals den API-Key selbst ein – nur diese Datei mit der Variablen-Referenz ist repo-sicher. Jedes Teammitglied setzt RDM_API_KEY lokal (z. B. in der Shell-Profildatei oder einem nicht eingecheckten .env) auf einen eigenen, dataset-gescopten Key.

Kein OAuth in Claude Code: Claude Codes OAuth-Flow für Remote-Server setzt Dynamic Client Registration (RFC 7591, „DCR") voraus. Microsoft Entra ID unterstützt kein DCR. Der API-Key (oben) ist deshalb der einzige unterstützte Weg für Claude Code – das ist eine bewusste Einschränkung des Zusammenspiels von Claude Code und Entra, kein Konfigurationsfehler auf Ihrer Seite.

8. Teil C – Copilot Studio (sekundär, API-Key)

Copilot Studio unterstützt MCP inklusive API-Key-Auth über Power-Platform-Connectors. Dieser Pfad ist sekundär (Lizenz-/Governance-Overhead) und nicht das Zielbild – für Microsoft 365 Copilot verwenden Sie stattdessen den Declarative Agent.

Kurzfassung:

1. API-Key mit read-Scope erstellen (wie in Teil B, Schritt 1).
2. In Copilot Studio den MCP-Onboarding-Assistenten starten und https://{host}/mcp als Server-URL eintragen.
3. Als Verbindungsart API-Key wählen und den Header Authorization: ApiKey <API-Key> hinterlegen.
4. Die Tools stehen anschließend im Copilot-Studio-Agenten zur Verfügung.

Empfehlung: Scopen Sie den für Copilot Studio verwendeten API-Key nach Möglichkeit auf genau die Datasets, die der Studio-Agent tatsächlich braucht (Dataset-Scoping bei der Key-Erstellung, Teil B, Schritt 1). Ein ungescopter Key macht in Copilot Studio alle Datasets sichtbar, auf die der Key Zugriff hat – anders als beim Declarative Agent (Teil D) gelten hier keine individuellen Nutzerrollen, sondern nur die Berechtigung des Keys.

9. Teil D – Microsoft 365 Copilot (Declarative Agent)

Voraussetzung: Sie sind M365-/Teams-Administrator Ihres Tenants (oder können einen solchen um Sideload-Freigabe bzw. den org-weiten Rollout bitten) und haben Zugriff auf das Teams Developer Portal.

Dieser Pfad bringt MDM Lite als Declarative Agent direkt in Microsoft 365 Copilot Chat – ohne eigene Copilot-Studio-Lizenz, mit den Rollen und Dataset-Berechtigungen des jeweils angemeldeten Users. Das vollständige, versionierte Setup-Paket liegt unter integrations/m365-agent/; dieser Abschnitt fasst die Schritte zusammen.

Schritt 1 – API-Berechtigung Mcp.Read prüfen

Die MDM-Lite-API muss den delegierten Scope Mcp.Read für Ihren Tenant freigeben (wie in Teil A, Schritt 3 beschrieben). Ist das bereits für Claude/OAuth eingerichtet, ist dieser Schritt bereits erledigt.

Schritt 2 – OAuth im Teams Developer Portal registrieren

Im Teams Developer Portal → Tools → OAuth client registration → Neue Registrierung:

1. Identitätsanbieter: Microsoft Entra ID.
2. Client-ID/Secret: Entra-App-Registrierung in Ihrem Tenant (neu oder wiederverwendet) anlegen und Client-ID sowie Client-Secret hinterlegen.
3. Scopes: api://{rdm-api-app-id-uri}/Mcp.Read anfordern und Admin-Consent in Ihrem Tenant erteilen.
4. Redirect-URLs: https://token.botframework.com/.auth/web/redirect und https://teams.microsoft.com/oAuthConsentRedirect eintragen.
5. Zugelassener Token-Store-Client: ab3be6b7-f5df-413d-ac2d-abf1e3fd9c0b (der M365-Token-Store) hinzufügen, damit Copilot in Ihrem Namen Tokens abrufen kann.
6. Speichern und die Registrierungs-ID notieren – sie wird im nächsten Schritt als OAUTH_REGISTRATION_ID benötigt.

Die ausgestellten Tokens tragen aud = MDM-Lite-API und tid = Ihr Tenant – MDM Lites bestehende Tenant-Zuordnung greift ohne zusätzliche Serverkonfiguration.

Schritt 3 – Paket befüllen, validieren, packen

1. env/.env.dev.template nach env/.env.dev kopieren und RDM_HOST, TEAMS_APP_ID (einmalig per GUID erzeugen), PUBLISHER_NAME und OAUTH_REGISTRATION_ID (aus Schritt 2) eintragen.

2. Mit dem Microsoft 365 Agents Toolkit (@microsoft/teamsapp-cli) validieren und packen:

   # aus integrations/m365-agent
   npx @microsoft/teamsapp-cli validate --manifest-file ./manifest.json --env-file ./env/.env.dev
   npx @microsoft/teamsapp-cli package  --manifest-file ./manifest.json --env-file ./env/.env.dev \
       --output-package-file ./appPackage.dev.zip
   

3. Platzhalter-Icons (color.png/outline.png) vor der Kundenauslieferung durch Ihr Branding ersetzen.

Details zu Validator-Fehlerbildern und den v2.4-Limits stehen im README des Pakets, §3.

Schritt 4 – Sideload oder org-weiter Rollout

• Test/Pilot: appPackage.dev.zip über Upload a custom app im Teams-/Copilot-Client sideloaden, in Copilot Chat den MDM Lite Agent auswählen und beim ersten Aufruf per OAuth anmelden.
• Org-weit: im Microsoft 365 Admin Center → Einstellungen → Integrierte Apps → Benutzerdefinierte Apps hochladen dasselbe Paket hochladen und den gewünschten Benutzern/Gruppen zuweisen.

Schritt 5 – Testen

Fragen Sie den Agenten: „Welche Datasets gibt es?" – er ruft list_datasets auf und antwortet mit den Datasets Ihres Mandanten. Ein Schreibversuch („Lege ein neues Dataset an") wird höflich abgelehnt – der Agent ist read-only.

Für die Feinheiten der mitgelieferten Agent-Instructions (Versions-Transparenz, Umgang mit Draft-/Archived-Datasets, Injection-Hygiene) siehe den Abschnitt „Agent behaviour" im README des Pakets.

10. Secret-Rotation & Widerruf

Planen Sie Secret-/Key-Rotation gemäß Ihrer internen Richtlinie ein.

11. Netzwerk & Firewall

Verbindungen von claude.ai / Claude Desktop kommen nicht vom Endgerät, sondern von den Servern von Anthropic. Wenn Ihr MDM-Lite-Deployment hinter einer Firewall / IP-Allowlist liegt, muss der eingehende Zugriff auf https://{host}/mcp aus dem Egress-Bereich von Anthropic erlaubt sein:

160.79.104.0/21

Claude Code läuft dagegen lokal bzw. in Ihrer eigenen Umgebung – hier gilt Ihre normale Ausgangs-Netzwerkkonfiguration. Microsoft 365 Copilot verbindet sich von Microsoft-seitigen Servern aus; eine feste Egress-Range veröffentlicht Microsoft nicht – planen Sie den Zugriff über die Erreichbarkeitsanforderung unten statt über eine IP-Allowlist.

Der /mcp-Endpunkt muss aus dem Internet über HTTPS erreichbar sein (Streamable HTTP).

12. Fehlerbehebung

Weiterführende Dokumentation

• MCP Server V1 – Spezifikation — Architektur, Auth, Basis-Tools
• MCP Server v1.1 – Copilot- & Claude-Integration (Spezifikation) — Delivery-Gate, Versions-Transparenz, get_hierarchy
• MDM Lite Agent für M365 Copilot — Declarative-Agent-Paket
• MCP V1 – Security & E2E Verification
• Benutzerhandbuch, Kapitel 10 – Versionierung & Historie