Este repositorio contiene un servidor de Protocolo de Contexto de Modelo (MCP) para interactuar con el sistema de gestión de indicadores de características de Unleash. Permite a los agentes de IA gestionar indicadores de características a través de la API de Unleash.
El Protocolo de Contexto de Modelo (MCP) es una especificación que permite que los modelos de IA interactúen con herramientas externas y fuentes de datos. Este servidor implementa el protocolo MCP para Unleash, lo que permite a los asistentes de IA gestionar indicadores de características mediante programación.
Related MCP server: @shipeasy/mcp
Puedes instalar el paquete desde npm:
npm install -g @ylin6/unleash-ff-mcp-serverO ejecútelo directamente usando npx:
npx @ylin6/unleash-ff-mcp-serverEl servidor requiere las siguientes variables de entorno:
UNLEASH_API_URL : La URL de su instancia de API Unleash
UNLEASH_AUTH_TOKEN : El token de autenticación para su instancia de Unleash
El servidor MCP proporciona las siguientes herramientas para administrar indicadores de características:
Recupera una lista de todos los proyectos en la instancia de Unleash.
Recupera todos los indicadores de características dentro de un proyecto específico.
Parámetros:
projectId : El ID del proyecto
Crea una nueva bandera de característica dentro de un proyecto.
Parámetros:
projectId : El ID del proyecto
name : El nombre de la bandera de característica
description : Una descripción de la bandera de característica
type : el tipo de indicador de función (por ejemplo, "lanzamiento", "experimento", "operacional", "interruptor de seguridad")
Actualiza una bandera de característica existente.
Parámetros:
projectId : El ID del proyecto
featureId : El ID del indicador de característica
description : Una nueva descripción para la bandera de función.
type : Un nuevo tipo para la bandera de característica
Recupera detalles sobre una característica específica.
Parámetros:
projectId : El ID del proyecto
featureId : El ID del indicador de característica
Para utilizar este servidor MCP con Cursor, utilice el siguiente comando en la configuración del cursor
env UNLEASH_API_URL=XXXX UNLEASH_AUTH_TOKEN=XXX npx -y @ylin6/unleash-ff-mcp-serverEjemplo de conversación con Cursor/Claude:
You: Show me all the feature flags in the 'dashboard' project
Claude: I'll fetch all the feature flags in the 'dashboard' project for you.
[Claude uses the getFeatures tool with projectId='dashboard']
Claude: Here are all the feature flags in the 'website' project:
- new-homepage (type: release)
- dark-mode (type: experiment)
- beta-footer (type: operational)
...Para inspeccionar las operaciones del servidor MCP, puede ejecutar:
npm run inspectEsto utiliza el inspector MCP para analizar patrones de solicitud/respuesta.
ISC
Create a new feature flag
| Name | Required | Description | Default |
|---|---|---|---|
| featureData | Yes | ||
| projectId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Create a new feature flag', implying a write/mutation operation, but doesn't disclose any behavioral traits such as permissions required, whether it's idempotent, rate limits, or what happens on success/failure. This is a significant gap for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence 'Create a new feature flag', which is front-loaded and wastes no words. It's appropriately sized for its minimal content, though this conciseness contributes to under-specification in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (mutation tool with nested objects, no output schema, and no annotations), the description is incomplete. It doesn't cover parameter meanings, behavioral aspects, or usage context, making it inadequate for an AI agent to reliably invoke this tool. The lack of output schema further increases the need for descriptive detail that's missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning beyond the input schema, which has 0% schema description coverage. It doesn't explain what 'featureData' or 'projectId' represent, the significance of fields like 'type' with its enum values, or how parameters interact. With low schema coverage, the description fails to compensate, leaving parameters largely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new feature flag' clearly states the action (create) and resource (feature flag), but it's vague about what a 'feature flag' entails in this context and doesn't differentiate from sibling tools like 'updateFeatureFlag' or 'getFeatureFlag'. It provides basic purpose but lacks specificity about the domain or scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a projectId), when not to use it (e.g., for updates), or refer to sibling tools like 'updateFeatureFlag' or 'getFeatureFlag'. The description offers no context for usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a specific feature flag from a project
| Name | Required | Description | Default |
|---|---|---|---|
| featureId | Yes | ||
| projectId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states it's a retrieval operation. It doesn't disclose behavioral traits such as error handling (e.g., if the flag doesn't exist), authentication needs, rate limits, or what the return format looks like (since there's no output schema).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, clearly front-loading the core action. It's appropriately sized for a simple retrieval tool, though it could benefit from additional context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a read operation with 2 required parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't cover parameter meanings, usage context, or return values, making it inadequate for an agent to use the tool effectively without guesswork.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter details. It doesn't explain what 'featureId' and 'projectId' represent, their formats, or how they relate to retrieving the flag, leaving parameters undocumented beyond their names in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieve') and target ('a specific feature flag from a project'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'getFeatures' (which likely retrieves multiple flags) or specify what makes a flag 'specific' (e.g., by ID).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'getFeatures' (for listing flags) or 'createFeatureFlag'/'updateFeatureFlag' (for modifications). The description implies it's for retrieving a single flag but doesn't clarify prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve features for a specific project
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden but only states the action without behavioral details. It doesn't disclose whether this is a read-only operation, requires authentication, has rate limits, or what the return format might be, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, making it appropriately sized and front-loaded. Every part of the sentence contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (1 parameter, no output schema, no annotations), the description is incomplete. It lacks details on behavior, parameter semantics, and output, making it insufficient for an AI agent to fully understand how to invoke and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description doesn't add any meaning beyond the schema. It mentions 'specific project' which hints at the 'projectId' parameter, but provides no details on format, constraints, or examples, failing to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'retrieve' and the resource 'features for a specific project', making the purpose understandable. However, it doesn't differentiate from sibling tools like 'getFeatureFlag' or 'getProjects', which might retrieve similar data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'getFeatureFlag' or 'getProjects'. The description implies usage for retrieving features tied to a project, but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a list of projects
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action ('retrieve') without details on permissions, rate limits, pagination, or what the returned list includes. This is inadequate for a tool with no annotation coverage, as it leaves critical behavioral traits unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence ('Retrieve a list of projects') that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it highly concise and well-structured for its minimal content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a simple tool with 0 parameters, the description is incomplete. It lacks context on what 'projects' are, how the list is formatted, or any behavioral details like error handling. For even a simple tool, more information would help the agent use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't mention parameters, aligning with the schema. This earns a baseline score of 4, as it avoids redundancy while matching the schema's simplicity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Retrieve a list of projects' clearly states the action (retrieve) and resource (projects), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'getFeatureFlag' or 'getFeatures' which also retrieve data, leaving ambiguity about when to use this specific tool versus others.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'getFeatures' or 'getFeatureFlag'. It lacks context about prerequisites, such as whether authentication is needed or if there are any limitations, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing feature flag
| Name | Required | Description | Default |
|---|---|---|---|
| featureData | Yes | ||
| featureId | Yes | ||
| projectId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is an update operation, implying mutation, but doesn't disclose critical details like required permissions, whether changes are reversible, potential side effects, or response format. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly. No extraneous words or redundant information are present, which is ideal for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters with nested objects, mutation operation, no annotations, and no output schema), the description is inadequate. It doesn't cover parameter meanings, behavioral traits, or usage context, leaving the agent to guess based on schema structure alone. For a tool that modifies data, this lack of completeness could lead to incorrect invocations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 3 parameters (projectId, featureId, featureData) or nested properties are documented in the schema. The description adds no parameter information beyond implying an update occurs, failing to compensate for the coverage gap. It doesn't explain what featureData includes or how to use the parameters, leaving them largely ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing feature flag' clearly states the action (update) and target resource (feature flag), which is better than a tautology. However, it doesn't differentiate this tool from its sibling 'createFeatureFlag' beyond the verb difference, nor does it specify what aspects can be updated. The purpose is understandable but lacks specificity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing feature flag), when to choose update over create, or how it relates to siblings like 'getFeatureFlag' for checking current values. Without such context, the agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0createFeatureFlaggetFeatureFlaggetFeaturesgetProjectsupdateFeatureFlagScored across 5 tools
Every tool has a clearly distinct purpose with no overlap: createFeatureFlag and updateFeatureFlag handle modifications, getFeatureFlag and getFeatures retrieve specific or grouped data, and getProjects lists projects. The descriptions reinforce these distinctions, making misselection unlikely.
All tools follow a consistent verb_noun pattern with camelCase styling (e.g., createFeatureFlag, getFeatureFlag). There are no deviations in naming conventions, making the set predictable and easy to understand at a glance.
With 5 tools, the server is well-scoped for managing feature flags in Unleash. Each tool earns its place by covering essential operations: project listing, feature retrieval, and flag lifecycle management, without being overly sparse or bloated.
The toolset provides solid CRUD coverage for feature flags (create, get, update) and project listing, but lacks a deleteFeatureFlag tool, which is a minor gap. Agents can likely work around this, but the absence prevents full lifecycle management.
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
MCP server for building and testing AI agents with multi-model experimentation and insights.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
