Skip to main content
Glama

MCP for Claude & ChatGPT

Group and total records

odoo_read_group
Read-only

Aggregate records on an Odoo model (sum, avg, count, etc.) with optional grouping. Prefer this over odoo_search_read for totals or top-N. 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'). Always pass a tight limit and order so only the relevant slice comes back. Aggregates use 'field:agg' specs (e.g. 'amount_total:sum', '__count') and work on every Odoo version. Group by date with 'field:granularity' (e.g. 'date_order:month'). On Odoo 19+, use having to filter groups by aggregate values. Grouping by a currency only labels the amounts correctly if the measure is denominated in that same currency — check currency_field in odoo_fields_get ('amount_total' is in 'currency_id', 'amount_total_signed' in 'company_currency_id'); a mismatch is rejected. When a page comes back full the envelope reports the real total of groups — trust it: never consolidate a partial page of groups as if it were the full set; when has_more is true, call again with next_offset to read the rest.

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>",
      "groupby": "<groupby>"
    },
    "name": "odoo_read_group"
  }
}

Input Schema

NameRequiredDescriptionDefault
lazyNoDeprecated and ignored: the tool always returns the full cross-grouping of every groupby level, with the count named '__count', on every Odoo version. Accepted only so older saved calls don't break.
limitNoMax groups per page (default 20, max 500).
modelYesOdoo model technical name (e.g., 'sale.order', 'res.partner')
orderNo
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']]]].
fieldsNoLegacy alias of 'aggregates' (classic read_group spelling, same 'field:agg' specs). Prefer 'aggregates'; kept for backwards compatibility. DO NOT pass groupby granularities (e.g. 'date_order:year') here — those go in 'groupby' only.
havingNoOdoo 19+ ONLY: post-aggregation filter on aggregate values, e.g. [['__count', '>', 5]]. On Odoo 16/17/18 it is rejected with an error (the classic API cannot express it) — fetch the groups and filter on the aggregate values yourself instead.
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.
groupbyYesFields to group by. Use 'field:granularity' for dates (month, year, etc.).
aggregatesNoAggregate specs 'field:agg'. Supported aggs: sum, avg, min, max, count_distinct. Use '__count' for record count. Works on every Odoo version — the tool routes to the right grouping API internally. DO NOT include groupby granularities like 'date_order:year' — those belong in 'groupby' only.

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?

With readOnlyHint already covering safety, the description adds substantial behavior: having is Odoo 19+ only and rejected on 16/17/18, currency mismatches are rejected, and paginated group results must be trusted from the envelope total rather than consolidated from a partial page.

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?

The purpose and sibling preference are front-loaded, and most sentences carry relevant operational detail. However, it is a dense single paragraph and repeats some schema-level guidance about aggregate specs and groupby granularity, making it longer than strictly necessary.

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?

For an 11-parameter nested tool with no output schema, the description covers the critical context: routing versus odoo_search_read, skill loading, version constraints, currency pitfalls, and pagination. It is complete enough for an agent to invoke it correctly.

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 82%, so the schema already documents most parameters. The description adds useful operational nuance, especially the currency_field cross-check for grouped currency measures and the limit/order guidance, but it also repeats schema details for aggregates, groupby granularity, and having.

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 description states a specific verb and resource: aggregate records on an Odoo model with optional grouping. It also explicitly distinguishes the tool from odoo_search_read, saying to prefer it for totals or top-N, so an agent can select it without opening the 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 explicit routing guidance versus odoo_search_read, describes when to load a workspace skill, and advises passing tight limit and order. It also states version-specific behavior for having and explains pagination handling with has_more and next_offset.

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.