Fair random numbers (min to max) or a random pick from a comma separated list.
This tool declares no required parameters. Add optional parameters from the input schema as needed.
{
"id": 1,
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"arguments": {},
"name": "random"
}
}| Name | Required | Description | Default |
|---|---|---|---|
| n | No | How many | |
| max | No | ||
| min | No | ||
| pick | No | Comma separated items to pick from instead of numbers |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description bears the full burden. 'Fair' does disclose a uniformity guarantee, which is a genuine behavioral trait, but the definition never says whether bounds are inclusive, what is returned when no parameters are given (all four are optional), what the default for n is, or what the output shape looks like (single number vs. list).
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?
A single front-loaded sentence with zero filler, presenting the two modes in the order an agent would consider them. It is tersely efficient rather than padded, though the terseness leaves gaps noted elsewhere.
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 four-parameter, no-annotation, no-output-schema tool, the description should clarify defaults, inclusive ranges, and return shape. None of these appear, so an agent cannot predict the result of calling with no arguments or with conflicting parameters.
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 50%: n ('How many') and pick are documented in the schema, while min and max carry no descriptions. The description partially compensates by explaining min and max as a range and by stating pick replaces numeric output, but it adds no bounds semantics, default values, or interaction rules.
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 names the resource (random numbers) and two concrete behaviors: a numeric range from min to max, or a pick from a comma separated list. That is enough for an agent to distinguish it from siblings like calc or count_text, which do deterministic arithmetic or counting. It is not a 5 only because the name 'random' alone is vague and the description has to carry the disambiguation.
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?
Usage is implied through the two modes and the phrase 'instead of numbers', which hints that pick and min/max are mutually exclusive alternatives. There is no explicit statement of when to choose this over a sibling, nor any note about what happens when both pick and max/min are supplied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.