Client typé

MCP Fusion est utile des deux côtés de la frontière. Le serveur gère le pipeline de sécurité ; le client typé fournit à l’application qui l’appelle un contrat vérifié par le compilateur. Aucun SDK généré et aucune interface d’arguments dupliquée.

Exportez le routeur une seule fois

Sur le serveur, enveloppez les builders dans le registre typé curryfié et exportez son type de routeur inféré :

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

La valeur d’exécution est registry.registry ; _builders et _context sont des champs porteurs de types. InferRouter intersecte les cartes de routeur fantômes accumulées par chaque builder. Modifier un paramètre .withString() modifie donc le contrat de compilation du client sans étape de génération de code.

Exécutez avec le contrat

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

Une action pointée correspond à l’espace de noms filaire : projects.create devient callTool('projects', { ...args, action: 'create' }). Un segment unique passe tel quel. La clé discriminante par défaut est action, configurable avec discriminatorKey.

Lots et proxy

executeBatch(calls) utilise Promise.all et renvoie les résultats dans l’ordre des appels. Passez { sequential: true } lorsque le second appel dépend du premier. Le proxy fluide est un Proxy JavaScript récursif :

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

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

L’inspection de DevTools et la recherche de then de Promise sont protégées. Le proxy ne s’exécute donc pas accidentellement lorsqu’un débogueur ou un exécuteur de tests l’examine.

Middleware client

Le middleware client est compilé une seule fois lors de la création du client :

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

La signature est (action, args, next) => Promise<ToolResponse>. Utilisez-le pour le traçage côté client, les nouvelles tentatives avec une politique explicite ou l’ajout d’un en-tête de corrélation. Le serveur reste responsable de l’authentification, de la validation et de la rédaction.

Analyse des erreurs

Avec throwOnError: false, le client renvoie toujours ToolResponse ; inspectez isError. Avec true, une réponse portant isError: true devient MCPFusionClientError avec code, recovery, availableActions gelé, severity et la réponse brute. Le XML <tool_error> du framework est analysé, y compris les listes d’actions héritées séparées par des virgules.

Clients IA externes

Il n’existe pas d’adaptateurs estampillés MCP Fusion pour les frameworks de modèles. Utilisez leurs clients MCP officiels :

Le framework du serveur reste responsable du Presenter MVA, du DLP et de la limite du tenant. Le runtime du modèle ne consomme que la surface MCP obtenue.

Étapes suivantes

• Errors: le XML analysé par votre client
• Tool exposition: comment les actions pointées deviennent des outils
• Runtime architecture: comment le serveur les distribue