Eine Zentrale für Agents – Was ist der T-0 MCP Hub?

Wir verbinden Agents mit den richtigen Tools – sicher, nachvollziehbar und ohne Vendor‑Lock‑in. Der T‑0 MCP Hub fungiert als zentrales MCP‑Gateway: ein Tool‑Server, der zwischen Clients (z. B. IDEs, Chat‑UIs, Workflows) und fachlichen Diensten (CMS, Suche, Automatisierung, Files) durch dedizierte MCP-Services vermittelt. So werden Agenten in echten Prozessen handlungsfähig – mit sauberer Autorisierung, klaren Rollen und schlanker Architektur.

Kurzfassung

• Ein zentrales Gateway (MCP Hub) bündelt Tools hinter einer einheitlichen Schnittstelle und macht Agenten in bestehenden Systemen und Services mit API sofort nutzbar.
• Autorisierung und Nachvollziehbarkeit sind integriert: Token‑Scopes, audience‑gebundene JWT Access Tokens und kontextsensitive Policies sichern die Ausführung. Optional gibt es OAuth 2.
• Für KMU bedeutet das: schneller Nutzen statt Großprojekt oder Prototypen – anschlussfähig an vorhandene Konten, Daten und Workflows.
• Es gibt keine Workflows? Dann sollte man jetzt langsam damit anfangen. Unsere MCP Boilerplate und fortschrittliche Computer-use Agents ermöglichen oft auch einfachen Anschluss an Legacy-Systeme.

Warum ein MCP‑Gateway?

Agenten brauchen Zugriff auf viele Dienste – dynamisch, kontextabhängig und über Teamgrenzen hinweg. Klassische App‑Auth (eine App ↔ ein Scope‑Set) skaliert dafür schlecht. Das Model Context Protocol (MCP) definiert einen offenen Standard, wie Clients und Tool‑Server miteinander sprechen. Unser Hub setzt genau hier an: Er wird zum „Drehkreuz“ für Tools und macht Zugriffe kontrollierbar, nachvollziehbar und wiederverwendbar.

Architektur in 60 Sekunden

• Thin‑Wrapper, keine Redundanz: Der Hub übersetzt MCP ↔ HTTP. Business‑Logik lebt in isolierten Containern (z. B. „CMS“, „n8n“, „Google Workspace“, „Slack“, „Notion“, „Github“, „Design Tools“, „Deep Research“ usw.). Updates betreffen Services, nicht das Gateway.
• Drei Betriebswege (rollenbasiert):
  • Admin‑Zugang für interne Nutzung (voller Tool‑Katalog, schnelle Iteration, direkter Zugang zum Code des Hub sowie den Meta-Tools um am Hub zu bauen).
  • Client‑Bridges (z. B. Chat‑UIs) mit Discovery‑Pattern: wenige Meta‑Tools (`list_tools`, `invoke_tool`) halten den Kontext schlank; konkrete Tools werden bei Bedarf aufgerufen.
  • Nutzer=Agenten Zugang mit Scopes: fein granulierte Freigaben je Tool/Operation.
  • Transport über SSE (Server‑Sent Events) für interaktive Sessions; REST‑Routen für Health/Utility.

Die Referenz‑Implementierung „Ghost“ zeigt das Muster: Der Hub‑Wrapper ist eine dünne Proxy‑Schicht (Zod‑validiert), die den Container aufruft; der Container implementiert auf Basis die komplette Fachlogik gegen das Ghost Admin API. Das sorgt für klare Verantwortlichkeiten und saubere Testbarkeit. Publishing‑Policy: Draft‑First – Agenten erzeugen Entwürfe; die Veröffentlichung bleibt ein expliziter Schritt.

MCP Client --(SSE)--> T-0_MCP-Hub (Thin-Wrapper)
                        |
      +-----------------+-------------+--------------+
      |                 |             |              |
      v                 v             v              v
T-0_mcp-ghost     T-0_mcp-exchange  T-0_mcp-web  T-0_mcp-site-editor
   (CMS)             (Queue)       (Web Services)   (Site Editor)

Toolbox

• T-0 Ghost CMS (Posts/Pages): Inhalte listen, anlegen, aktualisieren, veröffentlichen – ideal für redaktionelle Workflows direkt aus Agenten heraus.
• T-0 Filesystem: Sicheres Lesen/Schreiben in definierten Arbeitsbereichen – z. B. Konfigs, Snippets, Exporte. Hat Anbindung an eine vielzahl gängiger Cloudspeicher, sowie unserer Github Repos.
• Exchange (Queue): Repo‑unabhängige Nachrichten‑Brücke zwischen Agenten und UIs (A2A, U2A, A2U, U2U) – z. B. ChatGPT ↔ VS Code; korreliert Nachrichten per Thread‑ID und unterstützt Status/Anhänge.
• Website/Site‑Editor: Orchestriert Erzeugung und Änderung von Seiten wie Homepage oder Landingpage; passt zum Einsatz „Agent schreibt, Mensch prüft“. Bei uns verknüpft mit einem Headless-CMS zur manuellen Bearbeitung von Templates und Partials.
• Web-Services: Testing, Recherchen und Web-Scraping mit kontrolliertem Zugriff und Rückweg in die Toolkette. Hier können bspw. verschiedene ähnliche Services gebündelt werden. Kandidaten: Tavily, Perplexity API für Deep Research, Playwright für Testing usw. - Diese Services können als Subservices containerized werden, oder sind einfache MCP-Clients für 3rd Party APIs in der Cloud.
• n8n Bridge: Komplette n8n Workflows end-to-end bauen und deployen. Flows triggern, Variablen lesen/schreiben, Webhooks – perfekt für vorhandene Automatisierung.

Meta‑Tools (`list_tools`, `invoke_tool`, `search_tool`) gehören zum Standard: Clients entdecken verfügbare Tools selbständig und rufen nur, was im Kontext erlaubt und gewünscht ist. Dadurch bleibt der Kontext kompakt und die Governance zentral.

Zusätzliche Admin-Meta Tools erlauben den Bau am Hub und den Tools selbst. So können bspw. auf Basis von Anthropics Skills Templates, oder dedizierten n8n Agents schnell zusätzliche Werkzeuge gebaut und im Hub registriert werden.

Sicherheit & Autorisierung – pragmatisch und standardnah

Wir setzen auf etablierte OAuth‑2.0‑Flows für Menschen und Agenten – inklusive PKCE für öffentliche Clients. Der Hub vergibt audience‑gebundene JWT Access Tokens (RFC 9068) und prüft sie strikt; Tokens sind auf den jeweiligen Resource‑Server beschränkt. Upstream‑APIs erhalten eigene, getrennte Token – es gibt keinen „Token‑Durchschleif“. Für höhere Absicherung unterstützen wir DPoP (RFC 9449), um Tokens an den Client‑Schlüssel zu binden. Weiterführend: Auth Code Flow und On‑Behalf‑Of‑Flow passen gut zu delegierten Agenten‑Zugriffen.

Wichtig für Interop in größeren Umgebungen: Mit „Protected Resource Metadata“ (RFC 9728) trennen wir sauber zwischen Authorization Server (Tokenfabrik) und Resource Server (MCP‑Server/Tool‑API). Das senkt Kopplung, erlaubt Weiterverwendung vorhandener IdPs und hält die MCP‑Clients schlank. Für breite Client‑Ökosysteme stehen Muster wie Dynamic Client Registration bzw. URL‑basierte Client‑IDs zur Verfügung – ohne dass jeder Client vorab manuell registriert werden muss. Hier arbeiten wir gerade an einem zusätzlichen Client-Management Service, der bspw. via Agent via CLI, oder auch über eine dedizierte, authentifizierte Benutzeroberfläche komfortabel angesprochen werden kann.

Zugriffssteuerung geschieht per Zugriffstokens, oft sogar kontextsensitiv:

• Scopes pro Tool/Operation (z. B. `hub:invoke:ghost`, `exchange:read`, `exchange:write`).
• Policies als Code (z. B. „Agent A darf Tool X niemals destruktiv nutzen“, „für Operation Y ist pro Thread expliziter Consent nötig“).
• Tracing/Audit: Der Gateway‑Pfad konsolidiert Ereignisse, sodass Prüfungen und Rückfragen nicht im Agentengeflecht verloren gehen.

Hinweise zur Spezifikation und Best Practices:

• JWT Access Tokens (RFC 9068) – interoperabler Standard für signierte Access Tokens.
• Protected Resource Metadata (RFC 9728) – Entkopplung von AS und RS, bessere Discovery.
• DPoP (RFC 9449) – Proof‑of‑Possession gegen reine Bearer‑Token‑Risiken.
• MCP Security Guidance – audience‑gebundene Tokens; keine Token‑Weitergabe an Upstream‑APIs.

Policy‑as‑Code – kurz & konkret:

# Pseudopolicy

deny when 
    tool == "ghost_delete_post" 
    and actor.role != "admin"

require_consent when 
    tool matches "hub:invoke:*" 
    and action == "write" 
    and thread.risk == "high"

limit when 
    tool == "exchange_send" 
    and rate.gt(60/min) 
    and actor.tier == "basic"

So lassen sich einfache Regeln – verbieten, zustimmungspflichtig, begrenzen – maschinenlesbar durchsetzen, ohne den Flow mit Pop‑ups zu überfrachten, oder Subagents zur Aufgabe zu zwingen.

Vergleich: Amazon Bedrock AgentCore Gateway vs. T‑0 MCP Hub

Erst im August hat AWS soetwas auf Enterprise-Ebene angekündigt. Es steht bisher nur ausgewählten Kunden im Experimentalbetrieb zu hohen Kosten und mit großem Anpassungsaufwand zur Verfügung.

Das T-0 Hub und Bedrocks Agentcore Ansätze verfolgen dabei ein sehr ähnliches Modell: ein zentraler Tool‑Server mit standardisierter Schnittstelle für Agent‑↔‑Tool‑Kommunikation + Authentifizierung. Amazon positioniert AgentCore Gateway als vollständig gemanagten, permanenten Enterprise‑Dienst mit Bausteinen wie Security Guard, Translation/Composition und semantischer Tool‑Auswahl für Agents und Users.

Unser Ansatz bei T‑0 ist komplementär und bleibt bewusst leichtgewichtig:

• Offen & selbst‑hostbar: MCP‑Standard, eigenständige, wartbare Container für jeden Service (1rst & 3rd Party!), klare HTTP‑Schnittstellen.
• Anschluss an bestehende Konten: OAuth‑Flows und Vault‑gestützte Secret‑Verwaltung; kein Zwang zu einer Cloud.
• Fokus KMU/Teams: schnell produktiv, gezielt ausbaubar; wir wrappen auch spezifische Dienste inklusive Client zu Ende‑zu‑Ende‑Services oder sogar zu simpelsten Workflows.
• Architektursauberkeit: Thin‑Wrapper‑Prinzip, keine doppelte Logik, einfache Wartbarkeit. Externe Services werden klar von Onboard- und Meta-Tools getrennt.

Wo liegen die Unterschiede in der Praxis? Bedrock adressiert großflächige Enterprise‑Governance und Tiefenintegration in AWS. Der T‑0 Hub ist ein präzises Werkzeugkasten‑Gateway, das sich an vorhandene Systeme (on‑prem, Cloud‑Mix) andockt und in Tagen bis Wochen messbaren Mehrwert liefert – ohne späteres Umpflanzen, mit voller Souveränität über die eigene

Alternativen/Ergänzungen im Ökosystem: API‑Gateways wie Kong (OIDC/OAuth2, Ratenbegrenzung, Transformations‑Plugins) eignen sich als Edge‑Layer vor dem MCP Hub. Agent/Tool‑SDKs wie das Volcano SDK können die Agenten‑Seite beschleunigen. Unser Ziel bleibt systemagnostisch: Wir empfehlen die Bausteine, die zur Organisation passen – der Hub bietet optional einen gemeinsamen, sicheren Zugangspunkt für Nutzer:innen, Agenten und Workflows.

Delegation auf Thread‑Ebene – was Agenten wirklich brauchen

Damit Agenten autonom wirken können, müssen Verantwortlichkeiten entlang eines „Threads“ delegierbar sein: mal handelt ein Agent „als User“, mal „als Agent für Agent“. Entscheidend ist, dass der laufende Haupt‑Agent und seine Sub-Agenten kontextbezogen nachweisen können, welche Rechte sie gerade benötigen und in wessen Auftrag sie genutzt werden. Dieses Prinzip bilden wir im Hub MCP Gateway über Scopes, Policies und Thread‑Kontext ab – maschinenlesbar, auditierbar und ohne menschliche Abnicker bei jedem Schritt. Die Basis bildet hier ein Vertrag - oder vereinfacht gesagt eine Freigabe - bei der jeweiligen Auftragsvergabe.

Ob man die Regeln als Policy‑as‑Code modelliert oder als Contracts (bis hin zu kryptographischen Nachweisen in Smart Contracts) – das Ziel ist identisch: Autorisierung wird zu einem kontinuierlichen Prozess, nicht zu einem einmaligen Dialog. So entstehen Agentennetze, die verantwortungsvoll und zielgerichtet handeln können, ohne Menschen mit Pop‑ups und Agents mit Hold-ups zu überfrachten. Damit kann die Nutzerinteraktion selbst bei komplexen agentischen Abläufen minimiert werden und das Ergebnis (bzw. der Weg zum Ergebnis) bleibt trotzdem nachvollziehbar.

Was bringt das konkret für KMU?

• Schnellstart statt Plattformwechsel: Wir binden existierende Tools und Konten ein und liefern sofort nutzbare Agent‑Funktionen. On Premise, in der Firmen-Cloud, oder DSGVO-Konform bei T-0 in der Service-Cloud gehostet.
• Sicherheit ohne Hürden: Standard‑Auth (OAuth2, JWT), konsolidierte Audit‑Spur, klare Trennung von Rollen, On-Demand Reporting.
• Schrittweise Erweiterung: Vom Blog‑Post aus dem Agent bis zum orchestrierten Mehrsystem‑Flow – alles über dasselbe Gateway.
• Systemagnostisch: Kann mit jeder Art von MCP Service zusammenarbeiten und unterstützt dabei neue MCP Services zu bauen.
• Zukunftsfest: Offene Protokolle, austauschbare Dienste, keine Sackgassen.
• Klein anfangen: Los gehen kann es mit einem simplen n8n Workflow, der samt n8n Instanz im Hub gewrapped wird. Das erste Werkzeug enthält damit gleich alle nötigen Schnittstellen und Meta-Tools, um weitere Werkzeuge anzubinden und zu nutzen, oder sogar zu bauen.

Meta‑Tools wie `list_tools` und `invoke_tool` halten die Zahl registrierter Schemas im Kontext des ausführenden Agent-Threads klein. Der Client lädt nur die Meta‑Schemas; konkrete Tool‑Schemas werden erst bei Bedarf gezogen. Das spart Kontext, reduziert Fehlerrisiken und bleibt dennoch transparent – ideal für Chat‑UIs und komplexe Agents.

Scopes – einfache Beispiele

# Exchange Permissions
exchange:read      # Nachrichten lesen, keine Zustellung
exchange:write     # Nachrichten senden (Rate Limits greifen)
hub:invoke:ghost   # Ghost-Tools via invoke nutzen 
                   # (CRUD & Publish je Tool policy-gesteuert)

Praxisbeispiele

A) Blog-Editor-Agents

Wir möchten einen Agent Scopen, der zwar Blogbeiträge verfassen, aber nicht publishen darf. Am Writer-Agent könnte dann bspw. ein Review-Agent hängen, der den Post anhand von spezifischen Guardrails und Vorgaben überprüft und erst nach iterativem Austausch mit dem Writer-Agent an einen Human-Editor übergibt. Über einen so gescopten Feedback-Loop zwischen Agents wird dem Editor langes hin-und-her kopieren zwischen Chat und Text-Editor, oder das iterieren mit Chat-Tools, erspart. Die Arbeitsgrundlage (der von der KI-erstellte Artikel) für den Human-Editor ist deutlich fundierter, orientiert sich an Best-Practices des Authors (bspw. vorangegangenen Posts dessen Users) und kann im Zweifel dann aus dem Tool des Human-Editors direkt gepublished werden. Hierbei ist agnostisch, in welcher Benutzeroberfläche sich der menschliche Nutzer, der den Auftrag (oder die Freigabe) erteilt, befindet.

B) Brand Sprint Agents

Ich werde bei Gelegenheit hier noch weitere Beispiele für im Hub-gewrappte Services ergänzen.

Weiterführende Quellen

• Model Context Protocol – Spezifikation: https://spec.modelcontextprotocol.io/
• RFC 9068 – JWT Access Tokens: https://datatracker.ietf.org/doc/rfc9068/
• RFC 9728 – OAuth 2.0 Protected Resource Metadata: https://datatracker.ietf.org/doc/rfc9728/
• RFC 9449 – OAuth 2.0 DPoP: https://oauth.net/2/dpop/
• „Let’s fix OAuth in MCP“ (Aaron Parecki): https://aaronparecki.com/2025/04/03/15/oauth-for-model-context-protocol
• „OAuth for MCP“ (GitGuardian): https://blog.gitguardian.com/oauth-for-mcp-emerging-enterprise-patterns-for-agent-authorization/
• Amazon Bedrock AgentCore Gateway (Blog): https://aws.amazon.com/de/blogs/machine-learning/introducing-amazon-bedrock-agentcore-gateway-transforming-enterprise-ai-agent-tool-development/ -
• T‑0 MCP Hub Repository (unveröffentlicht)

Lust auf einen Deep Dive?

Wir planen vertiefende Artikel zu Auth‑Flows, Policies/Contracts und konkreten Tool‑Wrappings (Ghost, n8n, Suche), sowie ein Whitepaper rund ums Meta-Tooling. Wenn Du jetzt schon eine Idee hast, die wir zusammen produktionsreif machen sollen: Erstgespräch anfragen und wir bringen bald Deine Agents ins Arbeiten.

Agentische KI für produktive Systeme mit dem Menschen im Zentrum · Made in Germany von T-0