FF
FeatureFlare docs
Guides and API reference
Back to app
GuidesAPI docs
Guide

MCP Server

Connect IDE assistants and terminal workflows to FeatureFlare operations.

Current section
Product and workflow docs
Use these pages when you are wiring projects, operating flags, and reviewing rollout behavior.

Connect IDE assistants and terminal workflows to FeatureFlare through the hosted first-party MCP service.

Use this guide when you want governed assistant access to flag diagnostics and rollout operations without switching back to the console for every task. Your team configures an MCP client entry in the IDE; FeatureFlare runs the server.

What the MCP server is

The FeatureFlare MCP server exposes a semantic, assistant-safe tool surface for common operational tasks. Instead of mirroring low-level CRUD fields, it provides focused operations for project inventory, feature activity, GitHub-linked release evidence, rollout control, and governed feature or flag changes.

For customer teams, this is a hosted service, not a self-managed runtime. The goal is to keep assistant workflows useful without bypassing governance. Write operations continue to route through the same FeatureFlare API paths used by first-party clients.

Hosted setup for VS Code

For daily usage, point VS Code at the hosted MCP endpoint in .vscode/mcp.json:

{
  "servers": {
    "featureflare": {
      "type": "http",
      "url": "https://mcp.featureflare.com/mcp"
    }
  }
}

After the server entry is added, start the FeatureFlare MCP connection in VS Code and complete the browser sign-in flow. This avoids static bearer-token handling in workspace config and is the preferred path for GitHub Copilot usage.

What your team manages

Your team manages the MCP client configuration and authentication flow in the IDE. FeatureFlare manages the hosted MCP runtime and the backing control-plane behavior.

  • Add the hosted MCP entry to .vscode/mcp.json.
  • Approve the browser sign-in flow when VS Code requests access.
  • Use the available MCP tools from Copilot or another compatible client.

What FeatureFlare manages

FeatureFlare hosts the MCP server, handles the browser-based authentication flow, and routes tool requests into the same governed API paths used by the console. Customers do not need to run the MCP service themselves for normal usage.

Available tools

The hosted MCP surface currently includes inventory, analysis, release, and governance tools. Read-only tools let assistants gather context before proposing mutations, while write tools continue to enforce the same approval and audit rules as the console.

Inventory and discovery
  • list_projects lists the projects the authenticated caller can access.
  • list_features lists features in a project, including linked-flag counts for follow-up release work.
  • get_inventory reads projects, features, flags, and environments through one typed inventory entry point.
  • get_feature_events returns the same release-run and change-history timeline shown in the console Events tab.
  • search_github_pull_requests lists pull requests from a connected GitHub repository or project mapping.
Explain and cleanup analysis
  • explain_flag_behavior explains why a specific user context received a particular flag value.
  • suggest_flag_cleanup returns ranked stale-flag candidates, blockers, and cleanup rationale.
Governed changes and release workflows
  • rollout_flag previews or applies percentage rollout changes with governance checks and optimistic concurrency.
  • create_flag_from_code creates a managed flag from assistant-supplied code provenance and optional initial rules.
  • create_feature creates a draft feature and assigns it to the authenticated MCP user.
  • link_feature_flag links an existing flag to an existing feature using the first-party relationship flow.
  • unlink_feature_flag removes an existing feature-to-flag link while preserving audit consistency.
  • manage_feature_release_run lists, creates, starts, advances, pauses, resumes, or rolls back feature release runs.
  • manage_feature_pr_link lists, links, confirms, or unlinks pull request evidence attached to a feature.

Governance behavior

Mutating tools are intended to be preview-first and explicit. Production changes still need a change reason, approval-compatible state, and a current optimistic-concurrency token when required. If a change is blocked by feature locks, approvals, or stale version state, the MCP server should return a clear blocker instead of inferring intent.

Related docs