Which integrations are available for this server?

Indexes Odoo code elements such as models, fields, views, menus, actions, and more, providing fast search and reference lookup for Odoo development.

How do I use Odoo Index MCP?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Odoo Index MCP search for model sale.order" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Odoo Index MCP

by letzdoo

Overview Schema Source Related Servers Discussions Admin

Python

Local

Odoo Index MCP

A lightweight MCP (Model Context Protocol) server for indexing Odoo code elements. Designed to help coding agents quickly look up models, fields, functions, views, and other Odoo components with their exact file locations.

Features

Fast Indexing: Uses AST parsing for Python and lxml for XML
Incremental Updates: Only re-indexes changed files (MD5 hash tracking)
Comprehensive Coverage: Indexes models, fields, methods, views, menus, actions, access rights, rules, scheduled actions, report templates, controller routes, and more
Multiple References: Tracks all occurrences (definition, inheritance, override, etc.)
Lightweight: Pure SQLite, no vector DB, no embeddings
MCP Compatible: Works with Claude Desktop and other MCP clients

Related MCP server: Synapse

What Gets Indexed

Core Elements

Models: Name, type (regular/transient/abstract), inheritance
Fields: Name, type, attributes (required, readonly, compute, related, etc.)
Functions/Methods: Name, decorators (@api.depends, @api.onchange, etc.)
Views: Type (form/tree/kanban/search), model, inheritance
Menus: Hierarchy, actions, security groups
Actions: Type (act_window/server/report), models, domains
Access Rights: Model permissions by security group
Record Rules: Domain-based access rules
Controller Routes: HTTP/JSON routes with auth types
Scheduled Actions: Cron jobs with intervals
Report Templates: QWeb templates
Module Metadata: Dependencies, version, description

Multiple References

Each element can have multiple file:line references:

definition: Where it's originally defined
inheritance: Where models are extended
override: Where methods/fields are overridden
reference: Where it's referenced
modification: Where views are modified with xpath

Installation

Prerequisites

Python 3.10+
uv package manager

Setup

# Clone or navigate to the project
cd odoo-index-mcp

# Create .env file
cp .env.example .env

# Edit .env and set your ODOO_PATH
nano .env

# Install dependencies with uv
uv sync

Usage

CLI Tool

# Full indexing
uv run python cli.py --index

# Incremental indexing (skip unchanged files)
uv run python cli.py --index --incremental

# Index specific modules
uv run python cli.py --index --modules sale,account,stock

# Clear database and re-index
uv run python cli.py --clear --index

# Show statistics
uv run python cli.py --stats

# Search from CLI
uv run python cli.py --search "sale.order" --type model
uv run python cli.py --search "partner_id" --type field --module sale

# Search XML IDs
uv run python cli.py --search-xml-id "action_view_%"
uv run python cli.py --search-xml-id "action_view_sale_order" --module sale

MCP Server

# Start MCP server
uv run odoo-index-mcp

Claude Desktop Integration

Add to your Claude Desktop config (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):

{
  "mcpServers": {
    "odoo-index": {
      "command": "uv",
      "args": ["run", "odoo-index-mcp"],
      "cwd": "/path/to/odoo-index-mcp",
      "env": {
        "ODOO_PATH": "/path/to/odoo"
      }
    }
  }
}

MCP Tools

The server provides 7 MCP tools:

1. `search_odoo_index`

Search for elements by name with wildcard support.

Parameters:

query (str): Search term (supports SQL LIKE with %)
item_type (str, optional): Filter by type
module (str, optional): Filter by module
parent_name (str, optional): Filter by parent (for fields/methods)
limit (int, default=50): Max results

Example:

search_odoo_index(query="sale.order", item_type="model")
search_odoo_index(query="partner%", item_type="field", module="sale")

2. `get_item_details`

Get complete details for a specific element including related items.

Parameters:

item_type (str): Type of item
name (str): Item name
parent_name (str, optional): Parent (for fields/methods)
module (str, optional): Module to disambiguate

Example:

get_item_details(item_type="model", name="sale.order")
get_item_details(item_type="field", name="partner_id", parent_name="sale.order")

3. `list_modules`

List all indexed modules with item counts.

Parameters:

pattern (str, optional): Filter by name pattern

Example:

list_modules()
list_modules(pattern="sale")

4. `get_module_stats`

Get detailed statistics for a module.

Parameters:

module (str): Module name

Example:

get_module_stats(module="sale")

5. `find_references`

Find all references to an element across the codebase.

Parameters:

item_type (str): Type of item
name (str): Item name
reference_type (str, optional): Filter by type (definition/inheritance/etc)

Example:

find_references(item_type="model", name="sale.order")
find_references(item_type="model", name="sale.order", reference_type="inheritance")

6. `search_by_attribute`

Advanced search by element attributes.

Parameters:

item_type (str): Type to search
attribute_filters (dict): Attribute filters
module (str, optional): Filter by module
limit (int, default=50): Max results

Example:

# Find all Many2one fields
search_by_attribute(
    item_type="field",
    attribute_filters={"field_type": "Many2one"}
)

# Find all transient models (wizards)
search_by_attribute(
    item_type="model",
    attribute_filters={"model_type": "transient"}
)

# Find all form views
search_by_attribute(
    item_type="view",
    attribute_filters={"view_type": "form"}
)

7. `search_xml_id`

Search for XML IDs by name pattern.

Parameters:

query (str): Search term (supports SQL LIKE patterns with %)
module (str, optional): Filter by module
limit (int, default=50): Max results

Example:

# Find all action_view XML IDs
search_xml_id(query="action_view_%")

# Find specific action
search_xml_id(query="action_view_sale_order")

# Find form views in sale module
search_xml_id(query="%_form_view", module="sale")

Performance

Indexing Speed: ~500-1000 files/second with concurrent processing and async database operations
Database Size: ~50-100MB for typical Odoo installation
Search Speed: <50ms for exact match, <200ms for pattern search
Memory Usage: <500MB during indexing, <100MB when serving
Database: Async connection pooling with aiosqlite for efficient concurrent writes

Configuration

Environment variables in .env:

# Required
ODOO_PATH=/path/to/odoo

# Optional (with defaults)
SQLITE_DB_PATH=./odoo_index.db
LOG_LEVEL=INFO
MAX_CONCURRENT_MODULES=4
MAX_CONCURRENT_FILES=8

Project Structure

odoo-index-mcp/
├── pyproject.toml              # uv project config
├── .env.example                # Environment template
├── .python-version             # Python version
├── README.md                   # This file
├── cli.py                      # CLI tool
├── odoo_index_mcp/
│   ├── __init__.py
│   ├── config.py               # Configuration
│   ├── database.py             # SQLite operations
│   ├── indexer.py              # Main indexing logic
│   ├── server.py               # FastMCP server
│   ├── tools.py                # MCP tool implementations
│   └── parsers/
│       ├── __init__.py
│       ├── python_parser.py    # AST parsing for Python
│       ├── xml_parser.py       # XML parsing for views/data
│       ├── csv_parser.py       # CSV parsing for access rights
│       └── manifest_parser.py  # Manifest file parsing

Database Schema

The index uses a normalized SQLite schema with 3 main tables:

indexed_items: Core item data (type, name, module, attributes JSON)
item_references: File locations (many-to-one with items)
file_metadata: File hashes for incremental indexing

All queries use proper indexes for fast lookups.

Development

# Install development dependencies
uv sync

# Run tests (TODO: add tests)
uv run pytest

# Format code
uv run black .

# Type checking
uv run mypy .

License

MIT

Contributing

Contributions welcome! Please:

Fork the repo
Create a feature branch
Add tests for new functionality
Submit a pull request

Support

For issues or questions:

Open an issue on GitHub
Check the documentation in ODOO_CODE_INDEXER.md

Roadmap

Future enhancements (not in v1):

Call graph analysis
Full-text search in method bodies
Dependency graph visualization
Watch mode (auto-reindex on changes)
Web UI for browsing
Export to other formats

Available Tools

9 tools

find_referencesB

Find all references to a specific Odoo element across the codebase.

Args: item_type: Type of item (model/field/function/view/etc) name: Item name reference_type: Filter by reference type (definition/inheritance/override/reference/modification)

Returns: All file locations where this item is referenced

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes
`item_type`	Yes
`reference_type`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, and the description offers limited behavioral context beyond the return type. There is no mention of side effects, permission requirements, or performance implications, leaving the agent underinformed.

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 concise, uses a clear structure with Args and Returns sections, and front-loads the purpose. It loses a point for the slightly verbose docstring format, but overall it's efficient.

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

Completeness3/5

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

Given the presence of an output schema, the description adequately covers return values. However, it lacks usage guidelines and behavioral transparency, which are important for a tool with 3 parameters and no annotations. Thus it is minimally viable but has gaps.

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 meaning to all three parameters (item_type, name, reference_type) beyond the bare schema, which has 0% coverage. It explains the role of each parameter, especially reference_type as a filter. A higher score would require more detail on allowed values.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'find' and resource 'references to a specific Odoo element across the codebase', which is specific and actionable. However, it does not differentiate from sibling tools like search_odoo_index or get_item_details, thus a 4.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool vs alternatives, no exclusions, and no context for appropriate usage. It solely describes the function without usage recommendations.

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

get_index_statusA

Get the current status of the index and any ongoing indexing operations.

Returns information about:

Database location
Whether indexing is currently running
Total number of indexed items
Number of modules indexed
Breakdown by item type
Indexing progress (if running)

Returns: Status information including database path, item counts and indexing state

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries the burden of behavioral disclosure. It transparently details the returned information (database location, running status, item counts, progress), indicating a read-only operation. However, it does not mention authentication requirements or rate limits, which would enhance transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, front-loading the core action and then bullet-listing return information. Every sentence contributes meaning without redundancy or fluff.

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?

Given no parameters and an output schema that presumably details the return structure, the description is complete. It lists all relevant return fields and the purpose, making further elaboration unnecessary.

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

Parameters5/5

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

The tool has zero parameters, and the description provides rich context about what the tool returns, adding value beyond the empty input schema. The baseline for 0 parameters is 4, but the detailed list of return fields elevates scoring to 5.

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 clearly states the tool gets the current status of the index and ongoing indexing operations, using a specific verb ('Get') and resource ('index status'). It distinguishes itself from sibling tools like search_odoo_index or list_modules by focusing solely on index status, not search or listing details.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for checking index status but does not explicitly state when to use this tool versus alternatives (e.g., for progress monitoring vs. searching items). No exclusions or when-not-to-use guidance is provided, leaving the agent to infer context.

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

get_item_detailsA

Get FULL details for a specific Odoo element.

WARNING: This returns ALL information including ALL references, ALL fields, ALL methods, ALL views, etc. for models. Use search_odoo_index() for quick lookups.

Use this ONLY when you specifically need:

All references (inheritance, overrides, usages)
All fields/methods of a model
All views/actions related to a model
Full attribute details

Args: item_type: Type of item (model/field/function/view/menu/action/etc) name: Item name (e.g., 'sale.order' for model, 'partner_id' for field) parent_name: Parent name (required for fields/methods - the model name) module: Module name (optional, helps disambiguate)

Returns: Complete item details with all references and related items

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes
`module`	No
`item_type`	Yes
`parent_name`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.7/5.0

Behavior4/5

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

No annotations provided, so description must fully disclose behavior. It warns that the tool returns 'ALL information including ALL references, ALL fields, ALL methods, ALL views', which is a critical behavioral trait. It implies read-only operation. No contradictions.

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?

Well-structured with a warning, usage conditions, and parameter docs. Information is front-loaded. Slightly verbose but each sentence is informative. Could be trimmed slightly but overall efficient.

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?

Description covers purpose, usage guidelines, parameter semantics, and return value ('Complete item details with all references and related items'). There is an output schema known to the system, but the description still explains return value. No gaps given complexity.

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

Parameters5/5

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

Schema description coverage is 0%, so description must compensate. It explains each parameter clearly: item_type with examples, name with examples, parent_name specifies required when for fields/methods, module as optional disambiguation. Adds significant value beyond schema types.

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 clearly states 'Get FULL details for a specific Odoo element', specifying the verb and resource. It distinguishes from sibling tool 'search_odoo_index' by warning to use that for quick lookups, highlighting this tool's comprehensive nature.

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?

Explicitly states when to use this tool ('when you specifically need: All references, All fields/methods...') and when not to ('Use search_odoo_index() for quick lookups'), providing clear context and an alternative.

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

get_module_statsA

Get detailed statistics for a specific Odoo module.

Args: module: Module name (e.g., 'sale', 'account', 'stock')

Returns: Module statistics including counts by item type

ParametersJSON Schema

Name	Required	Description	Default
`module`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.6/5.0

Behavior2/5

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

No annotations are provided, so the description bears full responsibility for behavioral disclosure. However, it only states the purpose and does not reveal side effects, read-only nature, or other behavioral traits. For a tool requesting statistics, it is unclear if any state changes occur.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: two sentences plus a bullet-point-like listing of args and returns. Every piece of information serves a purpose without redundancy. It is well-structured and front-loaded.

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?

Given the existence of an output schema (not shown but known from context signals), the description does not need to detail return values extensively. It briefly describes returns as 'counts by item type'. The tool is simple with one parameter, and the description covers purpose, input with examples, and return type. Minor gap: behavioral traits not disclosed, but overall adequate.

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 input schema has a single 'module' parameter with type string and no description (0% coverage). The description adds examples ('e.g., 'sale', 'account', 'stock''), which significantly helps the agent understand expected values. This goes beyond what the schema 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 clearly states the verb 'Get' and the resource 'detailed statistics for a specific Odoo module'. This distinguishes it from sibling tools like 'list_modules' (which lists modules) and 'get_item_details' (which gets details of items).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It does not mention use cases, prerequisites, or when not to use it. The agent is given no context to differentiate between this and similar tools like 'get_item_details'.

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

list_modulesA

List all indexed Odoo modules.

Args: pattern: Filter by module name pattern (optional)

Returns: List of modules with item counts

ParametersJSON Schema

Name	Required	Description	Default
`pattern`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.6/5.0

Behavior3/5

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

No annotations provided, so description bears full burden. It discloses the return type (list with item counts) and optional filtering by pattern, but does not mention performance, authentication needs, or pagination behavior. Adequate but lacks depth.

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 brief and well-structured: purpose, parameter, return value. Every sentence contributes, though the tool name could be included more integrally.

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

Completeness3/5

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

Given the tool's simplicity (one optional parameter, output schema exists), the description is adequate but missing best practices like recommending pattern syntax or explaining differences from sibling tools.

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 single parameter 'pattern' has significantly enriched description: 'Filter by module name pattern (optional)' adds meaning beyond the schema's basic type definition. With 0% schema description coverage, this is a clear value-add.

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 clearly states the tool lists all indexed Odoo modules, a specific verb and resource. This distinguishes it from siblings like search_odoo_index (searches across models) and get_item_details (specific item).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives such as search_odoo_index or get_module_stats. There are no context cues about typical use cases or limitations.

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

search_by_attributeA

Search Odoo elements by their attributes (advanced filtering).

Args: item_type: Type of item to search (model/field/view/action/etc) attribute_filters: Dict of attribute filters (e.g., {"field_type": "Many2one", "required": true}) module: Filter by module (optional) limit: Maximum results per page (default: 20, max: 100) offset: Number of results to skip for pagination (default: 0)

Returns: Matching items with their details and pagination info

Examples: - Find all Many2one fields: item_type="field", attribute_filters={"field_type": "Many2one"} - Find all transient models: item_type="model", attribute_filters={"model_type": "transient"} - Find all form views: item_type="view", attribute_filters={"view_type": "form"}

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`module`	No
`offset`	No
`item_type`	Yes
`attribute_filters`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It thoroughly explains the tool's functionality, including pagination behavior (limit, offset), default values, and filtering capabilities. The examples clarify realistic use cases. No behavioral traits are omitted.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficiently structured with Args, Returns, and Examples sections. It is concise yet comprehensive, with no redundant sentences. Every sentence adds value, and the format is easy to parse.

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?

Given the tool's complexity (5 parameters, 2 required, nested objects, and an output schema exists), the description covers all necessary aspects: all parameters are explained, examples are provided, and the return type is mentioned. It is complete enough for an agent to use the tool correctly.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must compensate. It does so excellently: it explains each parameter's meaning, provides types and examples for item_type and attribute_filters, and clarifies defaults for limit and offset. The examples demonstrate valid parameter combinations.

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 clearly states the purpose: 'Search Odoo elements by their attributes (advanced filtering).' It specifies the verb 'search' and the resource 'Odoo elements by attributes', distinguishing it from sibling tools like search_odoo_index which likely perform different kinds of searches.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides Args, Returns, and Examples, which give clear context on usage. It implies when to use this tool (for attribute-based search) but does not explicitly state when not to use it or list alternatives among siblings. Lacks explicit exclusions.

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

search_odoo_indexA

Search for indexed Odoo elements by name (returns CONCISE results).

This tool returns minimal, essential information only:

name, type, module, file, line number
Key attributes (description, field_type, etc.)

Results are sorted by relevance (exact matches first, then by dependency depth). The most relevant results are typically in the first 5 items.

Use get_item_details() if you need full details about a specific item.

PAGINATION: Results include 'has_more' and 'next_offset' fields. If has_more=true, call again with offset=next_offset to get more results.

Args: query: Search term (supports SQL LIKE patterns with %) item_type: Filter by type (model/field/function/view/menu/action/etc) module: Filter by module name parent_name: Filter by parent (e.g., model name for fields/methods) limit: Maximum results per page (default: 5, max: 50) offset: Number of results to skip for pagination (default: 0)

Returns: { total: Total matching items, returned: Number of items in this page, has_more: Whether more results are available, next_offset: Offset to use for next page (null if no more), results: Array of concise item data }

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`query`	Yes
`module`	No
`offset`	No
`item_type`	No
`parent_name`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description adequately discloses behavior: returns specific fields, sorting by relevance, pagination with has_more and next_offset. It does not explicitly state read-only or mention rate limits, but the search context implies no side effects.

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 well-structured with a summary, details, args, and return format. It is front-loaded but somewhat verbose; however, every sentence adds value.

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?

The description covers pagination, sorting, return format, and parameter details. It does not address error handling or empty results, but for a search tool this is sufficient.

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

Parameters5/5

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

All 6 parameters are individually described in the Args section, adding meaning beyond the schema (e.g., SQL LIKE patterns for query, default and max for limit). This compensates for 0% schema description coverage.

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 clearly states the tool searches for indexed Odoo elements by name and returns concise results. It specifies the verb, resource, and output format, and distinguishes from sibling get_item_details by noting it returns minimal info.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly advises using get_item_details() for full details and explains pagination. However, it does not address when to use search_by_attribute or search_xml_id instead, leaving some ambiguity among siblings.

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

search_xml_idA

Search for XML IDs by name pattern.

This tool searches across all Odoo elements that have XML IDs (views, actions, menus, rules, scheduled actions, report templates, and other data records).

Args: query: Search term (supports SQL LIKE patterns with %, e.g., 'action_view_%') module: Filter by module name (optional) limit: Maximum results per page (default: 20, max: 100) offset: Number of results to skip for pagination (default: 0)

Returns: XML IDs with their details including item type, model, file location, line numbers, and pagination info

Examples: - Find all action views: query="action_view_%" - Find specific action: query="action_view_sale_order" - Find form views: query="%_form_view"

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`query`	Yes
`module`	No
`offset`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.5/5.0

Behavior4/5

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

Describes search scope, pattern support (LIKE), pagination, and return fields. No annotation provided, but description sufficiently discloses behavior for a search tool.

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?

Well-structured with summary, args table, returns, and examples. Efficient but could be slightly more concise; still clear and scannable.

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?

Covers all parameters, return format, behavior, and examples. Output schema exists but description still provides sufficient context for agent to invoke correctly.

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

Parameters5/5

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

Each parameter is explained with type, optionality, defaults, and constraints (max limit). Examples illustrate usage. Schema coverage is 0%, so description fully compensates.

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?

Clearly states 'Search for XML IDs by name pattern' and enumerates the types of Odoo elements covered, distinguishing it from sibling tools like search_odoo_index.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear usage context through examples and parameter descriptions, but does not explicitly compare with alternatives or state when not to use this tool.

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

update_indexA

Update the Odoo index by scanning and parsing the codebase.

This tool triggers a re-indexing of the Odoo codebase in the background. By default, it performs incremental indexing (only re-parsing changed files). The function returns immediately while indexing continues in the background.

Args: incremental: If True, skip unchanged files (default: True). Set to False for full re-index. modules: Comma-separated list of module names to index (e.g., "sale,account,stock"). If not provided, all modules will be indexed. clear_db: If True, clear the entire database before indexing (default: False). WARNING: This will delete all existing index data!

Returns: Status message confirming indexing has started

Examples: - Incremental update: update_index() - Full re-index: update_index(incremental=False) - Index specific modules: update_index(modules="sale,account") - Clear and re-index: update_index(clear_db=True, incremental=False)

ParametersJSON Schema

Name	Required	Description	Default
`modules`	No
`clear_db`	No
`incremental`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.5/5.0

Behavior4/5

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

No annotations are provided, so the description carries full burden. It discloses key behaviors: background execution, immediate return, defaults, and a clear warning about clear_db deleting data. Could mention potential performance impact, but overall informative.

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 well-structured with sections (Args, Returns, Examples) and front-loads the main purpose. It is slightly long but every sentence provides value. Could be trimmed slightly without losing clarity.

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?

Given the complexity of 3 parameters and no annotations, the description covers behavior, all parameter details, return status, and examples. An output schema exists but is not needed since the description already explains the return. Fully adequate for agent invocation.

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

Parameters5/5

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

Schema description coverage is 0%, but the description thoroughly explains all three parameters (incremental, modules, clear_db) with details, defaults, and warnings. This adds significant meaning beyond the raw schema, fully compensating for the gap.

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 clearly states the tool updates the Odoo index by scanning and parsing the codebase, with explicit verb 'update' and resource 'index'. It distinguishes from sibling tools like search_odoo_index (searching) and get_item_details (retrieval).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides context on when to use incremental vs full indexing, how to specify modules, and when to clear the database. It offers examples covering common cases, though it does not explicitly state when not to use this tool or mention alternatives.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

9 tool updatesv0.2.2Jul 30, 2026
- First observedfind_references
- First observedget_index_status
- First observedget_item_details
- First observedget_module_stats
- First observedlist_modules
- First observedsearch_by_attribute
- First observedsearch_odoo_index
- First observedsearch_xml_id
- First observedupdate_index

Deploy Server

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

TDQS

A4.1/5.0

Scored 2026-07-30 10:55 across 9 tools

Disambiguation5/5

Each tool targets a distinct operation: concise search, full details, module listing, stats, references, attribute-based search, XML ID search, index update, and status. No overlap in functionality.

Naming Consistency5/5

All tools follow a consistent verb_noun snake_case pattern (e.g., search_odoo_index, get_item_details, find_references). No deviations.

Tool Count5/5

With 9 tools, the set is well-scoped for an Odoo index server. Each tool serves a clear purpose without unnecessary bloat or gaps.

Completeness4/5

The tools cover all essential query types (search, details, stats, references, attribute search, XML ID search) and index management (update, status). Minor gap: no tool for deleting specific index items, but that's administrative.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

developer-tools-mcp-server A
com.thenextgennexus
Search GitHub, npm, PyPI, StackOverflow, ArXiv from one MCP — built for coding agents.
Developer Tools Search
72
mcp
com.skopik
Your org's AI agents, tasks, runs, search, and brain files as MCP tools and resources.
Agent Orchestration Knowledge & Memory Search
2
Maguyva
ai.maguyva
Code intelligence for coding agents: semantic, AST, graph, and full-text search. 279+ languages.
Code Analysis Coding Agents
23
Symvanta A
com.symvanta
Hosted code graph over MCP: exact callers, dependencies, and cross-repo blast radius for AI agents.
Code Analysis Developer Tools
271

Related MCP Servers

CodeGraph
Code Analysis Search Knowledge & Memory
Phoenixrr2113
A
license
Not graded
quality
C
maintenance
Enables AI agents to search code by meaning, explore codebase structure, store and query knowledge with temporal facts, and read source code through a set of MCP tools.
Updated 6 days ago (2026-09-14 22:10 UTC)
248 npm
7
MIT
Synapse
Code Analysis Developer Tools
amitsingh2003
F
license
Not graded
quality
D
maintenance
Provides structural code intelligence via 26 MCP tools, enabling AI assistants to query code symbols, dependencies, and call graphs accurately without file-pasting.
Updated 3 months ago (2026-06-27 17:10 UTC)
-
odoo-analyzer
Developer Tools Code Analysis CI/CD & DevOps
FoxPink-dev
A
license
Not graded
quality
A
maintenance
AI-powered Odoo engineering platform providing static analysis, domain knowledge, and 14 MCP tools for code review, model exploration, and security auditing of Odoo modules.
Updated 3 months ago (2026-06-20 13:12 UTC)
18 npm
MIT
Cortex
RAG Systems Vector Databases Knowledge & Memory
Remskill
A
license
Not graded
quality
D
maintenance
Enables AI coding assistants to semantically search and retrieve relevant code patterns, documentation, and implementations from a codebase via MCP tools.
Updated 8 months ago (2026-01-07 13:16 UTC)
8
MIT

Odoo Index MCP

Features

What Gets Indexed

Core Elements

Multiple References

Installation

Prerequisites

Setup

Usage

CLI Tool

MCP Server

Claude Desktop Integration

MCP Tools

1. search_odoo_index

2. get_item_details

3. list_modules

4. get_module_stats

5. find_references

6. search_by_attribute

7. search_xml_id

Performance

Configuration

Project Structure

Database Schema

Development

License

Contributing

Support

Roadmap

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

1. `search_odoo_index`

2. `get_item_details`

3. `list_modules`

4. `get_module_stats`

5. `find_references`

6. `search_by_attribute`

7. `search_xml_id`