tslink

Overview Schema Source Related Servers Discussions Admin

Set an access deadline

extend

Destructive

Adjust an existing person-app grant or Funnel deadline with a relative for or absolute until, lengthening or shortening access and returning old and new deadlines.

Instructions

Reset an existing person-app grant or acknowledged Funnel deadline using for from the operation time or an absolute until, extending or shortening access. Returns previous and new deadlines, audience, change time and whether expired access was regranted. Use extend to change an existing deadline; use people_grant to create a person-app grant. who selects the person grant for service; omit who for Funnel, which is owner-only. Confirm target and duration with the owner. Expired access requires regrant=true; revoked people cannot be revived. For Funnel, regrant=true re-enables public internet exposure of an expired Funnel. Changes local state only; no invitations, live tailnet calls or access-log dependency.

Input Schema

TableJSON Schema

Name	Required	Description
`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`	No
`until`	No	RFC3339, YYYY-MM-DD or YYYY-MM-DDTHH:MM; local without offset. Mutually exclusive with for.
`regrant`	No
`service`	Yes
`ack_never`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`who`	No
`service`	Yes
`audience`	Yes
`regranted`	Yes
`changed_at`	Yes
`expires_at`	Yes
`previous_expires_at`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 19, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the annotations (destructiveHint=true, idempotentHint=false), the description discloses the return payload (previous and new deadlines, audience, change time, regrant flag), the regrant side effect on Funnel public internet exposure, that revoked people cannot be revived, and that changes are local-state only with no invitation/live-call/access-log dependency. That is substantial operational 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?

Front-loaded with the core action and scope, and every sentence carries rules (routing, who, regrant, Funnel exposure, local-only). The opening clause ("using for from the operation time or an absolute until") is slightly tangled, and the density is high, but there is little pure filler.

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 destructive, non-idempotent mutation with an output schema, the description still covers routing, prerequisites, edge cases (expired/revoked, Funnel exposure), and scope limits. Nothing an agent needs before calling it 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?

With only 33% schema description coverage, the description must compensate and largely does: it explains who (person grant selector vs. Funnel owner-only), for (relative from operation time vs. absolute until), and regrant semantics. It leaves service and ack_never unaddressed, so it falls short of full coverage.

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 description opens with a specific verb and resource: it resets an existing person-app grant or acknowledged Funnel deadline, including the extend-or-shorten direction. It explicitly names the sibling it is not (people_grant) so an agent can route correctly without opening either schema.

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 when/when-not routing ("use extend to change an existing deadline; use people_grant to create a person-app grant"), plus the who-omission rule for Funnel, the owner-confirmation prerequisite, and the regrant=true precondition for expired access. These are precisely the conditions an agent needs to choose and invoke correctly.

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