Tailscale
Tailscale is a secure networking platform for managing tailnets, devices, users, DNS, access policies, services, and other network administration resources.
Verdict
Common use cases
- Check which devices are online before deploying
- Audit who changed DNS settings last week
- Approve a new server from Slack thread
- Verify subnet routes for a staging machine
- List all devices tagged for a specific environment
Integration
- Vendor
- Tailscale
- Category
- other
- Auth
- API_KEY
- Tools
- 10
- Composio slug
tailscale
Tools
- Get Device
Get the full current record for one manageable Tailscale device by ID.
- Get DNS Configuration
Return the selected tailnet's combined MagicDNS, nameserver, search-path, and split-DNS configuration.
- Get Tailnet Settings
Return current tailnet-wide approval, update, key-duration, HTTPS, routing, logging, and posture settings.
- List Configuration Audit Logs
Return configuration audit events for an explicit RFC3339 time window in the selected tailnet, optionally filtered by actor, target, or event name.
- List Device Routes
Return the subnet routes advertised and currently enabled for a Tailscale device.
- List Tailnet Devices
Return all devices in the selected tailnet, including identifiers, names, addresses, tags, authorization state, and connectivity metadata. Supports exact server-side filtering by hostname, tags, and ephemeral state.
- List Users
Return users in the selected tailnet, optionally filtered by membership type or role.
- Set Device Authorization
Approve or revoke approval for one device when device approval is enabled on the tailnet.
- Set Device Routes
Replace the enabled subnet routes for one device with an explicit list of routes. Routes may be enabled before the device advertises them.
- Set Device Tags
Replace all ACL tags assigned to one Tailscale device.
Setup
Setup guide
- 11. In Switchy, open your workspace settings and navigate to the Integrations page. 2. Find Tailscale in the MCP directory and click Connect. 3. You'll be prompted to paste a Tailscale API key — generate one at https://login.tailscale.com/admin/settings/keys by clicking 'Generate access token'. 4. Choose scopes based on what your team needs: 'devices:read' and 'tailnet:read' cover most queries; add 'devices:write' if you want to authorize devices from chat. 5. Paste the key into Switchy and click Save. 6. Open any Project, type '@Tailscale list devices in my tailnet' and send — if you see a device list, the connection works. 7. From now on, @mention Tailscale in any Project message to invoke its tools; the AI will route your request to the right endpoint and format the response.
What teammates see: by default, memories from Tailscale are scoped to the Project (PROJECT visibility) - you can mark any memory PRIVATE or share it ORG-wide.
Works well with
Top models
Compatibility data appears once enough Projects have used this MCP together with a given model.
How Switchy teams use it
Starter prompts
List All Devices
@Tailscale list all devices in my tailnet and show their hostnames, IP addresses, and whether they're authorized.
Check DNS Config
@Tailscale get the current DNS configuration for my tailnet, including nameservers and search domains.
Review Recent Audit Logs
@Tailscale list configuration audit logs from the last 7 days and highlight any device authorization or settings changes.
Authorize New Device
@Tailscale authorize the device with ID 12345678901234567 so it can join the tailnet.
Inspect Device Routes
@Tailscale list the subnet routes for device ID 12345678901234567 and tell me which ones are currently enabled.
Example outputs
Illustrative - representative of the model's voice and quality, not literal recordings.
@tailscale list all devices in our tailnet that are tagged 'production' and show their current online status
Found 12 devices tagged 'production' in your tailnet. 10 are currently online: app-server-01 (100.64.0.5), db-primary (100.64.0.12), cache-node-1 through cache-node-6, and api-gateway-02. Two devices are offline: backup-server (last seen 3 hours ago) and staging-proxy (last seen 2 days ago). All online devices show active connections and are running Tailscale 1.56.1 or newer. Three devices have subnet routes enabled.
This example uses the List Tailnet Devices tool with server-side tag filtering. Requires API key with device:read scope. Device state reflects a point-in-time snapshot — connectivity can change between query and display. Useful for infrastructure audits and troubleshooting network topology.
@tailscale approve the device with hostname 'contractor-laptop-jsmith' that's pending authorization
Device 'contractor-laptop-jsmith' (ID: 12345678901234567) has been approved. The device can now access tailnet resources according to your ACL policy. Authorization was granted by API key holder at 2024-01-15T10:23:45Z. The device is currently online at 100.64.0.89 and is running Tailscale 1.54.0. Note: This approval is permanent until explicitly revoked or the device is removed from the tailnet.
This example uses Set Device Authorization to approve a pending device. Requires device:write scope and tailnet-level device approval to be enabled in settings. This is a destructive action — approval grants immediate network access. Always verify device identity before approving, especially for contractor or guest devices.
@tailscale review our DNS configuration and audit logs from the past week, then summarize any configuration changes that might affect internal service discovery
Your tailnet's MagicDNS is enabled with search domain 'tail-abc123.ts.net'. Three nameservers are configured: 1.1.1.1, 8.8.8.8, and an internal resolver at 10.0.1.53. Reviewing the past week's audit logs shows two relevant changes: On Jan 10, admin@company.com added a split-DNS override for 'internal.company.com' pointing to 10.0.1.53. On Jan 12, the same admin enabled HTTPS certificates for MagicDNS names. These changes mean internal services at *.internal.company.com now resolve through your private DNS, and all *.ts.net hostnames now support HTTPS. No changes to subnet routes or ACLs that would affect service reachability.
This example combines Get DNS Configuration and List Configuration Audit Logs with AI synthesis to connect infrastructure state with recent changes. Requires both dns:read and audit:read scopes. Audit log queries are time-bounded and may return large result sets for active tailnets — consider narrowing the time window for faster responses.
Use-case deep-dives
When Tailscale MCP beats manual VPN provisioning for small teams
An 8-person startup hires two contractors for a 3-month project. The founder needs to grant them access to staging servers, revoke it when the contract ends, and audit who touched what. The Tailscale MCP wins here because you can script device authorization and audit log pulls directly into a Slack workflow—no clicking through the admin console. Use Set Device Authorization to approve the contractor laptops, List Configuration Audit Logs to pull a weekly summary of access changes, and Get Device to confirm their routes before granting production access. The threshold: if you're onboarding more than 5 people per week, you need a real MDM tool, not an MCP. For occasional contractor churn at small scale, this MCP turns a 20-minute admin task into a 2-minute Switchy prompt.
Use this MCP when you need live network topology during outages
A 12-person SaaS team gets paged at 2am because the staging environment is unreachable. The on-call engineer needs to confirm which devices are advertising subnet routes and whether the DNS split-tunnel config changed in the last 6 hours. The Tailscale MCP is the right call because List Device Routes and Get DNS Configuration return live state without SSHing into anything. Pull the audit logs with List Configuration Audit Logs to see if someone toggled a route at 9pm. The trade-off: this MCP doesn't restart services or push config—it's read-heavy with one write action (device auth). If your incident runbooks require changing Tailscale settings under pressure, you're better off scripting the Tailscale CLI directly. For diagnosis and audit during firefights, this MCP saves 10 minutes of console navigation when every minute counts.
When Tailscale MCP handles compliance reporting at sub-50-device scale
A 15-person agency with remote workers in 4 countries needs to generate a quarterly report of device approvals, user roles, and configuration changes for a SOC 2 audit. The Tailscale MCP is the right tool because List Tailnet Devices, List Users, and List Configuration Audit Logs give you structured JSON you can drop into a spreadsheet or compliance dashboard. Pull the full device list, filter by authorization state, cross-reference with user roles, and export audit events for the 90-day window. The boundary: if you're managing more than 50 devices or need real-time alerting on config drift, you want a SIEM integration, not an MCP. For quarterly or monthly snapshots at small-team scale, this MCP turns a 2-hour manual export into a 5-minute Switchy query that your compliance lead can run without Tailscale admin access.
Frequently asked
What does the Tailscale MCP do in Switchy?
It lets your AI agents read and manage your Tailscale network directly from chat. Agents can list devices, check DNS settings, review audit logs, manage device authorization, and inspect subnet routes. This means you can ask questions about your tailnet or make configuration changes without opening the Tailscale admin console.
Do I need admin access to connect Tailscale MCP?
Yes. You need to generate an API key from your Tailscale admin console with appropriate scopes for the operations you want. The MCP uses API_KEY authentication, so whoever connects it must have permission to create keys with read or write access to devices, DNS, settings, and audit logs depending on what your team needs.
Can the Tailscale MCP create new devices or deploy exit nodes?
No. It can't provision new devices or configure exit nodes. The MCP focuses on visibility and management of existing devices—listing them, checking their routes, approving or revoking authorization, and reading configuration. To add devices or set up exit nodes, you still use the Tailscale client or admin console directly.
Why use this instead of just checking the Tailscale admin console?
The MCP lets you ask natural language questions and get answers instantly without context-switching. Instead of clicking through the console to find which device advertises a specific subnet or who approved a device last week, you ask your agent. It's faster for routine checks and useful when you're already in Switchy working on something else.
Who on the team should connect the Tailscale MCP?
Whoever manages your Tailscale network and has admin console access. This is typically your infrastructure or DevOps lead. Since the API key grants read and potentially write access to your entire tailnet, treat it like you would SSH keys—only connect it if your team actually needs AI agents to interact with Tailscale configuration.