Skip to main content
Glama

MCP for Claude & ChatGPT

Describe fields

odoo_fields_get
Read-only

Get business field metadata for an Odoo model: types, relations, searchable/sortable/groupable flags, the aggregation each field supports, selection options, and help text. A field is safe to group by in read_group when 'groupable' is true, and safe to aggregate when it carries an 'aggregator' (role 'measure'). Monetary fields carry 'currency_field' — the field that says which currency the amount is in. Read it before summing or grouping money: on the same record 'amount_total' is in 'currency_id' while 'amount_total_signed' is already converted to 'company_currency_id', so grouping by one and summing the other mislabels the result. System and mail bookkeeping fields are filtered out. Call before writing domains with unfamiliar fields or selection values. 'name_pattern' matches the field LABEL and help as well as the technical name, so search it with the words the user said ('due', 'vencim') rather than guessing Odoo's spelling. Returns a page envelope ('records' plus count / total / has_more / next_offset), the same contract as odoo_search_read. A wide model has hundreds of fields: narrow with 'fields' when you know the names, or 'name_pattern' to explore a family ('x_studio_*', 'date'); when 'has_more' is true, call again with 'offset' to read the rest — 'total' says how many there are in all. To inspect several related models at once (walking relational fields before a domain or a write), pass 'models' (up to 20) instead of 'model': each one comes back as its field list, or as an inline error. Pass 'with_operations' only when you are about to run a method on records (odoo_execute), not to read or explain: it adds 'operations', the buttons its form and list offer. An operation with 'method' runs with odoo_execute; one with 'wizard' opens that model: create it with odoo_create, passing the records in the context as active_model and active_ids, then run the method listed in the wizard's own operations with odoo_execute and that same context: many wizards read it again there.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "odoo_fields_get"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoPage size. Omit to ask for every field: a narrow model then arrives in one call. Pass it to page through a wide one with next_offset.
modelNoThe model to describe. Use 'models' for several.
fieldsNoReturn only these fields, by exact technical name. A name this model does not have brings its closest fields instead, with a note saying so.
modelsNoSeveral models in one call, instead of 'model'. Returns every field of each, keyed by model; 'fields', 'name_pattern', 'with_operations' and paging do not apply.
offsetNo
name_patternNoSubstring of the technical name, the LABEL or the help text, case-insensitive, so you can search with the words the user used: 'due' finds 'amount_residual', whose label is 'Amount Due'. Use '*' to anchor: '*_date', 'x_studio_*'. Nothing matching brings the closest fields. Combines with 'fields' as a union.
with_operationsNoAlso return 'operations': each button of the form and the list, with its label, the 'method' or 'wizard' it runs, the views it is on and its 'invisible' condition. 'name_pattern' does not narrow them.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered; the description goes further by disclosing filtering behavior ('System and mail bookkeeping fields are filtered out'), the fuzzy fallback that returns closest fields with a note on a miss, and the per-model inline error when passing several models. It does not discuss rate limits or performance on very wide models beyond advising narrowing.

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?

Front-loaded with the core purpose and organized by decision (narrow vs page, single vs multi-model, operations only for execute). It is long and the closing wizard-chaining passage is dense and somewhat tangential to field discovery, which keeps it out of the top band.

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 seven optional parameters, no output schema, and a non-obvious return shape, the description supplies the missing contract: the page envelope ('records' plus count/total/has_more/next_offset), what 'total' means, and how to continue with offset. Edge cases (unknown field, no match, multi-model errors) are all covered.

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 86%, so the baseline is 3; the description earns more by explaining the semantic consequences of parameters the schema only defines mechanically – that 'groupable' gates safe read_group use, that 'aggregator' marks safe measures, and that currency_field determines which currency an amount is in (with the amount_total vs amount_total_signed example). It also clarifies name_pattern matches label and help, not just the technical name.

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?

Opens with a specific verb+resource: 'Get business field metadata for an Odoo model', then enumerates exactly what metadata is returned (types, relations, flags, aggregators, selection options, help). An agent can tell this apart from odoo_search_read, odoo_read_group, and odoo_execute, all of which are named.

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?

Explicit when-to-use rules abound: 'Call before writing domains with unfamiliar fields', 'Pass with_operations only when you are about to run a method on records (odoo_execute), not to read or explain', and use 'models' (up to 20) instead of 'model' to walk relational fields. It also prescribes the next tool for each downstream case, so alternatives are named with their selecting conditions.

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.