tailscale_get_policy_fileGet the tailnet's ACL / policy file (returned as JSON via the Accept header, not HuJSON). Tailscale REST: GET /tailnet/{tailnet}/acl.
| Name | Required | Description | Default |
|---|---|---|---|
| details | No | If true, include metadata about the policy file (e.g. when and by whom it was last updated). |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows it's a safe read. The description adds valuable context: the response is JSON via the Accept header rather than HuJSON, and it specifies the exact REST endpoint. This goes beyond the annotation without contradicting it.
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 purpose and add one critical format detail. No wasted words or repetition of schema 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?
Given the simple one-parameter tool with readOnly annotation and no output schema, the description covers the purpose, endpoint, and response format. It could mention what the policy file contains or when to use the details flag, but the schema covers the flag, so this is largely complete.
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 only parameter 'details' is fully documented in the input schema (100% coverage), so the description doesn't need to add more. The tool description adds no extra meaning beyond the schema, 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?
The description uses the specific verb 'Get' and identifies the resource as 'the tailnet's ACL / policy file', distinguishing it from sibling tools like tailnet settings or DNS preferences. The mention of the REST endpoint further clarifies the exact 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 provides implied usage (this is the tool for reading the policy file) but does not explicitly state when to use it versus alternatives or any exclusions. With many sibling getters, more explicit guidance would help, but the context is reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct resource and action. For example, list/get/delete keys are clearly separated by operation, and DNS-related tools each address a different aspect (preferences, nameservers, searchpaths, split-dns). No two tools overlap in purpose.
All tools follow the `tailscale_<verb>_<noun>` pattern with consistent vocabulary (list, get, create, delete, set, expire, authorize). The style is uniformly snake_case, making the set predictable.
22 tools is on the higher end but still within a manageable scope for a comprehensive Tailscale API wrapper. Each tool covers a distinct endpoint, and no obvious duplication exists, though the number edges toward heavy.
The server provides strong coverage for devices and auth keys (CRUD plus actions), but DNS preferences, nameservers, search paths, split-DNS, policy file, tailnet settings, and webhooks are read-only. Missing update operations for these tailnet configuration resources are notable gaps for a management tool.