Loading ToolBench
MCP server for POHODA accounting software — file-based XML import/export (no mServer required)
21 tools with consistent naming (verb_noun pattern: list_*, create_*, delete_*) and complete input schemas. Descriptions are present but generic (avg ~100 chars, below 194-char baseline). All parameters have types and descriptions. Output schemas are not documented in visible code. Error handling is minimal, no recovery guidance or actionable error messages. Missing idempotency hints on write operations and confirmation patterns on destructive tools.
Create a new address/contact in POHODA addressbook. Requires name; optional fields: street, city, zip, IČO, DIČ, email, phone, web, note.
Create a bank document (receipt or expense) in POHODA. Requires bankType and date. Optional: text, account, bankCode, symbols, partner details, note, and line items.
Create a new contract in POHODA. Optional: number, datePlan, text, partner details, note.
Create a new enquiry in POHODA. Requires enquiryType and date. Optional: text, partner details, note, and line items.
Create an internal document in POHODA. Requires date. Optional: text, variable symbol, note, and line items.
Create a new invoice in POHODA. Requires invoiceType and date. Optional: dateTax, dateDue, dateAccounting, text, partner details, symbols, note, and line items.
Output schemas not documented. Tool descriptions state 'Returns JSON array' but do not specify field names, types, or structure. LLMs cannot plan downstream calls or extract required data.
Destructive tools (delete_*) lack confirmation or dry-run patterns. No guidance on recovery if deletion is accidental. Descriptions do not warn of irreversibility.
No error handling guidance. Tool descriptions do not explain what errors can occur, whether they are retryable, or what the LLM should do next. Errors will be raw exceptions.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2026-07-28+ | v2 |
Create a new offer in POHODA. Requires offerType and date. Optional: text, partner details, note, and line items.
Create a new order in POHODA. Requires orderType and date. Optional: numberOrder, text, partner details, note, and line items.
Delete an address from POHODA addressbook by ID. Requires the address ID.
Delete a contract from POHODA by ID. Requires the contract ID.
Delete an invoice from POHODA by ID. Requires the invoice ID.
Delete an order from POHODA by ID. Requires the order ID.
List addresses from POHODA addressbook. Supports filtering by id, company name, IČO, last changes date, or code. Returns JSON array of matching address records.
List bank documents (receipts and expenses) from POHODA. Supports filtering by ID, date range, company name, or last changes. Returns JSON array of matching records.
List contracts from POHODA. Supports filtering by ID, date range, company name, or last changes. Returns JSON array of matching contract records.
List enquiries from POHODA. Supports filtering by enquiry type (issued/received), ID, date range, company name, or last changes. Returns JSON array of matching enquiry records.
List internal documents from POHODA. Supports filtering by ID, date range, or last changes. Returns JSON array of matching records.
List invoices from POHODA. Supports filtering by invoice type, ID, date range, variable symbol, company name, IČO, or last changes. Returns JSON array of matching invoice records.
List offers from POHODA. Supports filtering by offer type (issued/received), ID, date range, company name, or last changes. Returns JSON array of matching offer records.
List orders from POHODA. Supports filtering by order type, ID, date range, company name, order number, or last changes. Returns JSON array of matching order records.
Update an existing address in POHODA addressbook by ID. Provide id (required) and any fields to update: name, street, city, zip, ico, dic, email, phone, web, note.
Descriptions are generic and below baseline (avg ~100 chars vs 194-char baseline). Missing context on WHEN to use each tool, dependencies, and prerequisites. E.g., 'Create a new address' does not explain required fields or validation rules.
No idempotency hints on write operations. LLMs do not know if retrying a create_* call will produce duplicates or safely return the existing record. Agents may avoid retries on transient failures.