O que é MCP e o que é o Moretes Architect

MCP (Model Context Protocol) é um protocolo aberto entre dois lados: o cliente, que é o agente onde o modelo roda (Claude Code, Codex, Kiro, Cursor, VS Code, Gemini CLI, Amazon Q), e o servidor, que oferece três coisas. Tools são funções com nome, esquema de entrada em JSON e um resultado: o modelo decide chamar, o servidor executa. Prompts são roteiros prontos que o cliente pode carregar para orientar o modelo. Resources são documentos endereçados por URI que o modelo pode ler, como moretes://guide. O cliente lista o que o servidor tem, o modelo escolhe, o cliente chama, o servidor responde JSON. Só isso.

A divisão de trabalho é o que importa. O modelo raciocina: entende seu pedido, escolhe a ferramenta, monta os argumentos, interpreta o resultado e escreve a resposta. O servidor executa: calcula, valida esquema, devolve estrutura. Nenhum dos dois faz o papel do outro. Quando você pede "calcule a concorrência para 5 requisições por segundo", o modelo não multiplica de cabeça; ele chama capacity_plan e lê o número que voltou. O transporte pode ser stdio (o cliente sobe o servidor como processo filho na sua máquina) ou Streamable HTTP (o cliente fala com uma URL). O Moretes Architect oferece os dois, e a aula 2 mostra o comando de cada cliente.

O Moretes Architect é determinístico: o servidor nunca chama um modelo. A mesma entrada devolve a mesma saída, hoje e daqui a seis meses. Isso foi uma decisão de operação, não de estética. Em 30 dias de geração de conteúdo em lote no Bedrock, eu gastei US$ 84 contra um teto de US$ 5 por mês; um serviço público que pagasse por token a cada chamada seria uma conta sem dono. Sem modelo, o custo marginal de uma chamada é o de um Lambda de 256 MB rodando alguns milissegundos.

O que o servidor devolve, então, são quatro coisas. Cálculos: concorrência, tamanho de fila, orçamento de latência, crescimento de armazenamento, erro budget do SLO. Estruturas: um ADR com alternativas e consequências, um modelo C4, um contrato de evento, um runbook, um plano de migração. Fontes: toda resposta heurística traz um campo sources com URL de documentação oficial, e as ferramentas aws_knowledge_* consultam o AWS Knowledge MCP oficial em tempo real. Lacunas explícitas: decisionsToClarify, limitations, validated: false. O servidor prefere dizer "não sei isto" a preencher com suposição.

A palavra heurística aparece em quase toda resposta e tem um sentido preciso aqui: é triagem, não certificação. Um threat_model do Moretes Architect encontra o que um checklist encontra; ele não substitui um pentest, uma revisão oficial Well-Architected ou um parecer jurídico. Se a ferramenta diz que uma política IAM tem * demais, isso é um ponto para você olhar, não um laudo.

Em src/personas.ts moram 10 arquitetos: solution, enterprise, business, data, infrastructure, software, ai, security, governance e finops. Cada um é um objeto com mandate, questions, checks, deliverables, tools e antiPatterns. Nenhum deles raciocina sozinho. A persona é uma lente: o modelo do seu cliente a adota e passa a fazer as perguntas daquele papel, cobrar as entregas daquele papel e chamar as ferramentas daquele papel.

Elas chegam até você por três caminhos. A tool architect_panel convoca várias de uma vez sobre um assunto e devolve, por papel, o que perguntar primeiro (askFirst), o que checar, o que entregar e quais ferramentas chamar. Os 10 prompts architect_<role> fazem o modelo vestir uma lente só, por exemplo architect_finops quando a conversa é sobre custo. E os 10 resources moretes://personas/<id> deixam o modelo ler a definição inteira do papel.

Por que isso importa num time de 4 pessoas, como o do nosso exemplo? Porque ninguém ali é arquiteto de segurança em tempo integral, e a pergunta "como os segredos são emitidos, rotacionados e revogados?" precisa ser feita mesmo assim. O painel garante que a pergunta apareça antes do desenho congelar. Se a sua empresa tem esses papéis de verdade, a persona não os substitui: ela adianta a pauta da reunião.

Todas as 10 aulas usam o mesmo caso, com os mesmos números, para você ver uma arquitetura nascer de ponta a ponta em vez de 10 exemplos soltos. É o caso que os arquivos docs/examples/*.json do repositório já usam, então cada saída que você vir aqui é real.

Pedidos de um marketplace: 300 pedidos por minuto no pico, pagamento por cartão, clientes no Brasil, confirmação do pedido em menos de 2 segundos (p95), histórico guardado por 5 anos. Equipe de 4 pessoas, orçamento de USD 1.500 por mês, SLO de 99,9% mensal. Esses números não são decorativos: 300 por minuto vira 5 por segundo no capacity_plan, os 5 anos de histórico viram uma curva no storage_growth, os USD 1.500 viram teto no cost_model e o 99,9% vira 43 minutos de indisponibilidade por mês no slo_budget.

Ao fim das 10 aulas você terá, para esse caso, o que eu entregaria a um cliente: os requisitos checados e as lacunas nomeadas; o painel de arquitetos com as perguntas feitas antes do desenho; a comparação de alternativas de computação e de banco com fonte oficial datada; o diagrama C4 e o diagrama de sequência do checkout; o cenário de capacidade, latência e custo por pedido; a revisão da política IAM e da infraestrutura como código; o ADR com alternativas, consequências e testes pendentes; o ensaio de falha e o runbook; e a revisão de segurança do próprio agente que vai operar isso. Tudo gerado dentro do seu cliente, com as ferramentas desta aula. A aula 2 começa pelo passo zero: conectar, em cada cliente, em 30 segundos.