Enrutamiento

MCP Fusion descubre tools en tu árbol de archivos igual que Next.js descubre páginas. Un archivo, una tool, la ruta es el nombre.

Tools basadas en archivos

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

Regístralas una vez al arrancar:

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

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

Cada archivo hace export por defecto de su builder, y la cascada de resolución de exports acepta un export por defecto, un export nombrado tool, o cualquier builder exportado que informe de su nombre.

Tools agrupadas

Una API con cientos de endpoints no se mapea a cientos de tools. Cada nombre, schema y descripción de tool cuesta ventana de contexto, y la precisión del agente cae a medida que la lista crece. GroupedToolBuilder consolida acciones relacionadas en una sola tool con un discriminador:

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

El agente llama a billing con un argumento discriminador, y las anotaciones de "Required for" le dicen qué parámetros necesita cada acción. Una superficie plana de 500 endpoints se convierte en un puñado de tools inteligentes, el mayor ahorro de tokens disponible en conectores grandes. Consulta Tools para el builder por tool y Governance para ver cómo las superficies agrupadas siguen siendo auditables.

Cadenas de middleware

El middleware se aplica globalmente por árbol de directorios y por 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);

• El f.middleware() global se ejecuta para todas las tools
• .use() en un builder añade middleware específico de la tool
• Las cadenas se precompilan en tiempo de build en un pipeline O(1), así que añadir middleware no ralentiza el camino de la petición

El contexto devuelto por el middleware se fusiona en ctx, tipado mediante el genérico initMCPFusion<AppContext>(). Cada handler, middleware y Presenter posterior ve el mismo contexto tipado, y así el aislamiento de tenant se mantiene consistente en todo el conector.

Arranque y contexto

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

contextFactory se ejecuta por petición, así que los recursos por petición, como conexiones a la base de datos y la identidad del tenant, son frescos y aislados. Todo lo que devuelve es el ctx que reciben tus handlers.

Próximos pasos

• Tools: el builder en sí, parámetros y state gating
• Quickstart: un conector mínimo funcional
• Deploy: despliega el árbol completo en Vinkius Cloud