Typisierter Client

MCP Fusion ist auf beiden Seiten der Grenze nützlich. Der Server verwaltet die Sicherheitspipeline; der typisierte Client gibt der aufrufenden Anwendung einen vom Compiler geprüften Vertrag. Kein generiertes SDK und keine doppelten Argument-Interfaces.

Router einmal exportieren

Umschließen Sie auf dem Server die Builder im curryfizierten typisierten Register und exportieren Sie den inferierten Router-Typ:

import { createTypedRegistry } from '@mcpfusion/core';
import type { InferRouter } from '@mcpfusion/core';

const registry = createTypedRegistry<AppContext>()(
  listProjects,
  createProject,
);

registry.registry.attachToServer(server, { contextFactory });
export type AppRouter = InferRouter<typeof registry>;

Der Laufzeitwert ist registry.registry; _builders und _context sind typtragende Felder. InferRouter schneidet die von jedem Builder gesammelten Phantom-Router-Maps, sodass eine Änderung an einem .withString()-Parameter den Client-Kompilierungsvertrag ohne Codegenerierung ändert.

Mit dem Vertrag ausführen

import { createMCPFusionClient } from '@mcpfusion/core/client';
import type { AppRouter } from './server.js';

const client = createMCPFusionClient<AppRouter>(transport, {
  throwOnError: true,
});

await client.execute('projects.create', {
  workspace_id: 'ws_1',
  name: 'V2',
});

Eine punktierte Aktion wird auf den Wire-Namespace abgebildet: projects.create wird zu callTool('projects', { ...args, action: 'create' }). Ein einzelnes Segment wird unverändert weitergegeben. Der Standardname des Discriminators ist action und kann mit discriminatorKey konfiguriert werden.

Batch und Proxy

executeBatch(calls) verwendet Promise.all und gibt Ergebnisse in Aufrufreihenfolge zurück. Übergeben Sie { sequential: true }, wenn der zweite Aufruf vom ersten abhängt. Der fließende Proxy ist ein rekursiver JavaScript-Proxy:

await client.proxy.projects.create({
  workspace_id: 'ws_1',
  name: 'V2',
});

await client.proxy.platform.users.list({ limit: 10 });

Die DevTools-Inspektion und die Suche nach then bei Promise sind geschützt, damit der Proxy nicht versehentlich ausgeführt wird, wenn ein Debugger oder Test-Runner ihn untersucht.

Client-Middleware

Die Client-Middleware wird einmalig beim Erstellen des Clients kompiliert:

const client = createMCPFusionClient<AppRouter>(transport, {
  middleware: [async (action, args, next) => {
    const started = Date.now();
    const result = await next(action, args);
    metrics.record(action, Date.now() - started, result.isError);
    return result;
  }],
});

Die Signatur lautet (action, args, next) => Promise<ToolResponse>. Verwenden Sie sie für clientseitiges Tracing, Wiederholungen mit einer ausdrücklichen Richtlinie oder zum Hinzufügen eines Korrelations-Headers. Der Server bleibt für Authentifizierung, Validierung und Schwärzung verantwortlich.

Fehleranalyse

Mit throwOnError: false gibt der Client immer ToolResponse zurück. Prüfen Sie isError. Mit true wird eine Antwort mit isError: true zu MCPFusionClientError mit code, recovery, eingefrorenem availableActions, severity und der Rohantwort. Der Client analysiert das frameworkeigene XML <tool_error>, einschließlich älterer, durch Kommas getrennter Aktionslisten.

Externe KI-Clients

Es gibt keine MCP-Fusion-Adapter mit Markenbindung für Modell-Frameworks. Verwenden Sie deren offizielle MCP-Clients:

Das Framework auf dem Server bleibt für den MVA-Presenter, DLP und die Tenant-Grenze verantwortlich. Die Modell-Laufzeit nutzt nur die daraus entstandene MCP-Oberfläche.

Nächste Schritte

• Errors: das XML, das Ihr Client analysiert
• Tool exposition: wie punktierte Aktionen zu Tools werden
• Runtime architecture: wie der Server sie verteilt