Loading ToolBench
The server registers 21 tools with explicit schemas and descriptions visible in source code. All tools follow verb_noun naming patterns (account, bankAccount, event, expense, etc.). Descriptions are present for all tools and range 18-97 characters, meeting the 10-1024 baseline but clustering toward the lower end. Input schemas are well-defined with typed parameters and descriptions for each. However, critical issues include: (1) No documented output schemas, tools declare input but not what they return, violating pattern:tool-description; (2) Generic parameter descriptions like 'Action to perform: get, search, create, update, delete' repeat across 8+ tools without context on when to use each action; (3) No error handling guidance, responses don't tell agents what to do on failure (missing pattern:recovery-guide); (4) No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite 12 WRITE tools and 9 READ_ONLY tools being marked in metadata but not exposed to LLMs; (5) Missing confirmation/dry-run support for destructive operations (invoice.delete, expense.delete, subject.delete, etc.), agents could accidentally destroy data; (6) Action-based tools (expense, invoice, generator with action='create|update|delete') mix multiple responsibilities in one tool rather than splitting into separate tools, violating pattern:tool; (7) Composite parameters like 'invoiceData', 'generatorData' have no schema documentation, LLMs cannot know what fields are valid.
Get account details
Get bank accounts for an account
Get all events from an account
Get, search, create, update, and delete expenses
Create and delete expense payments
Get, create, update, and delete generators
Get, create, and manage inbox files
Get, create, update, and delete inventory items
No output schema documentation. Tools declare input schemas but return types are not documented. LLMs cannot know what fields to expect, forcing them to guess or make redundant discovery calls.
Generic action parameter descriptions. 8 tools (expense, generator, inboxFile, inventoryItem, inventoryMove, invoice, recurringGenerator, subject, todo, webhook) use 'Action to perform: get, search, create, update, delete' without explaining when to use each action or their implications. Missing context on which actions are read-only vs destructive.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 51 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 25 | - | v1 |
Get and create inventory moves
Get, search, create, update, and delete invoices
Send and manage invoice messages
Create and delete invoice payments
Get metadata about the Fakturoid API
Get number format information
Get, create, update, and delete recurring generators
Analyze expense data and provide recommendations
Analyze invoice data and provide recommendations
Get, create, update, and delete subjects (contacts)
Get, create, update, and delete todos
Get user information
Get, create, update, and delete webhooks
No error handling guidance. Tool descriptions do not explain what happens on failure or what agents should do next. Missing recovery patterns like 'If invoice not found, try search_invoice() first' or error categorization (retryable vs fatal).
Missing tool annotations for LLM visibility. 12 WRITE tools (expense, expensePayment, generator, inboxFile, inventoryItem, inventoryMove, invoice, invoiceMessage, invoicePayment, recurringGenerator, subject, todo, webhook) are marked WRITE in metadata but lack destructiveHint annotation in schema. 9 READ_ONLY tools lack readOnlyHint. LLMs cannot distinguish safe vs dangerous tools without explicit annotations.
No confirmation or dry-run support for destructive operations. Tools like invoice, expense, subject, generator, todo allow 'delete' action without confirmation, dry-run, or idempotent retry protection. Agents can permanently destroy records with a single call.
Action-based tool design violates single-responsibility principle. 10 tools (expense, generator, inboxFile, inventoryItem, inventoryMove, invoice, recurringGenerator, subject, todo, webhook) combine get, search, create, update, delete in one tool with an 'action' enum parameter. This forces LLMs to decide which action to use and mixes multiple concerns. Should split into separate tools: get_invoice, search_invoices, create_invoice, update_invoice, delete_invoice.
Composite data parameters lack schema. Parameters like 'expenseData', 'invoiceData', 'generatorData', 'itemData', 'subjectData', 'todoData' are typed as 'object' with no description of valid fields, required fields, or structure. LLMs cannot know what to pass without API documentation outside the tool schema.
Missing pagination guidance. Tools like event, expense, invoice accept filters and search but no limit/offset/page parameters visible in schema. Without pagination, large result sets could exhaust context windows and violate pattern:paginated-result.
Vague parameter descriptions for complex filters. 'Filters for get action: since, updated_since, subject_id, custom_id, number, variable_symbol, status' lists field names without explaining their semantics, data types, or valid ranges. LLMs cannot construct correct filter objects.