Não comece com outro MCP.Comece pelo que já funciona.

Uma API descreve operações disponíveis para software. Uma superfície MCP bem projetada decide quais dessas operações fazem sentido para agentes, sob qual identidade, com quais permissões, limites e evidências. O Sprint existe para evitar transformar todos os endpoints em ferramentas sem contexto de negócio ou controle.

Geradores podem acelerar scaffolding, mas geração de código não resolve sozinha desenho de capacidade, autorização, isolamento por tenant, ações de escrita, retries, aprovações ou observabilidade. Quando a conversão automática for suficiente, nós dizemos isso; quando não for, delimitamos exatamente o que falta.

Esse é um resultado válido do Sprint. Podemos recomendar uma integração direta, um conector existente ou outra abordagem mais simples quando ela entrega o mesmo resultado com menos risco, custo ou complexidade.

Você compra uma decisão de arquitetura utilizável: workflow prioritário, inventário técnico, superfície de capacidades candidata, classificação de risco, avaliação de identidade/tenancy, recomendação build-vs-buy e um escopo de implementação delimitado. Não é um relatório genérico sobre tendências de IA.

Não. “Inicia e responde” prova muito pouco sobre identidade, permissões, isolamento, idempotência, falhas, rate limits, auditoria e compatibilidade real. Production readiness exige evidência sobre os comportamentos que importam no seu sistema e no seu risco operacional.

O protocolo foi desenhado para interoperabilidade, mas compatibilidade de protocolo não é a mesma coisa que comportamento validado em um cliente específico. Nós separamos “compatível em princípio” de “testado pela WM3” e só comunicamos a segunda afirmação quando existe prova executada.

Pode fazer. O primeiro passo é estabelecer uma fronteira confiável de dados e ações. Se a documentação ou a API atual não sustentarem uma integração segura, isso aparece como pré-requisito explícito em vez de ser escondido dentro do projeto.

Não assumimos que tudo deve entrar no mesmo MCP. Primeiro identificamos o workflow de maior valor e as fronteiras de autoridade; depois decidimos se faz sentido uma superfície única, múltiplos servidores ou integração direta para partes do ecossistema.

Não existe um número universal. A meta é a menor superfície que cubra workflows valiosos com contratos claros e previsíveis. Expor dezenas de endpoints como tools pode aumentar ambiguidade, custo de contexto e superfície de risco sem aumentar utilidade.

Leitura, escrita, operações sensíveis e operações destrutivas têm perfis de risco diferentes. O desenho considera efeito, reversibilidade, identidade, escopo de permissão e necessidade de confirmação humana antes de permitir que uma ação vire capacidade de agente.

Ações com efeito precisam de uma estratégia explícita de idempotência, deduplicação e retry. O padrão correto depende do sistema de origem e do contrato da operação; o Sprint identifica onde duplicação seria material e o que precisa existir antes de produção.

Nem sempre. O desenho deve minimizar estado protocolar desnecessário e manter a verdade operacional no sistema apropriado. Estado de negócio, autorização e auditoria não devem virar efeitos acidentais de uma sessão de transporte.

A arquitetura deve separar o contrato de negócio da camada protocolar e versionar pontos de compatibilidade. Na operação gerenciada, mudanças de especificação, SDK, autenticação ou clientes entram como regressões verificáveis — não como atualização cega de dependência.

Não necessariamente. Primeiro avaliamos como identidade e autorização funcionam hoje e se podem ser preservadas com menor privilégio. A meta não é criar um segundo sistema de identidade sem necessidade, e sim manter uma cadeia clara entre usuário, cliente, servidor MCP e sistema de origem.

OAuth pode estabelecer quem está pedindo acesso e quais escopos foram concedidos, mas não substitui autorização de negócio. Ainda é necessário decidir o que aquela identidade pode fazer em cada tenant, operação e contexto, inclusive quando uma ação exige aprovação adicional.

Tenant isolation precisa ser aplicada no boundary de autorização e validada com testes negativos, não apenas descrita em prompt. O servidor nunca deve confiar em identificadores fornecidos pelo modelo para ampliar autoridade além da identidade autenticada.

Não. O briefing público não deve receber passwords, tokens, chaves ou dados privados de produção. Para qualificação, documentação pública ou sanitizada é suficiente; qualquer acesso técnico posterior precisa de um canal apropriado e escopo de menor privilégio.

Aprovação precisa existir no ponto em que a ação pode produzir efeito, com contexto suficiente para a pessoa entender o que será executado. Uma mensagem de “tem certeza?” no frontend não substitui um boundary de autoridade no backend.

Para operações relevantes, a meta é conseguir reconstruir quem pediu, sob qual identidade, qual capability foi chamada, qual decisão de política ocorreu e qual efeito foi confirmado. O nível de retenção e detalhe depende da criticidade e das obrigações do cliente.

A decisão depende de rede, dados, autenticação, compliance e ownership. Podemos recomendar ambiente gerenciado, cloud do cliente ou outra topologia, mas o Sprint evita prescrever infraestrutura antes de entender as restrições reais.

O plano de aceitação cobre contratos, fluxos felizes, falhas previsíveis, permissões negativas, duplicação/retry e clientes-alvo quando aplicável. A WM3 diferencia “conformidade de protocolo” de “workflow comprovado no contexto do cliente”.

Isso pode ficar com a equipe do cliente ou entrar em uma operação gerenciada. A manutenção pode cobrir mudanças da API upstream, SDK/spec, autenticação, contratos de tools, dependências, incidentes e reruns de compatibilidade/evals.

O modelo recomendado preserva ownership do cliente sobre seus sistemas e dados e evita dependência desnecessária de credenciais dentro da WM3. O escopo final deixa explícito o que é entregue, o que é operado e quais responsabilidades permanecem de cada lado.

Comece pelo briefing assistido. Ele coleta o objetivo do negócio, sistema envolvido, documentação disponível, identidade, ações desejadas e restrições sem pedir secrets. A WM3 revisa esse contexto e confirma o escopo antes de qualquer pagamento.