Skip to main content
Glama
singleflo

io.github.singleflo/odoo-assistant

by singleflo

search_read

Search and read Odoo records in a single call by specifying model, domain, and fields. Automatically handles multi-company data and avoids common pitfalls like mixing invoice types or summing amounts in wrong currencies.

Instructions

Search and read records in one call (Odoo search_read).

Two pitfalls this tool cannot fix for you:

  • account.move and account.move.line mix customer invoices, vendor bills, credit notes and raw journal entries. A domain without move_type is refused — add ["move_type", "=", "out_invoice"] (or in_invoice, out_refund, in_refund) so the answer matches what the user sees on screen.

  • NEVER sum amount_total: it is expressed in each record's own currency, and eight foreign-currency invoices once inflated a total 11,9×. Ask for amount_total_signed instead — any field with a _signed twin is stored in company currency, and the twin is the one to add up.

Args: model: Odoo model, e.g. "sale.order". domain: Odoo domain, e.g. [["state", "=", "sale"]]. fields: Field names to return. Name them: the default asks for every field, which is slow and can fail to serialise on wide models. limit: Rows to return. Hard-capped at 200. offset: Rows to skip — how to page past a truncated result. company_ids: Companies to read from, e.g. [1, 2]. On a multi-company instance, omitting this reports one company as the whole business.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
modelYes
domainYes
fieldsNo
offsetNo
company_idsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations were provided, yet the description transparently discloses multiple behavioral details: hard-capped limit at 200, multi-company reporting bias, performance warning about requesting all fields, and the currency conversion pitfall. This fully compensates for the missing annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is front-loaded with the core purpose, then structured into two numbered pitfalls, then parameter explanations. Every sentence adds value—no filler. Slight length but justified given the complexity of Odoo's quirks. A minor point: the parameter list could be slightly more compact, but the trade-off for clarity is acceptable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 6 parameters, 0% schema coverage, no annotations, yet an output schema exists, the description covers parameter semantics, pitfalls, return behavior (hard cap, paging), and domain-specific business logic. It is completely sufficient for an AI agent to execute this tool safely and effectively, including handling complex edge cases.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description explains every parameter (model, domain, fields, limit, offset, company_ids) with usage examples, default behaviors, and warnings. It adds substantial meaning beyond what the schema types alone communicate, e.g., explaining the domain format, performance cost of null fields, and the company_ids multi-company trap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description uses specific verb 'Search and read' with resource 'records in one call' and immediately references the Odoo method 'search_read'. It clearly distinguishes from siblings like 'read_record' (probably single-record read) and 'count_records' by explaining this is a combined search-and-read operation returning fields.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides two explicit, high-value pitfalls with concrete examples: mandatory 'move_type' for account moves, and never summing 'amount_total' (use '_signed' twin). This tells the agent when NOT to use certain patterns and what alternatives to use, which is exceptional guidance beyond basic tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/singleflo/odoo-assistant-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server