Routing

MCP Fusion entdeckt Tools in Ihrem Dateibaum so, wie Next.js Seiten entdeckt. Eine Datei, ein Tool, der Pfad ist der Name.

Dateibasierte Tools

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

Registrieren Sie sie einmal beim Start:

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

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

Jede Datei exportiert ihren Builder als Default, und die Export-Auflösungskaskade akzeptiert einen Default-Export, einen benannten tool-Export oder jeden exportierten Builder, der seinen Namen meldet.

Gruppierte Tools

Eine API mit hunderten Endpoints mappt nicht auf hunderte Tools. Jeder Tool-Name, jedes Schema und jede Beschreibung kostet Kontextfenster, und die Genauigkeit des Agenten sinkt, je länger die Liste wird. GroupedToolBuilder konsolidiert verwandte Aktionen in einem Tool mit einem Diskriminator:

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);

Der Agent ruft billing mit einem Diskriminator-Argument auf, und die „Required for“-Annotationen sagen ihm, welche Parameter jede Aktion braucht. Eine flache Oberfläche von 500 Endpoints wird zu einer Handvoll intelligenter Tools, die größte verfügbare Token-Ersparnis bei großen Connectors. Siehe Tools für den Builder pro Tool und Governance dafür, wie gruppierte Oberflächen auditable bleiben.

Middleware-Ketten

Middleware greift global pro Verzeichnisbaum und pro 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);

• Globales f.middleware() läuft für jedes Tool
• .use() an einem Builder fügt toolspezifische Middleware hinzu
• Ketten werden zur Build-Zeit in eine O(1)-Pipeline vorkompiliert, daher verlangsamt zusätzliche Middleware den Anfragepfad nicht

Der von der Middleware zurückgegebene Kontext wird in ctx gemergt, typisiert über den Generik initMCPFusion<AppContext>(). Jeder Handler, jede Middleware und jeder Presenter flussabwärts sieht denselben typisierten Kontext, weshalb die Tenant-Isolation über einen ganzen Connector hinweg konsistent bleibt.

Start und Kontext

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

contextFactory läuft pro Anfrage, daher sind pro-Anfrage-Ressourcen wie Datenbankverbindungen und Tenant-Identität frisch und isoliert. Alles, was sie zurückgibt, ist der ctx, den Ihre Handler erhalten.

Nächste Schritte

• Tools: der Builder selbst, Parameter und state gating
• Quickstart: ein minimaler, funktionierender Connector
• Deploy: den ganzen Baum zu Vinkius Cloud ausliefern