Which integrations are available for this server?

Provides tools for interacting with Odoo ERP, enabling AI agents to inspect records, search models, manage mutations with preview and rollback, and handle Odoo business data safely.

How do I use Odoo MCP?

1. Click on "Install 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 MCP List all unpaid invoices from last month" 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 MCP

by techniondigitalsolutions

Overview Schema Related Servers Score Discussions

Python

Local

Odoo MCP

Safety-first Model Context Protocol server for Odoo 16, 17, 18, and 19. It uses standard MCP transports, so it can be connected to Codex, Claude Code, Google Antigravity, Gemini, and other MCP clients.

What It Does

Odoo MCP lets an AI assistant safely inspect Odoo records, explain business data, inspect model fields, prepare controlled changes, record those changes, and roll supported changes back.

Typical uses include:

Accounting review and exception reporting
Implementation and configuration inspection
Audit queries and MCP change-history review
Website page, menu, view, and theme work
Safe, approved updates to supported Odoo records

Related MCP server: Odoo MCP Improved

Documentation

Requirements

Python 3.10 or newer
Odoo 16, 17, 18, or 19
An Odoo user permitted to use the required applications and records
An API key generated for that Odoo user
An MCP-compatible client such as Codex, Claude Code, or Antigravity

Use a dedicated Odoo bot user. Do not connect the main administrator account.

Installation

Clone the repository after it is published:

git clone https://github.com/techniondigitalsolutions/odoo-mcp.git
cd odoo-mcp

For the current local checkout:

cd /Users/osamahalnihmi/odoo-mcp

Create an isolated Python environment and install the server:

python3 -m venv .venv
. .venv/bin/activate
pip install -e .

Windows PowerShell:

py -m venv .venv
.venv\Scripts\Activate.ps1
pip install -e .

The MCP command is:

/absolute/path/odoo-mcp/.venv/bin/python -m odoo_mcp.server

Always use an absolute path in the AI client's configuration.

Odoo Authorization

Create a dedicated Odoo user such as:

Name: Odoo MCP Bot
Login: odoo-mcp@example.com

Grant only the minimum access groups required for its job:

Auditor: read access to the applications being reviewed
Accountant assistant: required accounting read access
Implementer: access only to relevant implementation areas
Website editor: minimum website editing permissions

Then generate an API key:

Sign in as the dedicated user.
Open the user menu and select Preferences or My Profile.
Open Account Security.
Select New API Key.
Use a description such as Odoo MCP - laptop.
Select the shortest practical expiration.
Generate and securely store the key.

Odoo normally displays the complete key only once. Never commit it to Git or paste it into prompts, screenshots, issues, skills, or documentation.

Environment

Every MCP client configuration must provide:

ODOO_URL=https://your-company.odoo.com
ODOO_DATABASE=database-name
ODOO_USERNAME=odoo-mcp@example.com
ODOO_API_KEY=your-private-api-key
ODOO_API_MODE=auto
ODOO_ALLOW_MUTATIONS=false

ODOO_API_MODE=auto selects XML-RPC for Odoo 16-18 and JSON-2 for Odoo 19. Keep mutations disabled until read operations and Odoo permissions are tested.

Optional limits:

ODOO_MAX_READ_RECORDS=100
ODOO_MAX_MUTATION_RECORDS=20
ODOO_PLAN_TTL_SECONDS=300
ODOO_JOURNAL_PATH=~/.local/state/odoo-mcp/journal.sqlite3

Codex Configuration

Add this to the user Codex configuration, normally ~/.codex/config.toml:

[mcp_servers.odoo]
command = "/absolute/path/odoo-mcp/.venv/bin/python"
args = ["-m", "odoo_mcp.server"]

[mcp_servers.odoo.env]
ODOO_URL = "https://your-company.odoo.com"
ODOO_DATABASE = "database-name"
ODOO_USERNAME = "odoo-mcp@example.com"
ODOO_API_KEY = "your-private-api-key"
ODOO_API_MODE = "auto"
ODOO_ALLOW_MUTATIONS = "false"

Restart Codex after saving the configuration.

Claude Code Configuration

claude mcp add odoo \
  --env ODOO_URL=https://your-company.odoo.com \
  --env ODOO_DATABASE=database-name \
  --env ODOO_USERNAME=odoo-mcp@example.com \
  --env ODOO_API_KEY=your-private-api-key \
  --env ODOO_API_MODE=auto \
  --env ODOO_ALLOW_MUTATIONS=false \
  -- /absolute/path/odoo-mcp/.venv/bin/python -m odoo_mcp.server

Restart Claude Code after registering the server.

Antigravity And Other MCP Clients

Add a local stdio server through the client's MCP settings:

{
  "servers": {
    "odoo": {
      "type": "stdio",
      "command": "/absolute/path/odoo-mcp/.venv/bin/python",
      "args": ["-m", "odoo_mcp.server"],
      "env": {
        "ODOO_URL": "https://your-company.odoo.com",
        "ODOO_DATABASE": "database-name",
        "ODOO_USERNAME": "odoo-mcp@example.com",
        "ODOO_API_KEY": "your-private-api-key",
        "ODOO_API_MODE": "auto",
        "ODOO_ALLOW_MUTATIONS": "false"
      }
    }
  }
}

Client configuration formats vary. The required concept is always a local stdio command, argument list, and private per-server environment variables. Additional examples are available in config/.

Install The Built-In Skill

The repository includes the portable odoo-website-theme-design skill.

Codex:

ln -s /absolute/path/odoo-mcp/skills/odoo-website-theme-design \
  ~/.codex/skills/odoo-website-theme-design

Claude Code and the current local Antigravity build:

ln -s /absolute/path/odoo-mcp/skills/odoo-website-theme-design \
  ~/.claude/skills/odoo-website-theme-design

On systems without symlink support, copy the complete skill directory instead.

Test The Connection

Restart the AI client and ask:

Use odoo_connection_info and report the Odoo version, protocol, mutation status, and rollback scope.

The initial result should show mutations_enabled: false.

Then test a small read:

Use odoo_search_read on res.company, request only name, and return at most five records.

If access is denied, adjust the dedicated Odoo user's permissions rather than switching to an administrator account.

Enable Safe Changes

Change the client environment only after read-only testing succeeds:

ODOO_ALLOW_MUTATIONS=true

Restart the client. Supported changes follow this sequence:

The AI calls preview_odoo_mutation.
You review the exact model, record IDs, and values.
You explicitly approve the change.
The AI calls apply_odoo_mutation with the single-use preview token.
The MCP journals the previous state and verifies the result.
The MCP returns a change_id.

Keep the change_id when the change may need to be reversed.

Rollback

Ask the AI to call:

rollback_change(change_id)

Rollback currently restores supported scalar-field writes and removes records created through this MCP. It refuses to overwrite records changed again after the original MCP operation.

Rollback cannot reverse sent emails, webhooks, payments, custom automation side effects, or changes made outside this MCP. Maintain normal Odoo database backups.

Safety Model

Read-only by default: set ODOO_ALLOW_MUTATIONS=true to enable changes.
No generic method execution and no direct delete tool.
Sensitive models and fields are blocked or redacted.
Every mutation requires a short-lived preview token.
An owner-only local snapshot is journaled before each change.
Every action is written to a local SQLite audit journal.
rollback_change restores writes and removes records created by this MCP.
Rollback refuses to overwrite records changed again after the MCP operation.
Record counts, fields, models, and values are bounded by policy.

Rollback covers Odoo records changed through this server. It does not replace database backups and cannot reverse external side effects such as sent email, webhooks, payment operations, or custom automation triggered by a write. The initial rollback engine permits scalar-field writes only; relational field changes require a future relation-aware snapshot format.

Credentials are read only from environment variables and are never returned by tools or stored in the journal.

Troubleshooting

Authentication Failed

Verify that the login belongs to the API key's user.
Confirm that the key is complete, active, and unexpired.
Confirm that the URL and database belong to the same Odoo instance.

Access Denied

Authentication succeeded, but the dedicated user lacks a required access group, model permission, or record-rule permission. Grant only the missing access.

MCP Server Does Not Appear

Use an absolute Python path.
Confirm installation with .venv/bin/pip show odoo-mcp.
Restart the AI client.
Check that the client's JSON or TOML syntax is valid.

Changes Are Disabled

This is the expected default. Review the authorization and rollback behavior before setting ODOO_ALLOW_MUTATIONS=true.

Development

.venv/bin/python -m unittest discover -s tests
.venv/bin/ruff check .
.venv/bin/python -m compileall src

The bundled website skill is in skills/odoo-website-theme-design.

Available Tools

7 tools

apply_odoo_mutationC

Apply an approved preview token, snapshot state, verify, and journal the change.

ParametersJSON Schema

Name	Required	Description	Default
`preview_token`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.7/5.0

Behavior2/5

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

No annotations provided, so description must fully disclose behavior. It states mutation actions but lacks details on permissions, side effects, reversibility, or error conditions, which is insufficient for a mutation 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?

Extremely concise single sentence with no waste. However, the brevity sacrifices important information, making it borderline under-specified.

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

Completeness2/5

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

Given no annotations and presence of an output schema (unknown detail), the description is incomplete. It omits workflow context, error handling, and output expectations, leaving the agent with significant ambiguity for a mutation operation.

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

Parameters2/5

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

Schema coverage is 0% and description adds minimal meaning to the single 'preview_token' parameter. It mentions it's an approved token but provides no format, constraints, or validity rules beyond the schema's type string.

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 uses a specific verb 'Apply' and resource 'approved preview token', and lists actions like snapshot, verify, journal. It distinguishes from siblings like preview_odoo_mutation, though could be clearer about the finalization aspect.

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?

No explicit guidance on when to use this tool versus alternatives. It implies use after preview approval but doesn't mention prerequisites or exclusions, leaving the agent without decision support.

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

odoo_change_historyC

List local mutation audit entries without returning record contents.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.8/5.0

Behavior2/5

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

With no annotations, the description carries the full burden. It mentions that record contents are not returned, hinting at privacy, but omits details like pagination behavior, read-only nature, prerequisites, or rate limits.

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 a single efficient sentence with no wasted words. However, it may be too terse, sacrificing completeness for brevity.

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

Completeness2/5

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

Given the output schema exists but its content is unknown, the description does not sufficiently explain what constitutes a 'mutation audit entry' or how the limit affects results. Incomplete for a 1-parameter tool.

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

Parameters1/5

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

The single parameter 'limit' has no description in the schema (0% coverage) and is not explained in the description. The description does not add meaning 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 'List local mutation audit entries without returning record contents' clearly specifies the verb (list), the resource (mutation audit entries), and a key characteristic (no record contents). It distinguishes from siblings like 'apply_odoo_mutation' and 'rollback_change'.

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?

No guidance on when to use this tool versus alternatives such as 'rollback_change' or 'preview_odoo_mutation'. The description only states what it does without context or exclusions.

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

odoo_connection_infoA

Check Odoo version, adapter, safety mode, and rollback scope.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

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?

With no annotations, the description carries the full burden. It implies a read-only operation ('Check') but does not explicitly state safety, non-destructiveness, or any behavioral traits beyond listing what it checks.

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 a single, front-loaded sentence with no unnecessary words. Every word adds value by specifying exactly what is checked.

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 tool has no parameters, no annotations, and an output schema presumably covers return values, the description adequately lists the four checked items. It is complete but could further reassure that calling this tool is safe and informative.

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?

There are zero parameters, so the input schema requires no additional meaning. The description does not need to add param info, meeting the baseline of 4 for no-parameter tools.

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 uses the specific verb 'Check' and clearly lists the resources: Odoo version, adapter, safety mode, and rollback scope. It distinguishes from siblings like apply_odoo_mutation and rollback_change which involve modifications.

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?

No guidance is provided on when to use this tool versus alternatives. The description does not mention any context or exclusions, leaving the agent without direction on prioritization.

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

odoo_fields_getC

Inspect safe field metadata for an Odoo model.

ParametersJSON Schema

Name	Required	Description	Default
`model`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.6/5.0

Behavior2/5

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

With no annotations provided, the description must fully convey behavior. It mentions 'safe', implying non-destructiveness, but fails to disclose whether it fetches all fields, metadata format, or any potential side effects. Incomplete for a tool with no annotation support.

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

Conciseness3/5

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

The description is a single sentence, which is concise and front-loaded. However, it is too terse to convey necessary details about usage and behavior, sacrificing completeness for brevity.

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 has one parameter and an output schema, the description is minimally adequate. It identifies the core action and target, but lacks context on error handling, return structure (though output schema exists), and integration with sibling tools.

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

Parameters1/5

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

Schema description coverage is 0% and the description does not elaborate on the sole required parameter 'model'. It does not specify its format, allowed values, or how it is used to select the model, leaving the agent without essential guidance.

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 tool inspects field metadata for an Odoo model, using the verb 'inspect' and specifying 'safe' to imply read-only. It differentiates from sibling tools like apply_odoo_mutation or odoo_search_read, which focus on mutations or record retrieval.

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?

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or situations where it should be preferred over sibling tools like odoo_connection_info for schema exploration.

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

odoo_search_readB

Read bounded Odoo records without exposing credentials or sensitive fields.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`model`	Yes
`order`	No
`domain`	Yes
`fields`	Yes
`offset`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden. It mentions that the tool does not expose credentials or sensitive fields and that records are bounded, which provides some behavioral context. However, it lacks details on idempotency, side effects, or authentication requirements.

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

Conciseness3/5

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

The description is a single sentence, making it concise, but it front-loads the purpose adequately. However, it lacks structure and could benefit from brief parameter highlights or usage context without becoming verbose.

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

Completeness2/5

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

Given the tool has 6 parameters (3 required), an output schema, and no description for any parameter, the single-sentence description is insufficient. It does not address return values, pagination, or parameter interplay, leaving gaps for an agent to correctly invoke the tool.

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

Parameters1/5

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

Schema description coverage is 0%, and the tool description does not explain the meaning or usage of any parameters (model, domain, fields, etc.). This fails to add value beyond the raw schema, which is critical for a tool with 6 parameters.

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 reads bounded Odoo records and emphasizes security by not exposing credentials or sensitive fields. It distinguishes from sibling tools like apply_odoo_mutation and odoo_change_history, which are mutation or info tools.

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 reading bounded records, but provides no explicit guidance on when to use this tool versus alternatives like odoo_fields_get or when not to use it. The context is implied but not specified.

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

preview_odoo_mutationC

Validate a create/write and return a short-lived, single-use preview token.

ParametersJSON Schema

Name	Required	Description	Default
`ids`	Yes
`model`	Yes
`reason`	Yes
`values`	Yes
`operation`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.3/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavior. It mentions 'short-lived, single-use preview token' but does not explain validation details, error handling, or auth requirements. Incomplete for safe agent use.

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

Conciseness2/5

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

The description is extremely concise (one sentence) but at the expense of completeness. It lacks structure and fails to provide necessary detail for a tool with 5 required parameters and nested objects.

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

Completeness1/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 required params, nested values object, output schema) and no annotations, the description is critically incomplete. It fails to explain validation semantics, token usage, or param purposes, leaving the agent underinformed.

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

Parameters1/5

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

With 0% schema description coverage, the description must compensate but does not mention any parameter (ids, model, values, etc.). The agent gets no information beyond parameter names and types from the schema.

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 it validates a create/write operation and returns a short-lived preview token, distinguishing it from sibling 'apply_odoo_mutation' which likely applies the change. However, it does not explicitly contrast with siblings.

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?

No guidance on when to use this tool vs alternatives like 'apply_odoo_mutation' or 'rollback_change'. The description lacks context about prerequisites or typical use cases.

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

rollback_changeC

Rollback a journaled write or create performed through this MCP.

ParametersJSON Schema

Name	Required	Description	Default
`change_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.5/5.0

Behavior2/5

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

No annotations are provided, placing full burden on the description. It only implies a destructive action (rollback) without specifying side effects, authentication needs, rate limits, or what happens on failure. The phrase 'journaled' is vague and not explained.

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

Conciseness3/5

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

The description is a single sentence, which is concise but lacks structure (e.g., no sections or bullet points). It could be expanded slightly to include key details without sacrificing brevity.

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

Completeness2/5

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

Despite having an output schema and sibling tools, the description fails to provide essential context, such as how to obtain a change_id from a previous operation or what the expected outcome is. It leaves significant gaps for a 1-parameter tool.

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

Parameters1/5

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

The sole parameter 'change_id' has no description in the schema (0% coverage) and is not explained in the tool description. The agent has no information on what constitutes a valid change_id, where to find it, or its format.

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 action ('Rollback') and the target resource ('a journaled write or create performed through this MCP'). It effectively distinguishes from sibling tools like 'apply_odoo_mutation' or 'odoo_change_history' by specifying the rollback function.

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

Usage Guidelines1/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, nor any prerequisites or exclusions. For instance, it does not mention that a previous journaled operation is required or how to obtain a change_id, leaving the agent without decision-making support.

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. Dates show when Glama detected each change.

7 tool updatesv0.1.0Jun 25, 2026
- First observedapply_odoo_mutation
- First observedodoo_change_history
- First observedodoo_connection_info
- First observedodoo_fields_get
- First observedodoo_search_read
- First observedpreview_odoo_mutation
- First observedrollback_change

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3/5.0

Disambiguation5/5

Each tool targets a distinct action: preview vs apply mutation, check connection, inspect fields, search records, view history, rollback. No overlaps.

Naming Consistency2/5

Inconsistent naming: most tools start with 'odoo_' but two (apply_odoo_mutation, preview_odoo_mutation) embed 'odoo' in the middle, and rollback_change lacks the prefix entirely.

Tool Count5/5

Seven tools is a well-scoped set for an Odoo integration covering connection, schema, search, mutations, history, and rollback.

Completeness4/5

Covers key mutation workflows (preview, apply, rollback) and supporting actions (search, fields, history). Minor gap: no direct delete or create without preview, but overall sufficient.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcp COAuth
com.wix
A Model Context Protocol server for Wix AI tools
Developer Tools Content Management Systems App Automation
216
hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
Apideck MCP A
dev.apideck.mcp
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
Developer Tools
42
Studex MCP Server
io.github.itshivams
Model Context Protocol server for Studex tools, notifications, and profile integrations
Developer Tools
1

Related MCP Servers

Odoo MCP Server
ERP Systems Data Platforms
Willval117
A
license
Not graded
quality
D
maintenance
An implementation that integrates with Odoo ERP systems, enabling AI assistants to interact with Odoo data and functionality through the Model Context Protocol.
Updated a year ago (2025-04-11 01:03 UTC)
MIT
Odoo MCP Improved
ERP Systems Databases
hachecito
A
license
Not graded
quality
D
maintenance
A comprehensive implementation of the Model Context Protocol for Odoo ERP systems that enables AI assistants to interact directly with business data across sales, purchases, inventory, and accounting modules.
Updated 9 months ago (2025-12-12 12:33 UTC)
48
MIT
Odoo MCP Server
ERP Systems Developer Tools
vzeman
A
license
Not graded
quality
D
maintenance
A Model Context Protocol server that enables AI assistants to interact with Odoo ERP systems, providing comprehensive tools for searching, creating, updating, and managing Odoo records through a standardized interface.
Updated a year ago (2025-09-10 10:01 UTC)
24
GPL 3.0
MCP-Odoo
ERP Systems Finance App Automation
iaisep
A
license
Not graded
quality
D
maintenance
A Model Context Protocol server that bridges Odoo ERP systems with AI agents, enabling them to access and manipulate partner information, accounting data, invoices, and perform financial reconciliation through a standardized interface.
Updated a year ago (2025-08-13 07:40 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/techniondigitalsolutions/odoo-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server