Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →automateyournetwork/globalping-external-checks
Measure a public endpoint from thousands of probes worldwide - ping, traceroute, DNS, MTR and HTTP from real vantage points on the internet.
Passed 19 of 21 test cases with the skill, and 11 of 21 without it.
and 10 more in the full report
9 fixed12 passed either way2 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 9 test cases the skill fixed. Same model, same prompt, with and without the skill.
Users in Singapore are experiencing sporadic packet loss when accessing media.example.com. We need to observe per-hop latency and per-hop packet loss concurrently from probes in Singapore. Which tool command should be invoked?
| Checked | Without skill | With skill |
|---|---|---|
| Selects the globalping-mcp mtr tool to evaluate per-hop loss and latency concurrently. | Missed | Passed |
The instructions your model reads when the skill loads.
Every other device-facing tool NetClaw has looks at the network from the inside. This one looks at it from the outside — ~4,800 probes across ~1,390 autonomous systems, measuring toward a public target.
It is the tool for "the router is fine, so why can't anyone reach us?"
These look similar and mean completely different things. Getting them confused is the single failure mode this skill exists to prevent.
| Response | What it means | What to say |
|---|---|---|
no_probes_found (422) | The measurement never ran. No probe matched the location filter. | "Nothing was tested — no probes matched that location. Retrying with a broader filter." |
finished, 0 of N successful | The target did not answer. Probes ran and got nothing. | "Unreachable from all N probes — this is a real finding." |
| Target refused before calling | Out of scope. Private/internal address. | "Globalping only measures public endpoints. Use pyATS/multivendor-cli instead." |
no_probes_found is NOT an outage. It arrives looking like a failure and tells you nothing whatsoever
about the target. Reporting it as unreachability escalates an incident that does not exist. When you see it,
say the measurement did not run, widen the location, and try again.
0 of N successful IS a finding, and a valuable one. The measurement succeeded; the answer is "nobody out there could reach it." Report it as the answer, not as an error.
Check the target before every call. Refuse locally, do not let Globalping refuse it for you:
| Refuse | Why |
|---|---|
10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 | RFC1918 private |
127.0.0.0/8, localhost | Loopback |
169.254.0.0/16, fe80::/10 | Link-local |
fc00::/7 | Private IPv6 |
| Any internal-only hostname | Not resolvable from the internet, and discloses naming |
Globalping rejects these server-side too — but by then the address or hostname has already been sent to a third party. Refusing locally is a disclosure control, not a correctness one.
test cases passed, vs 11 / 21 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.