MCP for Claude & ChatGPT

Discover a model

odoo_schema_discover

Read-only

Discover Odoo models matching a keyword (typo-tolerant fuzzy match) and return their field metadata, plus enrichment with info, modules, record_count, has_messaging and has_activities. Fields come back compact by default (name, type, string, relation, short help); pass verbose=true or call odoo_fields_get(model=…) for the full per-field metadata. When you only need to know which model the user means ('where are invoices stored?'), pass with_fields=false: every model comes back ranked by relevance and record count, without fields, and the keyword becomes optional. Returns a page envelope ('records' plus count / total / has_more / next_offset): when 'has_more' is true, call again with 'offset' — a smaller 'limit' returns the same leading models, not the ones you are missing.

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_schema_discover"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Models per page: default 10 and at most 30 with fields, default 25 and at most 100 without.
`offset`	No	Skip this many matches. When a result comes back with 'has_more', call again with 'next_offset' to read the rest — lowering 'limit' returns the same leading models, not the ones you are missing.
`keyword`	No	What to look for, over the technical name, display name and description.
`verbose`	No
`with_fields`	No	false: rank every model you can read, without fields — the cheap way to find a model's technical name. true (default): only the matches, each with its fields.
`include_relational`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 2, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already establish read-only and non-destructive behavior, but the description adds substantial context beyond them: fuzzy typo-tolerant matching, default compact field output, enrichment fields, keyword optionality in with_fields=false mode, and a clear pagination envelope with has_more/next_offset behavior.

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 front-loaded and informative, with purpose first and mode/pagination guidance after. It is appropriately sized for a six-parameter discovery tool, though the pagination warning is repeated in both the description and the offset schema field.

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

Completeness4/5

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

It describes the return envelope, pagination, field compactness, and the two main operating modes well, which is important because there is no output schema. The only notable gap is that include_relational remains unexplained anywhere in the definition.

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?

The description adds meaningful semantics for verbose, with_fields, keyword optionality, and pagination beyond the 67%-covered schema. However, include_relational is not explained in either the description or the schema, leaving one parameter's purpose undocumented.

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?

States a specific verb and resource: discover Odoo models matching a keyword and returning field metadata plus enrichment. It clearly distinguishes the tool from odoo_fields_get by explaining that odoo_fields_get is for full per-field metadata on a known model.

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?

Gives explicit routing guidance: use with_fields=false when you only need to identify the model the user means, and use verbose=true or odoo_fields_get when full field metadata is needed. It also explains the pagination follow-up behavior with has_more and offset.

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

All MCP for Claude & ChatGPT tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.