tailscale_list_oauth_apps

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

Beyond the readOnlyHint annotation, it discloses the key behavioral caveat: client secrets are never included and are returned only once at creation time. It also states the response contains an oauthApps array with id, name, redirect URIs, and scopes, which is materially useful context.

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?

Three sentences, each earning its place: what the tool does, what it returns, and the critical secret caveat plus a usage workflow. The most important caveat is placed prominently rather than buried.

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?

For a parameterless list operation with strong annotations, the description covers behavior, return contents, an important exclusion (secrets), and a concrete downstream use. Nothing needed for correct invocation or interpretation is missing.

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?

The tool has no parameters, so the description correctly focuses on return data rather than parameter semantics. The baseline of 4 applies because parameter documentation is not needed with an empty schema.

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?

The description uses a specific verb ('List') and resource ('OAuth Apps registered in your tailnet'), and it clarifies the scope and output shape. It is clearly distinguishable from sibling tools like tailscale_get_oauth_app, tailscale_create_oauth_app, and tailscale_delete_oauth_app.

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?

It explicitly identifies a use case: recover the id of an app you did not record, then pass it to tailscale_delete_oauth_app. It does not explicitly contrast with tailscale_get_oauth_app, but the list-vs-get distinction and the recovery/revocation workflow give sufficient guidance.

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