List organization tailnets

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.

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.

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.

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.

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.

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.