Zum Inhalt springen
Für Entwickler · MCP-Broker

Ein MCP-Server.
Alle Ihre Tools.
Governed, nicht durchgereicht.

knotwork brokert Ihre eigenen Downstream-MCP-Server, Tools und API-Provider hinter einem Endpoint. Jeder Tool-Call läuft durch dieselbe Pipeline: Route, Residency, Credential, Freigabe, Audit. Kein transparenter Proxy — ein governter Broker.

Privater Zugang · Onboarding nach Freischaltung
MCP API DB Vault Claude ChatGPT IDE Route Residency Credential Freigabe Audit DE
Die governte Tool-Call-Pipeline

Jeder Aufruf passiert dieselben Gates — kein Bypass.

knotwork ist ein Broker, kein transparenter Proxy. Ein Tool-Call wird nicht durchgereicht, sondern Schritt für Schritt geprüft, bevor er ausgeführt und auditiert wird.

Route Residency Credential Approval Execute Validate Audit
GateWas es prüftDefault
1Route Ist diese Route / dieses Tool für diese Org und diesen User überhaupt freigegeben? default-deny
2Residency Bleiben Personendaten in Deutschland? Nicht-deutsche / unbekannte Verarbeiter werden für Personendaten abgelehnt. DE
3Credential Secrets liegen verschlüsselt im Vault; aufgelöst per Referenz zur Laufzeit — niemals roh im Tool-Argument. vault://
4Freigabe Schreibende Tools sind aktuell protected-locked; die interaktive Freigabe (server→client Elicitation) für sensible Aktionen ist implementiert und wird an einem echten Client gehärtet. risk:high → Elicitation protected-locked
5Audit Jeder schreibende Aufruf schreibt ein Audit-Event in derselben Transaktion — kein Write ohne Spur. Day-1, same Tx
Federation

Default-deny by design.

Downstream-MCP-Server und -Tools sind standardmäßig aus. Sie schalten sie bewusst frei — und selbst dann reicht knotwork niemals Ihr Token weiter.

01Default-deny Routes

Kein Downstream-Tool ist von Haus aus erreichbar. Routen werden pro Org und pro User explizit aktiviert — nicht implizit durchgereicht.

02Kein Caller-Token-Passthrough

Ihr Client-Token endet bei knotwork. Downstream-Aufrufe nutzen die im Vault hinterlegten Credentials — Ihr OAuth-Token wird nie weitergereicht.

03Provenance-Labels

Antworten aus Downstream-Quellen werden mit Herkunft etikettiert, damit das LLM und Sie wissen, woher ein Ergebnis kommt.

04Output-Schema-Validation

Downstream-Ausgaben werden gegen ein Output-Schema validiert, bevor sie an den Client zurückgehen — keine ungeprüften Payloads.

Ehrlich gesagt: Die Plattform-Tools sind live und durch die Pipeline gegated. Die Downstream-Federation (Transport, Provenance, Output-Schema-Enforcement) ist gebaut und wird scharf geschaltet; der interaktive Freigabe-Round-Trip wird gerade an einem echten Client gehärtet.

Vault & Credential-Modell

Ein zentraler, verschlüsselter Ort für Server, Tools und Verbindungen.

Ihre MCP-Server, Tools und API-Verbindungen liegen verschlüsselt im Vault — pro Organisation und pro Nutzer getrennt, hinter Row Level Security.

Per Org & per User getrennt, hinter FORCE RLS

Verbindungen liegen verschlüsselt und sauber pro Organisation und pro Nutzer getrennt — kein geteilter Geheimnis-Topf. Jede mandantenbezogene Anfrage läuft in einer mandantengebundenen Transaktion mit erzwungener Row Level Security.

Auflösung per Referenz, nie im Klartext-Argument

Tools referenzieren Secrets über vault://-Handles statt Roh-Werte; die Entschlüsselung passiert geschützt im Broker. Beim Einrichten geben Sie keine Geheimnisse in offene Formularfelder.

Auch lesende Aufrufe sind gated und auditiert

Connections, Audit-Suche, Records und Insights laufen ebenfalls durch die Pipeline und schreiben ein Audit-Event — Transparenz per Default, nicht nur bei Writes.

Workflow-Composer · live

Workflows aus Primitiven komponieren — jeder wird selbst zum MCP-Tool.

Verketten Sie vorhandene Bausteine zu einem benannten Ablauf — ohne Code, ohne Redeploy. Jeder gespeicherte Workflow wird über denselben Gateway als aufrufbares MCP-Tool bereitgestellt. Das Manifest ist dadurch von 38 auf 46 Tools gewachsen, inklusive eines tools:search Tool Search Tool für Progressive Disclosure.

01Authoring-Meta-Tools

Das Bauen ist selbst ein MCP-Tool-Call: workflows:* Meta-Tools, mit denen jeder LLM-Client (z. B. Claude) Workflows erzeugt — „MCP-Tools, die MCP-Tools bauen". Zustandslos über explizite Draft-Handles, die das Modell über die Calls zurückreicht.

workflows:putworkflows:bindworkflows:validateworkflows:publish

02Visueller Canvas

Ein aufgeräumter Builder im Web: Primitive wählen, Schritte verketten, Outputs auf Inputs binden, I/O deklarieren, benennen — der grafische Weg zur selben Definition.

draft → bind → publish

03Builder-Copilot

Berät („wie baue ich…?") und baut direkt — Human-in-the-Loop: Vorschläge erscheinen als Diff am Canvas und werden erst nach Ihrer Bestätigung übernommen.

advisedirect-buildcanvas-diff

Hybride Ausführung — deterministisch, mit optionalen LLM-Inseln

records.list llm: classify insights.summary connection.notify
deterministische Tool-Schritte · optionale, gekapselte LLM-Schritte · der kritische Pfad bleibt deterministisch

Verified-only, zweischichtiges RAG

Der Composer schlägt nur Bausteine vor, die zuvor verifiziert wurden — veraltete oder ungeprüfte Vorschläge sind ausgeschlossen. Das Retrieval filtert hart auf „verifiziert und nicht veraltet", hinter erzwungener Row Level Security. Jeder Kandidat durchläuft eine mehrstufige Prüfkette bis hin zur Ausführung in einer Sandbox: „verifiziert ⇒ in der Sandbox ausgeführt". Bindings werden immer live aus dem Katalog aufgelöst — das Schema ist die Wahrheit, nie ein eingebettetes.

DE-residente KI-Insel

Reasoning und Embeddings laufen über einen in Deutschland gehosteten KI-Anbieter, fail-closed — eine reine DE-Insel ohne Caller-Token-Passthrough; das Provider-Token kommt verschlüsselt aus dem Vault.

Drei Wege, eine Validierung — kein Gate-Bypass

Ob Meta-Tool, Canvas oder Copilot: alle schreiben dieselbe Definition und durchlaufen denselben Schema- und Build-Time-Typ-Check. Jeder einzelne Schritt eines publizierten Workflows läuft anschließend durch Route, Residency, Credential, Freigabe und Audit — ein Workflow umgeht die Governance nicht, er bündelt sie.

Der Copilot kann keinen ungültigen Workflow ausgeben

Diese Invariante ist in Code und Tests belegt — und durch Verteidigung in der Tiefe: mehrere unabhängige Schichten greifen ineinander (strukturierte Ausgabe, Schema-Prüfung, ein Typ-Check zur Build-Zeit, eine Publish-Validierung sowie das verified-only RAG). Jede Schicht für sich genügt, um einen ungültigen Workflow abzulehnen.

Hinweis: Die genannten Token-Reduktionen durch Progressive Disclosure und Code-Execution sind Best-Case-Werte aus Anthropics MCP-Techniken — keine von knotwork gemessenen Zahlen. Schreibende Tools bleiben weiterhin protected-locked, bis der interaktive Freigabe-Round-Trip an einem echten Client gehärtet ist.

MCP-Konformität

Spec-treu gebaut — Baseline fest, RC vorbereitet.

knotwork spricht MCP nach Spezifikation. Tool-Schemas sind sauberes JSON-Schema, der Transport ist Streamable HTTP, und die kommende RC ist im Design schon mitgedacht.

Baseline-Spec
2025-11-25
SDK exakt gepinnt
offizielles MCP-SDK · exakt versioniert
Transport
Streamable HTTP
Tool-Schemas
JSON-Schema 2020-12 · kein externes $ref
Forward-Design
RC 2026-07-28 · stateless-ready
Nicht-Core-Features
dev.knotwork/* · default-deny
Standards & Quellen

Auf offenen Standards gebaut — nachprüfbar.

knotwork erfindet keine eigenen Protokolle. Die Bausteine sind öffentlich spezifiziert — hier die maßgeblichen Primärquellen zum Nachlesen.

Model Context Protocol
Dynamic Client Registration
JSON Schema 2020-12
DSGVO · Verordnung (EU) 2016/679
Warteliste

Früh dabei sein — Zugang nach Freischaltung.

knotwork ist in einer privaten Phase: Der Zugang läuft noch nicht offen, sondern wird gezielt freigeschaltet. Tragen Sie sich ein, und wir melden uns, sobald Ihr Zugang bereitsteht.

Danke — Ihr E-Mail-Programm öffnet sich mit einer vorbereiteten Nachricht. Bitte abschicken, um sich einzutragen.

Kein Tracking, kein Drittanbieter: Ihre Angabe geht direkt per E-Mail an uns. In Deutschland gehostet, DSGVO.

Freischaltung Automatische Registrierung (DCR) OAuth 2.1 / PKCE Tenant-Resolve Tool-Liste
Bereits erprobt: Der End-to-End-Zugang mit einem echten KI-Client (Claude) ist live durchgespielt — OAuth, Tenant-Resolve, volle Tool-Liste, Connector-Icon.
RLS & Germany-Residency

Mandantentrennung auf DB-Ebene, Personendaten in Deutschland.

Isolation ist nicht optional und nicht nur App-Logik — sie ist in der Datenbank verankert. Personenbezogene Daten der Plattform bleiben in Deutschland.

Mandantengebundene Transaktionen

Jede mandantenbezogene Anfrage setzt den Org-Kontext nur lokal innerhalb der Transaktion — nie session-weit.

ENABLE + FORCE RLS

Jede org-bezogene Tabelle hat Row Level Security mit Policies in der Migration — auch der Tabellen-Owner umgeht sie nicht.

Kein Raw-SQL-Interpolieren

Caller-Werte gehen ausschließlich über parametrisierte Queries — gegen Injection geschützt und in der CI erzwungen.

Germany Residency

Plattform-kontrollierte Personendaten bleiben in Deutschland (Hetzner DE); unbekannte / nicht-deutsche Verarbeiter werden für Personendaten abgelehnt.

Audit Day-1, same Tx

Jeder tenant-Write schreibt sein Audit-Event in derselben Transaktion — Wirkung und Spur sind atomar.

Klartext-Status

Status wie Verbunden oder Freigabe nötig statt roher Maschinen-Codes.

Ehrlich gesagt: Wir behaupten keine „100 % europäische Kette“. Das Runtime-Hosting liegt in Deutschland (Hetzner); einzelne Bausteine außerhalb der EU sind als bewusster Rest-Risiko-Punkt dokumentiert, nicht weggeredet.

FAQ

Vier Fragen, die Entwickler zuerst stellen.

Ist knotwork ein transparenter Proxy?
Nein. knotwork ist ein governter Broker, kein Passthrough. Ein Tool-Call wird nicht einfach weitergereicht, sondern läuft durch Route-, Residency-, Credential-, Freigabe- und Audit-Gates. Downstream-Routen sind default-deny, und Ihr Caller-Token wird nie an Downstream-Server weitergegeben.
Welche MCP-Spec setzt ihr um?
Baseline ist die Spec 2025-11-25 mit dem offiziellen SDK exakt gepinnt, Transport ist Streamable HTTP. Tool-Schemas sind JSON-Schema 2020-12 ohne externes $ref. Die RC 2026-07-28 ist im Design vorbereitet; Nicht-Core-Features laufen als dev.knotwork/*-Extensions, default-deny und mit Graceful Degradation.
Wie werden meine Credentials behandelt?
Secrets liegen verschlüsselt im Vault, getrennt pro Org und pro User, hinter FORCE RLS. Tools referenzieren sie über vault://-Handles statt Roh-Werte; die Auflösung passiert geschützt im Broker. Beim Einrichten geben Sie keine Geheimnisse in offene Formularfelder.
Wie laufen schreibende Tool-Calls?
Schreibende Tools sind aktuell protected-locked. Das Freigabe-Gate ist gebaut: Sensible / schreibende Aktionen sind so ausgelegt, dass sie über eine interaktive Rückfrage (server→client Elicitation) bestätigt werden müssen, bevor sie laufen — und jeder Write schreibt sein Audit-Event in derselben Transaktion. Der interaktive Round-Trip ist implementiert, aber sein End-to-End-Ablauf mit einem echten Client wurde noch nicht durchgespielt; bis er gehärtet ist, bleiben die Write-Tools gesperrt. Die Architektur steht, der Live-Beweis steht noch aus.

Früh dabei sein?

Der Zugang wird gezielt freigeschaltet. Tragen Sie sich ein — wir melden uns, sobald Ihr Zugang bereitsteht.