MCP Fusion/Core concepts/O padrão MVA
O padrão MVA
O Model View Agent substitui o MVC em backends de IA: a View se torna um Presenter, uma camada de percepção que controla exatamente o que o agente de IA vê, sabe e pode fazer em seguida.
MVA significa Model View Agent. É um padrão de arquitetura para backends de agentes de IA, e o MCP Fusion é a sua implementação de referência para o Model Context Protocol. A ideia é pequena e profunda ao mesmo tempo: quando o consumidor da sua API é um agente de IA em vez de um navegador, a camada View muda de significado. Ela não renderiza mais HTML. Ela molda o que o agente percebe.
f.query() · billing.get_invoice// the agent called the tool
billing.get_invoice({ id: 'inv_2026_0417' })
// the handler returns the raw model row
ctx.db.invoices.findUnique({
where: { id: input.id },
});waiting for the tool result…
Raw SDK would giveA raw SDK server would return this row as-is: every column, every internal field, straight into the model context.
Pressione Run e acompanhe uma chamada de tool pelo padrão: linha bruta, Presenter, redação, regras, affordances e um pacote de percepção limpo.
As três letras
| Letra | Nome | Responsabilidade |
|---|---|---|
| M | Model | Seus dados de domínio: faturas, usuários, tickets. Declarados uma vez com defineModel(). |
| V | View (Presenter) | A camada de percepção: quais campos existem, quais valores são redigidos, quais regras o agente recebe, quais ações ele pode tomar em seguida. |
| A | Agent | O LLM. Ele nunca toca no Model diretamente. Ele só vê o que um Presenter escolheu mostrar. |
Três falhas que o MVA elimina
Inanição de contexto. Um dump de JSON puro desperdiça janela de contexto com campos de que a tarefa não precisa. Os Presenters podam cada resposta para os campos de que a tarefa precisa e limitam o volume com .limit().
Cegueira de ação. O agente terminou um passo e agora adivinha o que fazer em seguida, então alucina um nome de tool. Os Presenters fecham cada resposta com .suggest(), uma lista de affordances: o servidor diz ao agente o que ele pode fazer em seguida, como o HATEOAS faz para APIs web.
Deriva de percepção. Duas tools retornam a mesma entidade em formatos diferentes, ou as unidades mudam e ninguém avisa o modelo. Um Presenter é definido uma vez por entidade, então toda tool que retorna essa entidade mostra a mesma verdade moldada, e .rules() carregam o significado em linhas de system prompt.
MVC e MVA lado a lado
| Aspecto | MVC | MVA |
|---|---|---|
| Consumidor | Navegador | Agente de IA |
| Camada View | Renderiza HTML ou JSON | Molda a percepção: campos, regras, affordances |
| Fronteira de confiança | O usuário vê a UI | O modelo não pode ver segredos |
| Navegação | Links entre páginas | Affordances de .suggest() entre ações |
| Modo de falha | Página quebrada | Alucinação, vazamento de PII, unidades erradas |
Do que um Presenter é feito
Cada peça é opcional e combinável:
.schema(): os campos que existem, com descrições que o agente lê.redactPII(): caminhos removidos antes da serialização, sempre.rules(): linhas de system prompt injetadas com toda resposta.ui(): blocos renderizados, como tabelas cujos dados passam por fora da redação, para dashboards.suggest(): próximas ações que o agente tem permissão para considerar.limit(): um limite no volume da resposta com uma mensagem de auto-recuperação.embed(): presenters aninhados para entidades relacionadas
O Presenter é uma fronteira de segurança, não um auxiliar de formatação. A redação roda depois de renderizar os blocos de UI e antes da serialização, então a rede nunca vê dados sensíveis. É por isso que toda tool no MCP Fusion anexa o seu Presenter com .returns().
Próximos passos
- Models and Presenters: a API completa de ambos
- Tools: como as tools anexam Presenters
- Governance: provando que a superfície permaneceu segura ao longo do tempo
