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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=true, and openWorldHint=true, so the safety profile is covered. The description adds no behavioral context of its own — no mention of permissions needed, what the acceptance does to the tailnet/device, or that it is idempotent.

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?

A single front-loaded sentence with zero filler. Nothing is padded or restated.

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 one-parameter, no-output-schema tool with rich annotations, the description is minimally sufficient to call it correctly. It omits any note about the post-acceptance effect or required privileges, leaving a modest gap for a mutation 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 coverage is 100% and the single parameter 'invite' is documented as 'The device invite URL or invite code'. The description merely repeats that wording, adding no format or syntax detail beyond the schema; baseline 3 is appropriate.

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 ('Accept') and resource ('device share invitation'), which cleanly distinguishes it from the sibling invite tools (create/get/list/delete/resend device invite). It does not explicitly name an alternative, but the action is unambiguous.

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?

The phrase 'using the invite URL or code' implies the prerequisite (you must already hold an invite) but never states when to use this versus resending, deleting, or listing device invites. Usage is inferable but not spelled out.

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

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

Annotations already declare the safety profile (not read-only, idempotent, non-destructive, open-world), lowering the bar. The description adds the meaningful effect 'granting them access to the tailnet,' but says nothing about permissions required, reversibility, or what happens to already-approved users.

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?

A single front-loaded sentence with the action first and the effect second; no filler or redundancy.

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 one-parameter, non-destructive, idempotent operation with no output schema, the description conveys both purpose and outcome, which is close to sufficient. Only the precondition detail (how a user becomes 'pending') and any auth requirement are left unstated.

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?

With a single parameter and 100% schema description coverage, the schema fully documents userId. The description adds no format, source, or constraint detail beyond what the schema already provides, so the baseline 3 applies.

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 (approve) and resource (user) with a qualifying scope (pending) and the resulting effect (tailnet access). It implicitly separates itself from restore_user/suspend_user via the 'pending' state, but never names an alternative, so it stops short of full sibling differentiation.

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?

The word 'pending' implies the precondition (the user must be in a pending state) and thus gives a hint of when the tool applies. However, no explicit when-to-use guidance, prerequisites, or alternatives (e.g., restore_user, authorize_device) are provided.

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

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

Annotations already convey that the operation is not read-only, is not destructive, and is idempotent. The description adds the useful constraint that only pending-authorization devices are relevant, but does not disclose consequences beyond that, such as what authorization enables for the device.

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?

The description is a single, focused sentence with no filler. The action and the prerequisite condition are front-loaded and immediately actionable.

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?

This is a simple single-parameter tool with no output schema, and annotations cover idempotency and safety. The description adequately states the action and condition; a small gap is the lack of any note about authorization effects or alternatives, but nothing critical is missing for calling the 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%, and the deviceId parameter is well documented with an example and a warning not to use the nodeKey. The description itself adds no parameter-level detail, so the baseline score of 3 applies.

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 states a specific verb ('Authorize') applied to a specific resource ('a device') with a clear precondition ('pending authorization'). This clearly distinguishes a single-device authorization action from siblings like tailscale_deauthorize_device or tailscale_set_devices_authorized.

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?

The description gives a clear usage context: use this tool for devices that are pending authorization. It does not explicitly name alternatives or exclusions, such as batch authorization via tailscale_set_devices_authorized, so it stops short of full routing guidance.

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

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

Description contradicts annotations: it explicitly states 'pass null as the attribute config to delete', a destructive operation, while annotations declare destructiveHint=false. This is a serious inconsistency that misleads agents about the tool's side effects. Per rule, score is 1 when contradiction exists.

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, zero waste. Purpose is front-loaded, and the additional constraints (key prefix, merge patch, null deletion) are presented concisely. Ideal length for the tool's complexity.

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?

The description covers the essential behavioral aspects: batch scope, custom: prefix, merge patch semantics, and deletion via null. The nested schema covers parameter structure fully. However, the destructiveHint annotation conflict undermines completeness, and no mention of response format (though no output schema exists) is a minor gap. Overall, still quite complete for the complexity level.

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 coverage is 100%, so baseline is 3. The description adds value by explicitly stating the 'custom:' key prefix requirement and clarifying JSON Merge Patch semantics, which are not fully captured in the schema's parameter descriptions. The null-deletion behavior is repeated from the schema but the additional constraint justifies a 4.

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 states a specific verb ('batch update'), resource ('custom posture attributes'), and scope ('across multiple devices'). It clearly distinguishes itself from sibling tools like tailscale_set_device_posture_attribute and tailscale_delete_device_posture_attribute by emphasizing batch, multi-device operation.

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?

The description clearly implies use for batch updates across multiple devices. It doesn't explicitly mention alternatives or when not to use this tool, but the 'batch' wording gives clear context. No exclusions are stated, so it fits the 'clear context, no exclusions' level.

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

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

Annotations already indicate readOnlyHint=false and idempotentHint=false, so the tool is expected to have side effects and not be idempotent. The description adds that it 'creates or gets' an ID and the intended downstream use, but it does not disclose specifics about state changes, auth requirements, or rate limits. It doesn't contradict annotations, but it also doesn't enrich them significantly.

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?

The description is two sentences, front-loaded with the core purpose, and immediately directs the agent to the next action. Every word earns its place; there is no filler or redundancy.

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 tool with one well-documented parameter, clear annotations, and no output schema, the description provides sufficient context: it states what it does, why it is needed, and how to integrate it with the validation tool. It could explicitly mention that the tool returns the external ID, but that is strongly implied by 'Create or get' and the usage instructions. Overall, nothing critical 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 schema description coverage is 100% for the single parameter 'reusable', which is thoroughly explained (default behavior, what false means). Per the rubric, a high coverage baseline of 3 applies. The tool description itself adds no extra parameter context, so the schema carries the weight.

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 ('Create or get') and identifies the resource ('AWS external ID') with its purpose ('for S3 log streaming'). It clearly distinguishes this tool from siblings by naming the exact object and context, and it references the companion validation tool, making its role unambiguous.

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?

The description gives a clear workflow: obtain the ID, place it in the trust policy, then validate with tailscale_validate_aws_trust_policy. It implies when to use this tool (as a prerequisite to validation) but does not explicitly state when not to use it or mention alternative approaches. The 'reusable' parameter behavior is covered in the schema, not the description.

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

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

Annotations already indicate this is a non-read-only, non-idempotent, non-destructive mutation. The description adds context that it creates an invitation, but does not disclose side effects such as email sending or the return format. It does not contradict 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?

The description is a single, clear sentence that front-loads the primary action and purpose. No extraneous words.

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?

Given the tool's simplicity and the complete parameter documentation in the schema, the description is adequate but lacks information about expected response or any prerequisites. It does not mention that the device must exist or that an email may be sent, which could be relevant for an agent.

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 input schema has 100% coverage of all four parameters, including descriptions for email, deviceId, multiUse, and allowExitNode. The description itself adds no parameter-specific information beyond what the schema provides, so it relies on the schema's documentation.

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 clearly states a specific verb 'Create' and resource 'device share invitation', and explains its purpose of allowing an external user to access a specific device. This distinguishes it from user invites and other device operations.

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?

The description does not provide any guidance on when to use this tool versus alternatives such as tailscale_create_user_invite or other invite-related tools. It simply states what it does, leaving the agent to infer usage from the name and context.

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

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

Annotations already carry the mutation/idempotency hints, and the description adds meaningful behavior: the key value is shown only once and must be saved immediately. The explicit SECURITY warning that the response contains a long-lived credential that may be persisted by MCP clients is valuable context beyond any structured field. It does not cover error conditions or permission requirements, but that is a minor gap for this operation.

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?

The description is front-loaded with the core purpose and one-time retrieval behavior, then uses a clearly labeled SECURITY callout and three compact examples. Despite its length, each section earns its place and the structure makes it scannable for an agent.

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 12-parameter creation tool with no output schema, the description covers return behavior, security handling, all three supported key types, and representative parameter combinations. It omits error cases, authorization prerequisites, and explicit warnings about creating duplicate keys, but the combination of schema and description is largely sufficient.

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?

With 100% schema coverage, the schema already documents every parameter, so the baseline is 3. The description adds value with concrete example objects that show how tags, scopes, issuer, subject, and keyType compose for each of the three key types, helping an agent assemble valid parameter sets.

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 opens with a specific verb and resource ('Create a new key in your tailnet') and enumerates the three supported key types, which clearly distinguishes it from key lifecycle siblings like list_keys, get_key, update_key, and delete_key. It does not explicitly differentiate from the sibling tailscale_create_oauth_app, which also handles OAuth client creation, so it stops short of a perfect 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?

The description gives context for when each key type is appropriate (auth for adding devices, OAuth for API access, federated for OIDC CI/CD) and supplies example payloads. However, it never says when not to use this tool or names alternatives such as tailscale_create_oauth_app or tailscale_update_key, leaving routing between siblings to inference.

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

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

Adds important behavior beyond annotations: the response contains a long-lived credential that cannot be retrieved again, and MCP clients may persist it in logs. The security warning and alpha status give the agent operational context that readOnlyHint/idempotentHint/destructiveHint do not convey.

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?

The description is front-loaded with the core function and flow, then handles security, scope guidance, and sibling differentiation. Every paragraph serves a distinct purpose and no sentence is wasted.

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?

Given the moderate complexity and lack of an output schema, the description covers purpose, flow, required parameters, secret handling, and the key sibling alternative. The agent has enough information to invoke the tool correctly and handle its response safely.

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 coverage is 100%, so the baseline is 3. The description adds value by explaining the recommended scope's semantics ('one auth key per authorization, no refresh token') and clarifying that the tool does not restrict the scope value despite the API reference's example.

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 it creates an OAuth app for device provisioning, describes the authorization-code flow and user consent, and notes it returns the client secret. It also distinguishes itself from tailscale_create_key, making the purpose unambiguous.

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?

Explicitly names tailscale_create_key with keyType='client' as the alternative for machine-to-machine OAuth clients, and frames this tool as the one for third-party device enrollment after user consent. It also recommends the exact scope to use, leaving little room for incorrect selection.

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

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

The description goes well beyond the annotations by disclosing that the response contains a one-time OAuth client secret, that MCP clients may persist responses, that creation requires specific credentials, that there is a 10-tailnet limit, and that duplicate-name behavior is ambiguous between alreadyExists and a 400. This is exactly the kind of behavioral context an agent needs and is not inferable from annotations or schema.

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?

Although the description is longer than typical, every section earns its place: the core purpose and return value are front-loaded, followed by security, auth, quota, and duplicate-handling guidance. The formatting with labeled sections makes it scannable despite the density of information.

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 create operation with unusual security and idempotency implications and no output schema, the description is remarkably complete. It covers return values, secret sensitivity, credential prerequisites, quota limits, and ambiguous failure modes, leaving an agent well-equipped to call the tool correctly and handle results appropriately.

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%, and both parameters (displayName and organization) already have descriptive text including uniqueness and default behavior. The description adds no additional parameter-level details beyond what the schema provides, so the baseline score of 3 is appropriate.

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 opens with a specific action and resource: 'Create a new API-only tailnet in your organization.' It also clarifies what is returned (the tailnet plus an OAuth client), which distinguishes it from sibling create operations like create_oauth_app or create_webhook. The purpose is unambiguous and not a tautology.

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?

The description gives clear context for when to use the tool: it requires an OAuth client with the 'tailnets' scope, explains that an API key will not work, and describes follow-up actions after creation. It also tells the agent to call tailscale_list_org_tailnets before retrying after a timeout. It does not explicitly enumerate when not to use it, but for a create operation this is reasonable context.

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

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

Annotations already indicate it's a write operation (readOnlyHint=false) and not idempotent. The description adds no additional behavioral context, such as side effects, authentication needs, or failure modes. It neither contradicts annotations nor adds significant value beyond what is already declared.

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?

The description is a single, concise sentence that is front-loaded with the essential action and resource. It contains no fluff and is appropriately sized for the tool's simplicity.

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?

Given the tool's complexity (5 parameters, provider-specific quirks, a sensitive secret), the description is too minimal. It does not mention the provider-specific nature of the operation, what happens on success, or any prerequisites. With no output schema, the agent has no indication of the return value, making this a significant gap.

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%, with detailed per-parameter documentation including provider-specific mappings and sensitivity warnings. The tool description adds no parameter information beyond what the schema provides, so the baseline of 3 applies.

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 clearly states the action ('Create') and the resource ('device posture integration'). It differentiates from sibling tools like get, update, delete, and list posture integrations by indicating a create operation. No ambiguity about the tool's purpose.

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?

The description provides no guidance on when to use this tool versus updating or deleting an integration, nor does it mention prerequisites like provider credentials or that it is intended only for new integrations. No alternatives or exclusions are mentioned.

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

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

Annotations already declare readOnlyHint=false, non-idempotent, openWorld, non-destructive, so the safety profile is covered. The description adds only that the invite lets someone join the tailnet; it omits whether an email is dispatched, invite expiry, rate limits, or required privileges. For a mutation that contacts an external party, that leaves meaningful gaps.

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?

A single short sentence, front-loaded with the verb and resource, with no filler. It is efficient, though borderline under-specified rather than maximally informative.

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 simple two-parameter creation tool with no output schema and annotations covering the safety profile, the description is minimally adequate. It nonetheless leaves out the delivery mechanism, invite lifecycle, and permission requirements that an agent would need to call this correctly.

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 coverage is 100% and the schema itself explains both the email target and the role enum with its default of 'member'. The description adds nothing about parameter behavior, so the baseline 3 for schema-complete tools applies.

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+resource ('Create a new user invite') with a brief note on its effect ('allows someone to join your tailnet'). However, it never distinguishes itself from the numerous sibling invite tools (tailscale_create_device_invite, resend_user_invite, list/get/delete_user_invite), so the agent must infer scope from the name alone.

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?

No when-to-use guidance, no prerequisites (e.g., admin role required, seat availability), and no mention of the alternatives such as device invites or resending an existing invite. An agent gets no routing help from this text.

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

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

The description discloses the most important behavioral trait: the signing secret appears only once in the response and must be saved immediately. It also adds a security warning that MCP clients may persist responses to logs, which is valuable context beyond the annotations. The annotations already indicate this is a non-read, non-idempotent, non-destructive operation, and the description complements them with the one-time-secret and providerType-immutability details.

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?

The description is compact and front-loaded: the one-time secret warning appears in the first sentence, followed by providerType guidance and a security note. Every sentence earns its place, and the SECURITY section is clearly separated. No filler or repetition of schema content.

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 create operation with no output schema, the description covers the critical response behavior (one-time secret), the key parameter decision (providerType), and the security implications. It doesn't describe the full response shape or error cases, but the essential information an agent needs to call this correctly and handle the result is present.

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 coverage is 100%, so the schema already documents all three parameters. The description adds value by explaining the consequence of providerType (format deliveries for chat providers, cannot be changed after creation) and the consequence of subscriptions (category subscriptions include future events). This goes beyond the schema's basic descriptions, though it doesn't add syntax details for endpointUrl.

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 states a specific verb and resource ('Create a new webhook') and adds the critical detail that the response contains a one-time signing secret. It doesn't explicitly differentiate from sibling tools like tailscale_update_webhook or tailscale_test_webhook, but the create semantics are clear enough that an agent can distinguish it from list/get/delete/update siblings.

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?

The description gives clear context on when to set providerType (when the endpoint is a Slack, Mattermost, Google Chat or Discord incoming-webhook URL) and when to omit it (raw Tailscale JSON for custom receivers verifying signatures). It doesn't explicitly say 'use tailscale_update_webhook to modify later' or 'use tailscale_test_webhook to test', but the create-vs-alternative distinction is reasonably inferable from the sibling names and the description's focus on creation-time constraints.

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

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

The annotations already mark the action destructive and non-read-only; the description adds that access is removed immediately and that the device can reconnect only after being re-authorized. This clearly communicates the consequence and recovery path, going beyond the annotation flags.

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?

Two short sentences front-load the action and consequence, with no filler or repetition of the title. Every clause contributes meaning.

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 one-parameter mutation with annotations and a fully documented schema, the description is complete: it states the effect, the immediacy, and the recovery condition. No missing information prevents an agent from invoking it correctly.

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 schema description covers 100% of the parameter, including an example and a caution that the nodeKey is not accepted. The tool description adds no parameter detail, so the schema carries the full burden; baseline 3 applies.

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 opens with the verb 'Deauthorize' and the resource 'device,' and specifies the immediate effect of removing tailnet access. It is clearly a revocation action and distinguishable from siblings like tailscale_authorize_device, though it does not explicitly name alternative tools.

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?

The description implies the tool is for revoking a single device's tailnet access, but it offers no explicit guidance on when to choose it over related siblings such as tailscale_expire_device, tailscale_set_devices_authorized, or tailscale_delete_device. The re-authorization note hints at reversibility but does not provide selection criteria.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the destructive nature is known. The description adds beyond annotations by specifying the consequence: the device must re-authenticate to rejoin. This is valuable context that the annotations do not convey. There is no contradiction with 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?

The description is two sentences, front-loaded with the core purpose, and contains no redundant words. The irreversibility note is concise and directly relevant to usage decisions.

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?

The tool is simple (one parameter, no output schema) and the annotations provide the destructive hint. The description covers the key behavioral detail (re-authentication requirement) and the purpose. It does not mention return codes or error handling, but for a delete operation this is often implicit and not necessary for correct invocation. Overall it is complete for an agent to use effectively.

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 input schema provides 100% coverage with a detailed description of the deviceId parameter (including examples and clarifications about nodeId vs nodeKey). The tool description itself adds no additional parameter information, so the baseline of 3 applies since the schema already carries the semantic load.

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 clearly states a specific verb ('remove') and resource ('device'), and adds the qualifier 'permanently' which distinguishes it from temporary actions like expire or deauthorize. It also notes the irreversible nature, making the tool's purpose unambiguous.

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?

The description provides clear context that this is for permanent removal, and the irreversibility statement implies that it should not be used for temporary or reversible actions. However, it does not explicitly name alternative tools (e.g., tailscale_expire_device) or state 'use this when...', so guidance is implied rather than explicit.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds concrete consequence detail beyond them: the deletion is irreversible and the invite link stops working. That is genuinely useful behavioral context (no undo). It does not cover error behavior for an unknown inviteId, but the annotations supply the safety profile.

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?

Two short sentences, front-loaded with the operation and immediately followed by the irreversibility warning. Zero filler and every clause earns its place.

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 one-parameter, no-output-schema mutation tool, noting the irreversible effect and the invite-link consequence is close to sufficient. Missing only edge-case behavior (e.g. what happens if inviteId does not exist), which is minor.

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% and the single inviteId parameter is already documented in the schema as 'The device invite ID to delete'. The description adds no format, sourcing, or lookup guidance beyond that, so the baseline 3 applies.

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 (Delete) and resource (device invite) that mirrors the tool name, so the agent knows exactly what operation it performs. It does not, however, distinguish itself from near-name siblings such as tailscale_delete_user_invite, tailscale_delete_device, or the create/accept/resend device-invite family.

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?

The description never states when to use this tool versus alternatives — e.g. when to delete an invite instead of resending it (tailscale_resend_device_invite), accepting it (tailscale_accept_device_invite), or deleting the underlying device (tailscale_delete_device). No prerequisites or context are given.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, and the description adds the more specific context that deletion is irreversible. This is meaningful beyond the generic destructive flag, and nothing contradicts 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?

Two short sentences with no filler: the first states the operation, the second adds the critical warning. The information is front-loaded and every word earns its place.

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 simple two-parameter delete with destructive annotations and rich parameter descriptions, the description covers the essential behavior including irreversibility. It omits explicit alternative guidance and response/error details, but those are secondary given the schema and annotations.

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 coverage is 100%, with both deviceId and attributeKey already well-documented through concrete examples and exclusions (e.g., not the nodeKey). The description adds no additional parameter-level meaning, so the baseline of 3 applies.

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 ('Delete') and identifies the resource ('custom posture attribute from a device'), clearly distinguishing this from sibling tools like tailscale_delete_posture_integration. It is direct and unambiguous about the operation and scope.

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?

No guidance is provided on when to use this over related tools such as tailscale_set_device_posture_attribute or tailscale_batch_update_posture_attributes. The only additional sentence warns about irreversibility, which is behavioral rather than usage guidance.

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

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

The description goes far beyond the annotations' destructiveHint=true by disclosing irreversibility, the differing impact on auth keys versus OAuth clients/federated identities, and the self-revocation edge case where the server's own credential is deleted and later calls fail with 401. This is rich, actionable behavioral 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?

The description is compact and front-loaded: it opens with the action and resource, then states irreversibility, and then covers per-type behavior. Every sentence adds distinct information, and nothing repeats the schema or annotations.

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 one-parameter destructive tool with no output schema, the description covers the required scope, irreversibility, per-key-type consequences, and the notable self-revocation failure mode. Combined with annotations that already declare destructive and idempotent hints, nothing essential is missing for correct invocation.

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 schema already documents keyId at 100% coverage, so the baseline is 3. The description adds genuine semantic value by clarifying that keyId may be an API access token itself and explaining the special self-authentication case. It stops short of explaining how to obtain or format key IDs, so it is not a 5.

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 states a specific verb ('Delete') and a well-scoped resource ('a key'), then enumerates the four key types: auth key, API access token, OAuth client, and federated identity. This clearly distinguishes it from sibling tools like tailscale_delete_oauth_app or tailscale_delete_device.

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?

The description gives clear context about consequences for each key type, but it never explicitly names alternatives or states when to prefer this tool over siblings such as tailscale_delete_oauth_app. Usage is implied by resource type rather than explicitly prescribed, so an agent must infer the selection logic.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, and the description adds useful context that deleting the configuration stops logs from being sent to the destination. It does not cover auth requirements or recovery options, but for a simple destructive delete with annotations, this is a meaningful addition.

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?

Two short sentences, front-loaded with the action and followed by the consequence. No filler; every sentence earns its place.

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 one-parameter destructive delete with rich annotations and no output schema, the description is complete enough for correct invocation. It omits usage routing but covers purpose and consequence.

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%, with logType fully documented and enum values explained. The description adds no parameter meaning beyond the schema, so baseline 3 applies.

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 and resource ('Delete a log streaming configuration'), making clear what the tool does. It does not name sibling tools or explain how it differs from get/set/list log stream config tools, so sibling differentiation is left to the tool name.

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?

Provides no explicit guidance about when to use this tool versus alternatives such as tailscale_set_log_stream_config or other delete tools. The operation is implied by the verb, but there are no prerequisites or exclusions stated.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is known, but the description goes well beyond that: it explains the client secret dies immediately, integrations lose their device-enrollment path, and already-enrolled devices survive. This is exactly the side-effect disclosure an agent needs for a destructive operation.

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?

Front-loaded with the action and the word 'irreversible' before the consequences, and the routing sentence lands last. Three sentences all earn their place, though the alpha parenthetical is slightly incidental.

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 one-parameter destructive tool with no output schema, the description covers irreversibility, the exact blast radius (secret invalidated, no new device authorization), what is NOT destroyed (enrolled devices), and how to source the id. Nothing an agent needs to call this safely 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?

Schema description coverage is 100%, so appId is already documented, and the description's only added semantics is pointing at tailscale_list_oauth_apps for the value. Baseline 3 applies when the schema carries the parameter documentation.

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 and resource (delete an OAuth App), names the object precisely, and flags its alpha status. An agent can distinguish it from siblings like tailscale_delete_key or tailscale_delete_device without opening any schema.

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?

The description points to tailscale_list_oauth_apps as the way to obtain the id, which is useful routing. However, it offers no guidance on when deletion is appropriate versus alternatives such as rotating the client secret or leaving the app in place, so usage context is only implied.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false and idempotentHint=true, so the safety profile is covered structurally. The description reinforces this with 'irreversible', which is useful emphasis, but adds nothing about cascading effects (e.g., devices relying on the integration), auth requirements, or error behavior.

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?

Two short sentences, verb-resource front-loaded and the hazard warning placed immediately after. Nothing redundant or padded.

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 one-parameter destructive tool with full schema coverage and explicit annotations, the description covers the essentials and needs no output schema explanation. However, it omits any note on dependencies or what breaks after deletion, which would matter for an irreversible operation.

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 coverage is 100% for the single integrationId parameter and its description already explains it is the ID to delete. The description adds no format, prefix, or sourcing detail beyond the schema, so the baseline 3 applies.

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 (Delete) and resource (posture integration) in the first sentence, so an agent can immediately distinguish it from the create/update/get/list posture-integration siblings. It stops short of explicitly naming those alternatives, but the action is unambiguous.

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?

There is no guidance on when to use this versus the sibling update_posture_integration or get_posture_integration, and no prerequisites such as required permissions. 'This is irreversible' is a warning, not usage direction.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered. The description adds real value beyond them by spelling out the concrete consequences: irreversibility and release of the MagicDNS name and virtual IP. It stops short of noting permission/auth requirements.

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?

Two short sentences, zero filler, with the action stated first and the irreversible consequence immediately after. Every clause earns its place.

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 one-parameter destructive tool with full annotation coverage and no output schema, the description supplies the key missing piece (side effects of deletion). It is nearly complete, lacking only auth/permission expectations that an agent might otherwise assume.

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% for the single serviceName parameter, so the schema already carries the semantics. The description adds nothing about name format or scoping (tailnet-level uniqueness), leaving this at the baseline for high-coverage schemas.

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 states a specific verb ('Delete') and resource ('Tailscale Service'), which cleanly separates it from sibling operations like tailscale_get_service, tailscale_update_service, and tailscale_list_services. It is clear without needing to name a sibling, though it does not explicitly justify itself against delete-adjacent tools such as tailscale_delete_device.

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?

There is no guidance on when to use this over alternatives (e.g., update_service, or deauthorizing hosts via list_service_hosts), nor any stated prerequisites or confirmation conventions. Usage is only implied by the tool name, which is the minimum bar.

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

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

Beyond the annotations, the description discloses that deletion is irreversible and removes every device, user, ACL, and key. It explains default targeting, credential requirements for alternate tailnets, local `confirmTailnet` refusal behavior, and that the confirmation is a typo guard rather than an authorization gate.

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?

The description is long, but it is front-loaded and organized around the destructive operation, target selection, confirmation semantics, and restrictions. Some details repeat the schema descriptions, but the length is largely justified for an irreversible operation.

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?

Given the irreversible destructive behavior, no output schema, and two parameters, the description provides unusually complete context: effects, default and alternate targeting, credential constraints, confirmation semantics, and server-side tool restrictions.

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?

Both parameters are fully described in the schema and expanded in the description. `tailnet` is explained as an optional alternate target, and `confirmTailnet` is described as a required exact-match guard whose semantics differ depending on whether `tailnet` is supplied.

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 states a specific verb and resource: 'Permanently delete a tailnet.' It immediately distinguishes the operation's scope by listing everything removed and identifies the intended use case: tearing down API-only tailnets created by tailscale_create_org_tailnet.

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?

The description provides explicit usage context: it defaults to the credential-associated tailnet, supports naming another via `tailnet`, and says it is intended for tearing down API-only tailnets created by tailscale_create_org_tailnet. It also explains credential and environment-variable restrictions that drop the tool from the server.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is covered structurally. The description earns credit for adding what those hints cannot: the operation is irreversible and the removal cascades to all of the user's devices. It stops short of noting permission requirements or whether dependent resources (keys, invites) are also affected.

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?

Two short sentences with zero filler, and the irreversible consequence is front-loaded right after the action statement. Nothing needs trimming and nothing is 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 destructive, single-parameter mutation with annotations carrying the safety hints and no output schema, the description covers action, scope, and consequence. The remaining gap is preconditions such as required privileges or confirmation expectations, which a delete operation of this severity would benefit from stating.

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?

There is a single parameter with 100% schema description coverage ('The user ID to delete'), so the schema fully documents the input. The description adds no format hints (e.g., numeric ID vs email), which is the correct baseline for a fully covered single-param 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?

States a specific verb and resource ('Delete a user from the tailnet') and immediately clarifies the blast radius ('the user and all their devices will be removed'). This clearly separates it from softer siblings like tailscale_suspend_user, tailscale_restore_user, and tailscale_delete_user_invite without the agent needing to open schemas.

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?

The description gives no when-to-use guidance relative to alternatives. With close siblings such as tailscale_suspend_user and tailscale_deauthorize_device available, an agent gets no signal on when deletion is preferred over suspension or why the user must be removed rather than disabled. Usage is only implied by the verb.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the mutation profile is known. The description adds concrete consequence detail beyond the annotations: the deletion is irreversible and the invite link stops working, which tells the agent exactly what is destroyed. It stops short of noting error behavior for an unknown inviteId.

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?

Two short sentences, front-loaded with the action and immediately followed by the consequence. Every clause earns its place and there is no filler.

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 single-parameter mutation with no output schema and annotations covering the safety profile, this is nearly complete: the action, its irreversibility, and the effect on the invite link are all stated. Only minor gaps remain (behavior on a stale/already-deleted ID, permission requirements).

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% for the single inviteId parameter, so the schema fully documents it. The description adds nothing about the parameter format or source (e.g., from list_user_invites), so the baseline 3 applies.

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 and resource (delete a user invite) so an agent immediately knows the operation. It does not, however, distinguish itself from the near-identical sibling tailscale_delete_device_invite, which the agent must disambiguate by name alone.

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?

The description gives no when-to-use guidance, no prerequisites, and never mentions the alternatives (list_user_invites, get_user_invite, resend_user_invite) that would precede or replace this call. Only the warning about irreversibility hints at caution.

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

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

Annotations already declare destructiveHint=true, so the description's real contribution is the concrete consequence: the webhook secret cannot be recovered. That is a genuine addition beyond the hint flags. It is not a contradiction with idempotentHint — repeated deletes yield the same end state, which is separate from reversibility.

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?

Two short sentences with the downside front-loaded immediately after the action. No filler, no restated name, nothing to trim.

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 one-parameter delete with no output schema and destructive annotations already present, the irreversible-secret note is the key missing piece and it is supplied. Only minor gaps remain, such as behavior when the webhook ID does not exist.

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% and there is a single required webhookId, so the schema carries the parameter meaning. The description adds nothing about format, source, or lookup (e.g., where to obtain the ID), making baseline 3 appropriate.

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 and resource ('Delete a webhook'), so the operation is unambiguous. It doesn't differentiate from sibling deletion tools or name adjacent webhook operations, but the resource is distinctive enough that no confusion arises.

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?

There is no when-to-use guidance and no mention of alternatives such as tailscale_rotate_webhook_secret, which is the non-destructive way to address a compromised secret. The agent gets no routing help, only a warning about the outcome.

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

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

While annotations cover the safety profile (readOnly, idempotent, non-destructive), the description adds substantial behavioral context annotations cannot: cost model (two preview requests per user), a 25-user/60-second cap that sets `truncated`, a `failed` list excluded from the comparison, user-only principal coverage that can hide tag/group revocations, posture-definition resolution behavior, and a hard failure when nothing can be compared. This is exactly the kind of context that goes beyond 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.

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

Purpose and routing to the sibling are front-loaded, and every sentence carries information (limits, caveats, failure handling) with no filler. It is dense and runs long, but nothing is padding.

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?

With no output schema, the description carries the burden of explaining returns and does so: gain/loss per user, the `truncated` flag, the skip count, the stopping limit, and the `failed` list. An agent knows both the input contract and what the response will tell it.

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 are already well documented, including the loginName caveat and the maxPrincipals rate-limit warning. The description reinforces the 25-user default but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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?

Names a specific verb (compares/diffs) and resource (ACL policy access), and frames the exact question it answers ('who loses access?'). It distinguishes itself from siblings by name (tailscale_update_acl, validate_acl), so an agent can select it without opening any schema.

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?

Explicitly states when to use it ('Run this before tailscale_update_acl') and why the alternative is insufficient ('validate_acl only checks syntax... a policy with no tests validates clean while revoking everyone'). The when-not condition is spelled out, leaving nothing to inference.

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

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

Annotations already mark the tool as destructive and idempotent; the description adds the key consequence that the device must re-authenticate, which clarifies the real-world effect of the action. It does not cover immediate availability or permissions, but given annotation coverage this is adequate.

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?

One short sentence ('Expire a device's key, forcing it to re-authenticate.') delivers the essential action and consequence with zero padding. This is ideal for a one-parameter tool.

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 single-parameter destructive action with a fully self-documenting schema and safety annotations, the description plus schema provides sufficient information for correct invocation. It does not mention preconditions like admin rights, but that is a minor gap for a tool this simple.

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 single parameter deviceId is fully documented in the schema with an example and an explicit warning against using nodeKey. The description text adds no additional parameter semantics, so it relies entirely on the schema, matching the baseline for 100% coverage.

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 states a specific verb ('Expire'), a resource ('a device's key'), and the effect ('forcing it to re-authenticate'). This clearly distinguishes it from siblings like tailscale_delete_device or tailscale_update_device_key.

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?

The description provides no guidance on when to use this tool versus alternatives such as tailscale_update_device_key or tailscale_deauthorize_device. It only states what the tool does, leaving the selection decision entirely to the agent.

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

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

Annotations already declare read-only, idempotent, non-destructive, open-world behavior, so safety is covered. The description adds genuinely useful context beyond them: the return is raw HuJSON text with comments and trailing commas preserved, plus an ETag for concurrency-safe updates. It doesn't discuss auth/permission requirements, but it adds real behavioral value.

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?

Two tight sentences, front-loaded with the purpose and followed by the most decision-relevant detail (format preservation and the ETag dependency). No filler.

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, so the description carries the return-value burden itself, and it does: raw HuJSON preservation and the ETag. Combined with annotations covering safety, an agent has everything needed to call it and use the result correctly.

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?

Zero parameters, so there is nothing to disambiguate; baseline 4 applies. The description correctly implies a no-argument, tailnet-scoped call.

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 (Get) and resource (current ACL policy for your tailnet), cleanly separating it from the write/validate/preview siblings (update_acl, validate_acl, preview_acl). An agent can identify the tool's job without opening the schema.

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?

Gives clear workflow context: the returned ETag 'must' be passed to tailscale_update_acl to update safely, effectively explaining the read-before-write relationship. It does not, however, address when to prefer this over validate_acl/preview_acl/diff_acl_access, so it stops short of explicit alternatives/exclusions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds behavioral context by explaining that filters operate server-side and that the log shows change history, which is useful for selecting the tool. It doesn't mention pagination or response format, but the annotation coverage lowers the bar, and the added context earns a 4.

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?

The description is two sentences, front-loads the core purpose, and adds a concise note about filters. Every sentence earns its place with no redundancy or fluff.

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 read-only get operation with a rich input schema and safety annotations, the description covers the main purpose, content, and filter behavior. It doesn't describe the return format, but the absence of an output schema and the tool's straightforward nature make this acceptable. Overall, it's complete enough for an agent to call correctly.

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%, with each parameter (start, end, actor, event, target) having detailed descriptions. The description only reiterates that filters exist and narrow queries server-side, adding marginal value over the schema. Baseline of 3 is appropriate for high coverage.

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 clearly states the tool retrieves the tailnet audit/configuration log and explains what it shows ('who changed what and when'). It's a specific verb+resource, and the purpose is unambiguous. It doesn't explicitly differentiate from siblings like tailscale_get_network_flow_logs, but the resource is distinct enough that the intent is clear.

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?

The description provides context on when to use the tool (troubleshooting, compliance) and hints at using filters for targeted queries. However, it doesn't explicitly state when not to use it or mention alternatives like network flow logs. Usage guidance is implied rather than explicit.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the specific contact fields returned, which is useful context, but does not disclose auth requirements, rate limits, or response format beyond 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?

The description is a single, front-loaded sentence that names the action, resource, and returned data with no wasted words.

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 no-parameter, read-only getter without an output schema, the description adequately conveys what the tool returns. It could optionally mention response shape or required permissions, but it is complete enough for correct invocation.

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 takes zero parameters, so there are no parameter semantics to document. Per calibration, a parameterless tool receives a baseline score of 4 for this dimension.

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 states a specific verb ('Get') and resource ('tailnet contact information') and clarifies the returned contact types with '(security, support, admin emails)'. It does not explicitly differentiate itself from the sibling set_contacts or from broader settings tools, but the resource is clear enough for an agent to identify the operation.

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?

There is no explicit when-to-use or when-not-to-use guidance, nor are alternatives named. However, the verb 'Get' combined with the specific resource implies this should be used when retrieving tailnet contact information, which is adequate for a simple read-only getter.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds valuable behavioral nuance about lastSeen omission: that a missing lastSeen on a connected device means 'online now', not 'never seen'. This is non-obvious and critical for correct interpretation, going beyond what annotations or schema provide.

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?

The description is two sentences long, with the core purpose front-loaded and a specific caveat appended. Every sentence earns its place: the first states the action, the second explains a subtle behavior. There is no fluff or redundancy, making it efficient for an agent to parse.

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?

The description provides all necessary context for correct invocation: it explains the field selection, the default return subset, and the lastSeen edge case. Since there is no output schema, the description adequately conveys the return semantics without needing to enumerate all fields. The tool's complexity is well-handled within this concise description.

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%, with both fields and deviceId having detailed descriptions. The tool description repeats some of this (e.g., default vs. all) but adds no new meaning beyond the schema. Since the schema already explains parameter values and effects, the description does not need to compensate, so a baseline score of 3 is appropriate.

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 clearly states the tool's purpose: retrieving detailed information for a specific device by its ID. It distinguishes itself from sibling tools like tailscale_list_devices by specifying 'a specific device', making its scope unambiguous. The mention of field subsets (default vs. all) further clarifies what the tool returns.

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?

The description implicitly signals when to use this tool: when you need details about one device rather than a list. It does not explicitly name alternatives, but the distinction from list_devices is evident from the description's focus on a single device. It also explains the fields parameter's effect, which guides selection of output detail. However, it lacks explicit exclusion guidance, such as 'use this instead of get_device_routes for routing info'.

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

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

The rich annotations (readOnlyHint, idempotentHint, destructiveHint, openWorldHint) already declare the full safety and idempotency profile, and the description adds no behavioral context beyond restating the purpose. No mention of auth requirements, permissions, or what 'details' are returned.

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?

A single short, front-loaded sentence with zero filler. It is efficient, though extremely terse given the surrounding tool set.

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 simple single-parameter read tool with full annotation coverage, the description is minimally adequate. With no output schema, it could say more about what an invite's details contain, but the low complexity makes the omission tolerable.

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 inviteId is fully documented in the schema. The description adds no syntax, format, or example meaning beyond what the schema provides, so the baseline 3 applies.

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 ('Get') and resource ('device invite') with a singular scope, which distinguishes it from list_device_invites in the sibling set. However, it never names or contrasts an alternative, so the differentiation is only implicit.

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?

No when-to-use or when-not-to-use guidance is given. An agent must infer that this fetches one invite by ID rather than listing, creating, or deleting invites, with no explicit routing to the many related siblings.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to restate safety. It adds minor context by noting the response includes both custom and system-managed attributes, but it does not disclose any further behavioral traits such as auth requirements or error behavior.

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?

A single, front-loaded sentence that states the action, target, and scope with no filler or redundancy. Every phrase earns its place.

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 simple single-parameter read-only tool with strong annotationsasi and full schema coverage, the description is nearly complete. It does not explain the return shape, but the absence of an output schema and the simplicity of the operation make that a minor gap.

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%, and the deviceId parameter is fully documented in the schema with an example and clarification about nodeId vs nodeKey. The description adds no additional parameter meaning, which is acceptable since the schema already carries the burden.

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?

Description states a specific verb ('Get') and resource ('posture attributes for a device'), and adds the clarifying scope 'including custom and system-managed attributes.' This distinguishes it from sibling mutation tools like tailscale_set_device_posture_attribute and tailscale_delete_device_posture_attribute.

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?

The description implies a read-only retrieval use case, but it does not explicitly say when to use this tool versus the set/delete/batch posture attribute siblings. No when/when-not guidance or alternatives are named, though the tool name and readOnlyHint make the intent reasonably clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds a small domain nuance — advertised vs enabled routes — but says nothing about authentication requirements, empty results, or how disabled routes are represented.

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?

One compact sentence that is front-loaded with the operation and resource, with no filler or redundant restatement of the title.

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 one-parameter read-only getter, the description covers the resource, the input requirement, and the output scope in one sentence. No output schema exists, but the description states what is returned (advertised and enabled subnet routes); a minor gap is that it does not hint at the response shape or possible absence of disabled routes.

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 coverage is 100% and the deviceId parameter is already well described with an example and a warning that nodeKey must not be used. The description contributes no parameter-level meaning beyond the schema, so baseline 3 applies.

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 names the exact operation — retrieving subnet routes for a device — and adds two useful distinctions: routes the device advertises and routes that are enabled. This differentiates it from related siblings like tailscale_set_device_routes and tailscale_get_device.

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?

The verb and object make the read-only retrieval context clear, and the description scopes the operation to routes specifically, which an agent can infer is for inspection rather than modification. However, it does not explicitly mention when not to use it or name tailscale_set_device_routes as the write alternative.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety and idempotency are covered without the description. The description adds the useful scoping note that the response is the unified view spanning four sub-configs. It doesn't describe return shape or the openWorldHint implication, so it adds moderate value.

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?

A single sentence that front-loads the verb+resource and packs the payload contents in compactly. No filler, nothing redundant.

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 no-parameter read tool with full annotation coverage, the description is essentially complete: the agent knows what it returns and that it is a safe unified read. There's no output schema, but the description enumerates the top-level contents, which largely compensates.

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?

Zero parameters, so the schema imposes no documentation burden and the baseline of 4 applies. The description correctly never invents parameters, staying consistent with the empty input 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?

Specific verb (Get) plus a precise resource (unified DNS configuration for your tailnet), and it enumerates exactly what the unified payload contains: nameservers, search paths, split DNS, and MagicDNS preference. This distinguishes it clearly from siblings like tailscale_get_nameservers, tailscale_get_split_dns, and tailscale_get_dns_preferences.

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?

The phrase 'in a single call' implicitly signals when to prefer this over the granular getters (get_nameservers, get_split_dns, get_dns_preferences), giving the agent a clear selection rationale. It doesn't explicitly state exclusions or prerequisites, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered without the description. The description's only added value is naming MagicDNS as part of the returned state, which is modest but real 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?

A single front-loaded sentence with no filler, stating scope first and the notable returned field second. Nothing is wasted and nothing needs reordering.

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 zero-param read there is little to explain, and annotations cover the safety profile. But with no output schema, the description could enumerate what 'preferences' includes beyond MagicDNS, and it never disambiguates this tool from the several sibling getters of related DNS state — leaving a real selection gap.

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 takes zero parameters, so per the baseline this scores 4. There is no parameter behavior for the description to explain, and it correctly implies the call is scoped to the caller's tailnet.

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 (Get) and resource (DNS preferences) scoped to 'your tailnet', and even names the key field returned (MagicDNS). It does not, however, distinguish itself from closely named siblings like tailscale_get_dns_configuration, tailscale_get_split_dns, or tailscale_get_search_paths, which an agent would otherwise confuse it with.

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?

There is no when-to-use guidance at all — no mention of when to call this versus tailscale_get_dns_configuration, tailscale_get_split_dns, or tailscale_get_nameservers. The agent must infer usage purely from the name.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds a non-obvious behavior: that revoked or expired keys are still returned with 'invalid: true'. This is valuable context beyond annotations, but it does not elaborate on other response traits (e.g., pagination or field structure), which are minor given the tool's simplicity.

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?

The description is two sentences with no superfluous words. The main purpose is stated first, and the additional invalid-key behavior is added as a concise second sentence. It is front-loaded and every sentence earns its place.

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?

With a single well-documented parameter and annotations covering the safety profile, the description is largely complete. It mentions the invalid-key flag, which is a key detail for handling results. It does not enumerate all possible return fields, but for a simple 'get details' tool, that is acceptable, especially since no output schema exists and the description gives enough context to call the tool correctly.

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 schema description for keyId already covers the parameter's meaning, including the list of key types. The description essentially repeats this information without adding new semantic detail (e.g., how to obtain the keyId or any format constraints). Since schema coverage is 100%, the baseline is 3, and no extra value is provided.

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 states a specific verb ('Get details') and resource ('a specific key'), and enumerates the key types (auth key, API access token, OAuth client, or federated identity), which clearly distinguishes it from sibling tools like tailscale_list_keys or tailscale_create_key. It also adds a behavioral detail about revoked/expired keys, further clarifying the tool's exact function.

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?

The description gives clear context that this tool is for retrieving details of a single key, implying it should be used when a specific keyId is known rather than listing all keys. However, it does not explicitly mention alternatives like tailscale_list_keys or state when not to use this tool, so it lacks explicit exclusions but provides enough context for an agent to infer correct usage.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds no behavioral context beyond that (no auth requirements, rate limits, or error behavior), which is acceptable but minimal for a read tool.

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?

A single efficient sentence with the resource and scope front-loaded. Nothing extraneous, though it is on the terse side.

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 simple one-parameter read with annotations covering safety and no output schema required, the description is adequate but thin — it leaves all context to the schema and annotations.

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 coverage is 100% and the enum (configuration/network) is fully documented in the schema itself. The description only restates that the config is keyed by log type, adding no meaning beyond the schema — baseline 3 applies.

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 (Get) and resource (log streaming configuration) with a scoping qualifier (for a specific log type). This distinguishes it from list_log_stream_configs and get_log_stream_status, though it doesn't name those siblings explicitly.

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?

The phrase 'for a specific log type' implicitly differentiates a single-config read from the list_ sibling, but there is no explicit when-to-use guidance, no exclusions, and no named alternative.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds useful semantic context about what 'status' means (successful delivery), but does not disclose anything further about rate limits, auth requirements, or response detail, so it is adequate but not rich.

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?

Two sentences, front-loaded with the core verb+resource and zero wasted preamble. The second sentence slightly restates 'status' but usefully specifies that it concerns delivery success, so it mostly earns its place.

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?

With one fully documented parameter, comprehensive safety annotations, and no output schema, the description is nearly complete for a simple read-status tool. It could be slightly more informative about what the status payload includes, but nothing essential for correct invocation 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 single logType parameter has 100% schema description coverage, including enum values and their meanings, so the schema carries the full parameter burden. The description only restates 'for a specific log type' and adds no format or constraint details beyond the schema, making the baseline 3 appropriate.

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 and resource ('Get the status of log streaming') and clarifies that it reports delivery health, which distinguishes it from the sibling config tools (get_log_stream_config, set_log_stream_config). However, it does not explicitly name or contrast those alternatives, so it falls 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?

The description implies usage by defining what the tool reports ('whether logs are being delivered successfully'), giving an agent enough context to infer when to call it. But it offers no explicit when-to-use guidance, no exclusions, and no mention of the config-oriented siblings, so it remains implied rather than stated.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered without the description. The description adds only the scoping detail 'configured for your tailnet' and says nothing about return shape or whether the list can be empty, which is a modest addition over the structured data.

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?

A single front-loaded sentence with no filler. Every word (DNS, nameservers, tailnet) carries meaning and nothing is redundant.

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 zero-argument getter with no output schema, the description is minimally sufficient but does not describe what the response contains (e.g., a list of nameserver IPs) or how it relates to DNS preference/split-DNS config. It is adequate but leaves a clear gap for an agent working among many DNS-related siblings.

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 takes zero parameters, so there is no parameter surface for the description to explain. Baseline 4 applies; no parameter information is missing or needed.

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 (Get) and resource (DNS nameservers) scoped to the tailnet, so the operation itself is unambiguous. However, it does not distinguish itself from nearby siblings like tailscale_get_dns_preferences, tailscale_get_split_dns, or tailscale_get_dns_configuration, which an agent could easily conflate with this tool.

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?

There is no guidance on when to use this tool versus the multiple DNS-related getters in the sibling list. The description gives no prerequisites, no conditions, and no alternatives, leaving routing entirely to inference from the name.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds context about the content of the logs but does not disclose additional behavioral traits such as pagination limits, auth requirements, or scope of data returned.

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?

The description is two sentences, front-loaded with the primary verb and resource, and adds relevant content and use cases without fluff. It is concise but not overly terse.

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 simple read-only tool with two well-documented parameters and strong annotations, the description adequately covers the data returned (source/destination nodes, timestamps, traffic metadata) and the use cases. It does not mention pagination or output schema, but that is acceptable given the tool's simplicity.

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 input schema already describes both parameters fully (100% coverage) with RFC3339 format and the behavior of the optional end parameter. The description does not add additional meaning about how to choose start/end beyond what the schema provides, 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource ('Get network traffic flow logs') and elaborates with content ('source/destination nodes, timestamps, and traffic metadata') and use cases ('security monitoring and debugging connectivity'), clearly distinguishing it from sibling tools like audit logs or log stream configs.

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?

The description provides usage context ('useful for security monitoring and debugging connectivity') which implies when to use the tool, but it does not explicitly name alternatives or state when not to use it. This is clear context without exclusions.

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

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

Annotations already declare read-only, idempotent, non-destructive, open-world behavior, so safety is covered. The description adds meaningful context beyond that: the client secret is never returned and only exists at creation time, which prevents an agent from expecting it and explains an important output limitation.

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 tight sentences with the core action and returned fields front-loaded, followed by purpose and then the important output caveat. No filler or redundancy.

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?

With no output schema, the description compensates by naming what is returned (name, redirect URIs, scopes) and what is excluded (client secret). For a simple single-parameter read tool with full annotations, nothing an agent needs to call it correctly 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?

Schema coverage is 100% and the single appId parameter is fully documented there, including its origin from create_oauth_app. The description only echoes 'by its app ID', adding no format or syntax detail beyond the schema, so the baseline of 3 applies.

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 and resource ('Get an OAuth App's configuration') and even enumerates the returned fields (name, redirect URIs, scopes). It is clearly distinct from the sibling create/list/delete OAuth app tools.

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?

Explicitly gives a use case ('Use this to verify an app was registered as intended'), which tells the agent the intent behind the call. However, it does not explicitly route away from siblings like tailscale_list_oauth_apps for broader discovery, so it stops short of naming alternatives.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered by structured data. The description adds no behavioral context beyond that — no return shape, no note on unknown IDs — so it earns only the baseline.

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?

A single front-loaded sentence with zero filler; the verb and resource lead and nothing is redundant.

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 one-parameter read tool fully covered by the schema and safety annotations, the definition is essentially complete. The only minor gap is that with no output schema, it doesn't hint at what 'details' the integration returns.

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 coverage is 100% and the single integrationId parameter is documented ('The posture integration ID'). The description only restates that a specific integration is fetched and adds no format or sourcing guidance, so the schema does the work.

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?

Clear verb+resource ('Get details for a specific device posture integration'), and the singular 'a specific' distinguishes it from the sibling list_posture_integrations. It does not name the sibling explicitly, but the singular/plural contrast makes the scope inferable.

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?

Requiring a 'specific' integration implies you must already have an integrationId and are not enumerating, which hints at when to use this over list_posture_integrations. However, there is no explicit when-to-use/when-not statement or named alternative.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered by structured data. The description only adds the tailnet scoping context, with no mention of return format, caching, or freshness; against this annotation coverage a 3 is appropriate.

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?

A single front-loaded sentence with no filler; the resource and scope appear immediately. Nothing is wasted and nothing relevant is 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 zero-parameter read-only getter with no output schema and annotations that already carry the safety semantics, the description is nearly sufficient. It stops short of describing what a search path entry looks like or how results are ordered, but for this tool's complexity that omission is minor.

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 takes zero parameters, so per the rubric the baseline is 4. Schema coverage is 100% and there is nothing further for the description to clarify about inputs.

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 and resource ('Get the DNS search paths') and scopes it to 'your tailnet', which is clear and unambiguous. However, it does not differentiate itself from adjacent DNS tools such as tailscale_get_split_dns, tailscale_get_dns_preferences, or its mutation counterpart tailscale_set_search_paths.

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?

The description offers no guidance on when to use this tool versus the many other DNS getters in the sibling list, and no prerequisites or conditions are stated. The agent must infer usage purely from the name.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is fully covered without description help. The description adds what the response contains (MagicDNS name, virtual IP, configuration), which is useful but no deeper behavioral context such as error handling for an unknown service name.

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?

A single front-loaded sentence with no filler; the returned-fields clause earns its place. It is efficiently sized, though very terse for a tool with a large sibling set.

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 simple read-only getter with one required param and full annotation coverage, the description is nearly sufficient. With no output schema present, the brief enumeration of returned fields (MagicDNS name, virtual IP, configuration) is a meaningful partial substitute, leaving only error/not-found behavior unaddressed.

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?

There is one parameter with 100% schema description coverage, so the schema already documents serviceName. The description adds nothing about the parameter's format (hostname vs. fully qualified name vs. tag), so the baseline of 3 applies.

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 and resource (get details for a specific Tailscale Service) and names the returned content. The word "specific" implicitly distinguishes it from tailscale_list_services, but no sibling is named explicitly, so it stops 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?

The description gives no when-to-use guidance, no prerequisites, and never points to the obvious alternatives (tailscale_list_services to discover names, tailscale_update_service / tailscale_delete_service for mutations). Usage can only be inferred from the required serviceName parameter.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds no behavioral context beyond that, such as what the approval status looks like or potential errors. Since annotations handle the core transparency, a 3 is fair; it neither contradicts nor enriches them.

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?

A single, grammatically correct sentence that is front-loaded with the verb and resource. No unnecessary words or repetition; it is concise and to the point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.