Skip to main content
Glama
Sign In
@yawlabs/tailscale-mcp

@yawlabs/tailscale-mcp

by YawLabs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

List organization tailnets

tailscale_list_org_tailnets
Read-onlyIdempotent

Use to list all tailnets in an organization, including API-only tailnets, with cursor-based pagination. Requires OAuth.

Instructions

List the tailnets in your organization, including API-only tailnets created via the API. Paginated: returns at most limit results (Tailscale defaults to 100) plus a cursor. Pass that cursor back to fetch the next page; an empty cursor in the response means you have reached the end. Requires OAuth authentication.

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": "tailscale_list_org_tailnets"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoMax tailnets to return in this page. Omit to use Tailscale's default of 100.
cursorNoPagination cursor from a previous response. Omit for the first page.
organizationNoOrganization ID. Defaults to '-' (the organization owning the calling credentials).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.17.1

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive), so credit is for the extra context: the pagination contract (at most `limit` results, cursor returned, empty cursor means end) and the OAuth authentication requirement. The auth prerequisite is a genuinely useful behavioral disclosure not present in the annotations.

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?

Purpose is front-loaded and the pagination explanation is compact and non-redundant. The auth note is a short final sentence that earns its place, though the definition is slightly longer than strictly necessary given the schema already documents cursor and limit.

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?

No output schema exists, and the description compensates by explaining the pagination envelope (results plus cursor) and terminating condition. Scope, auth, and pagination are all covered; only the shape of individual tailnet records is left unstated, which is acceptable for a list tool.

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%, so all three parameters (limit, cursor, organization) are already documented in the schema. The description restates the limit default and cursor round-trip but adds nothing the schema does not already provide, which is the baseline 3.

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?

States a specific verb (List) and resource (tailnets in your organization), and adds a scope distinction: it includes API-only tailnets created via the API, which a bare 'list' would leave ambiguous. It does not explicitly differentiate itself from siblings like tailscale_create_org_tailnet or tailscale_delete_tailnet, so it lands just short of a 5.

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?

Usage is implied by the verb and the pagination instructions, and it names no alternatives or when-not conditions. An agent can infer this is the read path for org tailnets versus the create/delete siblings, but the description never makes that routing explicit.

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

Deploy Server

Other Tools