Loading ToolBench
Nestaro Pilot Tier AI employee - Autonomous Nestaro Pilot with Gmail, WhatsApp, Facebook, Instagram, Twitter, LinkedIn, Odoo MCP, Ralph Wiggum loop, and comprehensive error recovery
This MCP server exhibits significant definition quality gaps across both email and Odoo tool suites. While tool names follow verb_noun conventions (send_email, get_invoices, create_invoice), parameter descriptions are inconsistent, many lack type information, and output schemas are completely undocumented. The email tools lack descriptions of return values; Odoo tools have better baseline descriptions but still miss critical details about data formats and error conditions. Most tools lack error handling guidance, confirmation patterns for destructive operations, and field-level descriptions. The codebase is partially visible (email-mcp/index.ts excerpt provided), but the complete tool registration and schema definitions for all 9 tools are not fully shown, requiring some inference.
Create a new invoice in Odoo for a specified partner with line items
Create a Gmail draft (not sent) for human review before sending
Get a financial summary for the current month including MTD revenue, outstanding invoices, and overdue items
Retrieve invoices from Odoo with optional filtering by status, payment state, date range, and partner
Retrieve customer/vendor partners from Odoo with optional search filter
Retrieve journal entries/transactions from Odoo for a date range with optional account filter
No output schemas documented for any tool. For all 9 tools, the response structure is not formally documented. This violates pattern:tool and pattern:response-shaper, forcing LLMs to guess what fields are returned and breaking composition, downstream tools cannot reliably chain on missing fields.
Missing error recovery guidance. None of the tool descriptions explain what to do when an operation fails. For example, create_invoice does not document what happens if the partner name matches multiple records, post_invoice does not explain validation errors, and record_payment does not guide on insufficient invoice balance. Agents cannot self-correct without actionable error messages (pattern:recovery-guide).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2026-07-28+ | v2 |
Post (validate) a draft invoice in Odoo to make it official and generate accounting entries
Record a payment against a posted invoice in Odoo
Send an email via Gmail API
Destructive and irreversible operations lack confirmation patterns. create_invoice, post_invoice, record_payment, and send_email all modify or send data but have no dry-run or confirmation step documented. Agents risk unintended consequences (e.g., sending an email multiple times on retry) without explicit confirmation support (pattern:confirmation-request).
Ambiguous parameter semantics in create_invoice and record_payment. create_invoice's 'partner_name' is described as 'will search for matching partner' but provides no guidance on non-unique matches. record_payment's 'amount' lacks currency validation and does not clarify partial vs full payment semantics. These undocumented dependencies invite silent misuse (review:param-relationships).
Pagination not fully documented. get_invoices, get_partners, and get_transactions accept 'limit' but do not specify pagination mechanism, is there a cursor, offset, or next_page token? Descriptions mention defaults and max values but not how to fetch additional results. Large result sets risk exceeding token limits without clear pagination guidance (pattern:paginated-result).
Date/time format inconsistency. Most tools accept 'ISO format' dates but do not explicitly state timezone handling, millisecond precision, or whether times are UTC or local. This is particularly critical for get_financial_summary (current month interpretation) and record_payment (payment_date defaults).
post_invoice uses domain-specific verb ('post'). Odoo terminology is not universally understood by LLMs. Renaming to 'finalize_invoice' or 'validate_invoice' would improve clarity without domain knowledge (review:name-clarity).