Multi-Tenant-Konnektoren

Mehrere Kunden mit einem Konnektor zu bedienen, ist kein nachträglich aufgesetztes Feature, sondern eine Eigenschaft des Aufbaus von Kontext, Sichtbarkeit und Wahrnehmung. MCP Fusion hat kein Tenancy-Modul, weil die bereits verwendeten Bausteine zusammen ein Muster bilden. Diese Seite zeigt das Rezept.

1. Tenant pro Request auflösen

Jeder Request beginnt mit einem frischen ctx, daher wird der Tenant vor jedem Handler einmal bestimmt:

interface AppContext {
  db: PrismaClient;
  tenantId: string;
  role: 'viewer' | 'admin';
}

registry.attachToServer(server, {
  contextFactory: async (extra) => {
    const claims = await verify(extra.session?.authToken);
    return {
      db: pool.forTenant(claims.tenant_id),
      tenantId: claims.tenant_id,
      role: claims.role,
    };
  },
});

Zwei Regeln machen dies sicher. Die Factory liefert ein frisches Objekt pro Request: Kein Request kann den Kontext eines anderen beobachten. Die Middleware schreibt mit Schutz gegen Prototype Pollution in dieses Objekt, sodass ein bösartiger Argumentname __proto__ nicht erreichen kann. Handler verwenden ctx.db oder ctx.tenantId als einzigen Zugang zu Daten, und die Tenant-ID kommt nie aus Tool-Argumenten.

2. Fähigkeiten nach Tags begrenzen

Tenants erhalten selten dieselbe Oberfläche. Tags und ein Filter entscheiden, was für wen existiert:

const filterFor = (role: string) =>
  role === 'admin'
    ? { anyTag: ['public', 'admin'] }
    : { tags: ['public'], exclude: ['internal'] };

attachToServer(server, { filter: filterFor(ctx.role) });

In dieser Form stellt ein kostenloses Deployment öffentliche Tools bereit, ein Enterprise-Deployment Admin-Tools, und die Handler-Codebasis bleibt identisch. Der Filter wird dort unter dem eigenen Request-Kontext ausgewertet, wo die Toolliste erstellt wird. Siehe Tool exposition.

3. Wahrnehmung nach Rolle formen

Die Sichtbarkeit bestimmt, welche Tools eine Rolle sieht; die Wahrnehmung bestimmt, was diese Tools anzeigen. Das geprüfte Muster sind zwei Tools über einem Handler, ausgewählt durch den Filter aus Schritt 2:

const listPeople = async (input, ctx) => ctx.db.people.findMany();

f.query('people.list_public')
  .describe('List people in the tenant, without contact details')
  .tags('public')
  .returns(ViewerPresenter)          // schema without email or phone
  .handle(listPeople);

f.query('people.list_admin')
  .describe('List people in the tenant with full records')
  .tags('admin')
  .returns(AdminPresenter)
  .handle(listPeople);               // same handler function

Ein Agent mit viewer-Rolle erhält nur people.list_public und sieht niemals Kontaktfelder. Ein Admin-Agent erhält beide Tools mit dem vollständigen Presenter. Feldregeln und Redaction liegen pro Zielgruppe an einer Stelle, und der Vertrags-Digest erfasst beide Oberflächen. Kontextregeln in der Form (data, ctx) => string[] ergänzen rollenabhängige Hinweise. Siehe Models and Presenters.

4. Credentials pro Tenant isolieren

Auch Anbieterschlüssel dürfen nicht zwischen Tenants geteilt werden. Deklarieren Sie sie mit defineCredentials und lesen Sie sie pro Request: Auf Vinkius Cloud injiziert die Runtime die Geheimnisse jedes Käufers pro Request, lokal liest derselbe Accessor Ihre Umgebung. Siehe Credentials.

5. Kosten und Datenverkehr zuordnen

Jeder Aufruf kann zugeordnet werden: Verwenden Sie ctx.tenantId als Rate-Limit-Schlüssel, damit ein Tenant das Budget eines anderen nicht aufbraucht, und geben Sie die Tenant-ID in Audit-Ereignissen und Telemetrie aus. In der Vinkius-Konsole zeigt derselbe Konnektor Kosten und Zuverlässigkeit pro Server, dokumentiert unter AI spend und Tool reliability.

Das Muster in einer Tabelle

Es gibt keinen Runtime-Schalter, den man vergessen könnte, und keinen falsch zu konfigurierenden Tenant-übergreifenden Cache, weil nichts gemeinsam genutzt wird, solange Sie es nicht ausdrücklich teilen. Das unterscheidet einen Multi-Tenant-Konnektor von einem Single-Tenant-Konnektor mit Tenant-Spalte.

Nächste Schritte

• Authentication: Woher die Identität kommt
• Middleware and context: Ableitung und Isolationsmechanik
• Security pipeline: Die Schichten jedes Requests