FeatQ

Tablero de votación de funciones alojado cuya solicitud principal tu agente de codificación (Claude Code, Cursor, Codex) extrae como especificación lista para construir a través de MCP.

Ver en featq.com

Documentación

MCP para tableros de FeatQ

El servidor MCP de FeatQ es un endpoint HTTP estándar transmisible en /api/mcp. Proporciona a un cliente compatible con MCP una conexión con alcance de tablero para leer solicitudes, verificar votos y comentarios, generar especificaciones de implementación y actualizar el estado de las solicitudes.

Cada solicitud se autentica con Authorization: Bearer fq_.... La clave del tablero determina a qué tablero puede acceder el cliente. FeatQ no utiliza el transporte SSE más antiguo, por lo que el cliente debe hablar HTTP transmisible. Claude Code, Cursor, Codex CLI y cualquier otro cliente que implemente este transporte pueden conectarse directamente.

Obtén tu clave de tablero

Abre la página de administración de tu tablero y busca el panel "Conecta tu agente de codificación". Copia la clave bearer o copia una configuración de cliente ya preparada. Mantén la clave privada; cualquiera que la tenga puede leer y actualizar ese tablero a través de MCP.

Las claves de tablero comienzan con fq_. Usa la clave del tablero que deseas que el agente administre, porque las herramientas no pueden cruzar de ese tablero a otro. Si mantienes tableros de producto o de staging separados, configura cada uno como un servidor MCP separado con su propia clave.

Claude Code

Ejecuta el comando desde el proyecto donde usas Claude Code. El transporte HTTP y el encabezado de autorización se almacenan con la definición del servidor, por lo que las herramientas estarán disponibles para ese proyecto de Claude Code después de un reinicio.

claude mcp add --transport http featq https://featq.com/api/mcp --header "Authorization: Bearer fq_YOUR_KEY"
  1. Abre una terminal en el proyecto donde usas Claude Code y ejecuta el comando anterior.
  2. La conexión predeterminada de alcance local se almacena bajo ese proyecto en ~/.claude.json. Mantén la clave bearer privada.
  3. Sal y reinicia Claude Code en ese proyecto para que recargue la conexión.
  4. Verifícalo preguntando: Usa FeatQ list_requests para listar las solicitudes de mi tablero.

Cursor

Cursor lee los servidores MCP desde un archivo de configuración JSON. El archivo del proyecto mantiene la conexión local a un repositorio, mientras que el archivo del directorio de inicio la hace disponible en todos los proyectos abiertos por tu cuenta de usuario.

{
  "mcpServers": {
    "featq": {
      "url": "https://featq.com/api/mcp",
      "headers": {
        "Authorization": "Bearer fq_YOUR_KEY"
      }
    }
  }
}
  1. Guarda el JSON como .cursor/mcp.json en un proyecto, o como ~/.cursor/mcp.json para usarlo globalmente. No confirmes un archivo que contenga tu clave bearer.
  2. Reinicia Cursor por completo después de guardar el archivo.
  3. Verifícalo en el chat de Agent preguntando: Usa FeatQ list_requests para listar las solicitudes de mi tablero.

Codex CLI

Codex CLI puede conectarse a FeatQ directamente a través de HTTP transmisible. Establece FEATQ_BOARD_KEY a tu clave de tablero fq_... en el entorno que inicia Codex. Un archivo de inicio de shell o tu administrador de secretos habitual puede proporcionar la variable, pero no debe confirmarse en el repositorio.

Agrega el servidor con el comando CLI a continuación. La bandera de token bearer le indica a Codex que lea el token de la variable de entorno nombrada en lugar de almacenar la clave en su archivo de configuración.

codex mcp add featq --url https://featq.com/api/mcp --bearer-token-env-var FEATQ_BOARD_KEY

El comando crea esta entrada en ~/.codex/config.toml. También puedes agregar la misma entrada manualmente. Reinicia Codex después de cambiar su configuración o entorno, luego pídele que llame a list_requests para verificar el acceso.

[mcp_servers.featq]
url = "https://featq.com/api/mcp"
bearer_token_env_var = "FEATQ_BOARD_KEY"

Cualquier otro cliente MCP

FeatQ funciona con cualquier cliente que implemente MCP sobre HTTP transmisible y pueda enviar un encabezado de autorización bearer. Crea una entrada de servidor HTTP remoto usando estos valores; no hay mercado de clientes ni paso de aprobación específico del cliente.

URL del endpoint

https://featq.com/api/mcp

Transporte

HTTP transmisible, no SSE

Encabezado de autenticación

Authorization: Bearer fq_your_key

Las etiquetas de los clientes varían, pero el tipo de conexión puede llamarse MCP remoto, MCP HTTP o HTTP transmisible. No selecciones un tipo de conexión solo SSE. Después de conectarse, el cliente debe descubrir las siete herramientas enumeradas a continuación durante la inicialización de MCP.

Referencia de herramientas

Todas las herramientas se ejecutan contra el tablero identificado por la clave bearer. Los ID de solicitud de un tablero diferente se devuelven como no encontrados. Los resultados de las herramientas se serializan en JSON dentro del contenido de texto MCP, lo que permite que un agente inspeccione los campos antes de decidir su próxima llamada.

list_requests

Lista las solicitudes del tablero autenticado. Úsalo para encontrar el trabajo más solicitado, revisar envíos recientes o enfocarte en una etapa del roadmap.

Argumentos

status (cadena, opcional)

Filtra por new, considering, planned, in_progress o done.

sort ("votes" | "newest", opcional)

Controla el orden de las solicitudes. El valor predeterminado es votes.

limit (entero, opcional)

Limita el resultado a entre 1 y 50 solicitudes. El valor predeterminado es 20.

Devuelve

Devuelve el slug y el nombre del tablero, más un arreglo de solicitudes. Cada solicitud contiene id, title, description, status, votes, comments y created_at.

Ejemplo

list_requests({ status: "planned", sort: "votes", limit: 10 })

get_ranked_requests

Clasifica las solicitudes abiertas en el tablero autenticado por demanda. La puntuación suma votos más medio punto por comentario y se desvanece a medida que una solicitud envejece durante aproximadamente 90 días, con empates que van a la solicitud más reciente. Las solicitudes ya marcadas como done se excluyen.

Argumentos

limit (entero, opcional)

Limita el resultado a entre 1 y 20 solicitudes. El valor predeterminado es 5.

Devuelve

Devuelve el tablero, generated_at, una descripción de clasificación y un arreglo de solicitudes. Cada solicitud contiene id, title, status, votes, comments, created_at y score.

Ejemplo

get_ranked_requests({ limit: 5 })

get_request

Lee el contexto completo de una solicitud en el tablero autenticado antes de planificarla o cambiarla.

Argumentos

id (cadena, obligatorio)

El ID de solicitud de función no vacío devuelto por list_requests.

Devuelve

Devuelve el tablero, el resumen de la solicitud con submitter_email y sus comentarios. Cada comentario incluye id, author_email, author_name, content, is_admin y created_at.

Ejemplo

get_request({ id: "REQUEST_ID" })

generate_spec

Crea un borrador de especificación de implementación en markdown listo para el agente a partir de una solicitud y su contexto de tablero.

Argumentos

id (cadena, obligatorio)

El ID de solicitud de función no vacío para convertir en un borrador de especificación.

Devuelve

Devuelve el tablero, un objeto de solicitud compacto con id, title y status, y el markdown generado. El markdown es un borrador que el agente debe verificar contra el código base.

Ejemplo

generate_spec({ id: "REQUEST_ID" })

update_request_status

Mueve una solicitud a un estado de flujo de trabajo válido. Marcarla como done también la hace aparecer en el changelog público del tablero.

Argumentos

id (cadena, obligatorio)

El ID no vacío de una solicitud en el tablero autenticado.

status (cadena, obligatorio)

Uno de new, considering, planned, in_progress o done.

Devuelve

Devuelve success, el resumen de la solicitud actualizada, notifications_queued y changelog_url. La URL del changelog está presente cuando el estado es done y es null para otros estados.

Ejemplo

update_request_status({ id: "REQUEST_ID", status: "done" })

get_board_stats

Obtén una vista compacta de la demanda y la distribución del flujo de trabajo en el tablero autenticado.

Argumentos

Sin argumentos.

Devuelve

Devuelve el tablero, total_requests, total_votes, conteos de by_status para los cinco estados y top_requests. El arreglo top_requests contiene los cinco resúmenes de solicitudes con más votos.

Ejemplo

get_board_stats({})

list_competitor_claims

Lista las afirmaciones que FeatQ extrajo de las páginas de comparación de competidores que este tablero observa. Solo lectura. Úsalo para ver lo que esas páginas dicen que falta en el producto antes de planificar el trabajo.

Argumentos

state (cadena, opcional)

Filtra por new, added o dismissed. El valor predeterminado es new.

limit (entero, opcional)

Limita el resultado a entre 1 y 100 afirmaciones. El valor predeterminado es 25.

Devuelve

Devuelve un arreglo de afirmaciones. Cada afirmación contiene id, feature, summary, quote, claim_type, competitor, source_url, first_seen_at, state y request_id.

Ejemplo

list_competitor_claims({ state: "new", limit: 25 })

Un flujo de trabajo de agente que entrega

Comienza pidiéndole al agente que llame a list_requests con sort: "votes". La respuesta clasifica las solicitudes por demanda demostrada y le da al agente los ID de solicitud que necesita para llamadas más profundas. El agente puede elegir el elemento principal, o puedes indicarle qué estado filtrar y cuántos candidatos comparar. Llamar a get_request a continuación agrega la descripción completa, el correo del remitente y el contexto de discusión antes de tomar decisiones de implementación.

Con una solicitud seleccionada, generate_spec produce un borrador de implementación en markdown. El agente de codificación debe conciliar ese borrador con el repositorio real, identificar los archivos afectados, implementar el cambio y ejecutar las verificaciones del proyecto. FeatQ proporciona el contexto de retroalimentación y el alcance propuesto; el agente aún verifica los supuestos técnicos contra el código que está cambiando.

Después de completar el trabajo, el agente llama a update_request_status con status: "done". FeatQ pone en cola las notificaciones de votantes aplicables y publica la solicitud completada en el changelog público del tablero. La respuesta incluye la ruta del changelog, para que el agente pueda informar dónde los usuarios pueden ver la actualización enviada.

Notas de seguridad

  • Una clave tiene alcance a un solo tablero. Permite que las herramientas MCP lean ese tablero y actualicen sus estados de solicitud, pero no otorga acceso a otros tableros de FeatQ.
  • Trata la clave como un secreto. Mantenla en variables de entorno, administradores de secretos o configuración privada del cliente. Nunca la pongas en código de navegador, registros públicos o un archivo confirmado en el control de versiones.
  • Se aplican límites de tasa por tablero. Cuando un tablero excede su límite de MCP, FeatQ responde con HTTP 429 y un encabezado Retry-After. Espera la cantidad de segundos en ese encabezado antes de reintentar en lugar de repetir la llamada de inmediato.

¿Tienes curiosidad sobre cómo se comparan otras herramientas de retroalimentación en esto? Consulta qué herramientas de retroalimentación tienen servidores MCP.