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

With no annotations, the description carries full burden, and it does disclose the key behavioral trait that even-length input yields the average of the two middle values. The free-trial billing note adds useful operational context, but nothing is said about empty or single-element arrays, error behavior, or how the string input is parsed.

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?

Three short sentences, front-loaded with the operation and followed by the return behavior and the trial note. Nothing is padding, though the emoji pricing line is slightly noisy for a tool-selection decision.

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 two-parameter tool with zero annotation coverage, no output schema, and 0% schema description coverage, the description should settle the input format and the values-vs-numbers ambiguity. It explains the return value but leaves the actual invocation contract underspecified.

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 coverage is 0% and there are two untyped-as-object string parameters named 'values' and 'numbers' with no required fields. The description names 'values' but never explains the expected format (comma-separated list? JSON array?) or clarifies what 'numbers' is for or how it relates to 'values', leaving a genuine ambiguity unresolved.

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 gives a specific verb and resource: 'Calculate the median of a numeric array', which is unambiguous and correctly identifies the operation. It does not differentiate from near-identical siblings such as x402-mean-of, x402-mode, or x402-weighted-median, which an agent must sift through unassisted.

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 only guidance is 'Provide values', which restates that the tool needs input rather than explaining when to choose median over mean, mode, or weighted-median. No exclusions, prerequisites, or alternative tools are named despite a crowded sibling set.

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