Unleash

offiziell

MCP-Server zur Verwaltung von Unleash-Feature-Flags und Automatisierung von Best Practices.

GitHub
20

Was kann man mit Unleash MCP machen?

  • Feature Flags erstellen — Bitten Sie den Assistenten, mit create_flag ein neues Flag zu erstellen, und geben Sie dabei Name, Typ und Beschreibung an.
  • Prüfen, ob eine Änderung ein Flag benötigt — Verwenden Sie evaluate_change, um das Risiko zu bewerten und eine Empfehlung zu erhalten, bevor Sie Code ändern.
  • Vorhandene Flags erkennen, um Duplikate zu vermeiden — Führen Sie detect_flag aus, um die Codebasis nach Flags zu durchsuchen, die Ihren Anwendungsfall bereits abdecken.
  • Anleitung zur Code-Umschließung erhalten — Nutzen Sie nach der Erstellung eines Flags wrap_change, um sprachspezifische Codeausschnitte für die Implementierung zu generieren.
  • Schrittweise Rollouts konfigurieren — Legen Sie mit set_flag_rollout den Rollout-Prozentsatz und die Klebrigkeit fest, bevor Sie ein Flag aktivieren.
  • Flags umschalten und Strategien verwalten — Aktivieren oder deaktivieren Sie Flags über toggle_flag_environment, entfernen Sie Strategien mit remove_flag_strategy und überprüfen Sie den Status mit get_flag_state.

Dokumentation

Unleash MCP Server

Ein zweckgerichteter Model Context Protocol (MCP) Server zur Verwaltung von Unleash Feature Flags. Dieser Server ermöglicht es LLM-gestützten Coding-Assistenten, Feature Flags gemäß den Unleash-Best-Practices zu erstellen und zu verwalten.

Um Feedback zu geben, 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 es KI-Coding-Assistenten ermöglichen:

  • Feature Flags erstellen mit ordnungsgemäßer Validierung und Typisierung.
  • Vorhandene Flags erkennen, um Duplikate zu vermeiden oder Wiederverwendung zu fördern.
  • Änderungen bewerten, um zu entscheiden, wann ein Feature Flag erforderlich ist.
  • Fortschritt streamen für Transparenz während der Operationen.
  • Fehler 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 das Risiko und empfiehlt die Verwendung von Feature Flags.
  • detect_flag: Entdeckt vorhandene Feature Flags, um Duplikate zu vermeiden.
  • wrap_change: Bietet Anleitung, wie eine Änderung in ein Feature Flag verpackt 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 mit Flags versehenen Codepfaden.

Kern-Workflow

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

  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 das Erstellen 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, den Unleash MCP-Server zu installieren und auszuführen. Sie können entweder einer Einrichtung für Agenten (wie Claude Code und Codex) folgen, den MCP als eigenständigen Prozess mit npx ausführen oder eine lokale Entwicklungsumgebung verwenden.

Agenten-Einrichtung

Sie können den MCP-Server direkt zu Claude Code oder Codex hinzufügen. Agenten-Konfigurationen 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-Einrichtung (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 werden muss. Kontaktieren Sie das Unleash-Team, um sie aktivieren zu lassen.

OAuth

Der OAuth-Flow ö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 zur 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, gemeinsam genutzte Entwicklungsumgebungen, Clients, die OAuth nicht unterstützen).

So erstellen Sie ein PAT: Melden Sie sich bei Ihrer Unleash-Instanz an, gehen Sie zu Profil > Persönliche Zugriffstoken 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 Flag --header sendet das PAT direkt und umgeht den OAuth-Flow 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 --log-level debug

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

Lokale Entwicklungsumgebung

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
  1. Im Entwicklungsmodus direkt von Claude oder Codex ausführen

Vermeiden Sie npm run-Ausgaben und tsx watch-Banner, da jegliches zusätzliches stdout den MCP-Handshake unterbricht. Zwei leise 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 (kein 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 leise (keine npm-Lifecycle-Ausgabe) und führt TS direkt aus; verwenden Sie dies, wenn Sie das Bauen vermeiden möchten.
  • node dist/index.js ist die sicherste Wahl; kombinieren Sie es mit npm run build:watch, um bei Änderungen neu zu bauen, während der Agentenbefehl stabil bleibt.
  • Logs verbleiben im Repo-Stammverzeichnis (app.log, mcp-stdio.log), beide sind gitignoriert.

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 Anwendungslogs in diese Datei geschrieben (nicht stdout). Wenn nicht gesetzt, gehen Logs nach stderr.
  • MCP_STDIO_LOG_FILE (optional): Wenn gesetzt, werden MCP stdin/stdout/stderr mit Kanalpräfixen in diese einzelne Datei umgeleitet. Protokollnachrichten fließen weiterhin normal über stdout.

Client-Attribution

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 Unleash-Ereignisprotokolle beantworten, "welches KI-Tool dieses Flag erstellt oder umgeschaltet hat", ohne serverseitige Änderungen. Attributionswerte 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 auf unleash-mcp/<version> (MCP Server) zurückzusetzen. Standard: aktiviert.

Tool-Referenz

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

Flag erstellen

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

Wann zu verwenden

Verwenden Sie dieses Tool, wenn Sie bereits festgestellt haben, dass ein Feature Flag erforderlich ist (z. B. nach Ausführung von evaluate_change) und bereit sind, es mit dem richtigen Typ und 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 Absicht angibt.
    • release: Schrittweise Feature-Rollouts für Benutzer.
    • experiment: A/B-Tests und Experimente.
    • operational: Systemverhalten und operative Umschalter.
    • kill-switch: Notabschaltungen oder Schutzschalter.
    • permission: Steuerung des Feature-Zugriffs basierend auf Benutzerrollen oder Berechtigungen.
  • description (erforderlich): Klare Erklärung, was das Flag steuert und warum es existiert.
  • projectId (optional): Zielprojekt (Standard: UNLEASH_DEFAULT_PROJECT).
  • impressionData (optional): Analyse-Tracking aktivieren (Standard: 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-Benutzeroberfläche, einen MCP-Ressourcenlink für programmatischen Zugriff, den Erstellungszeitstempel und Konfigurationsdetails enthält.

Änderung bewerten

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

Wann zu verwenden

Verwenden Sie evaluate_change zu Beginn eines Features oder einer Ä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 Anleitung zur Rollout-Planung wünschen.

Funktionsweise

Das Tool liefert detaillierte, in Markdown formatierte Anleitungen für den LLM-Assistenten basierend auf den Unleash-Best-Practices.

Die Anleitung umfasst:

  • Erkennung übergeordneter Flags: Prüft, ob Code bereits durch vorhandene Flags geschützt ist.
  • Risikobewertung: Analysiert Codemuster, um riskante Operationen zu identifizieren.
  • Bewertung des Codetyps: Klassifiziert die Änderung (z. B. Test, Konfiguration, Feature oder Bugfix).
  • Empfehlung: Schlägt vor, ob ein Flag erstellt, ein vorhandenes Flag verwendet oder auf ein 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, um:

  1. Das Tool create_flag aufzurufen, um das Feature Flag zu erstellen.
  2. Das Tool wrap_change aufzurufen, um sprachspezifische Code-Wrapping-Anleitungen zu erhalten.
  3. Den verpackten Code gemäß den erkannten Mustern zu implementieren.

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): Z. B. Authentifizierung, Zahlungen, Sicherheit und Datenbankoperationen.
  • Hohes Risiko (Punktzahl +3): Z. B. API-Änderungen, externe Dienste oder neue Klassen.
  • Mittleres Risiko (Punktzahl +2): Z. B. asynchrone Operationen oder Zustandsverwaltung.
  • Niedriges Risiko (Punktzahl +1): Z. B. Bugfixes, Refactorings oder kleine Änderungen.

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

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

Die Ausgabe enthält einen confidence-Wert (0-1), der die selbst eingeschätzte Sicherheit des LLM darstellt und mit mehr bereitgestelltem 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 sich auf ausgeschlossene Dateien beschränken, lösen keine Flag-Empfehlung aus.

Die vollständigen Musterdefinitionen, einschließlich Schlüsselwörter pro Kategorie, Datei-Globs, Codemuster und Begründungen, finden Sie in src/evaluation/riskPatterns.ts.

Erkennung übergeordneter Flags

Das Tool sucht nach gängigen Mustern in verschiedenen Sprachen, wie z. B.:

  • 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 (string): Repository-Name oder -Pfad.
  • branch (string): Aktueller Branch-Name.
  • files (array): Liste der zu ändernden Dateien.
  • description (string): Beschreibung der Änderung.
  • riskLevel (enum): low, medium, high oder critical, je nach Einschätzung des Benutzers.
  • codeContext (string): Umgebender Code zur Erkennung übergeordneter Flags.

Anwendungsbeispiel

Agent-Prompt

Einfache Verwendung, bei der Sie den Agenten Kontext sammeln lassen:

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 Evaluierungsergebnis zurück, einschließlich eines needsFlag-Booleans, eines recommendation (z. B. „create_new“), eines vorgeschlagenen Flag-Namens, des Risikograds 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 Tool detect_flag 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 Code-Evaluierung, um zu prüfen, ob bereits Flags existieren, die Ihren Anwendungsfall abdecken könnten. Dies hilft, Flag-Duplizierung zu vermeiden.

Funktionsweise

Das Tool liefert umfassende Suchanweisungen und verwendet mehrere Erkennungsstrategien:

  • Dateibasierte Erkennung: Suche in den von Ihnen geänderten Dateien nach vorhandenen Flags.
  • Git-Verlaufsanalyse: Suche nach kürzlich hinzugefügten Flags im Commit-Verlauf.
  • Semantischer Namensabgleich: Abgleich von Beschreibungen mit vorhandenen Flag-Namen.
  • Codekontextanalyse: Untersuchung des Codes rund um die Änderung.

Das Tool durchläuft dann einen 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 neues Flag erstellen.

Parameter

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

Anwendungsbeispiel

Agent-Prompt

Vor dem Erstellen eines Flags nach vorhandenen Flags suchen:

Use detect_flag with description "payment processing with Stripe"

Automatisch in die Evaluierung 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 anzeigt, ob ein Flag gefunden wurde. Wenn flagFound wahr ist, enthält es ein candidate-Objekt mit Name, Ort, Konfidenzwert und dem Grund für die Übereinstimmung des Flags.

Ü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 wrappen

Das Tool wrap_change generiert sprachspezifische Code-Snippets und Anleitungen zum Wrappen von Code mit Feature-Flags. Es hilft LLMs und Entwicklern, bestehende 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 bestehende Codebasis-Muster befolgen, oder wenn Sie frameworkspezifische Beispiele benötigen (z. B. React, Django).

Funktionsweise

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

Das Tool liefert in seiner Antwort die folgende Anleitung:

  1. Suchanweisungen: Schritt-für-Schritt-Anleitung zum Auffinden vorhandener Flag-Muster in Ihrer Codebasis mit grep.
  2. Mustererkennung: Identifiziert gängige Muster (z. B. Imports, Client-Variablennamen, Methodennamen oder Wrapping-Stile).
  3. Standardvorlagen: Fallback-Code-Snippets, falls keine Muster gefunden werden.
  4. Frameworkspezifische Beispiele: Spezialisierte Muster für React, Express, Django und andere.
  5. Mehrere Muster: If-Blöcke, Guard Clauses, Hooks, Decorators, Middleware und mehr.

Unterstützte Sprachen und Frameworks:

  • TypeScript/JavaScript: Node.js, React Hooks, Express-Middleware.
  • Python: FastAPI, Django, Flask-Decorators.
  • 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 gewrappt werden soll. Zum Beispiel: "new-checkout-flow" oder "stripe-integration".
  • language (optional): Programmiersprache (automatisch erkannt aus fileName, falls nicht angegeben). Unterstützt: typescript, javascript, python, go, ruby, php, csharp, java, rust
  • fileName (optional): Name der zu ändernden 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".

Anwendungsbeispiel

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 einen umfassenden, als Markdown formatierten String zurück, der den Benutzer anleitet, wie er seinen Code wrappen kann. Dies umfasst einen Schnellstart, Suchanweisungen, Wrapping-Anweisungen 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 Tool set_flag_rollout konfiguriert eine flexibleRollout-Strategie für eine Feature-Flag-Umgebung. Es legt den Rollout-Prozentsatz, die Stickiness und optionale Varianten auf Strategieebene fest. Dies aktiviert das Flag nicht; verwenden Sie toggle_flag_environment, um es einzuschalten.

Wann verwenden

Verwenden Sie dieses Tool nach dem Erstellen eines Flags mit create_flag, um zu konfigurieren, wie der Traffic verteilt wird, bevor es aktiviert wird. Verwenden Sie es auch, um einen bestehenden 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 Traffics, der das Feature erhalten soll (0–100).
  • projectId (optional): Projekt-ID (Standard: UNLEASH_DEFAULT_PROJECT).
  • groupId (optional): Stickiness-Bucketing-Schlüssel (Standard: der Feature-Name).
  • stickiness (optional): Stickiness-Feld (Standard: "default").
  • title (optional): Beschreibender Titel für die Strategie.
  • disabled (optional): Strategie im deaktivierten Zustand erstellen (Standard: false).
  • variants (optional): Liste von Varianten auf Strategieebene, jeweils mit name, weight (0–1000), optionalem weightType ("variable" oder "fix"), stickiness und payload ({type, value}).

Anwendungsbeispiel

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, einem Link zum Flag in der Unleash-Admin-UI, der Admin-API-Strategien-URL und einem MCP-Ressourcen-Link für das Flag zurück.

Flag-Status abrufen

Das Tool get_flag_state 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-Data-Einstellung und eine Zusammenfassung der aktiven Strategien und Varianten pro Umgebung zurück.

Wann verwenden

Verwenden Sie dieses Tool, um ein Flag zu inspizieren, bevor Sie es ändern, um zu prüfen, wie viele Strategien in verschiedenen 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 ignoriert).

Anwendungsbeispiel

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-Data, 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 Tool list_flags 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 (Standard) und einmal mit archived: true auf, um ein vollständiges Inventar für Audit-Workflows zu erhalten.

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 aufzubauen, bevor ein Flag erstellt oder gewrappt wird. Es ist das vom Agenten aufrufbare Ä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 statt aktiver Flags aufzulisten. Standard: false. Aktive und archivierte Flags können nicht in derselben Antwort zurückgegeben werden.
  • limit (optional): Maximale Flags pro Seite (Standard: serverseitige Seitengröße, typischerweise 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).

Anwendungsbeispiel

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, Archiviert-Status und Links). Verwenden Sie nextOffset, um durch große Projekte zu blättern.

Projekte auflisten

Das Tool list_projects 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 er Flags auflistet oder erstellt. Es ist das vom Agenten aufrufbare Äquivalent der unleash://projects-Ressource (siehe MCP-Ressourcen).

Parameter

  • limit (optional): Maximale Projekte pro Seite (Standard: serverseitige Seitengröße, typischerweise 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).

Anwendungsbeispiel

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 Tool toggle_flag_environment aktiviert oder deaktiviert ein Feature-Flag in einer bestimmten Umgebung. Für graduelle Rollouts konfigurieren Sie eine Strategie mit set_flag_rollout, bevor Sie es aktivieren.

Wann verwenden

Verwenden Sie dieses Tool, um ein Flag einzuschalten, nachdem Sie eine Rollout-Strategie konfiguriert haben, 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, die umgeschaltet werden soll (z. B. "production").
  • enabled (erforderlich): true zum Aktivieren, false zum Deaktivieren.
  • projectId (optional): Projekt-ID (Standard: UNLEASH_DEFAULT_PROJECT).

Anwendungsbeispiel

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

Liefert eine Bestätigung des neuen Zustands, eine Zusammenfassung der Umgebung (aktiviert/deaktiviert, Anzahl der Strategien) sowie Links zum Flag in der Unleash-Admin-UI und der Admin-API.

Strategie eines Flags 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 mit set_flag_rollout eine neue 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 über get_flag_state).
  • projectId (optional): Projekt-ID (Standard: UNLEASH_DEFAULT_PROJECT).

Anwendungsbeispiel

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

Liefert eine Bestätigung der Entfernung, die Anzahl der verbleibenden Strategien in der Umgebung sowie Links zum Flag in der Unleash-Admin-UI und der Admin-API.

Flag bereinigen

Das Tool cleanup_flag generiert schrittweise Anleitungen zum sicheren Entfernen von Feature-Flag-Code aus der Codebasis, wobei 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.
  • Bei der Abschaltung einer experimentellen Funktion (deaktivierten Pfad beibehalten).
  • Beim Entfernen eines nicht mehr benötigten Kill-Switches.
  • Bei der technischen Schuldenbereinigung alter Flags.

Funktionsweise

Das Tool liefert umfassende Bereinigungsanweisungen, die das LLM durch folgende Schritte führen:

  1. Auffinden aller Vorkommen des Flags mit grep-Mustern.
  2. Identifizieren von Verwendungsmustern (if-else-Blöcke, ternäre Ausdrücke, Guard-Klauseln, Hooks, Dekoratoren, Middleware).
  3. Entfernen der Flag-Prüfungen unter Beibehaltung des korrekten Codepfads.
  4. Bereinigen ungenutzter Importe mit sprachspezifischer Anleitung.
  5. Überprüfen der Änderungen durch erneute Suche und Testschritte.

Wenn preservePath nicht angegeben wird, liefert das Tool Anweisungen, 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). Falls nicht angegeben, fordert das Tool Sie auf, den Benutzer zu fragen.
  • files (optional): Bestimmte zu bereinigende Dateien. Falls nicht angegeben, wird die gesamte Codebasis durchsucht.
  • language (optional): Programmiersprache für spezialisierte Importbereinigungsanleitung (z. B. "typescript", "python"). Wird automatisch aus files erkannt, falls nicht angegeben.

Anwendungsbeispiel

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

Liefert einen Markdown-Leitfaden mit dem Bereinigungsumfang und dem beibehaltenen Pfad, grep-Befehlen zum Auffinden aller Vorkommen, Anweisungen zur Entfernung pro Muster, sprachspezifischer Importbereinigung und Schritten zur Überprüfung nach der Bereinigung (erneute Suche, Tests ausführen, manuelle Prüfung).

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-VorlageBeschreibung
unleash://projects{?limit,order,offset}Projekte auflisten. Standard-Seitengröße: 20, sortiert nach Erstellungszeit (neueste zuerst).
unleash://projects/{projectId}/feature-flags{?limit,order,offset}Flags in einem Projekt auflisten. Standard-Seitengröß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 sind anwendungsgesteuert, daher zeigen viele Clients sie nur über benutzergesteuerte UI an (z. B. #-Erwähnungen) und erlauben dem Agenten nicht, resources/read eigenständig aufzurufen. Wenn ein Agent programmatisch Projekte oder Flags auflisten muss, verwenden Sie die Tools list_projects und list_flags, die dieselben Daten über die Tool-Schnittstelle zurückgeben. Die Bestandsanalyse detect_flag läuft über denselben Pfad.

Beispiel für einen Ressourcen-Lesevorgang

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 erfüllt einen spezifischen, klar definierten Zweck.
  • Explizite Validierung: Zod-Schemas validieren alle Eingaben vor API-Aufrufen.
  • Fehlernormalisierung: Alle Fehler werden in das Format {code, message, hint} konvertiert.
  • Fortschrittsstreaming: 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 entfernt einen abschließenden /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 der MCP verwenden soll (optional).

CLI-Flags:

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

Best Practices

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

Flag-Lebenszyklus

  1. Mit Absicht erstellen: Den richtigen Flag-Typ wählen, um den Zweck zu signalisieren.
  2. Klar dokumentieren: Beschreibungen verfassen, die das „Warum“ erklären.
  3. Bereinigung einplanen: Feature-Flags sind temporär; ihre Entfernung planen.
  4. Nutzung überwachen: Impressionsdaten 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 Analyse entfernen).
  • Operational-Flags: Für Systemverhalten (langlebiger, regelmäßig überprüfen).
  • Kill-Switches: Für Notfallkontrollen (beibehalten, bis das Feature stabil ist).
  • Permission-Flags: Für Zugriffskontrolle (langlebiger, Berechtigungen überprüfen).

Namenskonventionen

  • Kebab-Case verwenden: new-checkout-flow
  • Aussagekräftig sein: enable-ai-recommendations statt flag1.
  • Bei Bedarf Geltungsbereich einbeziehen: mobile-push-notifications.

API-Referenz

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

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 .env-Datei 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-UI.

Fehler: „HTTP_409“: Ein Flag mit diesem Namen existiert bereits im Projekt. Verwenden Sie einen anderen Namen oder nutzen Sie das bestehende Flag wieder.

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.
  • Den Unleash-Best-Practices folgen.
  • Eine klare Dokumentation enthalten.