tslink

Overview Schema Source Related Servers Discussions Admin

Invite a tailnet member

invite_user

Send a Tailscale invitation to an email address or generate a bearer invite URL, assigning a member or admin role.

Instructions

Sends a real Tailscale invitation to a real email address, so confirm the address and role with the user before calling this. The invitation joins the recipient to the user's tailnet. Set print_link true to receive a bearer invite URL instead of having Tailscale send the email. A role other than member is refused with mcp_elevated_invite_refused unless the owner set mcp.allow_elevated_invites in config.json; the user can always run tslink invite user themselves.

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": {
      "email": "<email>"
    },
    "name": "invite_user"
  }
}

Input Schema

Name	Required	Description
`role`	No	Role assigned on acceptance. Defaults to member. Any other role needs the owner's opt-in (mcp.allow_elevated_invites in config.json).
`email`	Yes	Recipient email address.
`print_link`	No	Do not send email; return the API-provided invite URL for the user to deliver. Anyone holding that URL can accept.

Output Schema

Name	Required	Description
`id`	No
`kind`	Yes
`role`	No
`email`	No
`grant`	No	Person grant saved by the common access action.
`created`	No
`emailed`	Yes
`message`	No
`service`	No
`accepted`	No
`device_id`	No
`multi_use`	No
`recipient`	No
`invite_url`	No	Bearer invitation URL. Present only when the invite was created with print_link true or when invite_list was called with show_urls true; anyone holding it can accept the invitation.
`target_kind`	No
`access_state`	No
`allow_exit_node`	No
`last_email_sent_at`	No
`remote_side_effect_plan`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv0.3.0Oct 27, 2026

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

addedOutput schema / properties / grant

Added value: +{
+  "description": "Person grant saved by the common access action.",
+  "type": "object"
+}

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

changedOutput schema / required

Previous value: -[
-  "kind",
-  "id",
-  "emailed",
-  "remote_side_effect_plan"
-]New value: +[
+  "kind",
+  "emailed",
+  "remote_side_effect_plan"
+]

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?

Goes far beyond the annotations: it warns that a real email is sent, discloses that elevated roles are refused with the specific error mcp_elevated_invite_refused with the config gate (mcp.allow_elevated_invites), and notes the bearer URL grants access to anyone holding it. These are non-obvious behavioral facts an agent cannot infer from the structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

Front-loads the key warning (real send, confirm first) and each subsequent sentence carries distinct information (print_link alternative, elevated-role gate, self-service fallback). No filler sentences.

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 mutation tool with annotations and an output schema, the description supplies everything an agent needs: the write consequence, the permission gate, and the alternative delivery path. Return-format concerns are already covered by the 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 100%, so the baseline is 3; the description adds meaning beyond it by tying role elevation to the refusal/opt-in behavior and explaining that print_link returns a bearer URL that bypasses email delivery. Marginally redundant with the schema on print_link but genuinely additive on role.

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?

States a concrete verb and resource ('Sends a real Tailscale invitation to a real email address') and scopes it to joining the user's tailnet. This distinguishes it from device-invite (invite_device) and existing-member management siblings without needing the schema opened.

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?

Gives a clear precondition ('confirm the address and role with the user before calling this') and an explicit variant for print_link. It does not name a sibling alternative (e.g., invite_device vs people_add) for the nearest overlapping cases, so it stops short of full 5-level when/when-not routing.

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