net-mcp

Local Traceroute

local_traceroute

Trace the network path to any host, showing each hop with latency. Uses UDP probes without admin rights on macOS, Linux, and Windows.

Instructions

Trace the network path to a host from the local machine.

Shows each hop along the route with latency. Uses UDP probes by default (no admin required). On macOS/Linux uses traceroute, on Windows uses tracert. If the trace exceeds its time budget the partial output collected so far is returned with returncode 124.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`host`	Yes	Hostname or IP address to trace (an IPv6 literal may be bracketed)
`max_hops`	No	Maximum number of hops (1-64)

Output Schema

TableJSON Schema

Name	Required	Description
`note`	No	Additional context about the result
`error`	No	Why the tool could not produce a result: input validation failure, tool disabled by configuration, binary not installed, or no service answered. Empty when the command executed.
`stderr`	Yes	Standard error of the command, or the failure message when the command did not run
`stdout`	Yes	Standard output of the command (curl output is capped at 10,000 characters)
`command`	Yes	The exact command line that was executed, or the tool name if the command never ran
`success`	Yes	True when the command ran and exited with status 0
`platform`	Yes	Operating system the command ran on (Darwin, Linux or Windows)
`returncode`	Yes	Process exit status. 0 = success; 2 = input rejected before running; 124 = timed out; 126 = disabled by config or permission denied; 127 = binary not found

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 22, 2026

TDQS

A4.3/5.0

Behavior5/5

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

With zero annotations, the description carries the full burden and handles it well: it discloses probe type (UDP default), privilege requirement (no admin), platform variance (traceroute vs tracert), and crucially the timeout behavior — partial output returned with returncode 124. This exceeds the typical safety/behavior disclosure bar.

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?

Every sentence earns its place: purpose, output, probe/privelege, platform mapping, timeout behavior. Front-loaded with the core action, and compact at roughly 50 words with no filler.

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?

For a 2-parameter tool with an output schema (so return values are already specified), the description covers everything needed to invoke it correctly: privilege, platform, probe type, and the partial-output-on-timeout edge case. Nothing operationally relevant is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents host and max_hops with ranges and defaults. The description adds no parameter-specific meaning (e.g., how max_hops relates to the time budget), so the baseline 3 applies.

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?

States a specific verb ('Trace'), a resource ('the network path to a host'), and a clear scope ('from the local machine'), plus the output it produces ('each hop along the route with latency'). This cleanly distinguishes it from siblings like local_ping (reachability, no path) and dns_trace (DNS resolution path, not network path), even without naming alternatives.

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 usage context (diagnosing network path/hops) and adds practical conditions — UDP probes by default and 'no admin required' — but never explicitly says when to choose this over local_mtr or local_ping, nor names alternatives. Usage is inferable but not stated.

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