tslink

Overview Schema Source Related Servers Discussions Admin

Add a person and app access

people_add

Destructive

Grants a person access to chosen private HTTP or file apps, adding to existing grants while preserving omitted deadlines; members need no invite and outsiders accept a gateway invitation.

Instructions

Grant private HTTP/file apps to a person, adding to existing grants and preserving omitted deadlines. New grants default to 24h; never requires ack_never for members and device-invited guests. Explicit add can restore a revoked person after cleanup. The common access action verifies network membership, assigns gateway routes when enabled and prepares necessary device invitations. Members need no invitation; outsiders accept one gateway invitation or one per app when the gateway is off. API/identity/runtime failures return incomplete with retained local state. Requires owner authority for new people, routes and shares. Confirm apps, recipients and lifetime. TCP/public apps are refused. Bearer links are hidden unless print_links is true. Unknown POST outcomes require reconciliation; retries never blindly resend. Existing explicit legacy rights are preserved; incompatible open legacy policies conflict.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "who": "<who>",
      "apps": "<apps>"
    },
    "name": "people_add"
  }
}

Input Schema

Name	Required	Description
`qr`	No	Return QR payload text only; never image bytes.
`for`	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. New grants default to 24h; update omission preserves deadlines. Never requires ack_never for members and device-invited guests; finite guest grants retain the configured maximum.
`who`	Yes
`apps`	Yes	App names, or [all] for all current private HTTP/file apps. Required on add; omission on update keeps the app set.
`until`	No	Absolute deadline (RFC3339, YYYY-MM-DD, YYYY-MM-DDTHH:MM); conflicts with for.
`invite`	No	Compatibility field; necessary invitations are automatic.
`ack_never`	No
`qr_invite`	No	App invitation QR or @gateway; requires qr and print_links. Treat as a credential.
`print_links`	No

Output Schema

Name	Required	Description
`guide`	No
`access`	No
`person`	Yes
`portal`	No	Independent home portal configuration and exact runtime address when available.
`invites`	Yes
`message`	Yes
`complete`	Yes
`guide_zh`	No
`warnings`	No
`membership`	No
`qr_payload`	No
`qr_warning`	No
`invite_requirement`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv0.3.0Oct 27, 2026

changedInput schema / properties / for / description

Previous value: -"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. New grants default to 24h; update omission preserves deadlines. Never requires ack_never and a tailnet-member login; device-invited guests have the configured public maximum."New value: +"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. New grants default to 24h; update omission preserves deadlines. Never requires ack_never for members and device-invited guests; finite guest grants retain the configured maximum."

removedInput schema / properties / invite / default
```
Removed value: -false
```

addedInput schema / properties / invite / description

Added value: +"Compatibility field; necessary invitations are automatic."

addedOutput schema / properties / access

Added value: +{
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "access_state": {
+        "type": "string"
+      },
+      "app": {
+        "type": "string"
+      },
+      "message": {
+        "type": "string"
+      },
+      "url": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "app",
+      "access_state",
+      "message"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / membership

Added value: +{
+  "enum": [
+    "member",
+    "non_member"
+  ],
+  "type": "string"
+}

First observedv0.1.0Oct 19, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Beyond the annotations, the description discloses important behavioral traits: new grants default to 24h, omitted deadlines are preserved, ack_never is not required for members and device-invited guests, failures retain local state and return incomplete, bearer links are hidden unless print_links is true, and unknown POST outcomes require reconciliation. These are exactly the kinds of operational details an agent needs for a destructive, non-idempotent, open-world mutation.

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 front-loaded with purpose and nearly every clause carries relevant information. However, it is a single dense paragraph with semicolon-heavy jargon and compressed operational rules, which makes it harder to scan than it needs to be.

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?

An output schema exists, so return values need not be explained. The description covers authorization, invitation behavior, failure semantics, lifetime defaults, destructive constraints, and reconciliation guidance; the main remaining gap is the format of the who parameter.

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 67%, and the description adds useful semantic detail beyond the schema for apps, lifetime defaults and omission behavior, ack_never exceptions, and bearer-link visibility. It does not explain the who identifier format or the QR/invite fields in depth, but those are partly covered by the schema.

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 verb and resource: granting private HTTP/file apps to a person, with additive grant semantics. It is clear what the tool does, but it does not explicitly name sibling alternatives such as people_grant, people_update, or share, so it falls short of full sibling differentiation.

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?

It provides meaningful usage context: explicit add can restore a revoked person, members need no invitation while outsiders accept one, owner authority is required, and TCP/public apps are refused. It stops short of explicitly naming when to use this over sibling tools like people_grant or share.

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