Unleash

Unleash MCP Server

Ein zweckorientierter Model Context Protocol (MCP)-Server zur Verwaltung von Unleash-Feature-Flags. Dieser Server ermöglicht LLM-gestützten Codierungsassistenten das Erstellen und Verwalten von Feature-Flags gemäß den Unleash-Best Practices.

Für Feedback treten Sie unserem Community-Slack bei oder eröffnen Sie ein Issue auf GitHub.

Überblick

Dieser MCP-Server stellt Tools bereit, die mit der Unleash Admin API integriert sind und KI-Codierungsassistenten Folgendes ermöglichen:

• Feature-Flags erstellen mit ordnungsgemäßer Validierung und Typisierung.
• Bestehende Flags erkennen, um Duplikate zu vermeiden oder Wiederverwendung zu fördern.
• Änderungen bewerten, um zu entscheiden, wann ein Feature-Flag benötigt wird.
• Fortschritt streamen für Transparenz während der Vorgänge.
• Fehler elegant behandeln mit hilfreichen Hinweisen.
• Best Practices befolgen aus der Unleash-Dokumentation.

Verfügbare Tools

Der MCP-Server stellt die folgenden Tools bereit:

• create_flag: Erstellt ein Feature-Flag in Unleash.
• evaluate_change: Bewertet Risiko und empfiehlt die Verwendung von Feature-Flags.
• detect_flag: Findet vorhandene Feature-Flags, um Duplikate zu vermeiden.
• wrap_change: Bietet Anleitungen, wie eine Änderung in ein Feature-Flag eingebettet wird.
• set_flag_rollout: Konfiguriert Rollout-Strategien für ein Feature-Flag (aktiviert das Flag nicht).
• get_flag_state: Zeigt die Metadaten eines Feature-Flags und seine Aktivierungsstrategien an.
• list_flags: Listet alle Feature-Flags in einem Projekt auf, mit optionaler Paginierung und Sortierreihenfolge.
• list_projects: Listet Unleash-Projekte auf, die für das konfigurierte Token verfügbar sind, mit optionaler Paginierung.
• toggle_flag_environment: Aktiviert oder deaktiviert ein Feature-Flag in einer Umgebung.
• remove_flag_strategy: Löscht die Strategie eines Feature-Flags aus einer Umgebung.
• cleanup_flag: Generiert Anweisungen zum sicheren Entfernen von Code-Pfaden mit Flags.

Kern-Workflow

Der Kern-Workflow für einen KI-Assistenten ist wie folgt gestaltet:

1. evaluate_change: Zuerst eine Codeänderung bewerten, um zu sehen, ob ein Flag benötigt wird.
2. detect_flag: Dies wird oft automatisch von evaluate_change aufgerufen, um die Erstellung doppelter Flags zu verhindern.
3. create_flag: Wenn ein neues Flag erforderlich ist, erstellt dieses Tool es in Unleash.
4. wrap_change: Schließlich liefert dieses Tool den sprachspezifischen Code zur Implementierung des neuen Flags.

Weitere Informationen zu den Kern-Workflow-Tools finden Sie im Abschnitt Tool-Referenz.

Voraussetzungen

Bevor Sie den Server ausführen können, benötigen Sie Folgendes:

• Node.js 22 oder höher
• pnpm-Paketmanager oder npm
• Eine Unleash-Instanz (gehostet oder selbst gehostet)
• Ein persönliches Zugriffstoken mit Berechtigungen zum Erstellen von Feature-Flags

Erste Schritte

Dieser Abschnitt behandelt die verschiedenen Möglichkeiten zur Installation und Ausführung des Unleash MCP-Servers. Sie können entweder ein Setup für Agenten (wie Claude Code und Codex) befolgen, den MCP als eigenständigen Prozess mit npx ausführen oder ein lokales Entwicklungssetup verwenden.

Agenten-Setup

Sie können den MCP-Server direkt zu Claude Code oder Codex hinzufügen. Agentenkonfigurationen sind pfadspezifisch. Sie müssen den folgenden Befehl aus dem Stammverzeichnis des Projekts ausführen, in dem Sie den MCP verwenden möchten.

Für Claude Code:

claude mcp add unleash \
    --env UNLEASH_BASE_URL={{your-instance-url}} \
    --env UNLEASH_PAT={{your-personal-access-token}} \
    -- npx -y @unleash/mcp@latest --log-level error

Für Codex:

codex mcp add unleash \
    --env UNLEASH_BASE_URL={{your-instance-url}} \
    --env UNLEASH_PAT={{your-personal-access-token}} \
    -- npx -y @unleash/mcp@latest --log-level error

Remote-Agenten-Setup (experimentell)

Anstatt den MCP-Server lokal auszuführen, können Sie sich direkt mit dem integrierten Remote-MCP-Server Ihrer Unleash-Instanz über HTTP verbinden. Dies verwendet den Streamable HTTP Transport – kein lokaler Prozess erforderlich.

Hinweis: Remote-MCP ist eine experimentelle Funktion, die auf Ihrer Unleash-Instanz aktiviert sein muss. Kontaktieren Sie das Unleash-Team, um sie aktivieren zu lassen.

OAuth

Der OAuth-Ablauf öffnet Ihren Browser, ermöglicht Ihnen die Anmeldung bei Unleash und stellt automatisch ein kurzlebiges PAT bereit. Keine manuelle Token-Verwaltung erforderlich.

Für Claude Code:

claude mcp add unleash https://{{your-instance-url}}/api/admin/mcp --transport http

Für Codex:

codex mcp add unleash https://{{your-instance-url}}/api/admin/mcp --transport http

Bei der ersten Verwendung öffnet der Client automatisch Ihren Browser für die Anmeldung. Nach der Authentifizierung bei Unleash wird ein PAT erstellt und für alle nachfolgenden Anfragen verwendet.

Das PAT läuft standardmäßig nach 24 Stunden ab.

Persönliches Zugriffstoken (PAT)

Verwenden Sie diese Methode, wenn Sie bereits ein PAT haben oder einen headless/nicht-interaktiven Zugriff benötigen (CI-Pipelines, gemeinsame Entwicklerumgebungen, Clients ohne OAuth-Unterstützung).

So erstellen Sie ein PAT: Melden Sie sich bei Ihrer Unleash-Instanz an, gehen Sie zu Profil > Persönliche Zugriffstokens und erstellen Sie ein neues Token.

Für Claude Code:

claude mcp add unleash https://{{your-instance-url}}/api/admin/mcp \
  --transport http \
  --header "Authorization: Bearer {{your-personal-access-token}}"

Für Codex:

codex mcp add unleash https://{{your-instance-url}}/api/admin/mcp \
  --transport http \
  --header "Authorization: Bearer {{your-personal-access-token}}"

Das --header-Flag sendet das PAT direkt und umgeht den OAuth-Ablauf vollständig.

Schnellstart mit npx

Sie können den MCP-Server als eigenständigen Prozess ausführen, ohne das Repository zu klonen, indem Sie npx verwenden. Stellen Sie die Konfiguration über Umgebungsvariablen oder eine lokale .env-Datei im Verzeichnis bereit, in dem Sie den Befehl ausführen:

UNLEASH_BASE_URL={{your-instance-url}} \
UNLEASH_PAT={{your-personal-access-token}} \
UNLEASH_DEFAULT_PROJECT={{default_project_id}} \
npx @unleash/mcp@latest --log-level debug

Die CLI unterstützt dieselben Flags wie der lokale Build (zum Beispiel --dry-run, --log-level).

Lokales Entwicklungssetup

Befolgen Sie diese Schritte, um das Projekt für die lokale Entwicklung einzurichten.

1. Abhängigkeiten installieren

Klonen Sie das Repository und installieren Sie die Abhängigkeiten mit pnpm. Corepack hält alle auf derselben pnpm-Version:

git clone https://github.com/Unleash/unleash-mcp.git
cd unleash-mcp

# Enable Corepack once per machine, then prepare the pnpm this repo expects
corepack enable
corepack prepare pnpm@11.0.8 --activate

pnpm install

2. Im Entwicklungsmodus direkt von Claude oder Codex aus ausführen

Vermeiden Sie npm run-Ausgaben und tsx watch-Banner, da jede zusätzliche stdout-Ausgabe den MCP-Handshake unterbricht. Zwei ruhige Optionen:

A) Kompiliertes JS verwenden (am zuverlässigsten)

npm run build
# or keep it hot in another terminal: npm run build:watch

claude mcp add unleash-dev \
  --env UNLEASH_BASE_URL={{your-instance-url}} \
  --env UNLEASH_PAT={{your-personal-access-token}} \
  --env LOG_LEVEL=debug \
  --env APP_LOG_FILE="$(pwd)/app.log" \
  --env MCP_STDIO_LOG_FILE="$(pwd)/mcp-stdio.log" \
  -- node "$(pwd)/dist/index.js"

codex mcp add unleash-dev \
  --env UNLEASH_BASE_URL={{your-instance-url}} \
  --env UNLEASH_PAT={{your-personal-access-token}} \
  --env LOG_LEVEL=debug \
  --env APP_LOG_FILE="$(pwd)/app.log" \
  --env MCP_STDIO_LOG_FILE="$(pwd)/mcp-stdio.log" \
  -- node "$(pwd)/dist/index.js"

B) TypeScript direkt verwenden (ohne Build)

claude mcp add unleash-dev \
  --env UNLEASH_BASE_URL={{your-instance-url}} \
  --env UNLEASH_PAT={{your-personal-access-token}} \
  --env LOG_LEVEL=debug \
  --env APP_LOG_FILE="$(pwd)/app.log" \
  --env MCP_STDIO_LOG_FILE="$(pwd)/mcp-stdio.log" \
  -- node --no-warnings --import tsx "$(pwd)/src/index.ts"

codex mcp add unleash-dev \
  --env UNLEASH_BASE_URL={{your-instance-url}} \
  --env UNLEASH_PAT={{your-personal-access-token}} \
  --env LOG_LEVEL=debug \
  --env APP_LOG_FILE="$(pwd)/app.log" \
  --env MCP_STDIO_LOG_FILE="$(pwd)/mcp-stdio.log" \
  -- node --no-warnings --import tsx "$(pwd)/src/index.ts"

Hinweise:

• node --import tsx ist ruhig (keine npm-Lifecycle-Ausgabe) und führt TS direkt aus; verwenden Sie dies, wenn Sie das Erstellen vermeiden möchten.
• node dist/index.js ist die sicherste Wahl; kombinieren Sie es mit npm run build:watch, um bei Änderungen neu zu erstellen, während der Agentenbefehl stabil bleibt.
• Protokolle bleiben im Repository-Stammverzeichnis (app.log, mcp-stdio.log), beide gitignored.

Protokollierungssteuerung

• LOG_LEVEL (bevorzugt): steuert die Ausführlichkeit der Anwendungsprotokollierung (debug, info, warn, error). Standardmäßig error, wenn nicht gesetzt.
• --log-level-CLI-Flag: optionale Überschreibung für LOG_LEVEL, wenn Sie eine einmalige Änderung wünschen.
• APP_LOG_FILE (optional): Wenn gesetzt, werden Anwendungsprotokolle in diese Datei geschrieben (nicht stdout). Wenn nicht gesetzt, gehen Protokolle an stderr.
• MCP_STDIO_LOG_FILE (optional): Wenn gesetzt, werden MCP stdin/stdout/stderr in diese einzelne Datei mit Kanalpräfixen umgeleitet. Protokollnachrichten fließen weiterhin normal über stdout.

Client-Zuordnung

Wenn ein MCP-Client clientInfo während der Initialisierung sendet (Claude Code, Cursor, Copilot, Windsurf, Codex, Kiro und andere konforme Clients), reichert der Server den User-Agent-Header bei ausgehenden Unleash-Admin-API-Aufrufen an:

User-Agent: unleash-mcp/<version> (MCP Server; client=claude-code/1.2.3)

Dadurch können die Unleash-Ereignisprotokolle beantworten, "welches KI-Tool dieses Flag erstellt oder umgeschaltet hat", ohne serverseitige Änderungen. Zuordnungswerte werden bereinigt, sodass sie den User-Agent-Header nicht beschädigen können.

Setzen Sie UNLEASH_MCP_CLIENT_ATTRIBUTION=off, um die Anreicherung zu deaktivieren und zu unleash-mcp/<version> (MCP Server) zurückzukehren. Standard: aktiviert.

Tool-Referenz

Dieser Abschnitt beschreibt jedes der Kern-Tools im Detail, einschließlich Zweck, Parameter und Ausgabe.

Flag erstellen

Das create_flag-Tool erstellt ein neues Feature-Flag in Unleash mit umfassender Validierung und Fortschrittsverfolgung.

Wann verwenden

Verwenden Sie dieses Tool, wenn Sie bereits festgestellt haben, dass ein Feature-Flag erforderlich ist (zum Beispiel nach der Ausführung von evaluate_change) und bereit sind, es mit dem korrekten Typ und den korrekten Metadaten zu erstellen.

Parameter

Das Tool akzeptiert die folgenden Parameter:

• name (erforderlich): Eindeutiger Feature-Flag-Name innerhalb des Projekts.
• type (erforderlich): Feature-Flag-Typ, der Lebenszyklus und Zweck angibt.
  • release: Schrittweise Feature-Rollouts an Benutzer.
  • experiment: A/B-Tests und Experimente.
  • operational: Systemverhalten und betriebliche Schalter.
  • kill-switch: Notabschaltungen oder Schutzschalter.
  • permission: Steuert den Feature-Zugriff basierend auf Benutzerrollen oder Berechtigungen.
• description (erforderlich): Klare Erklärung, was das Flag steuert und warum es existiert.
• projectId (optional): Zielprojekt (standardmäßig UNLEASH_DEFAULT_PROJECT).
• impressionData (optional): Aktiviert Analysenachverfolgung (standardmäßig false).

Verwendungsbeispiel

Agenten-Prompt

Use create_flag with:
- name: "new-checkout-flow"
- type: "release"
- description: "Gradual rollout of the redesigned checkout experience"
- projectId: "ecommerce"

Tool-Payload

{
  "name": "new-checkout-flow",
  "type": "release",
  "description": "Gradual rollout of the redesigned checkout experience with improved conversion tracking",
  "projectId": "ecommerce",
  "impressionData": true
}

Tool-Ausgabe

Bei Erfolg gibt das Tool ein JSON-Objekt zurück, das die URL des neuen Feature-Flags in der Unleash-Admin-Oberfläche, einen MCP-Ressourcenlink für den programmatischen Zugriff, den Erstellungszeitstempel und Konfigurationsdetails enthält.

Änderung bewerten

Das evaluate_change-Tool bewertet, ob eine Codeänderung hinter einem Feature-Flag stehen sollte. Es untersucht Struktur, Kontext und potenzielles Risiko der Änderung und gibt eine Empfehlung mit Erklärung und nächsten Schritten zurück.

Wann verwenden

Verwenden Sie evaluate_change zu Beginn einer Funktion oder Änderung, wenn Sie verstehen möchten, ob die Arbeit ein Feature-Flag erfordert. Dieses Tool ist auch hilfreich, wenn Sie unsicher sind, welchen Flag-Typ Sie verwenden sollen, oder Anleitungen zur Rollout-Planung wünschen.

Funktionsweise

Das Tool gibt detaillierte, markdown-formatierte Anleitungen für den LLM-Assistenten basierend auf Unleash-Best-Practices zurück.

Die Anleitungen umfassen:

• Erkennung übergeordneter Flags: Prüft, ob Code bereits durch vorhandene Flags geschützt ist.
• Risikobewertung: Analysiert Codemuster, um riskante Vorgänge zu identifizieren.
• Bewertung des Codetyps: Klassifiziert die Änderung (zum Beispiel Test, Konfiguration, Funktion oder Fehlerbehebung).
• Empfehlung: Schlägt vor, ob ein Flag erstellt, ein vorhandenes Flag verwendet oder auf das Flag verzichtet werden soll.
• Nächste Aktionen: Bietet spezifische Anweisungen, was als Nächstes zu tun ist.

Wenn evaluate_change feststellt, dass ein Flag benötigt wird, gibt es explizite Anweisungen:

1. Rufen Sie das create_flag-Tool auf, um das Feature-Flag zu erstellen.
2. Rufen Sie das wrap_change-Tool auf, um sprachspezifische Code-Einbettungsanleitungen zu erhalten.
3. Implementieren Sie den eingebetteten Code gemäß den erkannten Mustern.

Der Bewertungsprozess

Das Tool folgt einem klaren Bewertungsprozess:

Step 1: Gather code changes (git diff, read files)
        ↓
Step 2: Check for parent flags (avoiding nesting)
        ↓
Step 3: Assess code type (test? config? feature?)
        ↓
Step 4: Evaluate risk (auth? payments? API changes?)
        ↓
Step 5: Calculate risk score
        ↓
Step 6: Make recommendation
        ↓
Step 7: Take action (create flag or proceed without)

Risikobewertung

Das Tool verwendet sprachunabhängige Muster zur Risikobewertung:

• Kritisches Risiko (Punktzahl +5): Zum Beispiel Authentifizierung, Zahlungen, Sicherheit und Datenbankoperationen.
• Hohes Risiko (Punktzahl +3): Zum Beispiel API-Änderungen, externe Dienste oder neue Klassen.
• Mittleres Risiko (Punktzahl +2): Zum Beispiel asynchrone Operationen oder Zustandsverwaltung.
• Niedriges Risiko (Punktzahl +1): Zum Beispiel Fehlerbehebungen, Refactorings oder kleine Änderungen.

Punktzahlen summieren sich über übereinstimmende Kategorien. Die Gesamtsumme wird einer Risikostufe zugeordnet:

• Kritisch: Punktzahl ≥ 5
• Hoch: Punktzahl ≥ 3
• Mittel: Punktzahl ≥ 2
• Niedrig: Punktzahl < 2

Die Ausgabe enthält eine confidence-Punktzahl (0-1), die die selbst eingeschätzte Sicherheit des LLM darstellt und mit mehr Kontext zunimmt.

Eine ausgeschlossene Kategorie umfasst Dateien, die unabhängig vom Inhalt keine Feature-Flags benötigen: Testdateien (*.test.ts, *_test.go usw.), Konfigurationsdateien (*.config.js, .env, *.yaml) und Dokumentationsdateien (*.md, docs/**). Änderungen, die auf ausgeschlossene Dateien beschränkt sind, lösen keine Flag-Empfehlung aus.

Die vollständigen Musterdefinitionen, einschließlich Schlüsselwörtern pro Kategorie, Dateiglobs, Codemustern und Begründungen, finden Sie in src/evaluation/riskPatterns.ts.

Erkennung übergeordneter Flags

Das Tool sucht nach gängigen Mustern über Sprachen hinweg, wie zum Beispiel:

• Bedingungen: if (isEnabled('flag')), if client.is_enabled('flag'):
• Zuweisungen: const enabled = useFlag('flag')
• Hooks: const enabled = useFlag('flag') → {enabled && <Component />}
• Guards: if (!isEnabled('flag')) return;
• Wrapper: withFeatureFlag('flag', () => {...})

Parameter

Alle Parameter sind optional, aber mehr Kontext führt zu besseren Empfehlungen:

• repository (Zeichenkette): Repository-Name oder -Pfad.
• branch (Zeichenkette): Name des aktuellen Branches.
• files (Array): Liste der geänderten Dateien.
• description (Zeichenkette): Beschreibung der Änderung.
• riskLevel (Aufzählung): low, medium, high oder critical, wie vom Benutzer eingeschätzt.
• codeContext (Zeichenkette): Umgebender Code zur Erkennung des übergeordneten Flags.

Verwendungsbeispiel

Agent-Prompt

Einfache Verwendung, bei der der Agent den Kontext sammelt:

Use evaluate_change to help me determine if I need a feature flag

Explizite Anweisungen:

Use evaluate_change with:
- description: "Add Stripe payment processing"
- riskLevel: "high"

Tool-Payload

{
  "repository": "my-app",
  "branch": "feature/stripe-integration",
  "files": ["src/payments/stripe.ts"],
  "description": "Add Stripe payment processing",
  "riskLevel": "high",
  "codeContext": "surrounding code for parent flag detection"
}

Tool-Ausgabe

Gibt ein JSON-Objekt mit dem Bewertungsergebnis zurück, einschließlich eines needsFlag-Booleschen Werts, eines recommendation (z. B. "create_new"), eines vorgeschlagenen Flag-Namens, der Risikostufe und einer detaillierten explanation.

{
  "needsFlag": true,
  "reason": "new_feature",
  "recommendation": "create_new",
  "suggestedFlag": "stripe-payment-integration",
  "riskLevel": "critical",
  "riskScore": 5,
  "explanation": "This change integrates Stripe payments, which is critical risk...",
  "confidence": 0.9
}

Flag erkennen

Das detect_flag-Tool findet vorhandene Feature-Flags in der Codebasis, sodass Sie diese wiederverwenden können, anstatt Duplikate zu erstellen. Dieses Tool ist automatisch in den evaluate_change-Workflow integriert, kann aber auch manuell verwendet werden.

Wann verwenden

Verwenden Sie dieses Tool, bevor Sie ein neues Feature-Flag erstellen oder während der Codebewertung, um nach vorhandenen Flags zu suchen, die Ihren Anwendungsfall möglicherweise bereits abdecken. Dies hilft, Flag-Duplikate zu vermeiden.

So funktioniert es

Das Tool gibt umfassende Suchanweisungen zurück und verwendet mehrere Erkennungsstrategien:

• Dateibasierte Erkennung: Suche in den Dateien, die Sie ändern, nach vorhandenen Flags.
• Git-Verlaufsanalyse: Suche nach kürzlich hinzugefügten Flags im Commit-Verlauf.
• Semantische Namensübereinstimmung: Abgleich von Beschreibungen mit vorhandenen Flag-Namen.
• Codekontextanalyse: Untersuchung des Codes rund um die Änderung.

Das Tool folgt dann einem Bewertungsprozess:

Step 1: Execute file-based search (grep for flag patterns in target files)
        ↓
Step 2: Search git history for recent flag additions
        ↓
Step 3: Perform semantic matching (description → flag names)
        ↓
Step 4: Analyze code context (if provided)
        ↓
Step 5: Combine scores from all methods
        ↓
Step 6: Return best candidate with confidence score

Konfidenzstufen

Das Tool gibt Kandidaten mit Konfidenzwerten zurück:

• Hoch ≥0.7: Starke Übereinstimmung; Wiederverwendung wird empfohlen.
• Mittel 0.4-0.7: Mögliche Übereinstimmung; manuell prüfen.
• Niedrig <0.4: Schwache Übereinstimmung; wahrscheinlich ein neues Flag erstellen.

Parameter

• description (erforderlich): Beschreibung der Änderung oder des Features. Zum Beispiel: "payment processing with Stripe", "new checkout flow".
• files (optional): Dateien, die geändert werden. Zum Beispiel: ["src/payments/stripe.ts", "src/checkout/flow.ts"].
• codeContext (optional): Benachbarter Code, der nach Flags durchsucht werden soll.

Verwendungsbeispiel

Agent-Prompt

Vor dem Erstellen eines Flags nach vorhandenen Flags suchen:

Use detect_flag with description "payment processing with Stripe"

Automatisch in die Bewertung integriert:

Use evaluate_change - automatically searches for existing flags

Tool-Payload

{
  "description": "payment processing with Stripe",
  "files": ["src/payments/stripe.ts"]
}

Tool-Ausgabe

Gibt ein JSON-Objekt zurück, das angibt, ob ein Flag gefunden wurde. Wenn flagFound wahr ist, enthält es ein candidate-Objekt mit dem Namen des Flags, dem Speicherort, dem Konfidenzwert und dem Grund für die Übereinstimmung.

Übereinstimmung gefunden:

{
  "flagFound": true,
  "candidate": {
    "name": "stripe-payment-integration",
    "location": "src/payments/stripe.ts:42",
    "context": "if (client.isEnabled('stripe-payment-integration')) {",
    "confidence": 0.85,
    "reasoning": "Found in same file you're modifying, added 2 days ago",
    "detectionMethod": "file-based"
  }
}

Keine Übereinstimmung gefunden:

{
  "flagFound": false,
  "candidate": null
}

Änderung umschließen

Das Tool wrap_change generiert sprachspezifische Codeausschnitte und Anleitungen zum Umschließen von Code mit Feature-Flags. Es hilft LLMs und Entwicklern, vorhandene Muster in der Codebasis zu befolgen und Flags korrekt zu verwenden.

Wann verwenden

Verwenden Sie dieses Tool, nachdem Sie ein Feature-Flag erstellt haben (mit create_flag) und es in Ihrem Code implementieren müssen. Es ist besonders nützlich, wenn Sie sicherstellen möchten, dass Sie vorhandene Codebasis-Muster befolgen oder frameworkspezifische Beispiele benötigen (z. B. React, Django).

So funktioniert es

Dieses Tool ist der letzte Schritt im evaluate_change → create_flag → wrap_change-Workflow.

Das Tool bietet in seiner Antwort die folgende Anleitung:

1. Suchanweisungen: Schritt-für-Schritt-Anleitung zum Finden vorhandener Flag-Muster in Ihrer Codebasis mit grep.
2. Mustererkennung: Identifiziert gängige Muster (z. B. Importe, Client-Variablennamen, Methodennamen oder Umschließungsstile).
3. Standardvorlagen: Fallback-Codeausschnitte, wenn keine Muster gefunden werden.
4. Frameworkspezifische Beispiele: Spezialisierte Muster für React, Express, Django und andere.
5. Mehrere Muster: If-Blöcke, Guard-Klauseln, Hooks, Dekorateure, Middleware und mehr.

Unterstützte Sprachen und Frameworks:

• TypeScript/JavaScript: Node.js, React Hooks, Express-Middleware.
• Python: FastAPI, Django, Flask-Dekorateure.
• Go: Standard-If-Blöcke, HTTP-Middleware.
• Ruby: Rails-Controller.
• PHP: Laravel-Controller.
• C#: .NET/ASP.NET-Controller.
• Java: Spring Boot.
• Rust: Actix/Rocket-Handler.

Parameter

• flagName (erforderlich): Name des Feature-Flags, mit dem der Code umschlossen werden soll. Zum Beispiel: "new-checkout-flow" oder "stripe-integration".
• language (optional): Programmiersprache (automatisch aus fileName erkannt, wenn nicht angegeben). Unterstützt: typescript, javascript, python, go, ruby, php, csharp, java, rust
• fileName (optional): Name der geänderten Datei (hilft bei der Spracherkennung). Zum Beispiel: "checkout.ts", "payment.py" oder "handler.go".
• codeContext (optional): Umgebender Code, um vorhandene Muster zu erkennen.
• frameworkHint (optional): Framework für spezialisierte Vorlagen. Zum Beispiel: "React", "Express", "Django", "Rails" oder "Spring Boot".

Verwendungsbeispiel

Agent-Prompt

Use wrap_change with:
- flagName: "new-checkout-flow"
- fileName: "src/components/checkout.ts"
- frameworkHint: "React"

Tool-Payload

{
  "flagName": "new-checkout-flow",
  "fileName": "checkout.ts",
  "frameworkHint": "React"
}

Tool-Ausgabe

Gibt eine umfassende, im Markdown-Format formatierte Zeichenkette zurück, die den Benutzer beim Umschließen seines Codes anleitet. Dies umfasst einen Schnellstart, Suchanweisungen, Umschließungsanweisungen mit Platzhaltern, alle verfügbaren Vorlagen für die Sprache und Links zur SDK-Dokumentation.

# Feature Flag Wrapping Guide: "new-checkout-flow"

**Language:** TypeScript
**Framework:** React

## Quick Start
[Recommended pattern with import and usage]

## How to Search for Existing Flag Patterns
[Step-by-step Grep instructions]

## How to Wrap Code with Feature Flag
[Wrapping instructions with examples]

## All Available Templates
[If-block, guard clause, hooks, ternary, etc.]

Flag-Rollout festlegen

Das set_flag_rollout-Tool konfiguriert eine flexibleRollout-Strategie in einer Feature-Flag-Umgebung. Es legt den Rollout-Prozentsatz, die Klebrigkeit (Stickiness) und optionale varianten auf Strategieebene fest. Dies aktiviert das Flag nicht; verwenden Sie toggle_flag_environment, um es zu aktivieren.

Wann verwenden

Verwenden Sie dieses Tool nach dem Erstellen eines Flags mit create_flag, um zu konfigurieren, wie der Datenverkehr verteilt wird, bevor Sie es aktivieren. Verwenden Sie es auch, um einen vorhandenen Rollout-Prozentsatz zu aktualisieren oder Varianten hinzuzufügen.

Parameter

• featureName (erforderlich): Name des Feature-Flags.
• environment (erforderlich): Zielumgebung (z. B. "production", "development").
• rolloutPercentage (erforderlich): Prozentsatz des Datenverkehrs, der das Feature erhalten soll (0-100).
• projectId (optional): Projekt-ID (Standard: UNLEASH_DEFAULT_PROJECT).
• groupId (optional): Klebrigkeits-Bucketing-Schlüssel (Standard: der Feature-Name).
• stickiness (optional): Klebrigkeitsfeld (Standard: "default").
• title (optional): Beschreibender Titel für die Strategie.
• disabled (optional): Strategie in deaktiviertem Zustand erstellen (Standard: false).
• variants (optional): Liste der Varianten auf Strategieebene, jeweils mit name, weight (0-1000), optionalem weightType ("variable" oder "fix"), stickiness und payload ({type, value}).

Verwendungsbeispiel

Agent-Prompt

Use set_flag_rollout with:
- featureName: "new-checkout-flow"
- environment: "production"
- rolloutPercentage: 25

Tool-Payload

{
  "featureName": "new-checkout-flow",
  "environment": "production",
  "rolloutPercentage": 25,
  "projectId": "ecommerce",
  "stickiness": "userId"
}

Tool-Ausgabe

Gibt eine Bestätigung mit dem konfigurierten Prozentsatz, einen Link zum Flag in der Unleash-Admin-Oberfläche, die Admin-API-Strategien-URL und einen MCP-Ressourcenlink für das Flag zurück.

Flag-Status abrufen

Das get_flag_state-Tool ruft die aktuellen Metadaten und Umgebungsstrategien eines Feature-Flags von der Unleash-Admin-API ab. Es gibt den Typ des Flags, den aktiviert/archiviert-Status, die Impression-Daten-Einstellung und eine Zusammenfassung der aktiven Strategien und Varianten pro Umgebung zurück.

Wann verwenden

Verwenden Sie dieses Tool, um ein Flag vor der Änderung zu inspizieren, um zu prüfen, wie viele Strategien in den Umgebungen aktiv sind, oder um Strategie-IDs zu finden, bevor Sie remove_flag_strategy aufrufen.

Parameter

• featureName (erforderlich): Name des Feature-Flags.
• projectId (optional): Projekt-ID (Standard: UNLEASH_DEFAULT_PROJECT).
• environment (optional): Ergebnisse auf eine einzelne Umgebung filtern (Groß-/Kleinschreibung wird nicht beachtet).

Verwendungsbeispiel

Agent-Prompt

Use get_flag_state with:
- featureName: "new-checkout-flow"
- environment: "production"

Tool-Payload

{
  "featureName": "new-checkout-flow",
  "projectId": "ecommerce",
  "environment": "production"
}

Tool-Ausgabe

Gibt eine Textzusammenfassung des Flags (Typ, aktiviert/archiviert/Impression-Daten, Projekt, Umgebungszusammenfassungen mit Strategieanzahl) sowie UI- und API-Links zurück. Die strukturierte Ausgabe enthält das vollständige Feature-Objekt mit allen Umgebungen und Strategiedetails.

Flags auflisten

Das list_flags-Tool listet die Feature-Flags in einem Projekt auf und gibt ein strukturiertes Inventar mit Paginierung und Sortierreihenfolge zurück. Aktive und archivierte Flags werden getrennt zurückgegeben: Rufen Sie es einmal mit archived: false (der Standard) und einmal mit archived: true auf, um ein vollständiges Inventar für Audit-Workflows zusammenzustellen.

Wann verwenden

Verwenden Sie dieses Tool, wenn ein Agent herausfinden muss, welche Flags bereits existieren, z. B. um ein Projekt zu auditieren, Kandidaten für die Bereinigung zu finden oder Kontext vor dem Erstellen oder Umschließen eines Flags aufzubauen. Es ist das agentenaufrufbare Äquivalent der unleash://projects/{projectId}/feature-flags-Ressource (siehe MCP-Ressourcen).

Parameter

• projectId (optional): Projekt, aus dem Flags aufgelistet werden sollen (Standard: UNLEASH_DEFAULT_PROJECT; automatisch aufgelöst, wenn nur ein Projekt existiert).
• archived (optional): true, um archivierte Flags anstelle von aktiven aufzulisten. Standard: false. Aktive und archivierte Flags können nicht in derselben Antwort zurückgegeben werden.
• limit (optional): Maximale Flags pro Seite (Standard: Server-Seitengröße, normalerweise 50).
• order (optional): Sortierreihenfolge nach Flag-Name, asc oder desc (Standard: asc).
• offset (optional): Anzahl der zu überspringenden Flags für die Paginierung (Standard: 0).

Verwendungsbeispiel

Agent-Prompt

Use list_flags with:
- projectId: "ecommerce"
- archived: false

Tool-Payload

{
  "projectId": "ecommerce",
  "archived": false,
  "limit": 50,
  "order": "asc"
}

Tool-Ausgabe

Gibt eine Textzusammenfassung plus strukturierten Inhalt mit projectId, archived, order, limit, offset, nextOffset, totalFlags und dem flags-Array zurück (jeweils mit Name, Typ, Projekt, Archivierungsstatus und Links). Verwenden Sie nextOffset, um durch große Projekte zu blättern.

Projekte auflisten

Das list_projects-Tool listet die Unleash-Projekte auf, die für das konfigurierte Token verfügbar sind, mit Paginierung und Sortierreihenfolge.

Wann verwenden

Verwenden Sie dieses Tool, wenn das Zielprojekt unbekannt ist oder wenn ein Agent ein Projekt auswählen muss, bevor es Flags auflistet oder erstellt. Es ist das agentenaufrufbare Äquivalent der unleash://projects-Ressource (siehe MCP-Ressourcen).

Parameter

• limit (optional): Maximale Projekte pro Seite (Standard: Server-Seitengröße, normalerweise 20).
• order (optional): Sortierreihenfolge nach Projekterstellungszeit, asc oder desc (Standard: desc, neueste zuerst).
• offset (optional): Anzahl der zu überspringenden Projekte für die Paginierung (Standard: 0).

Verwendungsbeispiel

Agent-Prompt

Use list_projects to see which projects are available.

Tool-Payload

{
  "limit": 20,
  "order": "desc"
}

Tool-Ausgabe

Gibt eine Textzusammenfassung plus strukturierten Inhalt mit order, limit, offset, nextOffset, totalProjects und dem projects-Array zurück (jeweils mit ID, Name, Beschreibung, Modus, Erstellungszeit und URL).

Flag-Umgebung umschalten

Das toggle_flag_environment-Tool aktiviert oder deaktiviert ein Feature-Flag in einer bestimmten Umgebung. Für schrittweise Rollouts konfigurieren Sie eine Strategie mit set_flag_rollout, bevor Sie aktivieren.

Wann verwenden

Verwenden Sie dieses Tool, um ein Flag nach der Konfiguration einer Rollout-Strategie zu aktivieren oder um ein Flag während eines Vorfalls oder nach Abschluss eines Rollouts zu deaktivieren.

Parameter

• featureName (erforderlich): Name des Feature-Flags.
• environment (erforderlich): Umgebung, in der umgeschaltet werden soll (z. B. "production").
• enabled (erforderlich): true zum Aktivieren, false zum Deaktivieren.
• projectId (optional): Projekt-ID (Standard: UNLEASH_DEFAULT_PROJECT).

Verwendungsbeispiel

Agent-Prompt

Use toggle_flag_environment with:
- featureName: "new-checkout-flow"
- environment: "production"
- enabled: true

Tool-Payload

{
  "featureName": "new-checkout-flow",
  "environment": "production",
  "enabled": true,
  "projectId": "ecommerce"
}

Tool-Ausgabe

Gibt eine Bestätigung des neuen Zustands, eine Zusammenfassung der Umgebung (aktiviert/deaktiviert, Strategieanzahl) sowie Links zum Flag in der Unleash-Admin-Oberfläche und der Admin-API zurück.

Flag-Strategie entfernen

Das Tool remove_flag_strategy löscht eine Strategiekonfiguration aus einer Feature-Flag-Umgebung. Verwenden Sie zuerst get_flag_state, um die Strategie-ID zu ermitteln.

Wann verwenden

Verwenden Sie dieses Tool, um veraltete Strategien zu bereinigen oder eine bestehende Strategie zu ersetzen, indem Sie die alte entfernen und eine neue mit set_flag_rollout konfigurieren.

Parameter

• featureName (erforderlich): Name des Feature-Flags.
• environment (erforderlich): Umgebung, aus der die Strategie entfernt werden soll.
• strategyId (erforderlich): ID der zu entfernenden Strategie (ermitteln Sie diese über get_flag_state).
• projectId (optional): Projekt-ID (Standard: UNLEASH_DEFAULT_PROJECT).

Verwendungsbeispiel

Agent-Prompt

Use get_flag_state to find strategy IDs for "new-checkout-flow" in production,
then use remove_flag_strategy to delete the old strategy.

Tool-Payload

{
  "featureName": "new-checkout-flow",
  "environment": "production",
  "strategyId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "projectId": "ecommerce"
}

Tool-Ausgabe

Gibt eine Bestätigung der Entfernung, eine Anzahl der verbleibenden Strategien in der Umgebung sowie Links zum Flag in der Unleash-Admin-Oberfläche und der Admin-API zurück.

Flag bereinigen

Das Tool cleanup_flag generiert Schritt-für-Schritt-Anweisungen zum sicheren Entfernen von Feature-Flag-Code aus der Codebasis, während der gewünschte Codepfad erhalten bleibt.

Wann verwenden

Verwenden Sie dieses Tool, wenn ein Feature-Flag seinen Lebenszyklus abgeschlossen hat:

• Nachdem ein Rollout 100 % erreicht hat und das Flag nicht mehr benötigt wird.
• Beim Einstellen einer experimentellen Funktion (den deaktivierten Pfad beibehalten).
• Beim Entfernen eines Notausschalters, der nicht mehr erforderlich ist.
• Bei der Bereinigung von technischen Schulden durch alte Flags.

So funktioniert es

Das Tool gibt umfassende Bereinigungsanweisungen zurück, die die LLM durch Folgendes führen:

1. Finden aller Vorkommen des Flags mithilfe von grep-Mustern.
2. Identifizieren von Verwendungsmustern (if-else-Blöcke, ternäre Ausdrücke, Guard-Klauseln, Hooks, Dekorateure, Middleware).
3. Entfernen von Flag-Prüfungen unter Beibehaltung des korrekten Codepfads.
4. Bereinigen ungenutzter Importe mit sprachspezifischen Anweisungen.
5. Überprüfen der Änderungen mit Such- und Testschritten nach der Bereinigung.

Wenn preservePath nicht angegeben ist, gibt das Tool Anweisungen zurück, den Benutzer zu fragen, welcher Pfad beibehalten werden soll, bevor fortgefahren wird.

Parameter

• flagName (erforderlich): Name des zu entfernenden Feature-Flags (z. B. "new-checkout-flow").
• preservePath (optional): "enabled", um den Codepfad bei aktiviertem Flag beizubehalten (typisch für abgeschlossene Rollouts), oder "disabled", um den Pfad bei deaktiviertem Flag beizubehalten (für entfernte Experimente). Wenn nicht angegeben, fordert das Tool Sie auf, den Benutzer zu fragen.
• files (optional): Bestimmte Dateien, die bereinigt werden sollen. Wenn nicht angegeben, wird die gesamte Codebasis durchsucht.
• language (optional): Programmiersprache für spezielle Anweisungen zur Importbereinigung (z. B. "typescript", "python"). Wird automatisch aus files erkannt, wenn nicht angegeben.

Verwendungsbeispiel

Agent-Prompt

Use cleanup_flag with:
- flagName: "new-checkout-flow"
- preservePath: "enabled"

Tool-Payload

{
  "flagName": "new-checkout-flow",
  "preservePath": "enabled",
  "files": ["src/components/checkout.tsx", "src/api/checkout.ts"],
  "language": "typescript"
}

Tool-Ausgabe

Gibt einen Markdown-Leitfaden zurück, der den Bereinigungsumfang und den beibehaltenen Pfad, grep-Befehle zum Finden aller Vorkommen, Anweisungen zum Entfernen pro Muster, sprachspezifische Importbereinigung und Schritte zur Überprüfung nach der Bereinigung (erneute Suche, Tests ausführen, manuelle Überprüfung) abdeckt.

MCP-Ressourcen

Der Server registriert MCP-Ressourcen zum Lesen von Projekt- und Feature-Flag-Daten. Alle Ressourcen geben JSON zurück und werden 60 Sekunden lang zwischengespeichert.

URI-Vorlage	Beschreibung
unleash://projects{?limit,order,offset}	Projekte auflisten. Standardseitengröße: 20, sortiert nach Erstellungszeit (neueste zuerst).
unleash://projects/{projectId}/feature-flags{?limit,order,offset}	Flags in einem Projekt auflisten. Standardseitengröße: 50, alphabetisch sortiert.
unleash://projects/{projectId}/feature-flags/{flagName}	Metadaten eines einzelnen Feature-Flags.

Die ersten beiden Vorlagen akzeptieren optionale Abfrageparameter: limit (Seitengröße), order (asc oder desc) und offset (Paginierungsstart). Antworten enthalten die Felder fetchedAt, cached, totalProjects oder totalFlags und nextOffset.

Ressourcen vs. Tools: MCP-Ressourcen werden von der Anwendung gesteuert, daher zeigen viele Clients sie nur über eine benutzergesteuerte Oberfläche an (z. B. #-Erwähnungen) und erlauben dem Agenten nicht, resources/read selbst aufzurufen. Wenn ein Agent Projekte oder Flags programmatisch auflisten muss, verwenden Sie die Tools list_projects und list_flags, die dieselben Daten über die Tool-Schnittstelle zurückgeben. Die detect_flag-Bestandsanalyse läuft über denselben Pfad.

Beispiel für das Lesen einer Ressource

Read unleash://projects/ecommerce/feature-flags?limit=10&order=asc

Gibt die ersten 10 Feature-Flags im Projekt ecommerce zurück, alphabetisch sortiert, mit Paginierungsmetadaten.

Architektur

Der Server folgt einem fokussierten, zweckorientierten Design.

Struktur

src/
├── index.ts                     # Stdio CLI entry point
├── server.ts                    # Transport-agnostic server factory
├── remote.ts                    # HTTP request handler for embedded mode
├── config.ts                    # Configuration loading and validation
├── context.ts                   # Shared runtime context
├── version.ts                   # Version constant
├── unleash/
│   └── client.ts                # Unleash Admin API client
├── tools/
│   ├── types.ts                 # Shared ToolDefinition type
│   ├── createFlag.ts            # create_flag tool
│   ├── evaluateChange.ts        # evaluate_change tool
│   ├── detectFlag.ts            # detect_flag tool
│   ├── wrapChange.ts            # wrap_change tool
│   ├── cleanupFlag.ts           # cleanup_flag tool
│   ├── setFlagRollout.ts        # set_flag_rollout tool
│   ├── getFlagState.ts          # get_flag_state tool
│   ├── toggleFlagEnvironment.ts # toggle_flag_environment tool
│   └── removeFlagStrategy.ts    # remove_flag_strategy tool
├── resources/
│   └── unleashResources.ts      # MCP resource handlers (projects, flags)
├── prompts/
│   └── promptBuilder.ts         # Markdown formatting utilities
├── evaluation/
│   ├── riskPatterns.ts          # Risk assessment patterns
│   └── flagDetectionPatterns.ts # Parent flag detection patterns
├── detection/
│   ├── flagDiscovery.ts         # Flag discovery strategies
│   └── flagScoring.ts           # Scoring and ranking logic
├── knowledge/
│   └── unleashBestPractices.ts  # Best practices knowledge base
├── templates/
│   ├── languages.ts             # Language detection and metadata
│   ├── wrapperTemplates.ts      # Code wrapping templates
│   ├── searchGuidance.ts        # Pattern search instructions
│   └── cleanupGuidance.ts       # Flag cleanup instructions
└── utils/
    ├── errors.ts                # Error normalization
    ├── streaming.ts             # Progress notifications
    └── stdioLogging.ts          # Stdio protocol traffic logging

Designprinzipien

• Schlanke Oberfläche: Nur die Endpunkte, die für die Kernfunktionen benötigt werden.
• Zweckorientiert: Jedes Modul dient einem spezifischen, klar definierten Zweck.
• Explizite Validierung: Zod-Schemas validieren alle Eingaben vor API-Aufrufen.
• Fehlernormalisierung: Alle Fehler werden in das Format {code, message, hint} umgewandelt.
• Fortschritts-Streaming: Langlaufende Operationen bieten Transparenz.
• Integration von Best Practices: Anleitungen aus der Unleash-Dokumentation sind in die Tool-Beschreibungen eingebettet.

Konfiguration

Dieser Abschnitt bietet eine Kurzreferenz für alle Konfigurationsoptionen.

Umgebungsvariablen:

• UNLEASH_BASE_URL: Ihre Unleash-Instanz-URL (erforderlich). Sowohl https://your-instance.getunleash.io als auch https://your-instance.getunleash.io/api werden akzeptiert – der Server normalisiert ein abschließendes /api, falls vorhanden, sodass Sie denselben Wert einfügen können, den die meisten Unleash-SDKs erwarten.
• UNLEASH_PAT: Persönliches Zugriffstoken (erforderlich).
• UNLEASH_DEFAULT_PROJECT: Die Standard-Projekt-ID, die das MCP verwenden soll (optional).

CLI-Flags:

• --dry-run: Operationen simulieren, ohne tatsächliche API-Aufrufe durchzuführen.
• --log-level: Ausführlichkeit der Protokollierung festlegen (debug, info, warn, error).

Best Practices

Dieser Server fördert Unleash-Best-Practices aus der offiziellen Dokumentation:

Flag-Lebenszyklus

1. Mit Absicht erstellen: Wählen Sie den richtigen Flag-Typ, um den Zweck zu signalisieren.
2. Klar dokumentieren: Schreiben Sie Beschreibungen, die das „Warum“ erklären.
3. Bereinigung planen: Feature-Flags sind temporär; planen Sie ihre Entfernung.
4. Nutzung überwachen: Impression-Daten für wichtige Flags aktivieren.

Flag-Typen

• Release-Flags: Für schrittweise Feature-Rollouts (nach vollständigem Rollout entfernen).
• Experiment-Flags: Für A/B-Tests (nach der Analyse entfernen).
• Operative Flags: Für Systemverhalten (längerlebig, regelmäßig überprüfen).
• Notausschalter: Für Notfallkontrollen (beibehalten, bis das Feature stabil ist).
• Berechtigungs-Flags: Für Zugriffskontrolle (längerlebig, Berechtigungen überprüfen).

Namenskonventionen

• Kebab-Case verwenden: new-checkout-flow
• Beschreibend sein: enable-ai-recommendations nicht flag1.
• Bei Bedarf den Geltungsbereich einbeziehen: mobile-push-notifications.

API-Referenz

Dieser Server verwendet die Unleash Admin API. Die vollständige API-Dokumentation finden Sie unter:

• Unleash Admin API OpenAPI-Spezifikation
• Unleash-API-Dokumentation

Verwendete Endpunkte

• GET /api/admin/projects – Projekte auflisten
• GET /api/admin/projects/{projectId}/features – Feature-Flags auflisten
• POST /api/admin/projects/{projectId}/features – Feature-Flag erstellen
• GET /api/admin/projects/{projectId}/features/{featureName} – Flag-Details abrufen
• POST /api/admin/projects/{projectId}/features/{featureName}/environments/{environment}/strategies – Rollout-Strategie hinzufügen
• DELETE /api/admin/projects/{projectId}/features/{featureName}/environments/{environment}/strategies/{strategyId} – Strategie entfernen
• POST /api/admin/projects/{projectId}/features/{featureName}/environments/{environment}/on – Flag aktivieren
• POST /api/admin/projects/{projectId}/features/{featureName}/environments/{environment}/off – Flag deaktivieren

Fehlerbehebung

Konfigurationsprobleme

Fehler: „UNLEASH_BASE_URL muss eine gültige URL sein“: Stellen Sie sicher, dass Ihre Basis-URL vollständig ist, einschließlich Protokoll. Zum Beispiel: https://app.unleash-hosted.com/instance. Entfernen Sie alle abschließenden Schrägstriche.

Fehler: „UNLEASH_PAT ist erforderlich“: Überprüfen Sie, ob Ihre Datei .env existiert und UNLEASH_PAT={{your-personal-access-token}} enthält. Stellen Sie sicher, dass das Token in Unleash gültig ist.

API-Probleme

Fehler: „HTTP_401“: Ihr persönliches Zugriffstoken ist möglicherweise ungültig oder abgelaufen. Generieren Sie ein neues Token unter Profil > Profileinstellungen anzeigen > Persönliche API-Tokens > Neues Token.

Fehler: „HTTP_403“: Ihr Token hat keine Berechtigung, Flags in diesem Projekt zu erstellen. Überprüfen Sie Ihre Rolle und Berechtigungen in Unleash.

Fehler: „HTTP_404“: Die Projekt-ID existiert nicht. Bestätigen Sie die Projekt-ID in der Unleash-Admin-Oberfläche.

Fehler: „HTTP_409“: Ein Flag mit diesem Namen existiert bereits im Projekt. Verwenden Sie einen anderen Namen oder verwenden Sie das vorhandene Flag erneut.

Lizenz

MIT

Mitwirken

Dies ist ein zweckorientiertes Projekt mit einem fokussierten Umfang. Beiträge sollten:

• Mit der bestehenden Tool-Oberfläche und dem MCP-Ressourcenmodell übereinstimmen.
• Die schlanke, zweckorientierte Architektur beibehalten.
• Unleash-Best-Practices folgen.
• Klare Dokumentation enthalten.