Skip to main content
Glama
odoo-mcp-server

odoo-mcp-server

Totals by group

odoo_aggregate
Read-onlyIdempotent

Groups Odoo records matching a domain by chosen fields and computes totals or counts per group, returning compact grouped rows instead of reading many records.

Instructions

Group the records of one model that match a domain and compute totals per group, e.g. sales per customer per month, and return {model, groupby, measures, count, rows} with one key per groupby item and measure in each row; many2one groups come as {id, name}. Without groupby it returns one row for all matching records. Use it for sums, averages or counts per group instead of reading many records; use odoo_count for a single number and odoo_search for the records themselves.

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

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum number of groups. Values above the model's max_records_per_call (usually 200) are reduced to it.
modelYesTechnical model name from odoo_list_models, e.g. 'res.partner' or 'sale.order'.
orderNoSort groups by a groupby item or measure given above, e.g. 'amount_total:sum desc' or '__count desc'. Default: by group.
domainNoOdoo domain: a list of [field, operator, value] conditions, combined with AND unless prefixed by '|' (OR) or '!' (NOT). A dotted path follows a relation to another available model, e.g. 'country_id.code'. Omit or [] to match every record you can see; archived records are left out unless the domain has a condition on active. Example: [["customer_rank", ">", 0], ["country_id.code", "=", "BE"]].
groupbyNoFields to group by. Date and datetime fields need :day, :week, :month, :quarter or :year, e.g. ['partner_id', 'date_order:month'].
measuresNo'__count' for the number of records, or 'field:function' with sum, avg, min, max, count or count_distinct, e.g. 'amount_total:sum'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv1.1.1
    • changedInput schema / properties / domain / description
      Previous value: -"Odoo domain, e.g. [[\"customer_rank\", \">\", 0], [\"country_id.code\", \"=\", \"BE\"]]."New value: +"Odoo domain: a list of [field, operator, value] conditions, combined with AND unless prefixed by '|' (OR) or '!' (NOT). A dotted path follows a relation to another available model, e.g. 'country_id.code'. Omit or [] to match every record you can see; archived records are left out unless the domain has a condition on active. Example: [[\"customer_rank\", \">\", 0], [\"country_id.code\", \"=\", \"BE\"]]."
    • addedInput schema / properties / groupby / description
      Added value: +"Fields to group by. Date and datetime fields need :day, :week, :month, :quarter or :year, e.g. ['partner_id', 'date_order:month']."
    • addedInput schema / properties / limit / description
      Added value: +"Maximum number of groups. Values above the model's max_records_per_call (usually 200) are reduced to it."
    • addedInput schema / properties / measures / description
      Added value: +"'__count' for the number of records, or 'field:function' with sum, avg, min, max, count or count_distinct, e.g. 'amount_total:sum'."
    • changedInput schema / properties / model / description
      Previous value: -"Technical model name, e.g. 'res.partner'."New value: +"Technical model name from odoo_list_models, e.g. 'res.partner' or 'sale.order'."
    • changedInput schema / properties / order / description
      Previous value: -"Sort groups, e.g. 'amount_total:sum desc' or '__count desc'. Default: by group."New value: +"Sort groups by a groupby item or measure given above, e.g. 'amount_total:sum desc' or '__count desc'. Default: by group."
  2. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already cover the read-only, idempotent, non-destructive profile, and the description adds useful behavior beyond that: the return shape, the no-groupby fallback, and the many2one group representation. It does not discuss performance or error behavior, but the core behavioral contract is well disclosed.

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 description is dense but front-loaded with the main operation and return structure. It avoids filler, though the semicolon-heavy sentence packs several distinct concepts together, which slightly reduces readability.

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 aggregation tool with six parameters and no output schema, the description provides the missing return-value context and explains the key grouping behavior. Combined with the fully documented input schema and clear annotations, an agent has enough information to invoke it correctly.

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

Parameters3/5

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

Schema coverage is 100%, so the input schema already carries the detailed parameter semantics. The description adds some useful grouping behavior, such as the no-groupby fallback and many2one output shape, but it does not add parameter-level meaning beyond what the schema already provides.

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 pair: grouping records of one model and computing totals per group. It also distinguishes the tool from siblings by name, explicitly positioning odoo_count for a single number and odoo_search for raw records.

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 guidance on when to use this tool for sums, averages, or counts per group instead of reading many records. It names alternatives and the conditions that select them, including odoo_count for a single number and odoo_search for the records themselves.

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