Tunnel Manager

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v2.1.0
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.
Average 2.7/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 79 commits in the last 12 weeks
- Last stable release on July 12, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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.
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.
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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![tunnel-manager MCP server](https://glama.ai/mcp/servers/Knuckles-Team/tunnel-manager/badges/card.svg)](https://glama.ai/mcp/servers/Knuckles-Team/tunnel-manager)

Score Badge

Copy to your README.md:

[![tunnel-manager MCP server](https://glama.ai/mcp/servers/Knuckles-Team/tunnel-manager/badges/score.svg)](https://glama.ai/mcp/servers/Knuckles-Team/tunnel-manager)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Knuckles-Team/tunnel-manager'

If you have feedback or need assistance with the MCP directory API, please join our Discord server