Globalping External Checks

Globalping External Checks

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?"

Read this first — three ways to get nothing back

These look similar and mean completely different things. Getting them confused is the single failure mode this skill exists to prevent.

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.

Public targets only — refuse internal ones before calling out

Check the target before every call. Refuse locally, do not let Globalping refuse it for you:

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.

When refusing, name the tool to use instead:

"10.0.0.1 is a private address — Globalping measures from the public internet and can't reach it. For internal reachability use pyATS (run_show_command with ping) or multivendor-cli; for a path from this host outward, use gtrace."

Available Tools

Five measurement tools. All take target, locations, limit and context.

1. ping — reachability and latency

python3 $MCP_CALL globalping-mcp ping '{
  "target":"example.com", "locations":"world", "limit":10, "packets":3,
  "context":"Validating external reachability and latency distribution for a public service endpoint during operational troubleshooting."
}'

2. traceroute — the path from a probe toward the target

python3 $MCP_CALL globalping-mcp traceroute '{
  "target":"example.com", "locations":["Japan","Germany"], "limit":2,
  "context":"Identifying the network path and potential failure point toward a public endpoint from two distant regions."
}'

3. dns — resolution and propagation

python3 $MCP_CALL globalping-mcp dns '{
  "target":"example.com", "locations":"world", "limit":15, "queryType":"A",
  "context":"Verifying global DNS propagation consistency for a public domain record following a planned change."
}'

4. mtr — per-hop loss and latency together

python3 $MCP_CALL globalping-mcp mtr '{
  "target":"example.com", "locations":"Singapore", "limit":2,
  "context":"Correlating per-hop packet loss with latency toward a public endpoint to localise a degradation."
}'

5. http — application-layer reachability, status and timing

python3 $MCP_CALL globalping-mcp http '{
  "target":"example.com", "locations":"world", "limit":10, "method":"GET", "path":"/",
  "context":"Confirming HTTP availability and response timing for a public web endpoint across multiple global regions."
}'

6. limits — check the budget before a big investigation

python3 $MCP_CALL globalping-mcp limits '{
  "context":"Reviewing remaining measurement allowance before planning a broad multi-region reachability investigation."
}'

7. locations — are there probes where you want to measure from?

python3 $MCP_CALL globalping-mcp locations '{
  "context":"Checking probe availability in a target region before issuing a narrowly scoped measurement request."
}'

Call this before using a narrow filter. It is the difference between a wasted call and a real answer.

getMeasurement retrieves a prior result by id. help, authStatus, compareLocations and get_more_tools are self-describing — use them if you want, they need no guidance here.

Location syntax

"London,UK" does not work. A comma inside a single string fails. Use + for AND, or an array for several locations.

AS13335 never returns probes — even though it appears as an example in Globalping's own tool documentation. Cloudflare hosts no probes. AS15169 (Google) hosts none either. AS3320, AS16509 and AS174 do.

So when an ASN filter returns no_probes_found, the overwhelmingly likely cause is that ASN has no probes, not that the syntax is wrong. Check locations rather than rewriting the filter. Only ~1,390 of the internet's autonomous systems host a probe.

Budget: limit is what you spend

500 probe-measurements/hour with a token (250/hour unauthenticated, per IP). Rolling one-hour window, shared across everything using the token.

The cost of a call equals its probe count. limit: 1 spends 1, limit: 5 spends 5, limit: 20 spends 20. Calling limits to check the budget is free.

So limit is the dial that spends the allowance — choose it for the question being asked:

Five 100-probe world tests exhaust the hour. Don't reach for limit: 100 because it is available.

Equally, don't loop where one call would do: ten separate 3-probe pings cost the same 30 units as one 30-probe ping, but give you ten small unattributed samples instead of one broad comparable set. Prefer one right-sized call.

Call limits first before a big investigation — it costs nothing and tells you what you have.