Loading ToolBench
MCP server: generate random strings — hex, alphanumeric, base64, custom alphabet.
Single tool 'generate' has a clear action verb and well-structured JSON Schema with proper type constraints (integer, enum, string). Description is adequate at ~140 chars but lacks WHEN/WHY guidance. Parameter 'length' has min/max bounds (1-1024) and type; 'alphabet' is an enum; 'custom' has a description but lacks explicit type annotation in the schema. No output schema documented, LLMs cannot predict the response structure. Error handling is basic (try/catch with generic messages). No tool annotations (readOnlyHint, idempotentHint). Composition is sound (single responsibility), but parameter descriptions could be more explicit about constraints and use cases.
Generate a cryptographically random string. alphabet: hex, alphanumeric, alpha, numeric, urlsafe, base64, custom.
No output schema documented. LLMs cannot predict response structure (e.g., is it {value: string} or {random_string: string}?). Agents must infer from examples.
Tool description lacks WHEN/WHY context. It states WHAT (generate random strings) but not WHEN to use it (e.g., 'Use for generating secure tokens, session IDs, or test data'). LLMs may underutilize the tool.
Parameter 'custom' lacks explicit type annotation in inputSchema (should be {type: 'string'}). Schema is incomplete and may confuse strict validators.
No tool annotations (readOnlyHint, idempotentHint). The 'generate' tool is read-only and idempotent, but this is not declared. Agents cannot optimize caching or retry logic.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2026-07-28+ | v2 |
Error messages are generic ('randomstr failed: ...') and do not guide recovery. E.g., if custom alphabet is empty, the error should suggest 'custom alphabet required, provide at least one character'.