Documentation

MCP Fusion/Reference/Migration

Migration

Demandez à l’IA à propos de Vinkius

Migrez un serveur MCP existant du SDK brut vers MCP Fusion de façon incrémentale : un domaine de tools à la fois, des réponses JSON.stringify aux Presenters, à la rédaction et aux rules.

MCP Fusion n’exige pas une réécriture. Le SDK MCP brut et MCP Fusion peuvent coexister dans un même serveur, et la plupart des équipes migrent un domaine de tools à la fois, de l’ordre de 15 à 30 minutes par domaine. Cette page montre la forme d’un tel pas.

Avant : un tool du SDK brut

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

Les problèmes sont structurels. JSON.stringify(invoice) envoie chaque colonne au modèle, y compris celles dont vous aviez oublié l’existence. Les unités vivent dans un savoir tribal, donc le modèle devine. Il n’y a nul endroit où rédaction, validation ou prochaines actions pourraient même intervenir.

Après : le même 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 } });
  });

Même logique de handler. Ce qui a changé :

AspectSDK brutMCP Fusion
Forme de la sortieJSON.stringify, toutes les colonnesSchéma du Presenter, uniquement les champs déclarés
PIISur le fil.redactPII() avant sérialisation
Unités et significationFolklore de prompts.rules() en lignes système
Prochaines actionsAucuneaffordances de .suggest()
ValidationManuelleZod fourni par le builder

Le chemin incrémental

  1. Installez côte à côte. npm install @mcpfusion/core ne dérange pas les handlers existants.
  2. Choisissez un domaine de tools. Généralement celui qui touche les données les plus sensibles.
  3. Écrivez d’abord le Presenter. Déclarez les champs dont la tâche a besoin, appliquez la rédaction au reste et écrivez les rules sur lesquelles le modèle se trompe sans arrêt.
  4. Déplacez le handler. La logique de requête survit généralement intacte.
  5. Branchez autoDiscover. Les nouveaux tools viennent de src/tools/, et les anciens handlers continuent de fonctionner pendant la transition.
  6. Verrouillez et testez. Lancez mcpfusion lock sur la nouvelle surface et ajoutez les assertions d’egress de Testing.

Venir d’autres frameworks

  • Depuis des API HTTP simples. @mcpfusion/openapi-gen génère des Models, Views et Agents à partir d’une spec OpenAPI ou Swagger existante, donc envelopper une API interne commence presque entièrement généré.
  • Depuis un schéma Prisma. @mcpfusion/prisma-gen génère des tools et des Presenters avec sécurité au niveau des champs et isolation par tenant à partir d’annotations du schéma.
  • Depuis n8n. @mcpfusion/n8n transforme les webhooks n8n en tools avec filtrage par tags.
  • Depuis des briques AWS internes. @mcpfusion/aws hisse des fonctions Lambda et des Step Functions en tools via des tags de ressources.

Prochaines étapes