Featureflow MCP Server
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| FEATUREFLOW_API_URL | No | API base URL (optional) - use for self-hosted Featureflow instances | https://beta.featureflow.io/api |
| FEATUREFLOW_API_TOKEN | Yes | Personal Access Token (required) - starts with 'api-' |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Server capabilities have not been inspected yet.
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_projectsB | List all projects in the organization. Optionally filter by a search query that matches project name or key. |
| get_projectC | Get detailed information about a specific project by its ID or key. |
| create_projectC | Create a new project in the organization. |
| update_projectC | Update an existing project's name. |
| delete_projectB | Delete a project. This will also delete all features and environments in the project. |
| list_featuresB | List all features. Can filter by project key, search query, or predefined filters (maintaining, bookmarked, recent). |
| get_featureB | Get detailed information about a specific feature by ID or unified key (projectKey:featureKey). |
| create_featureC | Create a new feature flag in a project. |
| update_featureC | Update an existing feature's properties like name, description, or variants. |
| clone_featureC | Clone an existing feature with a new key and name. |
| archive_featureC | Archive or unarchive a feature flag. |
| delete_featureA | Delete a feature flag. Requires production editor or admin permissions. |
| get_feature_controlB | Get the feature control configuration for a specific feature and environment. Shows enabled state, rules, and variant assignments. |
| update_feature_controlC | Update feature control settings for a specific environment. Can enable/disable the feature, change the off variant, and modify rules. |
| list_environmentsB | List all environments for a project or the entire organization. |
| get_environmentC | Get detailed information about a specific environment by ID or unified key (projectKey:environmentKey). |
| create_environmentB | Create a new environment for a project. Optionally clone settings from an existing environment. |
| update_environmentC | Update an existing environment's properties. |
| delete_environmentB | Delete an environment. Cannot delete the last environment in a project. |
| list_targetsC | Get all targets (user attributes) for a project. Targets are used in targeting rules for A/B testing. |
| get_targetC | Get a specific target by its key. |
| list_api_keysC | List API keys for a specific environment. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 22 tools
Each tool has a clearly distinct purpose with no ambiguity, as they target specific resources (feature, environment, project, target, API key) and actions (create, get, list, update, delete, clone, archive). Overlap is minimal, such as 'get_feature' and 'get_feature_control' which serve different levels of detail, and descriptions clarify boundaries effectively.
Tool names follow a highly consistent verb_noun pattern throughout, using snake_case uniformly (e.g., create_feature, list_environments, update_project). The naming convention is predictable, making it easy for agents to infer functionality and maintain readability across all 22 tools.
With 22 tools, the count is slightly high but reasonable for a feature flag management system, covering CRUD operations for multiple resources (features, environments, projects, targets, API keys). It feels comprehensive rather than bloated, though it borders on the upper limit of typical scoping (3-15 tools).
The tool surface provides complete CRUD/lifecycle coverage for the feature flag management domain, including creation, retrieval, listing, updating, deletion, and specialized operations like cloning and archiving. No obvious gaps exist; agents can perform all core workflows without dead ends, from project setup to feature control updates.