What can you do with this server?

Tunnel Manager is a production-grade MCP server for managing SSH tunnels, remote hosts, and infrastructure operations via AI agents, CLI, or direct API usage. * Host Inventory Management (tm_hosts): Add, remove, and list SSH host aliases with connection details (hostname, port, user, password, identity file, proxy command). * Remote SSH Operations (tm_remote): Execute shell commands, send/receive files, check SSH connectivity, test key authentication, set up passwordless SSH, copy SSH configs, rotate keys, and remove host keys on individual remote hosts. * Bulk Inventory Operations (tm_inventory): Execute operations across groups of hosts defined in a YAML inventory — configure key auth, bootstrap mesh networks, run commands, copy SSH configs, rotate keys, and transfer files in bulk with parallel execution. * Operation Lifecycle Management (tm_operations): Start, track progress, cancel, and retrieve metrics for long-running operations and active sessions. * Remote System Intelligence (tm_system): Gather system info, discover running services, analyze logs with pattern matching, and map network topology via SSH. * Advanced File Operations (tm_files): Recursive copy/move/delete/chmod/chown, content search, file watching, cross-host diff comparisons, and backups with compression/incremental support. * Security Auditing (tm_security): Conduct security audits, compliance checks (CIS, PCI-DSS, HIPAA), vulnerability scans, and access control audits on remote hosts. * Knowledge Graph Ingestion (tunnel_ingest_hosts): Push SSH inventory into an epistemic knowledge graph, mapping hosts, groups, and SSH keys as typed nodes with relationship links. * AI Agent & Enterprise Features: Hosts a Pydantic AI agent with ACP/AG-UI support, Eunomia policy-based authorization, OIDC token delegation, Tool Guard, Prompt Injection Defense, and native OpenTelemetry/Langfuse telemetry.

Which integrations are available for this server?

Provides native OpenTelemetry exports for telemetry and tracing, allowing observability integration with OpenTelemetry-compatible backends.

How do I use Tunnel Manager?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Tunnel Manager add host 'dev-server' with IP 192.168.1.10" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

de en ja ko ru zh

Tunnel Manager

by Knuckles-Team

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

Tunnel Manager

CLI or 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

Documentation — Installation, deployment, usage across the API, CLI, and MCP and agent interfaces are maintained in the official documentation.

Related MCP server: mcp-ssh

Overview

Tunnel Manager is a production-grade Agent and Model Context Protocol (MCP) server designed to interface directly with Create SSH Tunnels to your remote hosts and host as an MCP Server for Agentic AI!.

Key Features

Consolidated Action-Routed MCP Tools: Minimizes token overhead and eliminates tool bloat in LLM contexts by grouping methods into optimized, togglable tool modules.
Enterprise-Grade Security: Comprehensive support for Eunomia policies, OIDC token delegation, and granular execution context tracking.
Integrated Graph Agent: Built-in Pydantic AI agent supporting the Agent Control Protocol (ACP) and standard Web interfaces (AG-UI).
Native Telemetry & Tracing: Out-of-the-box OpenTelemetry exports and native Langfuse tracing.

CLI or API

This agent wraps the Create SSH Tunnels to your remote hosts and host as an MCP Server for Agentic AI! API. You can interact with it programmatically or via its integrated execution entrypoints.

Detailed instructions on how to use the underlying API wrappers, extended schema bindings, and developer SDK references are maintained in docs/index.md.

MCP

This server utilizes dynamic Action-Routed tools to optimize token overhead and maximize IDE compatibility.

Available MCP Tools

Auto-generated from the live MCP server — do not edit by hand.

Condensed action-routed tools (`MCP_TOOL_MODE=condensed`)

MCP Tool	Toggle Env Var	Description
`tm_files`	`FILETOOL`	Advanced file operations on remote hosts.
`tm_hosts`	`HOSTTOOL`	Manage the local host alias inventory.
`tm_inventory`	`INVENTORYTOOL`	Bulk inventory operations against YAML host groups.
`tm_operations`	`OPERATIONSTOOL`	Operation lifecycle and session management.
`tm_remote`	`REMOTETOOL`	Single-host SSH operations with shared connection params.
`tm_security`	`SECURITYTOOL`	Security scanning and compliance.
`tm_system`	`SYSTEMTOOL`	Remote system intelligence via SSH.
`tunnel_ingest_hosts`	`INGESTTOOL`	List the managed SSH inventory and push it into the epistemic-graph KG.

Verbose 1:1 API-mapped tools (`MCP_TOOL_MODE=verbose` or `both`)

MCP Tool	Toggle Env Var	Description
`tunnel_manager_add_host`	`HOST_MANAGERTOOL`	Invoke the add_host operation.
`tunnel_manager_get_host`	`HOST_MANAGERTOOL`	Get a host config by alias, denying an alias the caller isn't entitled to.
`tunnel_manager_list_hosts`	`HOST_MANAGERTOOL`	List the host aliases the CALLER is entitled to, secrets redacted.
`tunnel_manager_load_inventory`	`HOST_MANAGERTOOL`	Invoke the load_inventory operation.
`tunnel_manager_remove_host`	`HOST_MANAGERTOOL`	Invoke the remove_host operation.
`tunnel_manager_save_inventory`	`HOST_MANAGERTOOL`	Invoke the save_inventory operation.

8 action-routed tool(s) · 6 verbose 1:1 tool(s). Each is enabled unless its <DOMAIN>TOOL toggle is set false; MCP_TOOL_MODE selects the surface (intent default — the six verb-tools, granular set loaded on demand · condensed action-routed · verbose 1:1 · both). Auto-generated — do not edit.

Detailed tool schemas, parameter shapes, and validation constraints are preserved in docs/usage.md.

Dynamic Tool Selection & Visibility

This MCP server supports dynamic toolset selection and visibility filtering at runtime. This allows you to restrict the set of exposed tools in order to prevent blowing up the LLM's context window.

You can configure tool filtering via multiple input channels:

CLI Arguments: Pass --tools or --toolsets (or their disabled counterparts --disabled-tools and --disabled-toolsets) during startup.
Environment Variables: Define standard environment variables:
- MCP_ENABLED_TOOLS / MCP_DISABLED_TOOLS
- MCP_ENABLED_TAGS / MCP_DISABLED_TAGS
HTTP SSE Request Headers: Pass custom headers during transport initialization:
- x-mcp-enabled-tools / x-mcp-disabled-tools
- x-mcp-enabled-tags / x-mcp-disabled-tags
HTTP SSE Request Query Parameters: Append query parameters directly to your transport connection URL:
- ?tools=tool1,tool2
- ?tags=tag1

When query strings or parameters are supplied, an LLM-free Knowledge Graph resolution layer (using DynamicToolOrchestrator) matches query intents against known tool tags, names, or descriptions, with safe fallback and automated 24-hour background cache refreshing.

MCP Configuration Examples

Install the connector-focused [mcp] extra. Examples use tunnel-manager[mcp] to add FastMCP / FastAPI through agent-utilities[mcp]; the required Agent Utilities core still carries epistemic-graph[full]. The [agent-runtime] extra additionally enables model orchestration.

stdio Transport (local 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"
      }
    }
  }
}

Runtime references require an alias-aware launcher such as GraphOS. Other launchers must omit those entries and inject the resolved values through their own runtime secret boundary.

Streamable-HTTP Transport (networked / production)

{
  "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"
      }
    }
  }
}

Alternatively, connect to a pre-deployed Streamable-HTTP instance by url:

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

Run a reviewed container image as a least-privilege stdio child (no listener or published 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

For containerized network HTTP, supply an authenticated TLS ingress (or direct server TLS), exact MCP_ALLOWED_HOSTS, and an exact trusted-proxy CIDR policy through the operator-owned deployment profile. The generator does not emit an unauthenticated non-loopback listener.

Auto-generated from the code-read env surface (MCP_TOOL_MODE + package vars) — do not edit.

Additional Deployment Options

tunnel-manager can run as a local stdio process or container, or behind a remote network boundary. The Deployment guide carries the detailed transport contract.

Local container — launch a reviewed immutable image as a least-privilege stdio child with no listener or published port.
Remote URL — connect through an operator-supplied authenticated HTTPS ingress. Keep its URL, outbound identity references, trust profile, and exact MCP_ALLOWED_HOSTS in AgentConfig.

Inventory

tunnel-manager works from a single shared YAML inventory that maps short host aliases (e.g. edge-node) to their SSH connection details. Every ecosystem surface reads the same file — the HostManager API, the tunnel-manager CLI, the MCP server, container-manager-mcp (its cm_* host aliases), and the ssh-bootstrap skill — so you define your fleet once.

Location — ~/.config/agent-utilities/inventory.yml (.yml preferred). A legacy inventory.yaml at the same path is still read when no .yml exists, so existing installs keep working. Override with TUNNEL_INVENTORY.

Manage it with the inventory subcommand:

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

Full schema, every host field, the copy-paste template, and override options live in the Inventory guide.

Environment Variables

Package environment variables

Variable	Example	Description
`HOST`	`127.0.0.1`
`PORT`	`8000`
`TRANSPORT`	`stdio`	options: 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`	options: 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`	—	default remote host (e.g. 198.51.100.10)
`TUNNEL_REMOTE_PORT`	`22`	default SSH port
`TUNNEL_USERNAME`	—	default SSH username
`TUNNEL_PASSWORD_REF`	—	env://, vault://, secret://, or sqlite:// reference
`TUNNEL_KNOWN_HOSTS`	`~/.ssh/known_hosts`	independently verified server host keys
`TUNNEL_CERTIFICATE`	—	path to an SSH certificate file
`TUNNEL_PROXY_COMMAND`	—	SSH ProxyCommand for jump-host/bastion connections
`TUNNEL_INVENTORY`	—	path to the inventory file (defaults to XDG config path)
`TUNNEL_INVENTORY_GROUP`	`all`	inventory host group to target
`TUNNEL_PARALLEL`	`False`	run host operations in parallel
`TUNNEL_MAX_THREADS`	`6`	max worker threads when 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`	—	base config dir (defaults to ~/.config) for inventory resolution
`HOSTTOOL`	`True`	Grouped condensed-surface toggles, one per register__tools registrar.
`REMOTETOOL`	`True`
`INVENTORYTOOL`	`True`
`OPERATIONSTOOL`	`True`
`SYSTEMTOOL`	`True`
`FILETOOL`	`True`
`SECURITYTOOL`	`True`
`INGESTTOOL`	`True`	KG-ingest tools (list the SSH inventory into epistemic-graph)
`TUNNEL_KG_INGEST`	`true`	default-on best-effort inventory ingest on `list`
`TUNNEL_MANAGER_HEALTH_INGEST`	`true`	default-on best-effort network-signal trend ingestion
`TUNNEL_MANAGER_HEALTH_AGGREGATE_S`	`3600`	window (s) over which samples distill to ONE :HealthTrend node/host/signal
`TUNNEL_MANAGER_HOSTS`	`r510,r710,r820,rw710`	comma-separated inventory aliases to probe/derive over (default: full inventory)
`TUNNEL_MANAGER_HEALTH_NOTIFY_URL`	—	best-effort webhook for network-anomaly notifications

Inherited agent-utilities variables (apply to every connector)

Variable	Example	Description
`MCP_TOOL_MODE`	`intent`	Tool surface: `intent` \| `condensed` \| `verbose` \| `both`
`MCP_ENABLED_TOOLS`	—	Comma-separated tool allow-list
`MCP_DISABLED_TOOLS`	—	Comma-separated tool deny-list
`MCP_ENABLED_TAGS`	—	Comma-separated tag allow-list
`MCP_DISABLED_TAGS`	—	Comma-separated tag deny-list
`MCP_CLIENT_AUTH`	—	Outbound MCP child auth: `oidc-client-credentials` \| `basic` \| `none`
`OIDC_CLIENT_ID`	—	OIDC client id (service-account auth)
`OIDC_CLIENT_SECRET_REF`	`secret://identity/oidc-client-secret`	Runtime secret reference for the OIDC service account
`MCP_BASIC_AUTH_USERNAME`	—	HTTP Basic username (`MCP_CLIENT_AUTH=basic`)
`MCP_BASIC_AUTH_PASSWORD_REF`	`secret://identity/mcp-basic-password`	Runtime secret reference for HTTP Basic auth (`MCP_CLIENT_AUTH=basic`)
`MCP_URL`	`http://localhost:8000/mcp`	URL of the MCP server the agent connects to
`PROVIDER`	`openai`	LLM provider for the agent
`MODEL_ID`	`gpt-4o`	Model id for the agent
`ENABLE_WEB_UI`	`True`	Serve the AG-UI web interface

44 package + 14 inherited variable(s). Auto-generated from .env.example + the shared agent-utilities set — do not edit.

Every variable the server reads, grouped by purpose. See .env.example for a copy-paste starting point.

SSH connection & credentials

Variable	Description	Default
`TUNNEL_IDENTITY_FILE`	Path to the SSH private key	`~/.ssh/id_ed25519`
`TUNNEL_USERNAME`	SSH username	—
`TUNNEL_PASSWORD_REF`	`env://`, `vault://`, `secret://`, or `sqlite://` SSH password reference	—
`TUNNEL_KNOWN_HOSTS`	Independently verified SSH server-key trust store	`~/.ssh/known_hosts`
`TUNNEL_CERTIFICATE`	Path to an SSH certificate	—
`TUNNEL_REMOTE_HOST`	Default remote host	—
`TUNNEL_REMOTE_PORT`	Default remote SSH port	`22`
`TUNNEL_PROXY_COMMAND`	SSH `ProxyCommand` for jump hosts	—

Inventory & parallelism

Variable	Description	Default
`TUNNEL_INVENTORY`	Path to the shared inventory (`.yml` preferred, `.yaml` legacy fallback)	`~/.config/agent-utilities/inventory.yml`
`TUNNEL_INVENTORY_GROUP`	Default inventory host group	—
`TUNNEL_PARALLEL`	Run bulk operations in parallel	—
`TUNNEL_MAX_THREADS`	Max concurrent SSH worker threads	—
`XDG_CONFIG_HOME`	Base config dir used to resolve the inventory	`~/.config`

MCP server / transport

Variable	Description	Default
`TRANSPORT`	`stdio`, `streamable-http`, or `sse`	`stdio`
`HOST`	Bind host (HTTP transports)	`127.0.0.1`
`PORT`	Bind port (HTTP transports)	`8000`
`MCP_TOOL_MODE`	Tool surface: `condensed`, `verbose`, or `both`	`condensed`
`MCP_ENABLED_TOOLS` / `MCP_DISABLED_TOOLS`	Comma-separated tool allow/deny list	—
`MCP_ENABLED_TAGS` / `MCP_DISABLED_TAGS`	Comma-separated tag allow/deny list	—
`DEBUG`	Verbose logging	`False`
`PYTHONUNBUFFERED`	Unbuffered stdout (recommended in containers)	`1`

Tool toggles

Each action-routed tool can be disabled individually via its toggle env var (set to false). The full list is in the Available MCP Tools table above (HOSTTOOL, REMOTETOOL, INVENTORYTOOL, OPERATIONSTOOL, SYSTEMTOOL, FILETOOL, SECURITYTOOL).

Telemetry & governance

Variable	Description	Default
`ENABLE_OTEL`	Enable OpenTelemetry export	`True`
`OTEL_EXPORTER_OTLP_ENDPOINT`	OTLP collector endpoint	—
`OTEL_EXPORTER_OTLP_PUBLIC_KEY` / `OTEL_EXPORTER_OTLP_SECRET_KEY`	OTLP auth keys	—
`OTEL_EXPORTER_OTLP_PROTOCOL`	OTLP protocol (e.g. `http/protobuf`)	—
`EUNOMIA_TYPE`	Authorization mode: `none`, `embedded`, `remote`	`none`
`EUNOMIA_POLICY_FILE`	Embedded policy file	`mcp_policies.json`
`EUNOMIA_REMOTE_URL`	Remote Eunomia server URL	—

Agent runtime (full `[agent]` runtime only)

Variable	Description	Default
`MCP_URL`	URL of the MCP server the agent connects to	`http://localhost:8000/mcp`
`PROVIDER`	LLM provider (e.g. `openai`)	`openai`
`MODEL_ID`	Model id (e.g. `gpt-4o`)	`gpt-4o`
`ENABLE_WEB_UI`	Serve the AG-UI web interface	`True`

Agent

This repository features a fully integrated Pydantic AI Graph Agent. It communicates over the Agent Control Protocol (ACP) and interacts seamlessly with the Agent Web UI (AG-UI) and Terminal interface.

Running the Agent CLI

To start the interactive command-line agent:

# 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 Orchestration

The following docker/agent.compose.yml configures the Agent, Web UI, and Terminal Interface together:

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"

Detailed graph node architecture explanations, custom skill configurations, and agentic trace guides are available in docs/deployment.md.

Security & Governance

Built directly upon the enterprise-ready agent-utilities core, standard security parameters are fully supported:

Access Control & Policy Enforcement

Eunomia Policies: Fine-grained, policy-driven tool authorization. Supports none, local embedded (mcp_policies.json), or centralized remote modes.
OIDC Token Delegation: Compliant with RFC 8693 token exchange for flowing authenticating user credentials from Web UI / ACP → Agent → MCP.
Scoped Credentials: Execution context runs restricted to the specific caller identity.

Runtime Security Grid

Feature	Functionality	Enablement
Tool Guard	Sensitivity inspection with human-in-the-loop validation	Enabled by default
Prompt Injection Defense	Input scanning, repetition monitoring, and recursive loop blocks	Enabled by default
Context Safety Guard	Stuck-loop detectors and contextual overflow preemptive alerts	Enabled by default

Installation

Pick the extra that matches what you want to run:

Extra	Installs	Use when
`tunnel-manager[mcp]`	Connector-focused MCP server (`agent-utilities[mcp]` — FastMCP/FastAPI + `epistemic-graph[full]`)	You only run the MCP server (smallest install / image)
`tunnel-manager[agent]`	Agent runtime (`agent-utilities[agent-runtime,logfire]` — model orchestration + `epistemic-graph[full]`)	You run the integrated agent
`tunnel-manager[all]`	Everything (`mcp` + `agent` + `logfire`)	Development / both surfaces

# 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`)

One multi-stage docker/Dockerfile builds two right-sized images, selected by --target:

Image tag	Build target	Contents	Entrypoint
`example/tunnel-manager:mcp`	`--target mcp`	`tunnel-manager[mcp]` — connector-focused, includes `epistemic-graph[full]`; no model-orchestration stack	`tunnel-manager-mcp`
`example/tunnel-manager@sha256:<digest>`	`--target agent` (default)	`tunnel-manager[agent]` — agent runtime, model orchestration + `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 runs the connector-focused :mcp server; docker/agent.compose.yml runs the agent (immutable agent digest) with a co-located :mcp sidecar.

Knowledge-graph database (`epistemic-graph`)

Both [mcp] and [agent] carry the epistemic-graph engine through the required Agent Utilities core dependency (epistemic-graph[full]). The [mcp] extra keeps the server connector-focused; [agent] additionally enables model orchestration. Local deployments can use the bundled engine. For production or shared state, run epistemic-graph as a dedicated database service and configure the runtime to use it. Deployment recipes (single-node + Raft HA), connection configuration, and architecture diagrams are documented in the epistemic-graph deployment guide.

Documentation

The complete documentation is published as the official documentation site and is the recommended reference for installation, deployment, and day-to-day operation.

Page	Contents
Installation	pip, source, extras, prebuilt Docker image
Inventory	the shared `inventory.yaml` — default location, how to create it, formats, overrides
Deployment	run the MCP and agent servers, Compose, Caddy + Technitium, env config
Usage	the MCP tools, the `HostManager` / `Tunnel` API, the CLI
Overview	ecosystem role, distributed SSH swarm scaling, MCP configuration
Teleport Architecture	certificate, proxy and cross-OS connection model
Concepts	concept registry (`CONCEPT:TUN-*`)

AGENTS.md is the canonical contributor/agent guidance.

Maintainers

Maintained by the project contributor team. Package metadata intentionally uses a role address rather than personal identity.

Contribute

Contributions are welcome! Please ensure code quality by executing local checks before submitting pull requests:

Format code using ruff format .
Lint code using ruff check .
Validate type-safety with mypy .
Execute test suites using pytest

Deploy with `agent-utilities-deployment`

Provision this package with the consolidated agent-utilities-deployment workflow. It selects an installed-package, editable-source, or immutable-container path; records only runtime secret and TLS-profile references in AgentConfig; and runs doctor, registration, policy, observability, and rollback gates. Ask your agent to "deploy tunnel-manager with agent-utilities-deployment".

Install mode	Command
Installed package	`uv tool install "tunnel-manager[mcp]"`, then run `tunnel-manager-mcp`
Editable source	`uv pip install -e ".[agent]"`, then run `tunnel-manager-mcp`
Immutable container	deploy `registry.example.invalid/tunnel-manager@sha256:<digest>` through the operator-selected orchestrator

The repository embeds no deployment profile, credential value, certificate path, or environment-specific endpoint. Supply those at runtime through AgentConfig and the configured secret provider.

Governed capability contract

This package ships a compact canonical skill surface with specialist procedures kept as referenced workflows. The current MCP tools, skill metadata, connector_manifest.yml, ontology, mappings, shapes, fixtures, migrations, tool-schema fingerprints, and certification metadata form one versioned capability contract. Validate them together; do not rely on stale tool names or historical per-task skill wrappers.

Runtime endpoints, credentials, certificate trust, tenant identity, retention, and observability policy are deployment inputs and are never packaged values. See Configuration, trust, and privacy before enabling a network transport, connector ingestion, GraphOS delegation, or trace export.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.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

ResponsivenessNo issues

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
termalin-web A
in.termal
Run commands and read/write files on your servers over Termalin's keyless tunnels (hosted MCP).
Shell Access File Systems
81
Incwo MCPOAuth
io.github.incwo
Secure MCP server for exploring incwo CRM data, documents, and email workflows.
CRM Email Documentation Access
2

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 a month ago (2026-08-10 14:34 UTC)
7
335
98
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 4 months ago (2026-05-08 17:39 UTC)
117
1
MIT
MCP SSH Manager
Shell Access Command Line Networking & Infrastructure
bysonte
A
license
A
quality
C
maintenance
MCP server for managing remote servers via SSH, enabling command execution, file transfer, rsync, tunnels, health checks, backups, and database operations.
Updated 2 months ago (2026-07-14 00:42 UTC)
17
425
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 21 days ago (2026-08-21 17:08 UTC)
MIT

Tunnel Manager

CLI or API | MCP | Agent

Overview

Key Features

CLI or API

MCP

Available MCP Tools

Condensed action-routed tools (MCP_TOOL_MODE=condensed)

Verbose 1:1 API-mapped tools (MCP_TOOL_MODE=verbose or both)

Dynamic Tool Selection & Visibility

MCP Configuration Examples

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

Streamable-HTTP Transport (networked / production)

Additional Deployment Options

Inventory

Environment Variables

Package environment variables

Inherited agent-utilities variables (apply to every connector)

SSH connection & credentials

Inventory & parallelism

MCP server / transport

Tool toggles

Telemetry & governance

Agent runtime (full [agent] runtime only)

Agent

Running the Agent CLI

Docker Compose Orchestration

Security & Governance

Access Control & Policy Enforcement

Runtime Security Grid

Installation

Container images (:mcp vs :agent)

Knowledge-graph database (epistemic-graph)

Documentation

Maintainers

Contribute

Deploy with agent-utilities-deployment

Governed capability contract

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

Condensed action-routed tools (`MCP_TOOL_MODE=condensed`)

Verbose 1:1 API-mapped tools (`MCP_TOOL_MODE=verbose` or `both`)

Agent runtime (full `[agent]` runtime only)

Container images (`:mcp` vs `:agent`)

Knowledge-graph database (`epistemic-graph`)

Deploy with `agent-utilities-deployment`