Loading ToolBench
This server has three tools with basic but incomplete schemas and descriptions. All tools are explicitly registered in src/index.ts with type definitions and enums, but descriptions lack context about when to use each tool, error recovery, and expected output. Parameter descriptions are minimal or absent. No output schemas are documented. Error handling exists (formatError function) but lacks recovery guidance. The tools are read-only/write operations covering a financial API, which is appropriate, but the definitions would benefit from more detailed parameter guidance and output documentation.
Get a single entity by ID from Moneybird.
List entities from Moneybird. Entities: contacts, sales_invoices, estimates, recurring_sales_invoices, products, projects, time_entries, financial_accounts, ledger_accounts. Use filter for server-side filtering (e.g. state:open, period:this_month, contact_id:123).
Make a custom Moneybird API request. Common paths: contacts, sales_invoices, estimates, recurring_sales_invoices, documents/purchase_invoices, documents/receipts, financial_accounts, financial_mutations, ledger_accounts, products, projects, time_entries, tax_rates, subscriptions, webhooks. See https://developer.moneybird.com for full docs.
Output schemas not documented. Tools return raw JSON responses without specifying the structure callers should expect. LLMs cannot reliably extract data for downstream tool calls or plan multi-step operations.
Parameter descriptions are minimal or missing context. 'query' parameter says 'Search term (contacts, products, time_entries)' but does not explain matching behavior, partial vs exact, or case sensitivity. 'filter' parameter references 'server-side filter' without explaining valid filter syntax or examples beyond two hardcoded ones.
Tool descriptions lack WHEN-to-use context. 'moneybird_list' vs 'moneybird_get' vs 'moneybird_request' are not clearly distinguished for the LLM. When should an agent prefer the generic 'moneybird_request' over the specific 'moneybird_list'? This ambiguity will cause LLMs to pick the wrong tool.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 51 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 36 | - | v1 |
'moneybird_request' is a bypass tool that bypasses moneybird_list and moneybird_get, inviting misuse. LLMs may use the generic tool when specific ones would be safer. The description lists 'common paths' but does not explain why an agent should prefer it over the specific tools for those same paths.
Error handling is present (formatError) but does not guide LLM recovery. Rate limit errors mention 'resets at X' but do not suggest backoff strategy or retry timing. Missing entity errors do not offer alternatives. This violates the recovery-guide pattern.
No pagination limit documented. 'moneybird_list' accepts 'per_page' parameter but the description does not state min/max, or what happens if per_page=99999 is requested. API response size could exhaust context window without guidance.
'query' parameter in moneybird_list does not specify which entities support search. Description says '(contacts, products, time_entries)' but code does not validate this. If an LLM tries query=something on sales_invoices, what happens? Undocumented behavior.
No documentation of what data 'moneybird_request' returns for different paths. The description lists common paths but does not specify the response structure for each, forcing the LLM to guess what fields to expect.