tslink

Overview Schema Source Related Servers Discussions Admin

Enable the app portal

portal_enable

Idempotent

Enable a Tailnet-only home portal to control private app access by setting owner and admin identities, with gateway mode enabled by default.

Instructions

Enable an independent Tailnet-only home portal. New portals default to gateway mode. Omitted owner/admins preserve verified identities; first enrollment may leave owner unset. Optional admins can open all private apps. HTTP MCP requires the current exact portal owner before any owner/admin settings can change; other callers receive access_request_owner_required. Local CLI/stdio MCP is the bootstrap/recovery path; an unset owner cannot be claimed remotely. Confirm administrative identities with the owner. Grants and service registrations stay intact; the daemon hot-reloads the portal independently. Does not install or restart the daemon, send invites, or change tailnet ACLs. Funnel is explicitly refused. A pending result is saved configuration, not proof of a running URL; check status. Outside-tailnet visitors also need the home node shared through Tailscale.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "portal_enable"
  }
}

Input Schema

Name	Required	Description	Default
`owner`	No
`admins`	No
`funnel`	No	Always refused when true.
`gateway`	No	Enable the persistent gateway. Omit to retain current settings; false removes gateway mode only when no routes remain.
`hostname`	No		home
`gateway_tag`	No	Credentialed gateway tag; omitted retains the tag, empty restores the default.
`gateway_ports`	No	Gateway port range, initially 8443-8499; omitted retains the range.

Output Schema

Name	Required	Description	Default
`url`	No
`error`	No
`state`	Yes
`enabled`	Yes
`gateway`	No
`message`	No
`hostname`	No
`unavailable_apps`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.3.0Oct 27, 2026
- removedInput schema / required
```
Removed value: -[
-  "owner"
-]
```
- addedOutput schema / properties / message
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / unavailable_apps
```
Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
```
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?

Beyond annotations, it discloses important behavior: owner/admin identity preservation, first-enrollment owner caveat, HTTP MCP owner-required error, pending-result semantics, hot reloading, and unchanged grants/service registrations. These details materially improve safe invocation and are consistent with 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core action and every sentence carries operational meaning. It is dense and somewhat semicolon-heavy, but justified by the complexity of the tool and the number of important caveats.

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?

For a complex mutation with an output schema, it covers the major operational concerns: authorization, bootstrap/recovery, owner semantics, hot reload, pending status, outside-tailnet prerequisites, and explicit exclusions. Little needed for correct invocation 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 only 57%, but the description compensates by explaining owner/admin identity semantics, first-enrollment owner behavior, admin permissions, funnel refusal, and gateway defaults. It does not cover every parameter (e.g., hostname), so it is strong but not complete.

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 first sentence states a specific verb and resource: enabling an independent Tailnet-only home portal. It also names key scope/default behavior (gateway mode) and exclusions (Funnel refused), making the tool distinguishable from portal_disable and related portal tools.

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 gives clear usage context and several exclusions: local CLI/stdio is the bootstrap/recovery path, remote owner claiming is impossible, and the tool does not install/restart the daemon, send invites, or change tailnet ACLs. It stops short of explicitly routing the agent to sibling tools such as portal_disable or portal_route_add.

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