Loading ToolBench
OCL reference MCP server serving public example context packs for Odoo business logic and data model documentation
OCL server has 5 tools with basic naming and descriptions, but critical gaps in schema documentation and parameter descriptions. Tool names follow verb_noun pattern (get_context, resolve_noun, explain_field, get_join_path, validate_write_intent), which is good. However, input schemas visible in TypeScript SDK show parameter types but lack descriptions for most parameters. The Python reference implementation (ocl_examples.py) is incomplete in the provided excerpt and does not show full tool registration. Descriptions are present but generic (50-150 chars), below the 194-char baseline for A+ tools. No output schemas documented. Error handling and recovery guidance absent. Security concern: validate_write_intent is marked WRITE but no confirmation/dry-run pattern evident.
Explains the semantic meaning and limitations of a specific field in an Odoo model
Retrieves OCL context pack with facts, warnings, and unknowns based on a question about Odoo business logic, filtered by Odoo version, edition, and required modules
Determines the join path between two Odoo models to establish relationships
Resolves a business noun to its corresponding Odoo model and domain, returning matching noun mappings from the example set
Validates a write operation intent on an Odoo model, checking authorization and business rules
Parameter descriptions missing or minimal. TypeScript SDK shows parameter types (string, array, integer) but descriptions are sparse. E.g., 'modules' param has description 'List of required Odoo modules (default: [account, sale, stock])' but no guidance on valid module names, constraints, or when to override defaults.
Output schemas not documented. No specification of what get_context, resolve_noun, explain_field, get_join_path, or validate_write_intent return. LLMs cannot plan downstream calls or extract required fields without knowing response structure.
validate_write_intent is a WRITE operation but lacks confirmation/dry-run pattern. No evidence of a dry-run mode or explicit confirmation step before executing authorization checks or business rule validation on Odoo models. Agents could inadvertently trigger unintended state changes.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 49 | 2026-07-28+ | v2 |
Error handling and recovery guidance absent. No documented error responses, error codes, or actionable recovery hints. E.g., if resolve_noun fails to find a noun, what should the LLM do next? Search with a partial name? Try a synonym?
Tool composition and chaining unclear. No documentation of which tools should be called in sequence or what IDs/references each tool returns. E.g., does resolve_noun return a model_id that get_join_path accepts? Does explain_field require output from resolve_noun?