Skip to main content
Glama
minte-app

mcp-untun

by minte-app
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Local

Untun MCP - Secure Tunnels for Local Servers NPM Version License

❌ Without Untun MCP

Local development can be frustrating when you need to expose your server to the internet:

  • ❌ Complex tunnel setup and command-line arguments

  • ❌ Hard to track which tunnels are running across different terminal sessions

  • ❌ No easy way to manage multiple tunnels from a single interface

Related MCP server: Portainer MCP

✅ With Untun MCP

Untun MCP creates and manages secure tunnels directly from your AI assistant:

  • 1️⃣ Simply tell your AI assistant to create a tunnel

  • 2️⃣ Get a public URL within seconds

  • 3️⃣ Manage all your tunnels with simple natural language commands

No complex CLI commands to remember. No more lost tunnels. Easy management of multiple tunnels.

⚠️ Disclaimer

This project uses the untun package from npm but is not officially affiliated with, endorsed by, or connected to Cloudflare or UnJS. This is an independent, community-developed MCP wrapper around the untun CLI tool.

🛠️ Getting Started

Requirements

  • Node.js >= v18.0.0

  • MCP-compatible client (Cursor, Claude Desktop, VS Code, etc.)

  • untun CLI tool (installed automatically as needed)

Install in Cursor

Go to: Settings -> Cursor Settings -> MCP -> Add new global MCP server

Paste the following configuration into your Cursor ~/.cursor/mcp.json file:

{
  "mcpServers": {
    "untun": {
      "command": "npx",
      "args": ["-y", "@minte-app/untun-mcp@latest"]
    }
  }
}

Install in VS Code

Install in VS Code (npx)

Add this to your VS Code MCP config file:

{
  "servers": {
    "Untun": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@minte-app/untun-mcp@latest"]
    }
  }
}

Installing via Smithery

To install Untun Secure Tunnel Manager for Claude Desktop automatically via Smithery:

npx -y @smithery/cli install @minte-app/untun-mcp --client claude

Install in Claude Desktop

Add this to your Claude Desktop claude_desktop_config.json file:

{
  "mcpServers": {
    "Untun": {
      "command": "npx",
      "args": ["-y", "@minte-app/untun-mcp@latest"]
    }
  }
}

🔨 How to Use

Ask your AI assistant to create a tunnel with natural language:

Create a tunnel to my localhost:3000 server

Check your running tunnels:

Show me all my active tunnels

Stop a specific tunnel:

Stop the tunnel to localhost:3000

Available Tools

  • start_tunnel: Creates a secure tunnel from a public internet address to your local server

    • url (required): The local URL to expose (e.g., http://localhost:3000)

    • name (optional): Custom name for the tunnel

  • stop_tunnel: Stops a running tunnel or all local tunnels

    • name (optional): Name of a specific tunnel to stop

  • list_tunnels: Lists all active tunnels including their status and details

Troubleshooting

Tunnel Not Starting

If your tunnel doesn't start, try these steps:

  1. Make sure your local server is running

  2. Check if there's already a tunnel running for that port

  3. Use list_tunnels to check the status of all tunnels

Remote Tunnels

Tunnels are tracked by hostname. If you see "remote" tunnels that can't be stopped, they are likely running on another machine. You'll need to stop them from the original machine.

Development

Clone the project and install dependencies:

npm install

Build:

npm run build

License

MIT

Available Tools

3 tools
list_tunnelsA

Lists all active tunnels including their status and details.

This tool will:

  • Show all tunnels in the registry

  • Auto-detect any running tunnels not in the registry

  • Display tunnel status, name, URLs, and runtime information

  • Indicate whether tunnels are local or running on remote machines

Use this tool to check the status of your tunnels and get their public URLs.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.4/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it shows all tunnels in the registry, auto-detects running tunnels not in the registry, displays specific details (status, name, URLs, runtime info), and indicates local vs. remote. However, it lacks information on permissions, rate limits, or error handling, which are important for a tool with no annotations.

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 well-structured and appropriately sized. It starts with a clear purpose statement, uses bullet points for key behaviors, and ends with usage guidance. Every sentence adds value without redundancy, making it efficient and easy to parse.

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

Completeness4/5

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

Given the tool's complexity (listing and auto-detecting tunnels), no annotations, no output schema, and 0 parameters, the description is mostly complete. It covers purpose, usage, and behavioral details but could benefit from mentioning output format or error cases. However, it provides sufficient context for basic use.

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

Parameters4/5

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

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately does not discuss parameters, focusing instead on the tool's behavior and output. Baseline for 0 parameters is 4, as it avoids unnecessary parameter details.

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 clearly states the specific action ('Lists all active tunnels') and resource ('tunnels'), including their status and details. It distinguishes from siblings by focusing on listing/status checking rather than starting or stopping tunnels, which are the sibling tools.

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

Usage Guidelines5/5

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

The description explicitly states when to use this tool: 'Use this tool to check the status of your tunnels and get their public URLs.' This provides clear context for usage versus the sibling tools (start_tunnel, stop_tunnel), which are for different operations.

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

start_tunnelA

Creates a secure tunnel from a public internet address to your local server.

This tool will:

  • Start an untun tunnel process connecting to your specified local URL

  • Return a public URL that can be used to access your local server

  • Allow you to name your tunnel for easier management

After starting a tunnel, wait a few seconds and use 'list_tunnels' to check its status and get the public URL.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameNoOptional custom name for the tunnel. If not provided, 'default' will be used.
urlYesThe local URL to expose (e.g., http://localhost:3000)

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: it starts a tunnel process, returns a public URL, allows naming for management, and mentions the need to wait and check status with another tool. It covers the core operational flow but doesn't mention potential errors, timeouts, or security implications.

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 well-structured and front-loaded with the core purpose, followed by bullet points for key behaviors and a clear follow-up instruction. Every sentence earns its place with no redundant information, making it efficient and easy to parse.

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

Completeness4/5

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

Given the tool's moderate complexity (creating a network tunnel), no annotations, and no output schema, the description does a good job covering the essential context: what it does, key behaviors, and follow-up steps. However, it doesn't describe the return value format or error conditions, leaving some gaps for a mutation tool with no structured output documentation.

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 schema already fully documents both parameters (name and url). The description adds marginal value by mentioning naming 'for easier management' and giving an example URL format, but doesn't provide additional semantic context beyond what the schema descriptions already state.

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 clearly states the specific action ('Creates a secure tunnel'), the resource ('from a public internet address to your local server'), and distinguishes from siblings by mentioning 'list_tunnels' for status checking. It explicitly describes what the tool does beyond just the name.

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

Usage Guidelines4/5

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

The description provides clear context on when to use this tool (to expose a local server) and references 'list_tunnels' as a follow-up action. However, it doesn't explicitly state when NOT to use it or mention alternatives like 'stop_tunnel' for tunnel management, leaving some guidance implicit rather than explicit.

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

stop_tunnelA

Stops a running tunnel or all local tunnels.

This tool will:

  • Stop a specific tunnel identified by name (if provided)

  • Stop all local tunnels (if no name is provided)

  • Only affects tunnels running on the current machine

  • Will not affect tunnels running on other machines

After stopping tunnels, you can use 'list_tunnels' to confirm they've been terminated.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameNoOptional name of a specific tunnel to stop. If not provided, all local tunnels will be stopped.

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations, the description carries full burden and discloses key behavioral traits: it only affects tunnels on the current machine, not others, and the outcome depends on name parameter presence. It doesn't mention error handling or permissions, but covers scope and conditional behavior adequately.

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?

Front-loaded with purpose, followed by bullet points for key behaviors, and ends with a usage tip. Every sentence earns its place, with no redundancy or fluff, making it efficient and well-structured.

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

Completeness4/5

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

Given no annotations, no output schema, and a simple parameter, the description is nearly complete: it explains purpose, usage, behavioral scope, and references a sibling tool. It lacks details on errors or return values, but for a stop action with one optional parameter, this is sufficient.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the semantic effect of the parameter: if provided, stops a specific tunnel; if not, stops all local tunnels. This clarifies the conditional logic beyond the schema's description.

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 clearly states the verb ('stops') and resource ('a running tunnel or all local tunnels'), distinguishing it from sibling tools list_tunnels (for listing) and start_tunnel (for starting). It specifies the scope ('local tunnels') and dual functionality (specific vs. all).

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

Usage Guidelines5/5

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

Explicit guidance is provided: use with a name to stop a specific tunnel, or without to stop all local tunnels. It distinguishes when to use this tool vs. list_tunnels for confirmation, and implicitly contrasts with start_tunnel for opposite actions.

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

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.5/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: list_tunnels for viewing status, start_tunnel for creation, and stop_tunnel for termination. The descriptions reinforce these distinct roles, making misselection unlikely.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern (list_tunnels, start_tunnel, stop_tunnel) with uniform snake_case styling. This predictability makes the tool set easy to understand and navigate.

Tool Count5/5

With 3 tools, this server is well-scoped for tunnel management, covering the essential lifecycle operations: list, start, and stop. Each tool earns its place without bloat or thinness.

Completeness5/5

The tool set provides complete CRUD-like coverage for tunnel management: list (read), start (create), and stop (delete). There are no obvious gaps, and the descriptions indicate seamless workflow integration.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

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/minte-app/untun-mcp'

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