Cryptographically-strong randomness: hex bytes plus an optional uniform integer in [min, max]. Pay per call via x402 ($0.003, USDC on Base), or 1 credit(s) with a prepaid session.
| Name | Required | Description | Default |
|---|---|---|---|
| max | No | ||
| min | No | ||
| bytes | No | 1-256, default 16 |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/openWorld annotations, the description adds important behavioral context including per-call pricing and the cryptographic strength guarantee. It also clarifies that the integer is optional and uniform, which shapes expected output.
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 two sentences, with the first sentence front-loading the core functionality and output, and the second adding pricing details. It is concise and free of redundant phrasing.
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 simple tool, the description covers the core purpose, parameters, and cost, but it could be more explicit about the exact return structure (e.g., JSON format) and edge cases like min > max. Overall, it is adequate for an agent to select and invoke the tool correctly.
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?
The schema only documents the bytes parameter, leaving min and max without descriptions. The description compensates by explicitly stating that the integer is uniform in [min, max] and that bytes generates hex bytes, thereby clarifying all three parameters effectively.
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 explicitly states the tool generates cryptographically-strong randomness, specifying both hex bytes and an optional uniform integer. This clearly distinguishes it from sibling tools like crypto_price and funding_rates, which serve entirely different purposes.
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 clear usage context by highlighting cryptographic strength and payment requirements, implying it is for secure random generation with costs. It does not explicitly name alternatives or exclusions, but the sibling tools are unrelated, so this level of guidance is sufficient.
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.
Each tool has a clearly distinct purpose: catalog for discovery/pricing, chat for LLM completion, crypto_price for spot prices, funding_rates for perp funding, and random for randomness. There is no overlap or ambiguity between any two tools.
All tool names follow a consistent lowercase_with_underscores pattern (catalog, chat, crypto_price, funding_rates, random). No mixing of conventions or inconsistent verb styles.
With 5 tools, the set is well-scoped for a multi-purpose utility API. Each tool provides a distinct service, and the count is within the ideal 3-15 range.
The tool surface covers the apparent domain (paid utility endpoints) well, including a catalog for discovery and payment instructions. A minor gap is the lack of an explicit balance/session status tool, but this is not critical for the core workflows.