Dokumentation

MCP Fusion/Reference/Migration

Migration

Frag die KI über Vinkius

Migrieren Sie einen bestehenden MCP-Server Schritt für Schritt vom rohen SDK zu MCP Fusion: ein Tool-Domain nach dem anderen, von JSON.stringify-Antworten zu Presenters, Redaction und Rules.

MCP Fusion erfordert keine Neuschreibung. Das rohe MCP-SDK und MCP Fusion können in einem Server koexistieren, und die meisten Teams migrieren einen Tool-Domain nach dem anderen, im Bereich von 15 bis 30 Minuten pro Domain. Diese Seite zeigt die Form eines solchen Schritts.

Vorher: ein Tool aus dem rohen SDK

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) }],
    };
  }
});

Die Probleme sind strukturell. JSON.stringify(invoice) schickt jede Spalte an das Modell, auch die, deren Existenz Sie vergessen hatten. Einheiten leben in Stammeswissen, also rät das Modell. Es gibt keinen Ort, an dem Redaction, Validierung oder Next Actions überhaupt stattfinden könnten.

Nachher: dasselbe Tool in 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 } });
  });

Dieselbe Handler-Logik. Was sich geändert hat:

AspektRohes SDKMCP Fusion
AusgabeformJSON.stringify, alle SpaltenPresenter-Schema, nur deklarierte Felder
PIIAuf der Leitung.redactPII() vor der Serialisierung
Einheiten und BedeutungPrompt-Folklore.rules() als Systemzeilen
Next ActionsKeineAffordances von .suggest()
ValidierungManuellZod vom Builder

Der inkrementelle Weg

  1. Installieren Sie parallel. npm install @mcpfusion/core stört die bestehenden Handler nicht.
  2. Wählen Sie einen Tool-Domain. Meist den, der die sensibelsten Daten berührt.
  3. Schreiben Sie zuerst den Presenter. Deklarieren Sie die Felder, die die Aufgabe braucht, wenden Sie Redaction auf den Rest an und schreiben Sie die Rules, die das Modell ständig falsch bekommt.
  4. Ziehen Sie den Handler um. Die Query-Logik übersteht das meist unverändert.
  5. Verdrahten Sie autoDiscover. Neue Tools kommen aus src/tools/, alte Handler funktionieren während der Umstellung weiter.
  6. Verriegeln und testen. Führen Sie mcpfusion lock für die neue Oberfläche aus und ergänzen Sie die Egress-Assertions aus Testing.

Von anderen Frameworks kommend

  • Von reinen HTTP-APIs. @mcpfusion/openapi-gen erzeugt Models, Views und Agents aus einer bestehenden OpenAPI- oder Swagger-Spec, sodass das Ummanteln einer internen API fast vollständig generiert beginnt.
  • Von einem Prisma-Schema. @mcpfusion/prisma-gen erzeugt Tools und Presenters mit Sicherheit auf Feldebene und Tenant-Isolation aus Schema-Annotationen.
  • Von n8n. @mcpfusion/n8n macht n8n-Webhooks zu Tools mit Tag-Filterung.
  • Von AWS-Interna. @mcpfusion/aws hebt Lambda-Funktionen und Step Functions über Ressourcen-Tags zu Tools.

Nächste Schritte