tslink

Overview Schema Source Related Servers Discussions Admin

Share a local app, file or folder

share

Expose a local file, directory, or HTTP port on your private Tailscale network so other tailnet devices can open it; optionally publish publicly via Funnel after explicit confirmation.

Instructions

Setting funnel true on this tool publishes the target to the entire public internet, so ask the user before doing that; with funnel false (the default) it exposes a local directory, one file, or an HTTP port only on the user's private Tailscale network. A directory target serves every file under it and is browsable; a regular-file target serves only that file and answers 404 for its siblings. Without allow, every member of the user's tailnet can read the share; pass allow to restrict it to named principals. Use this after creating a local page or report that the user wants to open on another tailnet device. If status is needs_login, open auth_url in a browser and retry after authorization.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	No	Optional requested DNS-label service name. A matching target is reused only if it already has this name; unrelated name collisions receive a numeric suffix.
`tags`	No	ACL tags applied to the tailnet node, each prefixed tag:. Defaults to the configured default tag.
`allow`	No	Principals allowed to reach the share over HTTP: email addresses, or tag:<name> ACL tags. Omitting it leaves the share readable by every member of the user's tailnet. Rejected together with funnel.
`funnel`	No	Publish to the public internet through Tailscale Funnel. Requires public_ack true, an HTTP port target, and no allow entries.
`target`	Yes	Existing file or directory path, bare port from 1 to 65535, or host:port HTTP target. A file path shares that one file; a directory path shares everything under it. The daemon will proxy to any address it can reach on its own network; link-local and cloud-metadata addresses are refused only as literal IP addresses (unspecified addresses too) or the metadata.google.internal hostname: hostnames are not resolved and nothing is checked at connect time, so a name that resolves to one of those addresses is accepted.
`ephemeral`	No	Keep true for temporary shares; set false only when the user wants durable tailnet node state.
`funnel_ttl`	No	Relative lifetime (descending unique units w,d,h,m,s,ms,us,ns) or until <RFC3339\|YYYY-MM-DD\|YYYY-MM-DDTHH:MM>. Local unless offset given; DST gaps/folds require an offset. Minimum 1h. Presets: 1h, 8h, 24h, 3d, 7d. Default 24h; guest/public maximum defaults to 7d, configurable in durations.public_max. Never refused. Omission on add preserves an existing deadline.
`public_ack`	No	Explicit acknowledgement that funnel exposes the target publicly. funnel true without it is rejected.
`preserve_host`	No	Proxy only: forward this node's trusted canonical external name in Host and X-Forwarded-Host; fail closed if unavailable. Default false keeps upstream Host rewriting.
`request_limits`	No
`no_daemon_install`	No	Require an already running TSLink service; do not automatically install its background service.

Output Schema

TableJSON Schema

Name	Required	Description
`url`	No
`name`	Yes	Actually registered service name, always present on success, including needs_login. Use this name for url and unshare; never guess or fall back to the requested name.
`status`	Yes
`auth_url`	No
`exposure`	Yes
`warnings`	No
`preserve_host`	No	Proxy only: forward this node's trusted canonical external name in Host and X-Forwarded-Host; fail closed if unavailable. Default false keeps upstream Host rewriting.
`funnel_rearmed`	No	True when the reused share's Funnel deadline had already passed and this call re-armed it with the requested funnel_ttl.
`request_limits`	No
`daemon_installed`	No	Present only when this call installed TSLink's background service, a persistent OS autostart entry; absent when the service already ran or no_daemon_install was true.
`funnel_expires_at`	No	When the public Funnel of this share stops. Absent when exposure.kind is not public_funnel, and absent for a public_funnel share that never expires. A reused share keeps its own deadline, which can be sooner than the funnel_ttl this call asked for.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 19, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only declare readOnly=false, openWorld=true, destructive=false. The description goes well beyond that, disclosing the public-exposure consequence of funnel, the privacy default, that a directory share is browsable and serves every file under it while a file share 404s siblings, that omitting allow grants every tailnet member read access, and a needs_login/auth_url recovery path. This is rich behavioral context the annotations cannot convey.

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?

Four dense sentences, appropriately front-loading the highest-risk fact (funnel publishes to the public internet, ask the user). Every clause carries decision-relevant information, though the directory/404 sentence is slightly long and could be split.

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

Completeness5/5

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

Given 11 parameters including a nested request_limits object, an output schema, and 91% schema coverage, the description covers the decision-critical behaviors (funnel consent, allow scoping, target type semantics, login recovery) while leaving field-level detail to the schema. Nothing an agent needs to invoke it safely is missing.

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 already 91% and the property descriptions are unusually detailed (e.g. target's link-local/metadata refusal rules), so the baseline is 3. The description adds meaning on top: the funnel-vs-default exposure distinction, the directory/file serving behavior, and the allow default of tailnet-wide read access.

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?

States a specific verb ('share') and concrete resources (local app, file, or folder), and immediately distinguishes the two exposure modes: funnel=true publishes to the public internet, funnel=false exposes only on the private tailnet. An agent can tell exactly what this does versus the inverse sibling 'unshare'.

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?

Gives clear when-to-use guidance ('after creating a local page or report that the user wants to open on another tailnet device') plus an explicit consent precondition for the public-funnel case ('ask the user before doing that'). No explicit when-not-to-use or named alternative tool, which keeps it short of a 5.

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