Documentación

MCP Fusion/Reference/Migración

Migración

Pregunta a la IA sobre Vinkius

Migra un servidor MCP existente del SDK puro a MCP Fusion de forma incremental: un dominio de tools cada vez, de respuestas con JSON.stringify a Presenters, redacción y rules.

MCP Fusion no exige una reescritura. El SDK MCP puro y MCP Fusion pueden coexistir en un mismo servidor, y la mayoría de los equipos migra un dominio de tools cada vez, en el orden de 15 a 30 minutos por dominio. Esta página muestra la forma de uno de esos pasos.

Antes: una tool del SDK puro

typescript
server.setRequestHandler(CallToolRequestSchema, async (request) => {
  if (request.params.name === 'get_invoice') {
    const invoice = await db.invoices.findUnique({
      where: { id: request.params.arguments.id },
    });
    return {
      content: [{ type: 'text', text: JSON.stringify(invoice) }],
    };
  }
});

Los problemas son estructurales. JSON.stringify(invoice) envía todas las columnas al modelo, incluidas las que olvidaste que existían. Las unidades viven en conocimiento tribal, así que el modelo adivina. No hay lugar donde la redacción, la validación o las siguientes acciones pudieran siquiera ocurrir.

Después: la misma tool en MVA

typescript
const InvoicePresenter = createPresenter('Invoice')
  .schema({
    id: t.string,
    customer: t.string,
    amount_cents: t.number.describe('CENTS, divide by 100'),
    status: t.enum('draft', 'paid', 'overdue'),
  })
  .redactPII(['customer.email', 'customer.ssn'])
  .rules(['amount_cents is in CENTS. Divide by 100.']);

export default f.query('billing.get_invoice')
  .describe('Retrieve an invoice by ID')
  .withString('id', 'Invoice ID')
  .returns(InvoicePresenter)
  .handle(async (input) => {
    return db.invoices.findUnique({ where: { id: input.id } });
  });

La misma lógica de handler. Qué cambió:

AspectoSDK puroMCP Fusion
Forma de la salidaJSON.stringify, todas las columnasSchema del Presenter, solo los campos declarados
PIIEn el cable.redactPII() antes de serializar
Unidades y significadoFolclore de prompts.rules() como líneas de sistema
Siguientes accionesNingunaaffordances de .suggest()
ValidaciónManualZod del builder

El camino incremental

  1. Instala en paralelo. npm install @mcpfusion/core no perturba los handlers existentes.
  2. Elige un dominio de tools. Normalmente el que toca los datos más sensibles.
  3. Escribe primero el Presenter. Declara los campos que la tarea necesita, aplica redaction al resto y escribe las rules en las que el modelo suele fallar.
  4. Mueve el handler. La lógica de query normalmente sobrevive intacta.
  5. Conecta autoDiscover. Las tools nuevas vienen de src/tools/, y los handlers antiguos siguen funcionando durante la transición.
  6. Bloquea y prueba. Ejecuta mcpfusion lock sobre la nueva superficie y añade las aserciones de egress de Testing.

Si vienes de otros frameworks

  • De APIs HTTP sencillas. @mcpfusion/openapi-gen genera Models, Views y Agents a partir de una spec de OpenAPI o Swagger existente, así que envolver una API interna empieza casi todo generado.
  • De un schema de Prisma. @mcpfusion/prisma-gen genera tools y Presenters con seguridad a nivel de campo y aislamiento de tenant a partir de anotaciones del schema.
  • De n8n. @mcpfusion/n8n convierte webhooks de n8n en tools con filtrado por tags.
  • De las interioridades de AWS. @mcpfusion/aws eleva funciones Lambda y Step Functions a tools mediante tags de recursos.

Próximos pasos