Loading ToolBench
Single tool with solid naming and schema definition, but descriptions lack depth and parameter-level guidance. Tool name 'create-anki-cards' follows verb_noun convention appropriately. Input schema is fully visible and properly typed with JSON Schema, including enum constraints for deck and model fields. However, parameter descriptions are minimal or missing context (e.g., 'Target deck for the card' lacks explanation of what happens if an invalid deck is specified). Output schema is completely undocumented, no type or structure guidance provided for the return value. Error handling is absent from the code sample. The tool operates on a constrained domain (Anki card creation) with clear, enforceable constraints, but lacks the comprehensive guidance patterns recommend for LLM-driven composition.
Create one or many Anki notes (Basic or Cloze) from structured JSON
Output schema completely undocumented. createAnkiCards() returns `result` with no type or structure guidance. LLMs cannot plan downstream operations or extract relevant fields without knowing what fields are present, their types, or their meaning.
Tool description lacks detail on state mutation and recovery. The description states what the tool does ('Create one or many Anki notes') but does not clarify: Are created cards persisted immediately? Can creation be rolled back? What happens if some cards fail? This leaves agents uncertain about idempotency and retry safety.
Missing parameter-level descriptions for nested object fields. The 'fields' parameter contains 'Front', 'Back', 'Example', 'Text', and 'BackExtra', but the schema only hints at which are required for which model types (e.g., 'required when model=Basic'). This dependency is undocumented at the parameter level, forcing LLMs to infer relationships from schema structure alone.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 53 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 45 | - | v1 |
No error handling guidance. The code calls ankiConnectService.addNotes() and returns the result without validating it or providing recovery hints. If notes fail to create, the LLM receives an opaque response (array of ids/nulls) with no explanation of what went wrong or how to retry.
Tool description is 96 characters, below the baseline minimum of ~190 chars for adequate LLM guidance. It omits key context: When should the agent use this tool? What are typical failure modes? What does the return value represent? The brevity forces LLMs to reason from schema structure alone.