Skip to main content
Glama

MCP for Claude & ChatGPT

Search records

odoo_search_read
Read-only

Search and read records from any Odoo model. Returns paginated results — if has_more is true, the response carries a truncation_notice and you should call again with next_offset to fetch the next page. A workspace skill may already encode the right query: load it with tuqui_skill(action='get') when something names one, else look for one with tuqui_skill(action='list'). Keep limit tight (default 10) and always pass the smallest fields list that answers the question; every extra record and field stays in the conversation context. When fields is omitted, the tool returns the top-K most relevant fields per the schema (identity, workflow, required, common refs) plus rich-text/HTML stripped — the response then carries fields_selected / fields_total, so read those before concluding anything from a field you do not see: empty values are dropped, so an absent key means empty or not selected, never 'this model has no such field'. Ask for a monetary field and its currency comes back with it, even when you pinned fields — read that currency, never assume it ('amount_total' is in 'currency_id', 'amount_total_signed' is already converted to 'company_currency_id'). For a count alone pass count_only=true: it returns {'count': n} and no records. For aggregates or top-N use odoo_read_group; to find records by words the user remembers (free text, ranked), odoo_search_text. html fields come back as markdown (checklists as - [ ]/- [x]), lossy on classes and embeds; to see the stored HTML or edit part of it, use odoo_html if you have it. Datetime domains use UTC — for 'today in local time' use the user timezone from tuqui_context to compute the correct UTC bounds (e.g. UTC-3 → today starts at 03:00:00 UTC).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "model": "<model>",
      "domain": "<domain>"
    },
    "name": "odoo_search_read"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoMax records per page (default 10, max 500).
modelYesOdoo model technical name (e.g., 'sale.order', 'res.partner')
orderNoSort expression, e.g. 'amount_total desc'.
domainYesOdoo domain filter as logical operators ('&', '|', '!') and/or 3-item condition tuples like ['field', '=', 'value'] or ['field', 'in', ['a', 'b']]. For relational filters use 'any' / 'not any' with a sub-domain on a to-one/to-many field (Odoo 17+), which does a whole anti-join in one query: [['sale_order_ids', 'any', [['date_order', '>=', '2025-01-01']]], ['sale_order_ids', 'not any', [['date_order', '>=', '2026-01-01']]]].
fieldsNoField names to return. Omit for the top-K most relevant fields.
offsetNo
contextNoOptional Odoo execute_kw context. The user's ``lang`` is injected from their profile — pass it here only to override it. See each field below for what it does.
count_onlyNoReturn only how many records match the domain, as {'count': n}.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare read-only safety, and the description adds substantial behavioral context beyond that: pagination via has_more/truncation_notice/next_offset, the fields_selected/fields_total response metadata, the rule that absent keys mean empty-or-unselected, automatic currency co-return, lossy HTML-to-markdown conversion, and UTC domain semantics. This is exactly the kind of non-obvious operational detail an agent needs before calling.

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?

It is a dense block, but front-loaded with purpose then pagination, and nearly every sentence carries actionable guidance. Slight ding for length and for not using bullets/short paragraphs to separate the many distinct topics (pagination, fields, currency, html, timezone).

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?

No output schema exists, yet the description documents return shape (paginated results, truncation_notice, fields_selected/fields_total, {'count': n} for count_only) and the domain/field/timezone behaviors, which is complete for an 8-parameter search tool with nested context.

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

Parameters4/5

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

Schema coverage is 88% so baseline is 3, but the description adds real semantics on top: limit should stay tight for context economy, fields omission falls back to top-K relevant fields with the fields_selected/fields_total contract, and count_only returns {'count': n}. It goes beyond restating schema descriptions, though offset/order/context fields are left largely to the schema.

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?

The opening sentence states a specific verb and resource ('Search and read records from any Odoo model') and the description explicitly contrasts itself with siblings odoo_read_group, odoo_search_text, and odoo_html. An agent can pick this tool over its alternatives without opening a schema.

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?

It gives concrete routing rules: use odoo_read_group for aggregates/top-N, odoo_search_text for ranked free-text lookup, odoo_html for stored HTML, count_only=true for a bare count, and tuqui_skill to load an existing query skill. Guidance is explicit about both when to use and when to defer to a sibling.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.