MCP · Para agentes de código
Conecta tu agente a featury
featury expone un endpoint MCP remoto para que agentes de código (Claude Code, Kimi CLI, Cursor, cualquier cliente MCP) trabajen con tu workspace: triar solicitudes, leer el inventario de funcionalidades, ver qué se entregó y preguntarle al agente del código.
Lo más rápido: instala el plugin
¿Usas Claude Code o Codex? El plugin de featury hace por ti los pasos 1, 2 y 5 de abajo: conecta tu agente a featury y agrega la skill. No tienes que copiar ninguna clave.
Claude Code
claude plugin marketplace add owe-br/plugins
claude plugin install featury@owe-brCodex
codex plugin marketplace add owe-br/plugins
codex plugin add featury@owe-br
codex mcp login featuryEn Codex, la última línea inicia tu sesión. En Claude Code, escribe /mcp, elige featury y luego Authenticate. Tu navegador abre featury y tú pulsas Conectar.
1. Crea una API key
En la app, ve a Cuenta → API keys → Crear API key. La clave completa se muestra solo una vez. Guárdala en un lugar seguro. En el servidor solo se conserva su hash, así que no se puede recuperar después.
Una clave actúa como tú: el agente trabaja con tu identidad y tus permisos exactos en cada workspace al que perteneces, ni más, ni menos. Revoca la clave desde la misma página en cuanto se filtre.
2. Conecta tu agente
Apunta tu cliente MCP al endpoint de abajo, con tu clave como token Bearer. Transporte: Streamable HTTP (sin estado).
https://api.featury.app/mcpclaude.ai, ChatGPT y otras apps que inician sesión
Agrega featury como conector con la dirección de arriba, sin clave. La app abre featury, tú pulsas Conectar y listo. Recibe su propia clave, que aparece en Cuenta → API keys, donde puedes revocarla.
Un agente en una máquina sin navegador (un servidor, un contenedor) puede iniciar sesión con un código corto en vez de pegar una clave. La skill de featury, más abajo, le enseña cómo.
Claude Code
claude mcp add --transport http featury https://api.featury.app/mcp \
--header "Authorization: Bearer fk_…" \
--header "X-Featury-Agent: claude-code"Codex
# ~/.codex/config.toml
[mcp_servers.featury]
url = "https://api.featury.app/mcp"
bearer_token_env_var = "FEATURY_API_KEY"
http_headers = { "X-Featury-Agent" = "codex" }Va en ~/.codex/config.toml. Exporta FEATURY_API_KEY=fk_… en tu shell. Codex lee el token del entorno en lugar del archivo.
Cursor, VS Code y otros clientes MCP
La mayoría de los clientes aceptan un bloque JSON como este: la URL del endpoint más un header Authorization: Bearer fk_…, transporte Streamable HTTP. ¿Self-hosted? Usa el origen de tu propia API.
{
"mcpServers": {
"featury": {
"url": "https://api.featury.app/mcp",
"headers": {
"Authorization": "Bearer fk_…",
"X-Featury-Agent": "claude-code"
}
}
}
}3. Quién hizo qué
Cada acción de tu agente ocurre en tu cuenta. Featury también muestra QUÉ agente lo hizo: “Claude Code · vía ti” en las líneas de tiempo, comentarios y el tablero.
Vincula un agente a la clave al crearla (Cuenta → Claves API → Crear clave → “Actúa como”): cada llamada con esa clave se atribuye a ese agente, sin configurar el cliente. Esta es la forma recomendada.
¿Prefieres control por petición? Haz que cada cliente envíe el encabezado X-Featury-Agent, como en los ejemplos de arriba. Un encabezado explícito prevalece sobre el vínculo de la clave, así una sola clave puede servir a varios agentes.
Y si no hay nada de eso, featury usa el nombre que el propio cliente informa al conectarse (“claude-code”, “cursor”): la atribución funciona incluso sin configuración.
4. Lo que tu agente puede hacer
Las herramientas de descubrimiento (list_workspaces, list_projects) encuentran los slugs de workspace y project por ti; las demás los reciben: los mismos slugs que ves en las URLs de la app.
| Herramienta | Qué hace |
|---|---|
| list_workspaces | Los workspaces a los que perteneces (id, nombre, slug, tu rol): el punto de partida |
| list_projects | Los proyectos a los que tienes acceso en un workspace (id, nombre, slug, modo de acceso) |
| get_product_overview | Qué es el producto, sintetizado desde su código: titular, pitch, qué hace |
| list_requests | Lista solicitudes (bugs + propuestas), filtrables por status, kind, horizon, size, impact, search. Filas compactas para revisar el tablero, con updatedAt, shippedAt y area (detail: "full" para los objetos completos) |
| get_request | Detalle completo de una solicitud: recorrido, comentarios, artefactos de spec, reality read |
| create_request | Registra una nueva solicitud (triaje estándar: dedup, resolución de área, reality read) |
| update_request | Actualiza una solicitud: fija un override humano de horizon/size/fit y/o edita title/body/severity (mismos caminos que las acciones en la app) |
| set_request_status | Mueve una solicitud por los carriles manuales: OPEN / PLANNED / CLOSED / DECLINED |
| add_request_comment | Comenta en una solicitud (notifica a los participantes, las menciones @Nombre avisan) |
| merge_requests | Absorbe una solicitud en otra (duplicados): la absorbida se entrega automáticamente cuando lo hace la principal |
| list_features | El inventario vivo de funcionalidades del proyecto |
| get_feature | Una funcionalidad completa: dónde vive en el código, qué la cambió y quién la conoce |
| list_areas | Las áreas de producto en las que se agrupa el mapa de funcionalidades |
| list_decisions | Las decisiones registradas: memoria de proyecto estilo ADR para lo que NO vive en el repo |
| read_decision | Detalle completo de una decisión: contexto, lo que se decidió y su estado del ciclo de vida |
| create_decision | Registrar una decisión tomada como memoria duradera del proyecto (MANAGER+) |
| update_decision | Editar la redacción de una decisión o avanzar su ciclo de vida (MANAGER+) |
| recent_changes | Cambios recientes clasificados: qué se entregó, en lenguaje claro |
| list_in_flight | Qué se está construyendo ahora: pull requests abiertos y carriles de release, mapeados al producto |
| get_changelog | El changelog en una sola lectura: la página pública, el ritmo, las notas al redactor y la edición en revisión |
| set_changelog_notes | Reescribe las notas permanentes que guían qué cuenta el changelog y cómo (MANAGER+) |
| set_changelog_cadence | Define cada cuánto se redacta una edición, y cuánto espera antes de publicarse sola (MANAGER+) |
| prepare_changelog_edition | Redacta la próxima edición ahora y reemplaza cualquier borrador abierto (MANAGER+) |
| update_changelog_edition | Edita el borrador antes de que salga: renómbralo, reescribe, reordena o quita entradas (MANAGER+) |
| publish_changelog_edition | Publica el borrador. Recibe su número y enlace permanente, y la página pública se activa (MANAGER+) |
| unpublish_changelog_edition | Devuelve la edición más reciente a borrador (MANAGER+) |
| ask_featury | Pregúntale al agente del código; pasa conversationId para seguir el hilo |
| create_report_schedule | Programa un Update de resumen recurrente para un proyecto: cada intervalDays (opcionalmente fijado a un día de la semana), a la hora hour:minute UTC |
| list_report_schedules | Las programaciones de resúmenes recurrentes del proyecto (cadencia, horario UTC, última/próxima ejecución) |
| delete_report_schedule | Elimina una programación de resumen recurrente: los Updates generados se conservan, las ejecuciones futuras se detienen |
| list_webhook_endpoints | Los endpoints de webhook del producto (MANAGER+, como todas las herramientas de webhook) |
| create_webhook_endpoint | Registra un endpoint para eventos firmados del producto. Devuelve el secreto de firma una sola vez |
| update_webhook_endpoint | Cambia url, etiqueta, eventos o el estado activo de un endpoint (enabled: true reactiva uno auto-desactivado) |
| delete_webhook_endpoint | Elimina un endpoint y su historial de entregas |
| rotate_webhook_secret | Genera un nuevo secreto de firma: el anterior deja de funcionar al instante, el nuevo se muestra una sola vez |
| test_webhook_endpoint | Envía un ping de prueba firmado de forma síncrona e informa el resultado |
| list_webhook_deliveries | Las entregas recientes de un endpoint: estado, intentos, código HTTP, error |
| get_webhook_delivery | Una entrega con el payload JSON exacto que se envió |
5. Opcional: enséñale los flujos de trabajo
La skill de featury le enseña a tu agente cuándo usar cada herramienta, cómo hacer el triaje de las solicitudes y cómo dejar en ellas lo que encontró. El plugin de arriba ya la incluye. Sin el plugin, ponla en la carpeta de skills de tu agente:
mkdir -p ~/.agents/skills/featury \
&& curl -fsSL https://featury.app/skill/featury/SKILL.md \
-o ~/.agents/skills/featury/SKILL.mdSirve cualquier directorio de skills que tu agente lea (p. ej. ~/.claude/skills/featury/ para Claude Code). Ver el archivo de la skill
Bueno saberlo
- BUILDING y SHIPPED se derivan de señales reales del código y nunca se pueden fijar a mano: la misma regla que en la app.
- Una señal que sí controlas: cita el refCode de una solicitud en un commit o PR ("Closes idea/dark-mode", "Fixes bug/login-white-screen") y el ticket se entrega automáticamente y avisa a quien lo pidió.
- Las mutaciones se comportan exactamente como las acciones en la app (eventos de recorrido, notificaciones) y se atribuyen a ti.
- ask_featury consume el presupuesto de IA del workspace, como un mensaje de chat en la app.
- Los errores vuelven con un mensaje legible (p. ej. "Workspace not found"). Nunca stack traces.
- ¿Prefieres HTTP puro? Todas las capacidades del MCP también están disponibles en una REST API versionada. Mismas claves, mismos permisos. Docs de la API →