Provides agents with a safe, structured window into the local Tailscale daemon for tailnet discovery, SSH config generation, port sharing via Serve/Funnel, and latency probing.
Discover the tailnet (tailnet_status): list this node and peers with hostnames, MagicDNS names, Tailscale IPv4/IPv6, OS, online status, last seen, exit-node flags, and tags (optionally online-only).
Generate SSH config (generate_ssh_config): emit ssh-config Host blocks for tailnet nodes (dry-run by default), or write them to ~/.ssh/tailscale_dev_config or idempotently into ~/.ssh/config between managed markers.
Share a local port (share_port): expose a local port tailnet-only via Tailscale Serve, or to the open internet via Funnel when explicitly enabled with public: true.
Inspect active shares (share_status): report current Serve/Funnel endpoints, including which are publicly exposed.
Stop sharing (stop_share): turn off a specific HTTPS serve endpoint or clear the entire serve/funnel configuration.
Measure reachability and latency (ping_all): ping peers concurrently and return a latency matrix distinguishing direct, DERP-relayed, peer-relayed, and unreachable paths.
Fail safely: return structured errors with code and exact remedy commands (missing binary, stopped daemon, login needed, timeouts, Funnel disabled, permission denied); Funnel and share tools can be disabled via env flags, and no credentials are ever read or stored.
Provides tools for tailnet discovery, SSH config generation, port sharing via Serve/Funnel, and latency matrices through the local Tailscale daemon.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@tailscale-mcp share port 3000"
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.
MCP server for safe programmatic access to the local Tailscale daemon: tailnet discovery, SSH config generation, port sharing via Serve/Funnel, and latency matrices.
Gives agents and developer tools a safe, structured window into the local Tailscale daemon over stdio. It shells out to the tailscale CLI (resolved from PATH, with fallbacks to the default install locations on Windows and macOS) and never handles auth keys or tailnet credentials: the CLI talks to the already-authenticated local daemon.
When the binary is missing, the daemon is stopped, or the device needs login, every tool returns a structured error with a code and the exact remedy command instead of throwing.
Claude Code: claude mcp add tailscale -- npx -y @tmhs/tailscale-mcp
Claude Desktop: download tailscale-mcp.mcpb from the latest release and open it. The install dialog has switches for read-only mode and Funnel.
Cursor / VS Code: use the buttons above.
MCP Registry: listed in the official MCP Registry as io.github.TMHSDigital/tailscale-mcp, so registry-aware clients and catalogs can find it.
Or add it to any MCP client's configuration by hand:
{
"mcpServers": {
"tailscale": {
"command": "npx",
"args": ["-y", "@tmhs/tailscale-mcp"]
}
}
}Requires Node 22+ (an active LTS) and an installed, logged-in Tailscale client.
The server looks for tailscale on PATH, then in the platform's default install locations: C:\Program Files\Tailscale\tailscale.exe on Windows, and /Applications/Tailscale.app/Contents/MacOS/Tailscale, /opt/homebrew/bin/tailscale, and /usr/local/bin/tailscale on macOS. Mac App Store installs therefore work without extra setup. To use a different binary, set TAILSCALE_MCP_BIN:
{
"mcpServers": {
"tailscale": {
"command": "npx",
"args": ["-y", "@tmhs/tailscale-mcp"],
"env": { "TAILSCALE_MCP_BIN": "/path/to/tailscale" }
}
}
}Every tailscale invocation is bounded, by default to 10 seconds. A hung daemon returns a structured TIMEOUT error instead of stalling the agent. Set TAILSCALE_MCP_TIMEOUT_MS to raise the limit for slow machines or very large tailnets. share_port waits up to 15 seconds and ping scales with count and timeoutMs; ping_all as a whole is capped at 45 seconds.
All settings are environment variables in the server's env block. Boolean flags accept 1/true/yes/on or 0/false/no/off. Any other value stops the server at startup, so a typo can never silently loosen a safety setting.
Variable | Default | Effect |
| off | Allows |
| off | Monitoring-only mode: |
| (search) | Path to the |
|
| Per-call CLI timeout. |
On Linux only root or the configured operator can change Serve/Funnel settings. If share_port or stop_share returns PERMISSION_DENIED, allow your user once:
sudo tailscale set --operator=$USERRelated MCP server: mcp-tailscale
Every tool declares MCP annotations, so clients can auto-approve the read-only ones and confirm the rest. Results come back as structuredContent, typed by each tool's outputSchema, with the same JSON repeated in a text block for older clients. The full definitions are in mcp-tools.json, which is generated from the server.
Tool | Read-only | Destructive | Idempotent | Open world |
| yes | no | yes | no |
| yes | no | yes | no |
| yes | no | yes | no |
| no (writes only with | no | yes | no |
| no | no | yes | only when Funnel is allowed |
| no | yes | yes | no |
Trimmed view of tailscale status --json: self node plus peers with hostname, MagicDNS name, Tailscale IPv4/IPv6, OS, online flag, last seen, exit-node flags, and tags. Input: optional onlineOnly.
{
"backendState": "Running",
"tailnet": "user@example.com",
"magicDNSSuffix": "tail1234.ts.net",
"self": {"hostname": "DEVPC", "dnsName": "devpc.tail1234.ts.net", "ipv4": "100.101.1.10"},
"peerCount": 3,
"peers": [
{"hostname": "raspi", "dnsName": "raspi.tail1234.ts.net", "ipv4": "100.101.1.20", "os": "linux", "online": true, "exitNodeOption": true, "tags": []}
]
}Emits ssh-config Host blocks for tailnet nodes (MagicDNS name preferred, Tailscale IP fallback). Dry-run by default: returns the generated text only. Inputs: write, target, onlineOnly, includeShared, user.
Each Host alias is the node's first MagicDNS label (raspi.tail1234.ts.net → raspi), falling back to a sanitized OS hostname ([a-z0-9-] only). Colliding aliases get a numeric suffix and are listed under renamed. Mullvad exit nodes, and nodes of users you share with (unless includeShared: true), are left out and listed under skipped.
write: true writes the dedicated file ~/.ssh/tailscale_dev_config and returns the Include tailscale_dev_config instruction for ~/.ssh/config (never applied automatically).
target: "user_ssh_config" (with write: true) edits ~/.ssh/config directly, idempotently, between # BEGIN tailscale-mcp and # END tailscale-mcp markers. Content outside the markers is never touched. If the markers are malformed (orphaned, reversed, or duplicated) the tool returns SSH_CONFIG_MARKERS_CORRUPT and writes nothing.
Writes are atomic (temp file + rename), the previous ~/.ssh/config is kept as config.tailscale-mcp.bak, new files are created 0600 (existing modes are kept), and a symlinked config is written through rather than replaced.
{
"dryRun": true,
"hostCount": 2,
"configText": "# BEGIN tailscale-mcp\nHost raspi\n HostName raspi.tail1234.ts.net\n\nHost devbox\n HostName devbox.tail1234.ts.net\n# END tailscale-mcp"
}Shares a local port via Tailscale Serve. Tailnet-only by default. Inputs: port (required), public, path.
{"port": 3000, "public": false, "scope": "tailnet-only (Serve)", "urls": ["https://devpc.tail1234.ts.net/"]}public: true switches to Funnel and exposes the port to the open internet. It's refused unless TAILSCALE_MCP_ALLOW_FUNNEL=1 is set; see the security notes below.
Reports active Serve/Funnel sessions as structured endpoints, parsed from tailscale serve status --json. Each endpoint has its own public flag, which is true when Funnel exposes it to the internet, and publicExposure is true when anything is public:
{
"active": true,
"publicExposure": true,
"endpoints": [
{"url": "https://devpc.tail1234.ts.net/", "host": "devpc.tail1234.ts.net", "httpsPort": 443, "scheme": "https", "path": "/", "target": "http://127.0.0.1:3000", "targetType": "proxy", "public": true, "foreground": false}
]
}Raw TCP forwards appear under tcpForwards. On CLIs too old for --json, the text status comes back under status and publicExposure is null.
Stops shares. Name exactly one target:
httpsPort and/or path turns off one mount. httpsPort is the serve port shown in share_status (default 443, not the proxied local port), and path is the mount path given to share_port (default /). For example, {"path": "/api"} undoes share_port {"port": 3000, "path": "/api"}.
mine: true stops only the shares share_port created during this server session.
all: true clears the entire serve/funnel configuration, including shares you set up outside this server.
With no arguments nothing is stopped: the tool returns TARGET_REQUIRED and lists the active endpoints. Every successful call returns removed (the endpoints that went away) and remaining (the share_status view afterwards).
Mount paths must start with / and use only letters, digits, and . _ ~ - /, with no . or .. segments. A trailing slash is dropped.
Concurrent tailscale ping against peers (bounded to 5 in flight, with a per-ping timeout). Inputs: count, timeoutMs, onlineOnly (default true).
{
"pinged": 2,
"reachable": 1,
"timedOut": false,
"matrix": [
{"hostname": "raspi", "target": "100.101.1.20", "reachable": true, "latencyMs": 3, "path": "direct", "via": "192.168.1.20:41641", "attempts": 3, "replies": 3},
{"hostname": "exitbox", "target": "100.101.1.40", "reachable": false, "latencyMs": null, "path": null, "via": null, "attempts": 1, "replies": 0}
]
}path is direct (peer-to-peer), derp (relayed through a Tailscale DERP server), peer-relay (relayed through one of your nodes), or unknown, so an agent can tell "works but relayed" from "fast direct path". tailscale ping keeps pinging until a direct path comes up, so path and latencyMs describe the last reply, i.e. the settled path. The whole call is capped at 45 seconds: peers that haven't answered by then come back with an error and timedOut: true.
An agent asked to "deploy this to my dev VPS and show me the result" can do the whole discovery leg through this server:
tailnet_status {"onlineOnly": true} finds the VPS node and its MagicDNS name (devbox.tail1234.ts.net), with no hardcoded IPs.
generate_ssh_config {"write": true, "user": "deploy"} writes ~/.ssh/tailscale_dev_config; the agent shows the returned one-line Include instruction, and after the user adds it, ssh devbox resolves through the tailnet.
ping_all confirms the node is reachable and whether the path is direct or relayed before starting a large transfer.
After deploying, share_port {"port": 8080} returns a tailnet-only URL teammates on the tailnet can open. Nothing touches the public internet unless you have enabled Funnel with TAILSCALE_MCP_ALLOW_FUNNEL=1 and the agent is explicitly told to pass public: true.
share_port defaults to tailnet-only Serve. Nothing is reachable from outside your tailnet.
Funnel is off unless you turn it on. public: true uses Tailscale Funnel, which makes the URL reachable by anyone on the internet, not just your tailnet. A default install refuses it with FUNNEL_DISABLED, so a prompt-injected agent can't expose a port by itself. To allow it, set TAILSCALE_MCP_ALLOW_FUNNEL=1 in the client config. Even then the tool description carries the warning, so agents surface it before acting.
TAILSCALE_MCP_READONLY=1 removes the share tools entirely, for agents that should only observe.
Serve and Funnel must be enabled per-tailnet in the admin console. When they are not, the tool returns a structured SERVE_NOT_ENABLED error containing the exact enablement URL and changes nothing.
stop_share {"all": true} is the kill switch: it clears the entire serve/funnel configuration. Calling it without arguments never deletes anything.
This server never reads or stores TS_AUTHKEY or any other credential.
npm install
npm run build # tsc
npm test # vitest, fully offline (fixture-driven, no live tailnet)
npm run typecheck # src and tests
npm run gen:tools # regenerate mcp-tools.json after changing a toolTo try your build against your own tailnet, run it in the MCP Inspector:
npm run build
npx @modelcontextprotocol/inspector node dist/index.jsProvider adapter pattern: src/providers/types.ts defines the TailscaleProvider interface; CliProvider (the only implementation today) spawns the CLI through an injectable process runner so tests never launch a real binary. The interface leaves room for a future LocalAPI provider speaking HTTP over the local socket or named pipe.
tailscale-mcp/
src/index.ts stdio entry point
src/config.ts Environment variable parsing
src/providers/ TailscaleProvider interface + CliProvider
src/tools/ MCP tool registrations and output schemas
src/sshconfig.ts Pure ssh-config rendering and managed-block editing
src/__tests__/ vitest suites (offline, mocked CLI runner)
test/fixtures/ Sanitized CLI output used by the tests
mcp-tools.json Generated tool definitions (npm run gen:tools)
docs/ GitHub Pages site
.github/ CI/CD workflowsSee ROADMAP.md for the full project roadmap.
See CONTRIBUTING.md for guidelines.
CC-BY-NC-ND-4.0 -- see LICENSE for details.
Built by TMHSDigital
Generate ssh-config Host blocks for tailnet nodes (MagicDNS name preferred, Tailscale IP fallback). Dry-run by default: returns the generated config text only and writes nothing. With write=true it writes a dedicated file (~/.ssh/tailscale_dev_config) and returns instructions for adding an Include line to ~/.ssh/config (never applied automatically). Direct editing of ~/.ssh/config itself additionally requires target="user_ssh_config" and is idempotent between managed markers, never touching content outside them.
| Name | Required | Description | Default |
|---|---|---|---|
| user | No | Remote user to set on every Host block | |
| write | No | Actually write the config (default: false = dry-run, text only) | |
| target | No | Write target: "dedicated_file" (default, ~/.ssh/tailscale_dev_config) or "user_ssh_config" (edit ~/.ssh/config between managed markers) | |
| onlineOnly | No | Only include peers that are currently online (default: false) | |
| includeShared | No | Include nodes of users this node is shared with (default: false). Mullvad exit nodes are always skipped. |
| Name | Required | Description |
|---|---|---|
| note | No | |
| wrote | No | File written; null when nothing changed |
| backup | No | |
| dryRun | Yes | |
| renamed | No | |
| skipped | No | |
| hostCount | Yes | |
| configText | No | Generated config (dry run) |
| instructions | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare non-read-only, idempotent, and non-destructive, and the description adds substantial context beyond them: dry-run writes nothing, the Include line is never applied automatically, and direct ~/.ssh/config editing is idempotent only between managed markers and leaves outside content untouched. This is exactly the mutation-safety detail an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences, front-loaded with the dry-run default before the write and target details. Every clause carries information, though the final sentence is long enough that it could be split for easier parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation-capable tool with five optional parameters, the description covers defaults, side effects, write targets, and safety boundaries. An output schema exists, so return values need not be described, and nothing an agent needs in order to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: 'user' is applied to every Host block, 'write' toggles dry-run versus real output, and 'target' is coupled to the write path. It also notes that Mullvad exit nodes are always skipped, which is behavioral nuance not present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Generate ssh-config Host blocks for tailnet nodes') and scopes it to MagicDNS names with Tailscale IP fallback. No sibling tool generates SSH config, so the purpose is immediately distinguishable from tailnet_status, share_*, and ping_all.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly explains the default dry-run behavior versus write=true, and when to choose target="user_ssh_config" instead of the dedicated file. It lacks an explicit 'do not use this for X, use sibling Y' exclusion, but the mode-selection guidance is strong enough that an agent can pick correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ping tailnet peers concurrently (bounded to 5 at a time, with a per-ping timeout) and return a latency matrix: node, latency ms of the settled path, path (direct, DERP relay, or peer relay), or unreachable. Defaults to online peers only. The whole call is capped at 45s; peers not answered by then are reported with an error and timedOut is true.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Ping attempts per peer (default: 1) | |
| timeoutMs | No | Per-ping timeout in milliseconds (default: 5000) | |
| onlineOnly | No | Only ping peers reported online (default: true) |
| Name | Required | Description |
|---|---|---|
| matrix | Yes | |
| pinged | Yes | |
| timedOut | Yes | |
| reachable | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnly/idempotent annotations by disclosing concurrency bounding (5 at a time), a per-ping timeout, a hard 45s cap on the whole call, and exactly how unanswered peers are reported (error plus timedOut=true). These are execution traits an agent cannot get from the annotations or schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with what the tool does and its concurrency model, then the return shape, then the timeout failure mode. No filler or repetition of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists and the description still summarizes the returned fields and the timeout/error case. Combined with the concurrency and cap details, an agent has everything needed to call this correctly and interpret results without further lookup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds real meaning by tying timeoutMs to the per-ping timeout and explaining how the 45s overall cap interacts with attempts, and by restating that the default scope is online peers. It does not cover the 'count' attempts parameter explicitly in prose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb+resource ('Ping tailnet peers concurrently') and immediately defines the output shape (latency matrix: node, latency, path, unreachable). This is clearly distinguishable from siblings like tailnet_status or share_status, which do not measure per-peer latency.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the diagnostic use case ('latency matrix') and states the default of online-only pinging, but never says when to prefer this over tailnet_status or when a targeted ping is a better choice. Usage is inferable rather than explicit, and no alternatives or exclusions are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report the state of the local tailnet: this node plus all peers with hostname, MagicDNS name, Tailscale IPv4/IPv6, OS, online flag, last seen, exit-node flags, and tags. Returns a structured error with the exact fix command when the tailscale binary is missing, the daemon is stopped, or the device needs login.
| Name | Required | Description | Default |
|---|---|---|---|
| onlineOnly | No | Only include peers that are currently online (default: false) |
| Name | Required | Description |
|---|---|---|
| self | Yes | |
| peers | Yes | |
| health | Yes | |
| tailnet | Yes | |
| peerCount | Yes | Total peers, before any onlineOnly filter |
| backendState | Yes | |
| magicDNSSuffix | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered by structured data. The description earns credit for going beyond that by disclosing failure behavior: a structured error carrying the exact fix command for a missing binary, stopped daemon, or required login. That is precisely the kind of context annotations cannot express.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action, then the failure modes. Slightly dense in the field enumeration, but every clause carries information an agent would otherwise have to infer from the output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be spelled out, and the description correctly spends its budget on preconditions and error recovery instead. The only shortfall is the absence of guidance on how to handle a large tailnet or whether results are paginated, which is minor for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With a single parameter at 100% schema description coverage, the schema already documents onlineOnly and its default. The description adds nothing about filtering behavior or how onlineOnly interacts with the returned peer list, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("Report the state of the local tailnet") and enumerates exactly what is covered: node, peers, hostnames, MagicDNS names, IPs, OS, online flag, exit-node flags, tags. This is far more than a restated title. It doesn't explicitly distinguish itself from siblings like share_status or ping_all, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The read-only diagnostic framing implies when to reach for it, but there is no explicit "use this when..." statement and no mention of when to prefer share_status or ping_all instead. The implied usage is clear enough for an agent to proceed, but the routing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.4.0generate_ssh_config3 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / includeSharedAdded value: +{
+ "description": "Include nodes of users this node is shared with (default: false). Mullvad exit nodes are always skipped.",
+ "type": "boolean"
+}Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "backup": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "configText": {
+ "description": "Generated config (dry run)",
+ "type": "string"
+ },
+ "dryRun": {
+ "type": "boolean"
+ },
+ "hostCount": {
+ "type": "number"
+ },
+ "instructions": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "renamed": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "from": {
+ "type": "string"
+ },
+ "hostname": {
+ "type": "string"
+ },
+ "to": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "from",
+ "to",
+ "hostname"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "skipped": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "dnsName": {
+ "type": "string"
+ },
+ "hostname": {
+ "type": "string"
+ },
+ "reason": {
+ "enum": [
+ "no_address",
+ "mullvad_exit_node",
+ "shared_node"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "hostname",
+ "dnsName",
+ "reason"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "wrote": {
+ "description": "File written; null when nothing changed",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "dryRun",
+ "hostCount"
+ ],
+ "type": "object"
+}ping_all2 fields changedInput schema / additionalPropertiesRemoved value: -falseOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "matrix": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "attempts": {
+ "type": "number"
+ },
+ "dnsName": {
+ "type": "string"
+ },
+ "error": {
+ "type": "string"
+ },
+ "hostname": {
+ "type": "string"
+ },
+ "latencyMs": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "path": {
+ "anyOf": [
+ {
+ "enum": [
+ "direct",
+ "derp",
+ "peer-relay",
+ "unknown"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "reachable": {
+ "type": "boolean"
+ },
+ "replies": {
+ "type": "number"
+ },
+ "target": {
+ "type": "string"
+ },
+ "via": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "hostname",
+ "dnsName",
+ "target",
+ "reachable",
+ "latencyMs",
+ "path",
+ "via",
+ "attempts",
+ "replies"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "pinged": {
+ "type": "number"
+ },
+ "reachable": {
+ "type": "number"
+ },
+ "timedOut": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "pinged",
+ "reachable",
+ "timedOut",
+ "matrix"
+ ],
+ "type": "object"
+}share_port5 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / path / descriptionPrevious value: -"HTTPS mount path on the serve endpoint (default: \"/\")"New value: +"HTTPS mount path on the serve endpoint, e.g. \"/api\" (default: \"/\")"Input schema / properties / path / patternAdded value: +"^\\/[A-Za-z0-9._~\\-/]*$"Input schema / properties / public / descriptionPrevious value: -"Expose to the open internet via Funnel (default: false = tailnet-only Serve). DANGEROUS: public=true makes the port reachable by anyone on the internet."New value: +"Expose to the open internet via Funnel (default: false = tailnet-only Serve). DANGEROUS: public=true makes the port reachable by anyone on the internet. Disabled unless TAILSCALE_MCP_ALLOW_FUNNEL=1."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "port": {
+ "type": "number"
+ },
+ "public": {
+ "type": "boolean"
+ },
+ "scope": {
+ "type": "string"
+ },
+ "urls": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "port",
+ "public",
+ "scope",
+ "urls"
+ ],
+ "type": "object"
+}share_status1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "active": {
+ "type": "boolean"
+ },
+ "endpoints": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "foreground": {
+ "type": "boolean"
+ },
+ "host": {
+ "type": "string"
+ },
+ "httpsPort": {
+ "type": "number"
+ },
+ "path": {
+ "type": "string"
+ },
+ "public": {
+ "type": "boolean"
+ },
+ "scheme": {
+ "enum": [
+ "https",
+ "http"
+ ],
+ "type": "string"
+ },
+ "target": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "targetType": {
+ "enum": [
+ "proxy",
+ "path",
+ "text",
+ "redirect",
+ "unknown"
+ ],
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "url",
+ "host",
+ "httpsPort",
+ "scheme",
+ "path",
+ "target",
+ "targetType",
+ "public",
+ "foreground"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "publicExposure": {
+ "description": "True when any endpoint is exposed via Funnel; null if unknown (old CLI)",
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "status": {
+ "description": "Raw text status, only on CLIs without --json",
+ "type": "string"
+ },
+ "tcpForwards": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "foreground": {
+ "type": "boolean"
+ },
+ "port": {
+ "type": "number"
+ },
+ "public": {
+ "type": "boolean"
+ },
+ "target": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "port",
+ "target",
+ "public",
+ "foreground"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "active",
+ "publicExposure",
+ "endpoints"
+ ],
+ "type": "object"
+}stop_share6 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / allAdded value: +{
+ "description": "Clear the ENTIRE serve/funnel config, including shares not created by this server",
+ "type": "boolean"
+}Input schema / properties / httpsPort / descriptionPrevious value: -"HTTPS serve port to turn off (as shown in share_status). Omit to clear everything."New value: +"HTTPS serve port of the mount to turn off (default 443 when path is given)"Input schema / properties / mineAdded value: +{
+ "description": "Stop only the shares created by share_port in this session",
+ "type": "boolean"
+}Input schema / properties / pathAdded value: +{
+ "description": "Mount path to turn off, as passed to share_port (default: \"/\")",
+ "pattern": "^\\/[A-Za-z0-9._~\\-/]*$",
+ "type": "string"
+}Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "failures": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "error": {
+ "type": "string"
+ },
+ "httpsPort": {
+ "type": "number"
+ },
+ "path": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "httpsPort",
+ "path",
+ "error"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "remaining": {
+ "additionalProperties": false,
+ "properties": {
+ "active": {
+ "type": "boolean"
+ },
+ "endpoints": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "foreground": {
+ "type": "boolean"
+ },
+ "host": {
+ "type": "string"
+ },
+ "httpsPort": {
+ "type": "number"
+ },
+ "path": {
+ "type": "string"
+ },
+ "public": {
+ "type": "boolean"
+ },
+ "scheme": {
+ "enum": [
+ "https",
+ "http"
+ ],
+ "type": "string"
+ },
+ "target": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "targetType": {
+ "enum": [
+ "proxy",
+ "path",
+ "text",
+ "redirect",
+ "unknown"
+ ],
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "url",
+ "host",
+ "httpsPort",
+ "scheme",
+ "path",
+ "target",
+ "targetType",
+ "public",
+ "foreground"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "publicExposure": {
+ "description": "True when any endpoint is exposed via Funnel; null if unknown (old CLI)",
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "status": {
+ "description": "Raw text status, only on CLIs without --json",
+ "type": "string"
+ },
+ "tcpForwards": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "foreground": {
+ "type": "boolean"
+ },
+ "port": {
+ "type": "number"
+ },
+ "public": {
+ "type": "boolean"
+ },
+ "target": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "port",
+ "target",
+ "public",
+ "foreground"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "active",
+ "publicExposure",
+ "endpoints"
+ ],
+ "type": "object"
+ },
+ "removed": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "foreground": {
+ "type": "boolean"
+ },
+ "host": {
+ "type": "string"
+ },
+ "httpsPort": {
+ "type": "number"
+ },
+ "path": {
+ "type": "string"
+ },
+ "public": {
+ "type": "boolean"
+ },
+ "scheme": {
+ "enum": [
+ "https",
+ "http"
+ ],
+ "type": "string"
+ },
+ "target": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "targetType": {
+ "enum": [
+ "proxy",
+ "path",
+ "text",
+ "redirect",
+ "unknown"
+ ],
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "url",
+ "host",
+ "httpsPort",
+ "scheme",
+ "path",
+ "target",
+ "targetType",
+ "public",
+ "foreground"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "stopped": {
+ "anyOf": [
+ {
+ "const": "all",
+ "type": "string"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "httpsPort": {
+ "type": "number"
+ },
+ "path": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "httpsPort",
+ "path"
+ ],
+ "type": "object"
+ },
+ {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "httpsPort": {
+ "type": "number"
+ },
+ "path": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "httpsPort",
+ "path"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ ]
+ }
+ },
+ "required": [
+ "stopped",
+ "removed",
+ "remaining"
+ ],
+ "type": "object"
+}tailnet_status2 fields changedInput schema / additionalPropertiesRemoved value: -falseOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "backendState": {
+ "type": "string"
+ },
+ "health": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "magicDNSSuffix": {
+ "type": "string"
+ },
+ "peerCount": {
+ "description": "Total peers, before any onlineOnly filter",
+ "type": "number"
+ },
+ "peers": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "dnsName": {
+ "type": "string"
+ },
+ "exitNode": {
+ "type": "boolean"
+ },
+ "exitNodeOption": {
+ "type": "boolean"
+ },
+ "hostname": {
+ "type": "string"
+ },
+ "ipv4": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "ipv6": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "lastSeen": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "online": {
+ "type": "boolean"
+ },
+ "os": {
+ "type": "string"
+ },
+ "sharee": {
+ "type": "boolean"
+ },
+ "tags": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "hostname",
+ "dnsName",
+ "ipv4",
+ "ipv6",
+ "os",
+ "online",
+ "lastSeen",
+ "exitNode",
+ "exitNodeOption",
+ "tags",
+ "sharee"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "self": {
+ "additionalProperties": false,
+ "properties": {
+ "dnsName": {
+ "type": "string"
+ },
+ "exitNode": {
+ "type": "boolean"
+ },
+ "exitNodeOption": {
+ "type": "boolean"
+ },
+ "hostname": {
+ "type": "string"
+ },
+ "ipv4": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "ipv6": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "lastSeen": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "online": {
+ "type": "boolean"
+ },
+ "os": {
+ "type": "string"
+ },
+ "sharee": {
+ "type": "boolean"
+ },
+ "tags": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "hostname",
+ "dnsName",
+ "ipv4",
+ "ipv6",
+ "os",
+ "online",
+ "lastSeen",
+ "exitNode",
+ "exitNodeOption",
+ "tags",
+ "sharee"
+ ],
+ "type": "object"
+ },
+ "tailnet": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "backendState",
+ "tailnet",
+ "magicDNSSuffix",
+ "health",
+ "self",
+ "peerCount",
+ "peers"
+ ],
+ "type": "object"
+}v0.1.0generate_ssh_configping_allshare_portshare_statusstop_sharetailnet_statusScored across 6 tools
Each tool targets a distinct resource and action: tailnet_status (node/peer state), share_status (Serve/Funnel sessions), share_port (create share), stop_share (remove share), generate_ssh_config (SSH config), ping_all (latency). Even the two status tools split cleanly by domain (tailnet topology vs. serve endpoints).
All names use snake_case, with a coherent share_* family (share_status, share_port, stop_share). Minor deviation: some tools use noun-led status names rather than strict verb_noun, and stop_share breaks the prefix pattern slightly, but the convention remains readable and predictable.
Six tools tightly scoped to tailnet inspection, SSH config generation, and Serve/Funnel lifecycle. Every tool earns its place with no redundancy, well within the ideal range.
Covers the core lifecycle: state inspection, SSH config generation, and full share create/status/stop plus connectivity testing. There are minor gaps (no exit-node selection or peer management operations), but the primary workflows are fully supported.
Tailscale device, route, DNS, key, user, and ACL management over MCP and CLI.
Read devices, users, keys, ACLs and DNS for a tailnet; manage devices, routes and auth keys.
MCP server for mandates, delegation, policy-gated execution, credential grants, and audit.
Secure and manage MCP servers through the Speakeasy AI Control Plane from your agent.