de en ja ko ru zh

Tunnel Manager

Name: Tunnel Manager
Author: Knuckles-Team

by Knuckles-Team

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

Tunnel Manager

CLI oder API | MCP | Agent

PyPI - Version MCP Server PyPI - Downloads GitHub Repo stars GitHub forks GitHub contributors PyPI - License GitHub GitHub last commit (by committer) GitHub pull requests GitHub closed pull requests GitHub issues GitHub top language GitHub language count GitHub repo size GitHub repo file count (file type) PyPI - Wheel PyPI - Implementation

Version: 3.1.0

Dokumentation — Installation, Bereitstellung, Nutzung über die API, CLI und MCP sowie Agent-Schnittstellen werden in der offiziellen Dokumentation gepflegt.

Related MCP server: mcp-ssh

Überblick

Tunnel Manager ist ein produktionsreifer Agent- und Model Context Protocol (MCP)-Server, der direkt mit Create SSH Tunnels zu Ihren Remote-Hosts interagiert und als MCP-Server für Agentic AI fungiert!.

Hauptfunktionen

Konsolidierte aktionsgesteuerte MCP-Tools: Minimiert Token-Overhead und eliminiert Tool-Aufblähung in LLM-Kontexten, indem Methoden in optimierte, umschaltbare Tool-Module gruppiert werden.
Unternehmensgerechte Sicherheit: Umfassende Unterstützung für Eunomia-Richtlinien, OIDC-Token-Delegation und granulare Ausführungskontextverfolgung.
Integrierter Graph-Agent: Eingebauter Pydantic-AI-Agent, der das Agent Control Protocol (ACP) und standardmäßige Web-Schnittstellen (AG-UI) unterstützt.
Native Telemetrie & Tracing: Out-of-the-box OpenTelemetry-Exporte und natives Langfuse-Tracing.

CLI oder API

Dieser Agent kapselt die Create SSH Tunnels zu Ihren Remote-Hosts und hostet als MCP-Server für Agentic AI! API. Sie können programmatisch oder über die integrierten Ausführungs-Einstiegspunkte mit ihm interagieren.

Detaillierte Anweisungen zur Verwendung der zugrunde liegenden API-Wrapper, erweiterten Schema-Bindungen und Entwickler-SDK-Referenzen finden Sie in docs/index.md.

MCP

Dieser Server verwendet dynamische aktionsgesteuerte Tools, um den Token-Overhead zu optimieren und die IDE-Kompatibilität zu maximieren.

Verfügbare MCP-Tools

Automatisch vom Live-MCP-Server generiert — nicht von Hand bearbeiten.

Kondensierte aktionsgesteuerte Tools (`MCP_TOOL_MODE=condensed`)

MCP-Tool	Env-Var zum Umschalten	Beschreibung
`tm_files`	`FILETOOL`	Erweiterte Dateioperationen auf Remote-Hosts.
`tm_hosts`	`HOSTTOOL`	Verwaltung des lokalen Host-Alias-Inventars.
`tm_inventory`	`INVENTORYTOOL`	Massen-Inventaroperationen gegen YAML-Hostgruppen.
`tm_operations`	`OPERATIONSTOOL`	Betriebslebenszyklus- und Sitzungsverwaltung.
`tm_remote`	`REMOTETOOL`	SSH-Operationen für einzelne Hosts mit gemeinsamen Verbindungsparametern.
`tm_security`	`SECURITYTOOL`	Sicherheitsscans und Compliance.
`tm_system`	`SYSTEMTOOL`	Remote-Systeminformationen über SSH.
`tunnel_ingest_hosts`	`INGESTTOOL`	Listet das verwaltete SSH-Inventar auf und schiebt es in den epistemischen Graph-KG.

Ausführliche 1:1-API-zugeordnete Tools (`MCP_TOOL_MODE=verbose` oder `both`)

MCP-Tool	Env-Var zum Umschalten	Beschreibung
`tunnel_manager_add_host`	`HOST_MANAGERTOOL`	Ruft die add_host-Operation auf.
`tunnel_manager_get_host`	`HOST_MANAGERTOOL`	Ruft eine Host-Konfiguration per Alias ab und verweigert einen Alias, auf den der Aufrufer keinen Anspruch hat.
`tunnel_manager_list_hosts`	`HOST_MANAGERTOOL`	Listet die Host-Aliasse auf, auf die der AUFRUFER Anspruch hat, mit redigierten Geheimnissen.
`tunnel_manager_load_inventory`	`HOST_MANAGERTOOL`	Ruft die load_inventory-Operation auf.
`tunnel_manager_remove_host`	`HOST_MANAGERTOOL`	Ruft die remove_host-Operation auf.
`tunnel_manager_save_inventory`	`HOST_MANAGERTOOL`	Ruft die save_inventory-Operation auf.

8 aktionsgesteuerte(s) Tool(s) · 6 ausführliche 1:1-Tool(s). Jedes ist aktiviert, es sei denn, sein <DOMAIN>TOOL-Schalter ist auf false gesetzt; MCP_TOOL_MODE wählt die Oberfläche (**intent Standard* — die sechs Verb-Tools, granulare Menge bei Bedarf geladen · condensed aktionsgesteuert · verbose 1:1 · both). Automatisch generiert — nicht bearbeiten.*

Detaillierte Tool-Schemas, Parameterformen und Validierungsbeschränkungen sind in docs/usage.md erhalten.

Dynamische Tool-Auswahl und Sichtbarkeit

Dieser MCP-Server unterstützt die dynamische Auswahl des Toolsets und die Sichtbarkeitsfilterung zur Laufzeit. Dadurch können Sie die Menge der verfügbaren Tools einschränken, um eine Aufblähung des LLM-Kontextfensters zu verhindern.

Sie können die Tool-Filterung über mehrere Eingabekanäle konfigurieren:

CLI-Argumente: Übergeben Sie --tools oder --toolsets (oder deren deaktivierte Gegenstücke --disabled-tools und --disabled-toolsets) beim Start.
Umgebungsvariablen: Definieren Sie standardmäßige Umgebungsvariablen:
- MCP_ENABLED_TOOLS / MCP_DISABLED_TOOLS
- MCP_ENABLED_TAGS / MCP_DISABLED_TAGS
HTTP-SSE-Anfrageheader: Übergeben Sie benutzerdefinierte Header während der Transportinitialisierung:
- x-mcp-enabled-tools / x-mcp-disabled-tools
- x-mcp-enabled-tags / x-mcp-disabled-tags
HTTP-SSE-Anfrageabfrageparameter: Fügen Sie Abfrageparameter direkt an Ihre Transportverbindungs-URL an:
- ?tools=tool1,tool2
- ?tags=tag1

Wenn Abfragezeichenfolgen oder -parameter bereitgestellt werden, gleicht eine LLM-freie Knowledge-Graph-Auflösungsschicht (unter Verwendung von DynamicToolOrchestrator) Abfrageabsichten mit bekannten Tool-Tags, -Namen oder -Beschreibungen ab, mit sicherem Fallback und automatischer 24-Stunden-Hintergrund-Cache-Aktualisierung.

MCP-Konfigurationsbeispiele

Installieren Sie das verbindungsorientierte [mcp]-Extra. Beispiele verwenden tunnel-manager[mcp], um FastMCP / FastAPI über agent-utilities[mcp] hinzuzufügen; der erforderliche Agent-Utilities-Kern trägt weiterhin epistemic-graph[full]. Das [agent-runtime]-Extra aktiviert zusätzlich die Modellorchestrierung.

stdio-Transport (lokale IDEs — Cursor, Claude Desktop, VS Code)

{
  "mcpServers": {
    "tunnel-manager-mcp": {
      "command": "uvx",
      "args": [
        "--from",
        "tunnel-manager[mcp]",
        "tunnel-manager-mcp"
      ],
      "env": {
        "MCP_TOOL_MODE": "intent",
        "FILETOOL": "True",
        "HOSTTOOL": "True",
        "INGESTTOOL": "True",
        "INVENTORYTOOL": "True",
        "OPERATIONSTOOL": "True",
        "REMOTETOOL": "True",
        "SECURITYTOOL": "True",
        "SYSTEMTOOL": "True",
        "TUNNEL_IDENTITY_FILE": "~/.ssh/id_ed25519",
        "TUNNEL_INVENTORY_GROUP": "all",
        "TUNNEL_KG_INGEST": "true",
        "TUNNEL_KNOWN_HOSTS": "~/.ssh/known_hosts",
        "TUNNEL_MANAGER_HEALTH_AGGREGATE_S": "3600",
        "TUNNEL_MANAGER_HEALTH_INGEST": "true",
        "TUNNEL_MANAGER_HOSTS": "r510,r710,r820,rw710",
        "TUNNEL_MAX_THREADS": "6",
        "TUNNEL_PARALLEL": "False",
        "TUNNEL_REMOTE_PORT": "22"
      }
    }
  }
}

Laufzeitreferenzen erfordern einen alias-bewussten Launcher wie GraphOS. Andere Launcher müssen diese Einträge weglassen und die aufgelösten Werte über ihre eigene Laufzeit-Geheimnisgrenze injizieren.

Streamable-HTTP-Transport (vernetzt / Produktion)

{
  "mcpServers": {
    "tunnel-manager-mcp": {
      "command": "uvx",
      "args": [
        "--from",
        "tunnel-manager[mcp]",
        "tunnel-manager-mcp",
        "--transport",
        "streamable-http",
        "--port",
        "8000"
      ],
      "env": {
        "TRANSPORT": "streamable-http",
        "HOST": "127.0.0.1",
        "PORT": "8000",
        "MCP_TOOL_MODE": "intent",
        "FILETOOL": "True",
        "HOSTTOOL": "True",
        "INGESTTOOL": "True",
        "INVENTORYTOOL": "True",
        "OPERATIONSTOOL": "True",
        "REMOTETOOL": "True",
        "SECURITYTOOL": "True",
        "SYSTEMTOOL": "True",
        "TUNNEL_IDENTITY_FILE": "~/.ssh/id_ed25519",
        "TUNNEL_INVENTORY_GROUP": "all",
        "TUNNEL_KG_INGEST": "true",
        "TUNNEL_KNOWN_HOSTS": "~/.ssh/known_hosts",
        "TUNNEL_MANAGER_HEALTH_AGGREGATE_S": "3600",
        "TUNNEL_MANAGER_HEALTH_INGEST": "true",
        "TUNNEL_MANAGER_HOSTS": "r510,r710,r820,rw710",
        "TUNNEL_MAX_THREADS": "6",
        "TUNNEL_PARALLEL": "False",
        "TUNNEL_REMOTE_PORT": "22"
      }
    }
  }
}

Alternativ können Sie eine Verbindung zu einer bereits bereitgestellten Streamable-HTTP-Instanz per url herstellen:

{
  "mcpServers": {
    "tunnel-manager-mcp": {
      "url": "http://localhost:8000/tunnel-manager-mcp/mcp"
    }
  }
}

Führen Sie ein überprüftes Container-Image als stdio-Kind mit geringsten Rechten aus (kein Listener oder veröffentlichter Port):

docker run -i --rm \
  --read-only \
  --cap-drop=ALL \
  --security-opt=no-new-privileges \
  --pids-limit=256 \
  --tmpfs /tmp:rw,noexec,nosuid,nodev,size=64m \
  -e TRANSPORT=stdio \
  -e MCP_TOOL_MODE=intent \
  -e FILETOOL=True \
  -e HOSTTOOL=True \
  -e INGESTTOOL=True \
  -e INVENTORYTOOL=True \
  -e OPERATIONSTOOL=True \
  -e REMOTETOOL=True \
  -e SECURITYTOOL=True \
  -e SYSTEMTOOL=True \
  -e TUNNEL_IDENTITY_FILE=~/.ssh/id_ed25519 \
  -e TUNNEL_INVENTORY_GROUP=all \
  -e TUNNEL_KG_INGEST=true \
  -e TUNNEL_KNOWN_HOSTS=~/.ssh/known_hosts \
  -e TUNNEL_MANAGER_HEALTH_AGGREGATE_S=3600 \
  -e TUNNEL_MANAGER_HEALTH_INGEST=true \
  -e TUNNEL_MANAGER_HOSTS=r510,r710,r820,rw710 \
  -e TUNNEL_MAX_THREADS=6 \
  -e TUNNEL_PARALLEL=False \
  -e TUNNEL_REMOTE_PORT=22 \
  registry.example.invalid/tunnel-manager@sha256:<digest> tunnel-manager-mcp

Für containerisiertes Netzwerk-HTTP stellen Sie einen authentifizierten TLS-Ingress (oder direkten Server-TLS), exakte MCP_ALLOWED_HOSTS und eine exakte Trusted-Proxy-CIDR-Richtlinie über das vom Betreiber verwaltete Bereitstellungsprofil bereit. Der Generator gibt keinen nicht authentifizierten Nicht-Loopback-Listener aus.

Automatisch aus der codegelesenen Env-Oberfläche (MCP_TOOL_MODE + Paketvariablen) generiert — nicht bearbeiten.

Zusätzliche Bereitstellungsoptionen

tunnel-manager kann als lokaler stdio-Prozess oder Container oder hinter einer entfernten Netzwerkgrenze ausgeführt werden. Der Bereitstellungsleitfaden enthält den detaillierten Transportvertrag.

Lokaler Container — starten Sie ein überprüftes unveränderliches Image als stdio-Kind mit geringsten Rechten, ohne Listener oder veröffentlichten Port.
Remote-URL — verbinden Sie sich über einen vom Betreiber bereitgestellten authentifizierten HTTPS-Ingress. Bewahren Sie dessen URL, ausgehende Identitätsreferenzen, Vertrauensprofil und exakte MCP_ALLOWED_HOSTS in AgentConfig auf.

Inventar

tunnel-manager arbeitet mit einem einzigen gemeinsamen YAML-Inventar, das kurze Host- Aliasse (z. B. edge-node) ihren SSH-Verbindungsdetails zuordnet. Jede Ökosystemoberfläche liest dieselbe Datei — die HostManager-API, die tunnel-manager-CLI, den MCP-Server, container-manager-mcp (seine cm_*-Host-Aliasse) und die ssh-bootstrap-Fähigkeit — so definieren Sie Ihre Flotte einmal.

Speicherort — ~/.config/agent-utilities/inventory.yml (.yml bevorzugt). Eine ältere inventory.yaml am selben Pfad wird weiterhin gelesen, wenn keine .yml vorhanden ist, sodass bestehende Installationen weiter funktionieren. Überschreiben mit TUNNEL_INVENTORY.

Verwalten Sie es mit dem Unterbefehl inventory:

tunnel-manager inventory init     # write a commented inventory.yml template (--force to overwrite)
tunnel-manager inventory doctor   # validate hosts/groups; --fix migrates legacy .yaml -> .yml
tunnel-manager inventory show     # print the resolved path + host/group summary

Das vollständige Schema, jedes Host-Feld, die Kopier-Einfüge-Vorlage und Überschreibungsoptionen finden Sie im Inventar-Leitfaden.

Umgebungsvariablen

Paket-Umgebungsvariablen

Variable	Beispiel	Beschreibung
`HOST`	`127.0.0.1`
`PORT`	`8000`
`TRANSPORT`	`stdio`	Optionen: stdio, streamable-http, sse
`ENABLE_OTEL`	`True`
`OTEL_EXPORTER_OTLP_ENDPOINT`	`http://localhost:8080/api/public/otel`
`OTEL_EXPORTER_OTLP_PUBLIC_KEY`	secret-injected
`OTEL_EXPORTER_OTLP_SECRET_KEY`	secret-injected
`OTEL_EXPORTER_OTLP_PROTOCOL`	`http/protobuf`
`EUNOMIA_TYPE`	`none`	Optionen: none, embedded, remote
`EUNOMIA_POLICY_FILE`	`mcp_policies.json`
`EUNOMIA_REMOTE_URL`	`http://eunomia-server:8000`
`TUNNEL_IDENTITY_FILE`	`~/.ssh/id_ed25519`
`DEBUG`	`False`
`PYTHONUNBUFFERED`	`1`
`TUNNEL_REMOTE_HOST`	—	Standard-Remote-Host (z. B. 198.51.100.10)
`TUNNEL_REMOTE_PORT`	`22`	Standard-SSH-Port
`TUNNEL_USERNAME`	—	Standard-SSH-Benutzername
`TUNNEL_PASSWORD_REF`	—	`env://`-, `vault://`-, `secret://`- oder `sqlite://`-Referenz
`TUNNEL_KNOWN_HOSTS`	`~/.ssh/known_hosts`	Unabhängig verifizierte Server-Host-Keys
`TUNNEL_CERTIFICATE`	—	Pfad zu einer SSH-Zertifikatsdatei
`TUNNEL_PROXY_COMMAND`	—	SSH-ProxyCommand für Jump-Host/Bastion-Verbindungen
`TUNNEL_INVENTORY`	—	Pfad zur Inventardatei (Standard: XDG-Konfigurationspfad)
`TUNNEL_INVENTORY_GROUP`	`all`	Ziel-Hostgruppe des Inventars
`TUNNEL_PARALLEL`	`False`	Host-Operationen parallel ausführen
`TUNNEL_MAX_THREADS`	`6`	Maximale Worker-Threads, wenn TUNNEL_PARALLEL=True
`TUNNEL_MAX_COMMAND_CHARS`	`65536`
`TUNNEL_MAX_OUTPUT_BYTES`	`1048576`
`TUNNEL_MAX_TRANSFER_BYTES`	`268435456`
`TUNNEL_MAX_FLEET_HOSTS`	`1000`
`TUNNEL_MAX_CONCURRENCY`	`64`
`XDG_CONFIG_HOME`	—	Basis-Konfigurationsverzeichnis (Standard: ~/.config) für die Inventarauflösung
`HOSTTOOL`	`True`	Gruppierte kondensierte Oberflächen-Umschalter, einer pro register__tools-Registrar.
`REMOTETOOL`	`True`
`INVENTORYTOOL`	`True`
`OPERATIONSTOOL`	`True`
`SYSTEMTOOL`	`True`
`FILETOOL`	`True`
`SECURITYTOOL`	`True`
`INGESTTOOL`	`True`	KG-Ingest-Tools (SSH-Inventar in den epistemischen Graphen auflisten)
`TUNNEL_KG_INGEST`	`true`	Standardmäßig aktivierter Best-Effort-Inventar-Ingest bei `list`
`TUNNEL_MANAGER_HEALTH_INGEST`	`true`	Standardmäßig aktivierte Best-Effort-Netzwerksignal-Trend-Erfassung
`TUNNEL_MANAGER_HEALTH_AGGREGATE_S`	`3600`	Fenster (s), über das Stichproben zu EINEM :HealthTrend-Knoten/Host/Signal destilliert werden
`TUNNEL_MANAGER_HOSTS`	`r510,r710,r820,rw710`	Durch Kommas getrennte Inventar-Aliasse, die überprüft/abgeleitet werden sollen (Standard: vollständiges Inventar)
`TUNNEL_MANAGER_HEALTH_NOTIFY_URL`	—	Best-Effort-Webhook für Netzwerkanomalie-Benachrichtigungen

Geerbte Agent-Utilities-Variablen (gelten für jeden Connector)

Variable	Beispiel	Beschreibung
`MCP_TOOL_MODE`	`intent`	Tool-Oberfläche: `intent` \| `condensed` \| `verbose` \| `both`
`MCP_ENABLED_TOOLS`	—	Durch Kommas getrennte Tool-Allow-Liste
`MCP_DISABLED_TOOLS`	—	Durch Kommas getrennte Tool-Deny-Liste
`MCP_ENABLED_TAGS`	—	Durch Kommas getrennte Tag-Allow-Liste
`MCP_DISABLED_TAGS`	—	Durch Kommas getrennte Tag-Deny-Liste
`MCP_CLIENT_AUTH`	—	Ausgehende MCP-Kind-Authentifizierung: `oidc-client-credentials` \| `basic` \| `none`
`OIDC_CLIENT_ID`	—	OIDC-Client-ID (Servicekonto-Authentifizierung)
`OIDC_CLIENT_SECRET_REF`	`secret://identity/oidc-client-secret`	Laufzeit-Geheimnisreferenz für das OIDC-Servicekonto
`MCP_BASIC_AUTH_USERNAME`	—	HTTP-Basic-Benutzername (`MCP_CLIENT_AUTH=basic`)
`MCP_BASIC_AUTH_PASSWORD_REF`	`secret://identity/mcp-basic-password`	Laufzeit-Geheimnisreferenz für HTTP-Basic-Authentifizierung (`MCP_CLIENT_AUTH=basic`)
`MCP_URL`	`http://localhost:8000/mcp`	URL des MCP-Servers, mit dem der Agent verbindet
`PROVIDER`	`openai`	LLM-Anbieter für den Agenten
`MODEL_ID`	`gpt-4o`	Modell-ID für den Agenten
`ENABLE_WEB_UI`	`True`	AG-UI-Weboberfläche bereitstellen

44 Paket- + 14 geerbte Variable(n). Automatisch generiert aus .env.example + dem gemeinsamen Agent-Utilities-Satz — nicht bearbeiten.

Jede Variable, die der Server liest, nach Zweck gruppiert. Siehe .env.example für einen Copy-Paste-Ausgangspunkt.

SSH-Verbindung & Anmeldedaten

Variable	Beschreibung	Standard
`TUNNEL_IDENTITY_FILE`	Pfad zum SSH-privaten Schlüssel	`~/.ssh/id_ed25519`
`TUNNEL_USERNAME`	SSH-Benutzername	—
`TUNNEL_PASSWORD_REF`	`env://`-, `vault://`-, `secret://`- oder `sqlite://`-SSH-Passwortreferenz	—
`TUNNEL_KNOWN_HOSTS`	Unabhängig verifizierter SSH-Server-Key-Trust-Store	`~/.ssh/known_hosts`
`TUNNEL_CERTIFICATE`	Pfad zu einem SSH-Zertifikat	—
`TUNNEL_REMOTE_HOST`	Standard-Remote-Host	—
`TUNNEL_REMOTE_PORT`	Standard-Remote-SSH-Port	`22`
`TUNNEL_PROXY_COMMAND`	SSH-`ProxyCommand` für Jump-Hosts	—

Inventar & Parallelität

Variable	Beschreibung	Standard
`TUNNEL_INVENTORY`	Pfad zum gemeinsamen Inventar (`.yml` bevorzugt, `.yaml` als Fallback)	`~/.config/agent-utilities/inventory.yml`
`TUNNEL_INVENTORY_GROUP`	Standard-Inventar-Hostgruppe	—
`TUNNEL_PARALLEL`	Parallele Ausführung von Massenvorgängen	—
`TUNNEL_MAX_THREADS`	Maximale Anzahl gleichzeitiger SSH-Arbeiterthreads	—
`XDG_CONFIG_HOME`	Basisverzeichnis für die Auflösung des Inventars	`~/.config`

MCP-Server / Transport

Variable	Beschreibung	Standard
`TRANSPORT`	`stdio`, `streamable-http` oder `sse`	`stdio`
`HOST`	Bind-Adresse (HTTP-Transporte)	`127.0.0.1`
`PORT`	Bind-Port (HTTP-Transporte)	`8000`
`MCP_TOOL_MODE`	Werkzeugoberfläche: `condensed`, `verbose` oder `both`	`condensed`
`MCP_ENABLED_TOOLS` / `MCP_DISABLED_TOOLS`	Kommagetrennte Werkzeug-Zulassungs-/Sperrliste	—
`MCP_ENABLED_TAGS` / `MCP_DISABLED_TAGS`	Kommagetrennte Tag-Zulassungs-/Sperrliste	—
`DEBUG`	Ausführliche Protokollierung	`False`
`PYTHONUNBUFFERED`	Ungepufferte Standardausgabe (für Container empfohlen)	`1`

Werkzeugumschalter

Jedes aktionsgesteuerte Werkzeug kann einzeln über seine Umschalt-Umgebungsvariable deaktiviert werden (auf false setzen). Die vollständige Liste finden Sie in der Tabelle Verfügbare MCP-Werkzeuge oben (HOSTTOOL, REMOTETOOL, INVENTORYTOOL, OPERATIONSTOOL, SYSTEMTOOL, FILETOOL, SECURITYTOOL).

Telemetrie & Governance

Variable	Beschreibung	Standard
`ENABLE_OTEL`	OpenTelemetry-Export aktivieren	`True`
`OTEL_EXPORTER_OTLP_ENDPOINT`	OTLP-Collector-Endpunkt	—
`OTEL_EXPORTER_OTLP_PUBLIC_KEY` / `OTEL_EXPORTER_OTLP_SECRET_KEY`	OTLP-Authentifizierungsschlüssel	—
`OTEL_EXPORTER_OTLP_PROTOCOL`	OTLP-Protokoll (z. B. `http/protobuf`)	—
`EUNOMIA_TYPE`	Autorisierungsmodus: `none`, `embedded`, `remote`	`none`
`EUNOMIA_POLICY_FILE`	Eingebettete Richtliniendatei	`mcp_policies.json`
`EUNOMIA_REMOTE_URL`	Remote-Eunomia-Server-URL	—

Agent-Laufzeit (nur vollständige `[agent]`-Laufzeit)

Variable	Beschreibung	Standard
`MCP_URL`	URL des MCP-Servers, mit dem der Agent verbindet	`http://localhost:8000/mcp`
`PROVIDER`	LLM-Anbieter (z. B. `openai`)	`openai`
`MODEL_ID`	Modell-ID (z. B. `gpt-4o`)	`gpt-4o`
`ENABLE_WEB_UI`	AG-UI-Weboberfläche bereitstellen	`True`

Agent

Dieses Repository enthält einen vollständig integrierten Pydantic-AI-Graph-Agenten. Er kommuniziert über das Agent Control Protocol (ACP) und interagiert nahtlos mit der Agent Web UI (AG-UI) sowie der Terminal-Schnittstelle.

Agent-CLI ausführen

So starten Sie den interaktiven Agenten über die Befehlszeile:

# Set credentials
export TUNNEL_IDENTITY_FILE="your_value"
export DEBUG="your_value"
export PYTHONUNBUFFERED="your_value"

# Run the agent server
tunnel-manager-agent --provider openai --model-id gpt-4o

Docker-Compose-Orchestrierung

Die folgende docker/agent.compose.yml konfiguriert den Agenten, die Weboberfläche und die Terminal-Schnittstelle gemeinsam:

version: '3.8'

services:
  tunnel-manager-mcp:
    image: example/tunnel-manager:mcp
    container_name: tunnel-manager-mcp
    hostname: tunnel-manager-mcp
    restart: always
    env_file:
      - ../.env
    environment:
      - PYTHONUNBUFFERED=1
      - HOST=0.0.0.0
      - PORT=8000
      - TRANSPORT=streamable-http
    ports:
      - "8000:8000"
    healthcheck:
      test: ["CMD", "python3", "-c", "import urllib.request; urllib.request.urlopen('http://localhost:8000/health')"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 10s
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

  tunnel-manager-agent:
    image: example/tunnel-manager@sha256:<digest>
    container_name: tunnel-manager-agent
    hostname: tunnel-manager-agent
    restart: always
    depends_on:
      - tunnel-manager-mcp
    env_file:
      - ../.env
    command: [ "tunnel-manager-agent" ]
    environment:
      - PYTHONUNBUFFERED=1
      - HOST=0.0.0.0
      - PORT=9002
      - MCP_URL=http://tunnel-manager-mcp:8000/mcp
      - PROVIDER=${PROVIDER:-openai}
      - MODEL_ID=${MODEL_ID:-gpt-4o}
      - ENABLE_WEB_UI=True
      - ENABLE_OTEL=True
    ports:
      - "9002:9002"
    healthcheck:
      test: ["CMD", "python3", "-c", "import urllib.request; urllib.request.urlopen('http://localhost:9002/health')"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 10s
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

Detaillierte Erläuterungen zur Grapharchitektur, benutzerdefinierte Fähigkeitskonfigurationen und Anleitungen zu agentischen Abläufen finden Sie in docs/deployment.md.

Sicherheit & Governance

Direkt aufgebaut auf dem unternehmensreifen agent-utilities-Kern werden die folgenden Standard-Sicherheitsparameter vollständig unterstützt:

Zugriffskontrolle & Richtliniendurchsetzung

Eunomia-Richtlinien: Fein granulierte, richtliniengesteuerte Werkzeugautorisierung. Unterstützt none, lokale embedded-Richtlinien (mcp_policies.json) oder zentralisierte remote-Modi.
OIDC-Token-Delegierung: Konform mit RFC 8693-Tokenaustausch zur Übertragung von Benutzeranmeldeinformationen von Web-UI / ACP → Agent → MCP.
Bereichsbegrenzte Anmeldeinformationen: Der Ausführungskontext ist auf die Identität des jeweiligen Aufrufers beschränkt.

Laufzeitsicherheitsraster

Funktion	Funktionalität	Aktivierung
Werkzeugschutz	Empfindlichkeitsprüfung mit Human-in-the-Loop-Validierung	Standardmäßig aktiviert
Prompt-Injection-Abwehr	Eingabescans, Wiederholungserkennung und rekursive Schleifenblockaden	Standardmäßig aktiviert
Kontextsicherheitswächter	Erkennung von Endlosschleifen und präventive Warnungen bei Kontextüberlauf	Standardmäßig aktiviert

Installation

Wählen Sie das Extra, das zu Ihrem Einsatzszenario passt:

Extra	Installiert	Verwendung
`tunnel-manager[mcp]`	Verbindungsorientierter MCP-Server (`agent-utilities[mcp]` — FastMCP/FastAPI + `epistemic-graph[full]`)	Sie betreiben nur den MCP-Server (kleinste Installation / kleinstes Image)
`tunnel-manager[agent]`	Agent-Laufzeit (`agent-utilities[agent-runtime,logfire]` — Modellorchestrierung + `epistemic-graph[full]`)	Sie betreiben den integrierten Agenten
`tunnel-manager[all]`	Alles (`mcp` + `agent` + `logfire`)	Entwicklung / beide Oberflächen

# Connector-focused MCP server (includes the shared graph engine)
uv pip install "tunnel-manager[mcp]"

# Agent runtime (adds model orchestration to the shared graph engine)
uv pip install "tunnel-manager[agent]"

# Everything (development)
uv pip install "tunnel-manager[all]"      # or: python -m pip install "tunnel-manager[all]"

Container-Images (`:mcp` vs. `:agent`)

Ein mehrstufiges docker/Dockerfile erstellt zwei passend dimensionierte Images, ausgewählt über --target:

Image-Tag	Build-Ziel	Inhalt	Einstiegspunkt
`example/tunnel-manager:mcp`	`--target mcp`	`tunnel-manager[mcp]` — verbindungsorientiert, enthält `epistemic-graph[full]`; keine Modellorchestrierung	`tunnel-manager-mcp`
`example/tunnel-manager@sha256:<digest>`	`--target agent` (Standard)	`tunnel-manager[agent]` — Agent-Laufzeit, Modellorchestrierung + `epistemic-graph[full]`	`tunnel-manager-agent`

docker build --target mcp   -t example/tunnel-manager:mcp    docker/   # connector-focused MCP server
docker build --target agent -t example/tunnel-manager:agent-local docker/   # agent runtime

docker/mcp.compose.yml betreibt den verbindungsorientierten :mcp-Server; docker/agent.compose.yml betreibt den Agenten (unveränderlicher Agent-Digest) mit einem gemeinsam platzierten :mcp-Sidecar.

Wissensgraph-Datenbank (`epistemic-graph`)

Sowohl [mcp] als auch [agent] enthalten die epistemic-graph-Engine über die erforderliche Agent-Utilities-Kernabhängigkeit (epistemic-graph[full]). Das [mcp]-Extra hält den Server verbindungsorientiert; [agent] aktiviert zusätzlich die Modellorchestrierung. Lokale Bereitstellungen können die gebündelte Engine verwenden. Für Produktionsumgebungen oder gemeinsamen Zustand betreiben Sie epistemic-graph als dedizierten Datenbankdienst und konfigurieren die Laufzeit entsprechend. Bereitstellungsrezepte (Einzelknoten + Raft-HA), Verbindungskonfiguration und Architekturdiagramme sind im epistemic-graph-Bereitstellungshandbuch dokumentiert.

Dokumentation

Die vollständige Dokumentation ist als offizielle Dokumentationsseite veröffentlicht und dient als empfohlene Referenz für Installation, Bereitstellung und den täglichen Betrieb.

Seite	Inhalt
Installation	pip, Quellcode, Extras, vorgefertigtes Docker-Image
Inventar	das gemeinsame `inventory.yaml` — Standardort, Erstellung, Formate, Überschreibungen
Bereitstellung	MCP- und Agent-Server ausführen, Compose, Caddy + Technitium, Umgebungskonfiguration
Verwendung	die MCP-Werkzeuge, die `HostManager`- / `Tunnel`-API, die CLI
Überblick	Ökosystemrolle, verteilte SSH-Schwarm-Skalierung, MCP-Konfiguration
Teleport-Architektur	Zertifikat-, Proxy- und plattformübergreifendes Verbindungsmodell
Konzepte	Konzeptregister (`CONCEPT:TUN-*`)

AGENTS.md ist die maßgebliche Anleitung für Mitwirkende und Agenten.

Betreuer

Gepflegt vom Projekt-Mitwirkendenteam. Die Paketmetadaten verwenden bewusst eine Rollenadresse anstelle einer persönlichen Identität.

Mitwirken

Beiträge sind willkommen! Bitte stellen Sie die Codequalität sicher, indem Sie vor dem Einreichen von Pull Requests lokale Prüfungen ausführen:

Formatieren Sie den Code mit ruff format .
Linten Sie den Code mit ruff check .
Validieren Sie die Typsicherheit mit mypy .
Führen Sie die Testsuite mit pytest aus

Bereitstellung mit `agent-utilities-deployment`

Stellen Sie dieses Paket mit dem konsolidierten agent-utilities-deployment-Workflow bereit. Er wählt einen Pfad für installierte Pakete, bearbeitbare Quellen oder unveränderliche Container; zeichnet nur Laufzeit-Geheimnis- und TLS-Profil-Referenzen in AgentConfig auf; und führt Arzt-, Registrierungs-, Richtlinien-, Beobachtbarkeits- und Rollback-Gates aus. Bitten Sie Ihren Agenten, "deploy tunnel-manager with agent-utilities-deployment" auszuführen.

Installationsmodus	Befehl
Installiertes Paket	`uv tool install "tunnel-manager[mcp]"`, dann `tunnel-manager-mcp` ausführen
Bearbeitbare Quelle	`uv pip install -e ".[agent]"`, dann `tunnel-manager-mcp` ausführen
Unveränderlicher Container	Bereitstellen von `registry.example.invalid/tunnel-manager@sha256:<digest>` über den vom Operator ausgewählten Orchestrator

Das Repository enthält kein Bereitstellungsprofil, keinen Anmeldedatenwert, keinen Zertifikatspfad und keinen umgebungsspezifischen Endpunkt. Stellen Sie diese zur Laufzeit über AgentConfig und den konfigurierten Geheimnisanbieter bereit.

Vertrag über die verwaltete Fähigkeit

Dieses Paket bietet eine kompakte kanonische Skill-Oberfläche mit spezialisierten Verfahren, die als referenzierte Workflows geführt werden. Die aktuellen MCP-Tools, Skill-Metadaten, connector_manifest.yml, Ontologie, Zuordnungen, Formen, Fixtures, Migrationen, Tool-Schema-Fingerabdrücke und Zertifizierungsmetadaten bilden einen versionierten Fähigkeitsvertrag. Validieren Sie sie gemeinsam; verlassen Sie sich nicht auf veraltete Tool-Namen oder historische aufgabenspezifische Skill-Wrapper.

Laufzeit-Endpunkte, Anmeldedaten, Zertifikatsvertrauen, Mandantenidentität, Aufbewahrung und Beobachtbarkeitsrichtlinie sind Bereitstellungseingaben und niemals verpackte Werte. Siehe Konfiguration, Vertrauen und Datenschutz, bevor Sie einen Netzwerktransport, Connector-Ingestion, GraphOS-Delegation oder Trace-Export aktivieren.

Available Tools

8 tools

tm_filesAdvanced File OperationsC

Destructive

Advanced file operations on remote hosts.

ParametersJSON Schema

Name	Required	Description	Default
`mode`	No	Permission mode (recursive_ops/chmod).	755
`group`	No	Group (recursive_ops/chown).
`host1`	No	First host (diff_compare).
`host2`	No	Second host (diff_compare).
`owner`	No	Owner (recursive_ops/chown).
`action`	Yes	Action: 'recursive_ops', 'content_search', 'watch', 'diff_compare', 'backup'
`source`	No	Source path (recursive_ops).
`pattern`	No	Search pattern (content_search).
`duration`	No	Monitor duration secs (watch).
`password`	No	SSH password.
`username`	No	SSH username.
`file_path`	No	File path to compare (diff_compare).
`operation`	No	Operation type: copy, move, delete, list, chmod, chown (recursive_ops).
`recursive`	No	Recursive search (content_search).
`backup_dest`	No	Backup destination (backup).
`compression`	No	Enable compression (backup).
`destination`	No	Destination path (recursive_ops/copy/move).
`incremental`	No	Incremental backup (backup).
`max_results`	No	Max results (content_search).
`remote_host`	No	Remote host.
`watch_paths`	No	Paths to monitor (watch).
`backup_paths`	No	Paths to backup (backup).
`search_paths`	No	Directories to search (content_search).
`identity_file`	No	SSH identity file path.
`case_sensitive`	No	Case-sensitive (content_search).

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description does not add behavioral context beyond the annotations. Annotations already indicate destructiveHint=true, but the description fails to mention that operations may modify or delete files, require SSH credentials, or have side effects. With annotations present, the description should still provide safety or prerequisite details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely short (one sentence), but it fails to convey essential information. Conciseness should not come at the cost of usefulness. Every sentence should add value; this sentence is generic and does not help the agent select or invoke the tool effectively.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (25 parameters, 5 actions, output schema exists), the description is severely incomplete. It does not mention the supported actions, prerequisites (SSH credentials), or how to combine parameters. An output schema exists but is not referenced. The description leaves the agent with no guidance on how to operate the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100% with parameter descriptions, the tool's description does not summarize which parameters correspond to which action. With 25 parameters and multiple actions, the description should group parameters or list actions, but it just repeats the title. Baseline for high coverage is 3, but the lack of structural guidance reduces clarity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'Advanced file operations on remote hosts', which indicates the tool's domain (files on remote hosts) and implies operations, but lacks a specific verb-resource pair. It distinguishes from sibling tools like tm_hosts or tm_inventory, so a clear domain is established.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. The description does not specify contexts like 'for file management, use this; for host management, use tm_hosts'. An agent must infer from the name and schema alone, which is insufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

tm_hostsHost ManagementC

Destructive

Manage the local host alias inventory.

ParametersJSON Schema

Name	Required	Description
`port`	No	SSH port.
`user`	No	Username.
`alias`	No	Host alias.
`action`	Yes	Action: 'list', 'add', 'remove'
`hostname`	No	Real hostname or IP.
`password`	No	Password (if no key).
`identity_file`	No	Path to private key.
`proxy_command`	No	Proxy command.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already indicate destructiveHint=true, but the description does not elaborate on the destructive nature (e.g., removing hosts permanently) or other behavioral traits like authentication requirements or system changes. It adds no value beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single short sentence, which is concise but under-specified. It lacks critical information such as the available actions or the fact that it modifies local configuration. It is appropriately sized for a simple tool but incomplete for the complexity of 8 parameters.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 8 parameters, a required 'action' parameter, and a destructive annotation, the description is too minimal. It does not mention the three actions (list, add, remove) or the potential impacts. Even with an output schema, the description fails to provide essential operational context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, so each parameter is already documented. The description ('Manage...') does not add any additional meaning or context about how parameters relate. The baseline is 3 since the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'Manage the local host alias inventory,' which identifies the resource but uses the vague verb 'manage.' It does not specify the actions (list, add, remove) or how the tool operates. The title 'Host Management' provides context, but the description alone is insufficient to clearly distinguish the tool's specific function from siblings like tm_inventory.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives such as tm_remote or tunnel_ingest_hosts. There are no explicit when-to-use or when-not-to-use conditions, leaving the agent to infer usage from the action parameter and sibling names.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

tm_inventoryInventory OperationsC

Destructive

Bulk inventory operations against YAML host groups.

ParametersJSON Schema

Name	Required	Description	Default
`cfg`	No	Local SSH config path (copy_ssh_config).
`cmd`	No	Shell command (run_command).
`key`	No	Shared key path (configure_key_auth).	/app/.ssh/id_ed25519
`group`	No	Target group.	all
`lpath`	No	Local file path (send_file).
`rpath`	No	Remote file path (send_file/receive_file).
`action`	Yes	Action: 'configure_key_auth', 'mesh_bootstrap', 'run_command', 'copy_ssh_config', 'rotate_key', 'send_file', 'receive_file'
`key_pfx`	No	Prefix for new keys (rotate_key).	/root/.ssh/id_
`rmt_cfg`	No	Remote config path (copy_ssh_config).	/root/.ssh/config
`timeout`	No	Command timeout in seconds.
`key_type`	No	Key type: rsa or ed25519.	ed25519
`parallel`	No	Run parallel.
`inventory`	No	YAML inventory path (default: $XDG_CONFIG_HOME/agent-utilities/inventory.yaml).	/root/.config/agent-utilities/inventory.yml
`max_threads`	No	Max threads.
`lpath_prefix`	No	Local dir prefix (receive_file).

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations provide destructiveHint=true, but the description adds no behavioral context beyond that. It does not disclose what is destroyed, safety precautions, or any side effects. The description relies solely on the annotations for transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is terse (one sentence) and front-loaded with key terms. However, given the tool's complexity (15 parameters, multiple actions), it is too brief and could benefit from a structured overview.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having an output schema and 15 parameters, the description fails to provide a high-level explanation of the tool's actions or typical use cases. It is insufficient for an agent to fully understand the tool's capabilities without inspecting the schema extensively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so each parameter has a description. The tool-level description adds no additional meaning beyond the schema. It is adequate but not enhanced.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Bulk inventory operations against YAML host groups' is somewhat vague, using the generic term 'operations' without specifying the types of actions. The title 'Inventory Operations' also lacks specificity. It indicates the resource (YAML host groups) and bulk nature, but does not clearly define the tool's purpose relative to siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives like tm_hosts or tm_operations. The description does not mention context, prerequisites, or exclusions, leaving the agent to infer usage from the action parameter alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

tm_operationsOperation ManagementC

Destructive

Operation lifecycle and session management.

ParametersJSON Schema

Name	Required	Description
`action`	Yes	Action: 'start', 'get_progress', 'cancel', 'get_metrics', 'list_sessions'
`details`	No	Additional details (start).
`total_steps`	No	Total steps (start).
`operation_id`	No	Operation ID (get_progress/cancel/get_metrics).
`operation_type`	No	Type of operation (start).

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, so the description does not need to repeat that. However, it adds no further behavioral context beyond 'lifecycle and session management,' which is adequately covered by the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is only 5 words, which is too terse. While concise, it sacrifices informativeness and does not earn its place given the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having an output schema and annotations, the description is too brief to cover the tool's multiple actions and use cases. It fails to explain how to use the action parameter or what each action entails.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so all parameters are documented in the schema. The description adds no additional parameter information, so it meets the baseline without adding value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool manages operation lifecycle and sessions, which is a general purpose. It distinguishes from siblings like tm_files or tm_hosts, but lacks specificity about the exact actions (start, cancel, etc.) that are available.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, context for each action, or when to prefer sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

tm_remoteRemote SSH OperationsC

Destructive

Single-host SSH operations with shared connection params.

ParametersJSON Schema

Name	Required	Description	Default
`cfg`	No	SSH config path.	/root/.ssh/config
`cmd`	No	Shell command (run_command).
`key`	No	Key path (test_key_auth/setup_passwordless).
`host`	No	Remote host.
`lcfg`	No	Local SSH config (copy_ssh_config).
`port`	No	Port.
`rcfg`	No	Remote SSH config (copy_ssh_config).	/root/.ssh/config
`user`	No	Username.
`lpath`	No	Local file path (send_file/receive_file).
`proxy`	No	Teleport proxy.
`rpath`	No	Remote file path (send_file/receive_file).
`action`	Yes	Action: 'run_command', 'send_file', 'receive_file', 'check_ssh', 'test_key_auth', 'setup_passwordless', 'copy_ssh_config', 'rotate_key', 'remove_host_key'
`id_file`	No	Private key path.	/app/.ssh/id_ed25519
`new_key`	No	New private key path (rotate_key).
`timeout`	No	Command timeout in seconds.
`key_type`	No	Key type: rsa or ed25519 (setup_passwordless/rotate_key).	ed25519
`password`	No	Password.
`certificate`	No	Teleport certificate.
`known_hosts`	No	Known hosts path (remove_host_key).	/root/.ssh/known_hosts

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, so the agent knows operations may be destructive. The description adds no further behavioral context (e.g., that actions like remove_host_key modify remote host keys, or that some operations require authentication). Minimal value beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence is concise but overly minimal. It lacks front-loading of key information (e.g., list of actions or critical parameters). Every word earns its place, but additional context would improve usability without adding bloat.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 19 parameters and multiple actions, the description is too sparse. It does not explain the variety of actions, how to use shared parameters, or typical usage patterns. Even with an output schema, the description fails to provide sufficient context for effective tool selection and invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% (all 19 parameters have brief descriptions). The tool description adds no extra meaning; it only says 'shared connection params.' Baseline is 3 as schema does the heavy lifting, but description does not enhance understanding of parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description states 'Single-host SSH operations with shared connection params,' which clearly indicates the tool is for SSH actions on one remote host. It distinguishes from siblings like tm_files (local files) or tm_hosts (host management) by specifying SSH and single-host focus. However, it could list the specific actions (e.g., run_command, file transfer) for greater clarity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no explicit guidance on when to use this tool versus alternatives. It only implies usage for SSH-related tasks on a single host. No exclusion criteria, prerequisites, or comparisons with sibling tools are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

tm_securitySecurity AuditingC

Read-onlyIdempotent

Security scanning and compliance.

ParametersJSON Schema

Name	Required	Description	Default
`scope`	No	Security areas to audit (security_audit).
`action`	Yes	Action: 'security_audit', 'compliance_check', 'vulnerability_scan', 'access_control_audit'
`password`	No	SSH password.
`standard`	No	Compliance standard: cis_benchmark, pci_dss, hipaa (compliance_check).	cis_benchmark
`username`	No	SSH username.
`scan_type`	No	Scan type: basic, package, config (vulnerability_scan).	basic
`remote_host`	Yes	Remote host to audit.
`identity_file`	No	SSH identity file path.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds no behavioral context beyond confirming a read-only, idempotent operation. It fails to disclose that the tool requires SSH access (evident from schema but unmentioned) or to elaborate on side effects of scanning. The description does not add value beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely short (5 words), which is concise but risks under-specification. It front-loads no critical details like supported actions or security implications. While brevity is valued, the lack of structure (no bullet points, no separation of concerns) reduces clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having an output schema (not shown) and 8 parameters, the description covers almost nothing. It omits the tool's return values, SSH authentication requirements, and the specific actions it can perform. A complete description should at least hint at the action types (e.g., 'supports security_audit, compliance_check, etc.') to unify with the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the structured data already documents each parameter's meaning. The description 'Security scanning and compliance' adds no additional semantics for parameters. Baseline 3 applies since the description does not compensate or elaborate beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Security scanning and compliance' broadly matches the tool name and title, but it lacks a specific verb+resource combination. It vaguely groups scanning and compliance without defining distinct outcomes. Sibling tools (e.g., tm_files, tm_remote) imply a security focus, but the description does not differentiate this tool from potential security-related siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. The description does not mention when not to use it, prerequisites, or preferred contexts. For a tool requiring SSH credentials and offering multiple action types, this omission hampers correct selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

tm_systemSystem IntelligenceA

Read-onlyIdempotent

Remote system intelligence via SSH.

ParametersJSON Schema

Name	Required	Description
`action`	Yes	Action: 'get_info', 'discover_services', 'analyze_logs', 'network_topology'
`password`	No	SSH password.
`patterns`	No	Search patterns (analyze_logs).
`username`	No	SSH username.
`log_paths`	No	Log file paths (analyze_logs).
`remote_host`	Yes	Remote host.
`identity_file`	No	SSH identity file path.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that it uses SSH for intelligence, which aligns but doesn't elaborate on behaviors like connection handling or authentication requirements. It doesn't contradict annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that front-loads the core purpose. It is concise and avoids fluff, though slightly more context could improve it without harming conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema, annotations covering safety, and full schema coverage, the description is adequate but lacks details on SSH prerequisites, security considerations, or limitations. It could be more complete without being verbose.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with all 7 parameters described. The description itself adds no additional parameter-level meaning beyond what's already in the schema. Baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Remote system intelligence via SSH' clearly states the tool's purpose: to gather intelligence from remote systems over SSH. This verb+resource pattern effectively distinguishes it from sibling tools like tm_files (file operations) or tm_hosts (host management).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides minimal guidance on when to use this tool versus alternatives. It does not specify prerequisites, exclusions, or context. The name and description imply it's for system intelligence, but explicit usage guidance is lacking.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

tunnel_ingest_hostsIngest Hosts to Knowledge GraphC

Read-onlyIdempotent

List the managed SSH inventory and push it into the epistemic-graph KG.

Maps each alias → a typed :Host node (+ :HostGroup / :SshKey and their :inGroup / :usesKey links). Best-effort: no-ops cleanly when no KG engine is reachable.

ParametersJSON Schema

Name	Required	Description	Default
`group`	No	HostGroup name to attach the ingested hosts to.	all

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.9/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description's claim to 'push it into the epistemic-graph KG' suggests a write operation, contradicting the annotation readOnlyHint=true. Annotations indicate no modifications, while the description implies data ingestion. This is a clear annotation contradiction, lowering the score to 1.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, with the first sentence stating the core purpose and the second providing behavioral detail. Every word is necessary, and critical information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists and schema coverage is high, the description covers the main action and best-effort behavior. However, it fails to explain the group parameter's role and does not differentiate from sibling tools, leaving gaps for an agent choosing among related tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% for the single parameter, so baseline is 3. The description does not add any meaning beyond the schema's description of the 'group' parameter; it omits explaining its role in attaching hosts to a host group.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action: 'List the managed SSH inventory and push it into the epistemic-graph KG.' This clearly identifies the verb and resource. However, it does not explicitly differentiate itself from sibling tools like tm_inventory or tm_hosts, which may have overlapping functionality.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions 'Best-effort: no-ops cleanly when no KG engine is reachable,' which implies safe usage but does not specify when to use this tool versus alternatives like tm_inventory for direct inventory listing or tm_hosts for host management. No explicit when-not or alternative guidance is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

8 tool updatesv2.0.1Jul 9, 2026
- First observedtm_files
- First observedtm_hosts
- First observedtm_inventory
- First observedtm_operations
- First observedtm_remote
- First observedtm_security
- First observedtm_system
- First observedtunnel_ingest_hosts

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3/5.0

Scored 2026-07-09 23:50 across 8 tools

Disambiguation3/5

Most tools have distinct purposes (e.g., files, security, system intelligence), but tm_hosts and tm_inventory overlap in managing host inventory, and tm_remote may conflict with tm_files and tm_system. The outlier tunnel_ingest_hosts is distinct but not clearly related.

Naming Consistency3/5

Seven tools use the 'tm_' prefix, but one uses 'tunnel_', breaking consistency. The naming pattern is noun-based without clear verb-noun structure, which is acceptable but not ideal.

Tool Count5/5

Eight tools is a well-scoped set for remote host management, covering operations, inventory, security, and system intelligence without being overwhelming.

Completeness4/5

Covers file operations, SSH sessions, inventory, security, and system intelligence. Minor gaps like individual host CRUD (e.g., create/delete alias) might exist, but bulk operations and KG ingestion fill some needs.

Maintenance

ActivityActive

ResponsivenessUnresponsive

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Security Mcp A
io.github.varvararatta
MCP server for Security
Security Penetration Testing
2
Os Automation Mcp C
io.github.varvararatta
MCP server for OS Automation
OS Automation Command Line
2
Incwo MCPOAuth
io.github.incwo
Secure MCP server for exploring incwo CRM data, documents, and email workflows.
CRM Email Documentation Access
2
VerifyMCP A
io.verifymcp
Independent trust scores, tool surfaces and change history for MCP servers.
Developer Tools
91

Related MCP Servers

MCP SSH Agent
Shell Access Command Line OS Automation
AiondaDotCom
A
license
B
quality
A
maintenance
A server that enables secure interaction with remote SSH hosts through standardized MCP interface, providing functions like listing hosts, executing commands, and transferring files using native SSH tools.
Updated 2 months ago (2026-08-10 14:34 UTC)
7
261 npm
102
MIT
mcp-ssh
Shell Access Command Line Developer Tools
caikiji
A
license
Not graded
quality
D
maintenance
MCP server for SSH remote execution, file transfer, and file editing with automatic backup/trash and ~/.ssh/config integration.
Updated 5 months ago (2026-05-08 17:39 UTC)
117 npm
1
MIT
MCP SSH Manager
Shell Access Command Line Networking & Infrastructure
bysonte
A
license
A
quality
D
maintenance
MCP server for managing remote servers via SSH, enabling command execution, file transfer, rsync, tunnels, health checks, backups, and database operations.
Updated 3 months ago (2026-07-14 00:42 UTC)
17
2,150 npm
1
MIT
ssh-mcp-toolkit
Shell Access Command Line File Systems
xunuo2345
A
license
Not graded
quality
B
maintenance
MCP server providing safe, persistent SSH sessions to remote machines with multi-hop ProxyJump tunneling, SFTP file transfer, and stored host profiles.
Updated 20 days ago (2026-09-24 11:24 UTC)
MIT

Tunnel Manager

CLI oder API | MCP | Agent

Überblick

Hauptfunktionen

CLI oder API

MCP

Verfügbare MCP-Tools

Kondensierte aktionsgesteuerte Tools (MCP_TOOL_MODE=condensed)

Ausführliche 1:1-API-zugeordnete Tools (MCP_TOOL_MODE=verbose oder both)

Dynamische Tool-Auswahl und Sichtbarkeit

MCP-Konfigurationsbeispiele

stdio-Transport (lokale IDEs — Cursor, Claude Desktop, VS Code)

Streamable-HTTP-Transport (vernetzt / Produktion)

Zusätzliche Bereitstellungsoptionen

Inventar

Umgebungsvariablen

Paket-Umgebungsvariablen

Geerbte Agent-Utilities-Variablen (gelten für jeden Connector)

SSH-Verbindung & Anmeldedaten

Inventar & Parallelität

MCP-Server / Transport

Werkzeugumschalter

Telemetrie & Governance

Agent-Laufzeit (nur vollständige [agent]-Laufzeit)

Agent

Agent-CLI ausführen

Docker-Compose-Orchestrierung

Sicherheit & Governance

Zugriffskontrolle & Richtliniendurchsetzung

Laufzeitsicherheitsraster

Installation

Container-Images (:mcp vs. :agent)

Wissensgraph-Datenbank (epistemic-graph)

Dokumentation

Betreuer

Mitwirken

Bereitstellung mit agent-utilities-deployment

Vertrag über die verwaltete Fähigkeit

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Kondensierte aktionsgesteuerte Tools (`MCP_TOOL_MODE=condensed`)

Ausführliche 1:1-API-zugeordnete Tools (`MCP_TOOL_MODE=verbose` oder `both`)

Agent-Laufzeit (nur vollständige `[agent]`-Laufzeit)

Container-Images (`:mcp` vs. `:agent`)

Wissensgraph-Datenbank (`epistemic-graph`)

Bereitstellung mit `agent-utilities-deployment`