tslink

Overview Schema Source Related Servers Discussions Admin

Grant access to one app

people_grant

Destructive

Grant one person access to a private HTTP/file app while preserving all other grants and revocations, then return per-app access state and invitation progress.

Instructions

Grant one person's private HTTP/file app while preserving all other grants and revocations. Uses the shared membership, routing and invitation action; can contact Tailscale and create a device share. New people, routes and external sharing require owner authority. Existing member grants retain scoped operation, with audience policy, scope maximum and binding expiry checked under the writer lock. never requires ack_never and unrestricted owner authority. Does not restore a globally revoked person. Returns per-app access state and invitation progress; incomplete setup is an error with retained data.

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>",
      "app": "<app>",
      "for": "<for>"
    },
    "name": "people_grant"
  }
}

Input Schema

Name	Required	Description
`app`	Yes
`for`	Yes	Lifetime within audience policy, scope maximum and binding expiry; never requires ack_never and an unexpired unrestricted owner binding.
`who`	Yes
`ack_never`	No

Output Schema

Name	Required	Description	Default
`app`	Yes
`access`	No
`person`	Yes
`invites`	No
`message`	No
`revoked`	Yes
`complete`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedv0.3.0Oct 27, 2026

addedInput schema / properties / ack_never

Added value: +{
+  "default": false,
+  "type": "boolean"
+}

changedInput schema / properties / for / description

Previous value: -"Lifetime of at least 1h using the shared grammar and presets, within audience policy, scope maximum and binding expiry; never is refused."New value: +"Lifetime within audience policy, scope maximum and binding expiry; never requires ack_never and an unexpired unrestricted owner binding."

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 / complete
```
Added value: +{
+  "type": "boolean"
+}
```

addedOutput schema / properties / invites

Added value: +{
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "app": {
+        "type": "string"
+      },
+      "code": {
+        "type": "string"
+      },
+      "id": {
+        "type": "string"
+      },
+      "invite_url": {
+        "type": "string"
+      },
+      "reconcile_ids": {
+        "items": {
+          "type": "string"
+        },
+        "type": "array"
+      },
+      "remote_side_effect_plan": {
+        "additionalProperties": false,
+        "properties": {
+          "boundaries": {
+            "items": {
+              "type": "string"
+            },
+            "type": "array"
+          },
+          "default": {
+            "type": "string"
+          },
+          "disable_flag": {
+            "type": "string"
+          },
+          "id": {
+            "type": "string"
+          },
+          "mutates": {
+            "type": "boolean"
+          },
+          "operation": {
+            "type": "string"
+          },
+          "opt_in_flag": {
+            "type": "string"
+          },
+          "remote_system": {
+            "type": "string"
+          },
+          "resources": {
+            "items": {
+              "type": "string"
+            },
+            "type": "array"
+          },
+          "schema_version": {
+            "type": "integer"
+          }
+        },
+        "required": [
+          "schema_version",
+          "id",
+          "operation",
+          "remote_system",
+          "mutates",
+          "default",
+          "resources",
+          "boundaries"
+        ],
+        "type": "object"
+      },
+      "state": {
+        "type": "string"
+      },
+      "target_kind": {
+        "enum": [
+          "app",
+          "gateway"
+        ],
+        "type": "string"
+      }
+    },
+    "required": [
+      "app"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / message
```
Added value: +{
+  "type": "string"
+}
```

First observedv0.1.0Oct 19, 2026

TDQS

B3.3/5.0

Behavior4/5

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

Beyond annotations, it discloses external Tailscale contact, device share creation, writer-lock checks, owner-authority requirements, and error behavior with retained data. The explanation is useful but somewhat jargon-heavy and leaves some mechanics opaque.

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 purpose is front-loaded, but the remaining text is dense and sometimes grammatically awkward. It is not bloated, yet several clauses are cryptic and could be tightened or restructured for clarity.

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

Completeness3/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 and rich annotations, it covers important behavioral context such as authority, external calls, lock behavior, and error handling. However, it leaves key parameter semantics unclear, so an agent still lacks complete guidance for invoking it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 25%, and the description does not compensate: it never explains the format or meaning of who and app, and ack_never is mentioned cryptically without explaining when or why to set it. It adds only partial context for the for parameter, largely repeating schema constraints.

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 action and resource: granting one person's private HTTP/file app while preserving other grants and revocations. It is clear enough to distinguish from broad sharing tools, though the phrasing is awkward and it does not explicitly contrast with siblings like share or invite_device.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives some usage context—new people, routes, and external sharing require owner authority, and globally revoked people are not restored—but it does not explicitly say when to use this tool instead of sibling tools such as share or invite_device. The guidance is implied rather than direct.

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