Skip to main content
Glama
Sign In
tailscale-mcp

tailscale-mcp

by TMHSDigital
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Ping all peers

ping_all
Read-onlyIdempotent

Concurrently ping online Tailscale tailnet peers and return a latency matrix with each node's latency, path (direct, DERP relay, or peer relay), or unreachable status.

Instructions

Ping tailnet peers concurrently (bounded to 5 at a time, with a per-ping timeout) and return a latency matrix: node, latency ms of the settled path, path (direct, DERP relay, or peer relay), or unreachable. Defaults to online peers only. The whole call is capped at 45s; peers not answered by then are reported with an error and timedOut is true.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "ping_all"
  }
}

Input Schema

NameRequiredDescriptionDefault
countNoPing attempts per peer (default: 1)
timeoutMsNoPer-ping timeout in milliseconds (default: 5000)
onlineOnlyNoOnly ping peers reported online (default: true)

Output Schema

NameRequiredDescriptionDefault
matrixYes
pingedYes
timedOutYes
reachableYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.4.0
    • removedInput schema / additionalProperties
      Removed value: -false
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "matrix": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "attempts": {
+            "type": "number"
+          },
+          "dnsName": {
+            "type": "string"
+          },
+          "error": {
+            "type": "string"
+          },
+          "hostname": {
+            "type": "string"
+          },
+          "latencyMs": {
+            "type": [
+              "number",
+              "null"
+            ]
+          },
+          "path": {
+            "anyOf": [
+              {
+                "enum": [
+                  "direct",
+                  "derp",
+                  "peer-relay",
+                  "unknown"
+                ],
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "reachable": {
+            "type": "boolean"
+          },
+          "replies": {
+            "type": "number"
+          },
+          "target": {
+            "type": "string"
+          },
+          "via": {
+            "type": [
+              "string",
+              "null"
+            ]
+          }
+        },
+        "required": [
+          "hostname",
+          "dnsName",
+          "target",
+          "reachable",
+          "latencyMs",
+          "path",
+          "via",
+          "attempts",
+          "replies"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "pinged": {
+      "type": "number"
+    },
+    "reachable": {
+      "type": "number"
+    },
+    "timedOut": {
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "pinged",
+    "reachable",
+    "timedOut",
+    "matrix"
+  ],
+  "type": "object"
+}
  2. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

Goes well beyond the readOnly/idempotent annotations by disclosing concurrency bounding (5 at a time), a per-ping timeout, a hard 45s cap on the whole call, and exactly how unanswered peers are reported (error plus timedOut=true). These are execution traits an agent cannot get from the 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.

Conciseness5/5

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

Three tight sentences, front-loaded with what the tool does and its concurrency model, then the return shape, then the timeout failure mode. No filler or repetition of the title.

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

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists and the description still summarizes the returned fields and the timeout/error case. Combined with the concurrency and cap details, an agent has everything needed to call this correctly and interpret results without further lookup.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning by tying timeoutMs to the per-ping timeout and explaining how the 45s overall cap interacts with attempts, and by restating that the default scope is online peers. It does not cover the 'count' attempts parameter explicitly in prose.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

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

Opens with a specific verb+resource ('Ping tailnet peers concurrently') and immediately defines the output shape (latency matrix: node, latency, path, unreachable). This is clearly distinguishable from siblings like tailnet_status or share_status, which do not measure per-peer latency.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the diagnostic use case ('latency matrix') and states the default of online-only pinging, but never says when to prefer this over tailnet_status or when a targeted ping is a better choice. Usage is inferable rather than explicit, and no alternatives or exclusions are named.

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

Deploy Server

Other Tools