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

Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses the exact execution environment (netmon server, not mcpmond), the precise command flags (--mtu -m 10 -q 2 -w 1), the hop limit and truncation behavior, and server-side PTR lookups. It also explains the return format with null fields on timeout. This is a thorough and honest behavioral contract that goes far beyond what annotations convey.

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

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

The description is information-dense yet well-organized: purpose first, then execution context, command specifics, return shape, and an example. Every sentence contributes meaningful detail—nothing is redundant or filler. The front-loaded purpose and the structured flow make it easy for an agent to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only network diagnostic tool with no output schema, the description covers all essential aspects: what it does, where it runs, operational limits (10 hops, MTU), behavior on timeout, return field names, and a concrete example. It also notes the permission requirement. An agent has everything needed to invoke it correctly without additional assumptions.

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

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

Schema description coverage is 100%, so the parameter 'target' is already documented as an IP or hostname. The description reinforces this and provides a usage example, but it does not add new constraints or disambiguation beyond the schema. It adds mild value by clarifying the target's role in the traceroute context, but the baseline of 3 is appropriate given full schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Traceroute to a target from the Netmon server', which is a specific verb, resource, and origin point. It distinguishes itself from network siblings like ping by making clear it traces the path from a fixed server, and it names the underlying API and permission requirement. This is unambiguous and tells an agent exactly what operation is performed.

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

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

The description provides strong contextual cues about when this tool is relevant (network path tracing, MTU discovery, hops up to 10) but it never explicitly contrasts it with alternatives or states when not to use it. It does not name ping or other siblings, nor does it give a 'use this if...' rule, leaving usage inference to the agent. The purpose itself implies route tracing, but explicit guidance is missing.

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