MCP · Para agentes de código
Conecte seu agente ao featury
O featury expõe um endpoint MCP remoto para que agentes de código (Claude Code, Kimi CLI, Cursor, qualquer cliente MCP) trabalhem com o seu workspace: triar requests, ler o inventário de features, ver o que foi entregue e perguntar ao agente do código.
Mais rápido: instale o plugin
Usa o Claude Code ou o Codex? O plugin do featury faz os passos 1, 2 e 5 abaixo por você: conecta seu agente ao featury e instala a skill. Você não precisa copiar nenhuma chave.
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 featuryNo Codex, a última linha faz o login. No Claude Code, digite /mcp, escolha featury e depois Authenticate. O navegador abre o featury, e você clica em Conectar.
1. Crie uma API key
No app, vá em Conta → API keys → Criar API key. A chave completa é mostrada apenas uma vez. Guarde-a em um lugar seguro. No servidor só fica o hash, então ela não pode ser recuperada depois.
Uma chave age como você: o agente trabalha com a sua identidade e exatamente as suas permissões em cada workspace de que você faz parte, nem mais, nem menos. Revogue a chave na mesma página assim que ela vazar.
2. Conecte seu agente
Aponte seu cliente MCP para o endpoint abaixo, com a sua chave como token Bearer. Transporte: Streamable HTTP (sem estado).
https://api.featury.app/mcpclaude.ai, ChatGPT e outros apps que fazem login
Adicione o featury como conector com o endereço acima, sem chave. O app abre o featury, você clica em Conectar e pronto. Ele ganha uma chave própria, listada em Conta → API keys, onde você pode revogá-la.
Um agente numa máquina sem navegador (um servidor, um container) pode entrar com um código curto em vez de colar uma chave. A skill do featury, mais abaixo, ensina como.
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" }Vai em ~/.codex/config.toml. Exporte FEATURY_API_KEY=fk_… no seu shell: o Codex lê o token do ambiente em vez do arquivo.
Cursor, VS Code e outros clientes MCP
A maioria dos clientes aceita um bloco JSON como este: a URL do endpoint mais um header Authorization: Bearer fk_…, transporte Streamable HTTP. Self-hosted? Use a origem da sua própria API.
{
"mcpServers": {
"featury": {
"url": "https://api.featury.app/mcp",
"headers": {
"Authorization": "Bearer fk_…",
"X-Featury-Agent": "claude-code"
}
}
}
}3. Quem fez o quê
Toda ação do seu agente acontece na sua conta. A featury também mostra QUAL agente fez: “Claude Code · por você” em timelines, comentários e no board.
Vincule um agente à chave na criação (Conta → Chaves de API → Criar chave → “Age como”): toda chamada feita com essa chave é atribuída ao agente, sem nenhuma configuração no cliente. Esta é a forma recomendada.
Prefere controle por requisição? Faça cada cliente enviar o cabeçalho X-Featury-Agent, como nos exemplos acima. Um cabeçalho explícito sobrepõe o vínculo da chave, então uma única chave pode servir vários agentes.
E se nada disso estiver definido, a featury usa o nome que o próprio cliente informa ao conectar (“claude-code”, “cursor”): a atribuição funciona mesmo sem configuração.
4. O que seu agente pode fazer
As ferramentas de descoberta (list_workspaces, list_projects) encontram os slugs de workspace e project para você; as demais os recebem: os mesmos slugs que você vê nas URLs do app.
| Ferramenta | O que faz |
|---|---|
| list_workspaces | Os workspaces de que você faz parte (id, nome, slug, seu papel): o ponto de partida |
| list_projects | Os projetos a que você tem acesso em um workspace (id, nome, slug, modo de acesso) |
| get_product_overview | O que o produto é, sintetizado a partir do código: manchete, pitch, o que ele faz |
| list_requests | Lista requests (bugs + pedidos de feature), filtráveis por status, kind, horizon, size, impact, search. Linhas compactas para revisar o quadro, com updatedAt, shippedAt e area (detail: "full" para os objetos completos) |
| get_request | Detalhe completo de um request: jornada, comentários, artefatos de spec, reality read |
| create_request | Registra um novo request (triagem padrão: dedup, resolução de área, reality read) |
| update_request | Atualiza um request: fixa um override humano de horizon/size/fit e/ou edita title/body/severity (mesmos caminhos das ações no app) |
| set_request_status | Move um request pelas faixas manuais: OPEN / PLANNED / CLOSED / DECLINED |
| add_request_comment | Comenta em um request (notifica os participantes, menções @Nome avisam) |
| merge_requests | Absorve um request em outro (duplicatas): o filho é entregue junto quando o pai for |
| list_features | O inventário vivo de features do projeto |
| get_feature | Uma feature por inteiro: onde ela vive no código, o que a mudou e quem a conhece |
| list_areas | As áreas de produto em que o mapa de features é agrupado |
| list_decisions | As decisões registradas: memória de projeto estilo ADR para o que NÃO vive no repo |
| read_decision | Detalhe completo de uma decisão: contexto, o que foi decidido e o status do ciclo de vida |
| create_decision | Registrar uma decisão tomada como memória durável do projeto (MANAGER+) |
| update_decision | Editar a redação de uma decisão ou avançar seu ciclo de vida (MANAGER+) |
| recent_changes | Mudanças recentes classificadas: o que foi entregue, em linguagem clara |
| list_in_flight | O que está sendo construído agora: pull requests abertos e trilhos de release, mapeados no produto |
| get_changelog | O changelog em uma leitura: a página pública, o ritmo, as notas ao redator e a edição em revisão |
| set_changelog_notes | Reescreve as notas permanentes que orientam o que o changelog conta e como (MANAGER+) |
| set_changelog_cadence | Define de quanto em quanto tempo uma edição é rascunhada, e quanto ela espera antes de se publicar sozinha (MANAGER+) |
| prepare_changelog_edition | Rascunha a próxima edição agora e substitui qualquer rascunho aberto (MANAGER+) |
| update_changelog_edition | Edita o rascunho antes de ir ao ar: renomeia, reescreve, reordena ou remove entradas (MANAGER+) |
| publish_changelog_edition | Publica o rascunho. Ele ganha número e link permanente, e a página pública entra no ar (MANAGER+) |
| unpublish_changelog_edition | Traz a edição mais recente de volta para rascunho (MANAGER+) |
| ask_featury | Pergunte ao agente do código; passe conversationId para continuar a conversa |
| create_report_schedule | Agenda um Update de resumo recorrente para um projeto: a cada intervalDays (opcionalmente fixado num dia da semana), às hour:minute UTC |
| list_report_schedules | Os agendamentos de resumos recorrentes do projeto (cadência, horário UTC, última/próxima execução) |
| delete_report_schedule | Remove um agendamento de resumo recorrente: os Updates gerados são mantidos, as execuções futuras param |
| list_webhook_endpoints | Os endpoints de webhook do produto (MANAGER+, como todas as ferramentas de webhook) |
| create_webhook_endpoint | Registra um endpoint para eventos assinados do produto. Retorna o segredo de assinatura uma única vez |
| update_webhook_endpoint | Altera url, rótulo, eventos ou o estado ativo de um endpoint (enabled: true reativa um auto-desativado) |
| delete_webhook_endpoint | Remove um endpoint e seu histórico de entregas |
| rotate_webhook_secret | Gera um novo segredo de assinatura: o antigo para na hora, o novo aparece uma única vez |
| test_webhook_endpoint | Envia um ping de teste assinado de forma síncrona e reporta o resultado |
| list_webhook_deliveries | As entregas recentes de um endpoint: status, tentativas, código HTTP, erro |
| get_webhook_delivery | Uma entrega com o payload JSON exato que foi enviado |
5. Opcional: ensine os fluxos de trabalho
A skill do featury ensina seu agente quando usar cada ferramenta, como fazer a triagem dos requests e como registrar neles o que encontrou. O plugin acima já inclui a skill. Sem o plugin, coloque-a na pasta de skills do seu agente:
mkdir -p ~/.agents/skills/featury \
&& curl -fsSL https://featury.app/skill/featury/SKILL.md \
-o ~/.agents/skills/featury/SKILL.mdQualquer diretório de skills que o seu agente leia funciona (ex.: ~/.claude/skills/featury/ para o Claude Code). Ver o arquivo da skill
Bom saber
- BUILDING e SHIPPED são derivados de sinais reais do código e nunca podem ser definidos manualmente: a mesma regra do app.
- Um sinal que você controla: cite o refCode de um pedido em um commit ou PR ("Closes idea/dark-mode", "Fixes bug/login-white-screen") e o ticket é entregue automaticamente, avisando quem pediu.
- As mutações se comportam exatamente como as ações no app (eventos de jornada, notificações) e são atribuídas a você.
- ask_featury consome o orçamento de IA do workspace, como uma mensagem de chat no app.
- Os erros voltam com uma mensagem legível (ex.: "Workspace not found"). Nunca stack traces.
- Prefere HTTP puro? Todas as capacidades do MCP também estão disponíveis em uma REST API versionada. Mesmas chaves, mesmas permissões. Docs da API →