tslink

Overview Schema Source Related Servers Discussions Admin

Update a person's app access

people_update

Destructive

Edit an existing non-revoked person's app access and expiry in tslink; omit fields to preserve current apps and deadlines.

Instructions

Edit an existing non-revoked person: apps replaces the app set (omit to keep it); omitted for/until keeps deadlines. Use people_add for a new person and people_grant/people_revoke for one app. Confirm the person, apps and expiry with the user. Newly scoped apps deny callers without a grant or explicit legacy allow rule. TCP cannot enforce people; public Funnel is refused. invite creates one gateway device invitation for routed apps and per-app invitations for the rest; confirm first. invite alone resumes unfinished work; completed invitations are reused; no exactly-once guarantee. Invite needs a user-owned API token; OAuth cannot create device invites. Bearer links stay hidden unless print_links is true. No elevated exit-node, multi-use or tailnet-role permissions; use invite tools for those. Incomplete invitations keep local grants. Unknown POSTs need owner-verified reconcile_invites after remote listing. replace_invites retires a vanished or stale invitation and preserves grants and deadlines; invite only, no apps/for/until. Logins: nonempty, no controls/internal whitespace; outer ASCII whitespace trimmed, ASCII lowercased, no Unicode folding/normalization; invalid UTF-8 is a usage_error.

Input Schema

TableJSON 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 and a tailnet-member login; device-invited guests have the configured public maximum.
`who`	Yes
`apps`	No	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
`ack_never`	No
`qr_invite`	No	App invitation QR or @gateway; requires qr and print_links. Treat as a credential.
`print_links`	No
`replace_invites`	No	Update with invite only, no apps/for: owner-confirmed app or @gateway to recorded old invite ID. Requires remote absence for the same NodeID. A stale gateway invitation can be retired as target_gone when current gateway ownership is proven, including accepted shares; preserves grants and deadlines.
`reconcile_invites`	No	Update --invite only: owner-verified app or @gateway to invite ID mapping, or none after checking absence. Unknown POSTs cannot be retried blindly.

Output Schema

TableJSON Schema

Name	Required	Description
`guide`	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
`qr_payload`	No
`qr_warning`	No
`invite_requirement`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 19, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Far beyond the annotations (which only mark it as a destructive, non-idempotent, open-world write), the description discloses invite lifecycle behavior (resumes unfinished work, reuses completed invitations, no exactly-once guarantee), the requirement of a user-owned API token (OAuth cannot create device invites), that bearer links stay hidden unless print_links is true, that incomplete invitations keep local grants, and that replacement preserves grants and deadlines.

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 purpose and routing guidance are front-loaded, and the dense telegraphic clauses are information-bearing rather than filler. It is long and somewhat run-on, which costs some readability, but little of it is redundant.

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?

For an 11-parameter tool with nested objects, anyOf requirements, and a true output schema, the description covers the operational essentials an agent needs: what mutates, what is preserved, confirmation duties, and invite edge cases. A few peripheral parameters rely on the schema, which is acceptable given coverage and the existing output schema.

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 64%, and the description meaningfully compensates by explaining apps' replace-vs-omit behavior, for/until deadline preservation, and the specialized replace_invites and reconcile_invites semantics. It leaves a few params (ack_never, print_links, qr_invite) only lightly touched, but the schema carries those.

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 opening sentence states a specific verb and resource ('Edit an existing non-revoked person') and immediately clarifies the replace-vs-preserve semantics of apps and for/until. It also explicitly names the sibling tools it is not (people_add, people_grant, people_revoke), so an agent can distinguish it without opening other schemas.

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?

It gives explicit routing rules: use people_add for a new person, people_grant/people_revoke for one app, and invite tools for elevated exit-node/multi-use/tailnet-role permissions. It also states the confirm-with-user step, which is a real usage precondition.

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