Loading ToolBench
The server defines one tool, 'generate-emoji', with a visible schema and description. However, the schema is incomplete: the inputSchema uses Zod validation but does not expose a proper JSON Schema object structure. The description is adequate (98 chars) but lacks critical context about prerequisites, when to use this tool, and what the output contains. Parameters lack type declarations in the exposed schema, only Zod string descriptors are visible. The tool performs a state-modifying operation (calls an external LLM API) but the description does not state this, violating the pattern:command-tool requirement. Error handling is absent; there is no recovery guidance if the API call fails. No output schema is documented, callers cannot know what fields to expect from the response. The tool is READ_ONLY labeled, but it actually invokes external services with side effects.
Generate the most suitable eye-catching emoji (one character) for articles on Zenn (https://zenn.dev)
Input schema is not a valid JSON Schema object. The code uses z.string().describe() (Zod validation), which is server-side validation, not a schema exposed to the LLM. LLMs cannot parse Zod validators, they require a JSON Schema with 'type', 'properties', 'required', and 'description' fields.
Tool description does not state that this tool calls an external LLM API (OpenAI or Azure) to generate content. Descriptions of state-modifying tools must be explicit: 'Calls Claude/OpenAI API to generate an emoji and reason.' This is required for agents to understand side effects and retry logic.
Output schema is not documented. The tool returns {content: [{text: string, type: string}]} but callers cannot know this from the tool definition. LLMs need to know what fields to extract. A documented output schema is required.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 44 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 31 | - | v1 |
No error handling or recovery guidance. If the API call fails, the handler does not return a structured error with actionable guidance. Code shows a bare await client.chatCompletion() with no try-catch, errors will propagate as unstructured exceptions.
Tool is marked READ_ONLY but actually calls external APIs (OpenAI/Azure) which may have billing/side effects. The risk classification is inaccurate. Either correct the label to reflect API state-changes, or document exactly why this is considered read-only.
Parameters 'file' and 'text' lack context. 'file' is described as 'file path' but serves only for logging/context (not actually read by the tool). This is misleading. Clarify whether 'file' is required for operation or only metadata.