Skip to main content
Glama
Jambozx

OnlineCyberTools MCP (280+ filterable tools)

network_ping

Check if a host is reachable and measure its round-trip latency using ICMP ping or HTTP probe. Reports average ping time, TTL, or HTTP response status and time.

Instructions

Ping Host (ICMP/HTTP Reachability). Measure reachability and round-trip latency to a single host. Prefers a registered remote worker that runs a real ICMP ping (system ping -c, method remote_icmp) and returns average time, TTL, and full raw_output; if no worker is available it falls back to an HTTP HEAD/GET reachability probe (method HTTP simulation) that reports HTTP response time and status_code instead of true ICMP. Use this to confirm a host is up and gauge latency to ONE target. Use network_traceroute instead to see the per-hop path, network_website_status_checker to validate an HTTP(S) URL response/status, network_dns to resolve names to records, or networking_network_latency_calculator for offline RTT/jitter statistics. target may be a hostname or IPv4/IPv6 address (no scheme/path); private, reserved, and loopback addresses are rejected (SSRF guard, re-checked after DNS resolution). Performs an OUTBOUND network probe to the target, so results vary between calls and are not idempotent; it never modifies

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
targetYesHostname or IPv4/IPv6 address to ping, e.g. 8.8.8.8 or example.com. No scheme or path. Private, reserved, and loopback addresses are rejected.
packetNoNumber of ICMP echo packets to send on the remote-worker path; the reported time is the average across replies. Ignored by the HTTP fallback, which always issues one request.
worker_idNoOptional registered healthy worker peer ID. Omit to use the default master-server behavior.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
successNoTrue when the host responded (ICMP exit code 0, or a completed HTTP request).
targetNoThe hostname or IP that was pinged, echoed from the request.
hostNoHost that answered: the target hostname on the worker path, or the resolved public IP on the HTTP fallback path.
packetNoNumber of packets sent (worker path) or 1 (HTTP fallback).
timeNoRound-trip time in milliseconds: average ICMP reply time on the worker path, or total HTTP response time on the fallback. Null when no reply was received.
ttlNoTime To Live from the reply (parsed from ICMP on the worker path; defaulted to 64 on the HTTP fallback).
methodNoWhich mechanism produced the result: remote_icmp for a real ICMP ping via a worker, or HTTP simulation for the HTTP reachability fallback.
raw_outputNoFull raw text output of the system ping command. Present only on the remote_icmp worker path.
bytesNoPayload size in bytes (fixed 32). Present only on the HTTP simulation fallback path.
status_codeNoHTTP status code returned by the reachability probe. Present only on the HTTP simulation fallback path.
timestampNoISO 8601 timestamp of when the ping completed.
Behavior5/5

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

Description details dual behavior (prefers ICMP via remote worker, falls back to HTTP probe), SSRF guard rejecting private addresses, and non-idempotent nature. Annotations (readOnlyHint=false, idempotentHint=false) align and don't contradict.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

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

Description is front-loaded with purpose and compressed but includes necessary details. Slightly verbose due to behavioral and security explanations, but each sentence earns its place.

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?

Given the tool's complexity (dual mode, SSRF guard, variability) and presence of output schema, description covers reachability, latency, fallback, SSRF rules, and non-idempotency. Complete for agent selection and invocation.

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 covers all three parameters (target, packet, worker_id) with descriptions. Description adds context on target format, packet's role only in ICMP path and ignored by HTTP fallback, and worker_id as optional.

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?

Title and description clearly state 'Ping Host (ICMP/HTTP Reachability)' with verb 'ping' and resource 'host'. Description explicitly distinguishes from sibling tools (network_traceroute, network_website_status_checker, etc.) by stating when to use each alternative.

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

Usage Guidelines5/5

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

Description explicitly states 'Use this to confirm a host is up and gauge latency to ONE target' and provides clear alternatives for different needs (traceroute, DNS, HTTP validation).

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Jambozx/onlinecybertools-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server