MCP Fusion/Core concepts/El patrón MVA
El patrón MVA
El Model View Agent sustituye al MVC en backends de IA: la View se convierte en un Presenter, una capa de percepción que controla exactamente lo que el agente de IA ve, sabe y puede hacer a continuación.
MVA significa Model View Agent. Es un patrón de arquitectura para backends de agentes de IA, y MCP Fusion es su implementación de referencia para el Model Context Protocol. La idea es pequeña y profunda a la vez: cuando el consumidor de tu API es un agente de IA en lugar de un navegador, la capa View cambia de significado. Ya no renderiza HTML. Moldea lo que el agente percibe.
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.
Pulsa Run y sigue una llamada de tool a través del patrón: fila cruda, Presenter, redacción, reglas, affordances y un paquete de percepción limpio.
Las tres letras
| Letra | Nombre | Responsabilidad |
|---|---|---|
| M | Model | Tus datos de dominio: facturas, usuarios, tickets. Declarados una vez con defineModel(). |
| V | View (Presenter) | La capa de percepción: qué campos existen, qué valores se redactan, qué reglas recibe el agente, qué acciones puede tomar a continuación. |
| A | Agent | El LLM. Nunca toca el Model directamente. Solo ve lo que un Presenter decidió mostrar. |
Tres fallos que el MVA elimina
Inanición de contexto. Un volcado de JSON puro desperdicia ventana de contexto en campos que la tarea no necesita. Los Presenter recortan cada respuesta a los campos que la tarea necesita y limitan el volumen con .limit().
Ceguera de acción. El agente terminó un paso y ahora adivina qué hacer después, así que alucina un nombre de tool. Los Presenter cierran cada respuesta con .suggest(), una lista de affordances: el servidor le dice al agente qué puede hacer después, igual que HATEOAS lo hace para las APIs web.
Deriva de percepción. Dos tools devuelven la misma entidad con formas distintas, o cambian las unidades y nadie se lo dice al modelo. Un Presenter se define una vez por entidad, así que toda tool que devuelva esa entidad muestra la misma verdad moldeada, y .rules() llevan el significado en líneas del system prompt.
MVC y MVA lado a lado
| Aspecto | MVC | MVA |
|---|---|---|
| Consumidor | Navegador | Agente de IA |
| Capa View | Renderiza HTML o JSON | Moldea la percepción: campos, reglas, affordances |
| Frontera de confianza | El usuario ve la UI | El modelo no debe ver secretos |
| Navegación | Enlaces entre páginas | Affordances de .suggest() entre acciones |
| Modo de fallo | Página rota | Alucinación, fuga de PII, unidades incorrectas |
De qué está hecho un Presenter
Cada pieza es opcional y se puede componer:
.schema(): los campos que existen, con descripciones que el agente lee.redactPII(): rutas eliminadas antes de la serialización, siempre.rules(): líneas del system prompt inyectadas con cada respuesta.ui(): bloques renderizados, como tablas cuyos datos omiten la redacción, pensados para dashboards.suggest(): acciones siguientes que el agente puede considerar.limit(): un tope al volumen de la respuesta con un mensaje de autorreparación.embed(): presenter anidados para entidades relacionadas
El Presenter es una frontera de seguridad, no un ayudante de formato. La redacción se ejecuta después de renderizar los bloques de UI y antes de la serialización, así que el cable nunca ve datos sensibles. Por eso cada tool de MCP Fusion conecta su Presenter con .returns().
Próximos pasos
- Models and Presenters: la API completa de ambos
- Tools: cómo las tools conectan Presenter
- Governance: demostrando que la superficie se mantuvo segura con el tiempo