Uptime Ping Grounding Data

Overview

The API runs the system ping utility against `host`, one probe per round trip and one after another, and records the reply time of each probe that is answered. `host` must be a valid hostname or IP address that resolves to a public address; private ranges, loopback and similar targets return 400. A name that cannot be resolved is still attempted and comes back not alive.

`roundTrips` sets how many probes are sent, 1 to 5, default 1. `timeout` is given in milliseconds (100-3000, default 1500), but ping waits in whole seconds, so the value is rounded up: 100-1000 waits 1 second per probe, 1001-2000 waits 2 and 2001-3000 waits 3. Free plan calls always use the default, a 2-second wait.

`alive` is true when at least one probe was answered, and `roundTrips` in the response is the number answered, not the number sent. `packetLoss` is the unanswered share times 100 and is not rounded, so one loss in three reads 33.33 and more digits. `minMS`, `avgMS` and `maxMS` summarise `times`, the per-probe round trips in milliseconds, and `stdDev` is their population standard deviation.

If every probe fails, `alive` is false, `packetLoss` is 100, the timing fields are null and `times` is empty. If the second probe of a multi-probe run fails, the run stops there and the call returns an error status carrying that same not-alive payload. `numericHost` is the IP ping resolved, or `unknown`. Many hosts drop ICMP deliberately, so not alive can mean a firewall rather than an outage. On the Free plan `numericHost`, `packetLoss` and every timing field are null.

Live Test Uptime Ping Grounding Data Source →

The tool

Once your client is connected to the VerveContext server, this appears in its tool list as UptimePingGroundingData. It is read-only and open-world — it fetches and never mutates anything on your side — so most clients call it without asking you to confirm.

{
  "name": "UptimePingGroundingData",
  "arguments": {
    "host": "google.com"
  }
}

You do not name the tool yourself; the model picks it. Asking about google.com in the terms this source covers is enough for it to reach for UptimePingGroundingData on its own — naming it explicitly also works, and is the way to force the call.

Connecting

One server URL covers every source in the catalog, including this one. Authorization is OAuth: the client opens a browser once, and there is no key to paste into a config file.

{
  "mcpServers": {
    "vervecontext": {
      "url": "https://api.vervecontext.com/v1/mcp"
    }
  }
}

https://api.vervecontext.com/v1/mcp

Per-client setup — Claude, Cursor, VS Code, ChatGPT — is on the MCP setup page.

Arguments

These are the properties on the tool's inputSchema, so a well-behaved client validates them before the call is made. Premium arguments are accepted on every plan but only take effect on plans that include them.

What the model gets back

The result carries a structuredContent object matching the tool's declared outputSchema, so a client reads fields without parsing prose. status is "ok" and error is null on success; a null field means the value was not available for that input, not that the call failed.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

{
  "status": "ok",
  "error": null,
  "data": {
    "host": "google.com",
    "numericHost": "2607:f8b0:4001:c6e::8a",
    "alive": true,
    "roundTrips": 3,
    "packetLoss": 0,
    "minMS": 0.652,
    "avgMS": 0.6846666666666666,
    "maxMS": 0.712,
    "stdDev": 0.02478350706058811,
    "times": [
      0.712,
      0.652,
      0.69
    ]
  }
}

Response fields

Paths are relative to data. Premium fields are absent rather than zeroed on plans that do not include them, so check for presence instead of comparing to 0.

Why ground on it

A model can produce something that looks like this answer from its training data, and be confidently out of date or simply wrong. This source returns the current value in a shape you can check, which is the difference between an answer you can cite and one you have to hedge.

Point an evaluation at alive: it is the field most worth pinning a claim to, and it is either present and current or absent — never plausibly invented.

Failure modes

Errors come back as tool errors carrying a sentence the model can act on, not a bare status code. Error handling covers the full list.

A call costs 2 credits each time the tool actually runs; a model that reasons about the tool without calling it costs nothing.

Use cases

Server Reachability Checks

DevOps engineers trigger ping checks during deployments to confirm that newly provisioned web servers respond before routing production traffic to them.

Network Latency Monitoring

When network engineers detect sluggish connections, they inspect round-trip responses across public IP endpoints to diagnose potential packet drop issues.

Domain Availability Verification

To catch outages fast, internal status dashboards poll critical external third-party hostnames and display immediate alive indicators to support staff.

Automated Incident Triage

Alerting systems ping reported remote servers to verify reachability before paging on-call staff for an offline alert.

Other ways to use Uptime Ping Grounding Data

Set up Uptime Ping Grounding Data on VerveContext, or reach the same source a different way. Your VerveContext account and credits work on all of them — one key, one balance.

Related

More in Networking: