tslink

Overview Schema Source Related Servers Discussions Admin

List invitations

invite_list

Read-onlyIdempotent

Lists open Tailnet user and TSLink-owned device invitations so you can find an invite ID before revoking or resending; reads the Tailscale API and sends nothing.

Instructions

List open tailnet user invitations and TSLink-owned device invitations. Use this before invite_revoke or invite_resend to find an invite id; it reads the Tailscale API and sends nothing. complete false means at least one device could not be checked.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "invite_list"
  }
}

Input Schema

Name	Required	Description	Default
`show_urls`	No	Include bearer invite URLs. They are redacted by default because anyone holding one can accept the invitation.

Output Schema

Name	Required	Description
`count`	Yes
`complete`	Yes	False when at least one TSLink-owned device could not be checked; device_targets carries the per-service reason.
`user_invites`	Yes
`device_invites`	Yes
`device_targets`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedv0.3.0Oct 27, 2026
- addedOutput schema / properties / device_invites / items / properties / access_state
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / device_invites / items / properties / grant
```
Added value: +{
+  "description": "Person grant saved by the common access action.",
+  "type": "object"
+}
```
- addedOutput schema / properties / device_invites / items / properties / message
```
Added value: +{
+  "type": "string"
+}
```
- changedOutput schema / properties / device_invites / items / required
```
Previous value: -[
-  "kind",
-  "id",
-  "emailed"
-]New value: +[
+  "kind",
+  "emailed"
+]
```
- addedOutput schema / properties / user_invites / items / properties / access_state
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / user_invites / items / properties / grant
```
Added value: +{
+  "description": "Person grant saved by the common access action.",
+  "type": "object"
+}
```
- addedOutput schema / properties / user_invites / items / properties / message
```
Added value: +{
+  "type": "string"
+}
```
- changedOutput schema / properties / user_invites / items / required
```
Previous value: -[
-  "kind",
-  "id",
-  "emailed"
-]New value: +[
+  "kind",
+  "emailed"
+]
```
First observedv0.1.0Oct 19, 2026

TDQS

A4.5/5.0

Behavior4/5

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

The annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context that it calls the Tailscale API and sends nothing, and it interprets the complete=false result as meaning at least one device could not be checked.

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?

The description is three compact sentences with no wasted wording. It front-loads the purpose, then gives the key usage guidance, then explains the complete=false flag.

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?

The output schema exists, annotations are rich, and the single parameter is fully documented in the schema. The description covers the remaining agent-relevant behavior: when to use it, that it sends nothing, and what complete=false indicates.

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

Parameters3/5

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

Schema description coverage is 100%, and the single show_urls parameter is already documented in the schema, including the redaction warning. The description does not mention show_urls or add meaning beyond the schema, so the baseline of 3 is appropriate.

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 states a specific verb and resource: it lists open tailnet user invitations and TSLink-owned device invitations. It also distinguishes the tool from sibling invite_revoke and invite_resend by framing it as the lookup step before those mutations.

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 explicitly says to use this before invite_revoke or invite_resend to find an invite id, naming the relevant alternatives and the condition that selects this tool. It also clarifies that the tool reads the Tailscale API and sends nothing, reinforcing when it is appropriate.

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