Manifesto

O Manifesto MCP-first

Dez princípios para software construído primeiro para agentes, seguro, descrito e totalmente controlável.

MCP-first não é hype em torno de um novo protocolo. É uma mudança de arquitetura. O software moderno não é mais concebido primeiro como webapp, mas como um sistema de capabilities totalmente controlável, legível por máquina e seguro. Webapp, aplicativo móvel, CLI e interfaces administrativas passam a ser apenas interfaces secundárias sobre o mesmo núcleo.

Uma tela é apenas uma interface. O software real é a sua capability.

O Claim Central

1 · Capabilities em vez de Telas

Uma funcionalidade não é uma página. Uma funcionalidade é uma capability. Quem descreve a capability primeiro pode oferecê-la em qualquer lugar, na UI, no agente, no worker.

2 · Tools em vez de Botões

Um botão é apenas a representação humana de uma tool. A tool, tipada, com permissões verificadas, auditada, é o que realmente importa.

3 · Resources em vez de Tabelas

Uma tabela é apenas a representação visual de uma resource. Agentes precisam da resource com contexto, não da tabela renderizada.

4 · Workflows em vez de Navegação

Agentes não precisam de navegação. Precisam de workflows claros que os guiem por processos complexos.

5 · Policies em vez de Confiança

6 · Confirmação em vez de Automação Cega

Ações arriscadas exigem consentimento humano. MCP-first significa totalmente controlável, não totalmente automatizado.

7 · Auditoria em vez de Opacidade

Cada ação de um agente deve ser rastreável: quem, o quê, quando, com qual aprovação.

8 · Contexto em vez de Dados Brutos

Agentes precisam de contexto relevante e processado, não de bancos de dados completos. Redaction e Context-Filtering são obrigatórios.

9 · UI Humana como Cliente

Webapp e aplicativo móvel são clientes, não o núcleo. Eles invocam as mesmas ações que o agente.

10 · 100% controlável, não 100% autônomo

Tudo deve ser controlável. Nem tudo pode acontecer de forma autônoma.

Se o seu software consegue fazer, o MCP deve conseguir descrever. Se um agente pode invocar, a Policy deve conseguir controlar.

Skills de Exemplo

Os princípios não são um fim em si mesmos. Eles se manifestam melhor onde os agentes operam o próprio servidor MCP, criando-o, controlando-o e auditando-o. Tais skills são workflows empacotados que seguem exatamente as mesmas regras que impõem: cada etapa arriscada tem um nível de risco, etapas críticas ficam atrás de uma aprovação, e cada ação é auditada.

mcp.scaffold_server
High

Inicializa um servidor MCP capability-first: Domain-Actions primeiro, schemas tipados, Policy Engine, metadados de risco e auditoria, antes de qualquer interface ser criada.

trigger "Crie um servidor MCP para …" Criar

Ablauf

  1. Modelar Domain-Actions, a lógica de negócio permanece no domínio. Low
  2. Gerar schemas de Input, Output e Erro tipados. Low
  3. Atribuir nível de risco e Confirmation Policy a cada tool. Medium
  4. Gerar o servidor como adaptador: Discovery, Policy Checks, Audit. High
  5. Registrar tools críticas somente após aprovação explícita. Critical ⏸ Freigabe

Hält sich an

  • Capabilities em vez de Telas.
  • Inputs e outputs tipados.
  • Policies em vez de Confiança.
  • Auditoria em vez de Opacidade.
mcp.audit_trail
Low

Revisão somente de leitura: lê o Audit Trail e a cobertura de risco, percorre o checklist e reporta lacunas. Não altera nada.

trigger "Verifique o servidor MCP contra o MCP-first" Auditar

Ablauf

  1. Ler o inventário de capabilities e os níveis de risco. Low
  2. Verificar completude e redaction dos Audit Events. Low
  3. Marcar tools sem classificação de risco. Low
  4. Produzir laudo como relatório estruturado, nenhuma ação de escrita. Low

Hält sich an

  • Auditoria em vez de Opacidade.
  • 100% controlável, não 100% autônomo.
  • Contexto em vez de Dados Brutos.

Mais exemplos, adicionar capability, controlar visibilidade de tools, conectar clientes, fortalecer a segurança, na página Skills de Exemplo.

O futuro pertence ao software que não é apenas operável, mas seguro e controlável.