Routage

MCP Fusion découvre les tools dans votre arborescence de fichiers comme Next.js découvre les pages. Un fichier, une tool, le chemin est le nom.

Tools basées sur les fichiers

src/tools/
  billing/
    get-invoice.ts    →  billing.get_invoice
    refund.ts         →  billing.refund
  support/
    tickets/
      search.ts       →  support.tickets.search

Enregistrez-les une fois au démarrage :

import { initMCPFusion, autoDiscover } from '@mcpfusion/core';

const f = initMCPFusion();
await autoDiscover(f, './src/tools');

Chaque fichier fait un export par défaut de son builder, et la cascade de résolution des exports accepte un export par défaut, un export nommé tool, ou tout builder exporté qui signale son nom.

Tools groupées

Une API avec des centaines d’endpoints ne correspond pas à des centaines de tools. Chaque nom, schema et description de tool coûte de la fenêtre de contexte, et la précision de l’agent baisse à mesure que la liste grandit. GroupedToolBuilder consolide les actions liées en une seule tool avec un discriminateur :

f.group('billing')
  .describe('Invoice operations')
  .action('get', (a) => a
    .withString('id', 'Invoice ID')
    .requiredFor('get', ['id']))
  .action('refund', (a) => a
    .withString('id', 'Invoice ID')
    .withNumber('amount_cents', 'Amount in CENTS')
    .requiredFor('refund', ['id', 'amount_cents']))
  .returns(InvoicePresenter);

L’agent appelle billing avec un argument discriminateur, et les annotations « Required for » lui indiquent quels paramètres chaque action exige. Une surface plate de 500 endpoints devient une poignée de tools intelligentes, la plus grande économie de tokens disponible sur les gros connecteurs. Voir Tools pour le builder par tool et Governance pour savoir comment les surfaces groupées restent auditables.

Chaînes de middleware

Le middleware s’applique globalement par arborescence de répertoires et par tool :

// A middleware derives context; its return object merges into ctx.
const withTenant = f.middleware(async (ctx) => ({
  tenantId: resolveTenant(ctx.request),
}));

f.query('billing.get_invoice').use(withTenant);

• Le f.middleware() global s’exécute pour chaque tool
• .use() sur un builder ajoute un middleware spécifique à la tool
• Les chaînes sont précompilées à la construction en un pipeline O(1), donc ajouter du middleware ne ralentit pas le chemin de la requête

Le contexte renvoyé par le middleware est fusionné dans ctx, typé via le générique initMCPFusion<AppContext>(). Chaque handler, middleware et Presenter en aval voit le même contexte typé, et l’isolation de tenant reste ainsi cohérente sur tout le connecteur.

Démarrage et contexte

f.registry.attachToServer(server, {
  contextFactory: async (extra) => ({
    db: await pool.acquire(),
    tenantId: resolveTenant(extra),
  }),
});

contextFactory s’exécute à chaque requête, donc les ressources par requête, comme les connexions à la base et l’identité du tenant, sont fraîches et isolées. Tout ce qu’elle renvoie est le ctx que vos handlers reçoivent.

Prochaines étapes

• Tools : le builder lui-même, les paramètres et le state gating
• Quickstart : un connecteur minimal fonctionnel
• Deploy : déployez l’arborescence complète sur Vinkius Cloud