Provides tools for interacting with Odoo 19 through its JSON-2 API, including connection checks, model and field discovery, record reading, search, count, grouping, controlled creation, and update operations, with per-model grants and audit controls.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Monynha Odoo MCP Show me the fields on the res.partner model in my Odoo connection"
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.
An original, open-source and security-focused MCP gateway for Odoo, built in Python for the Monynha Softwares ecosystem. v0.1 alpha; review required before production use.
The gateway serves MCP over authenticated Streamable HTTP and local stdio,
with an Odoo 19 JSON-2 adapter and explicit policies for multiple instances.
11 MCP tools: server info, connection listing/checks, model and field discovery, record reading/search/counting/grouping, controlled creation and update.
Odoo 19 JSON-2 API with bearer API key, database header, typed/redacted errors and no automatic write retries. Large responses are stopped while streaming.
PostgreSQL tenant metadata, memberships, per-model operation grants, audit, versioned migration and administrative CLI.
OAuth protected resource metadata, remote OIDC/JWKS verification and stdio.
Public-destination validation and DNS-pinned outbound HTTPS.
Compact default record fields, request/concurrency budgets, blocked nested x2many write commands and write-intent audit events.
Not yet available: XML-RPC legacy compatibility, generic public methods, record deletion, business wizards, attachments, multi-step workflows, billing or web UI. The external JSON-2 API requires a compatible Odoo installation/plan.
Related MCP server: Odoo 18 MCP Server
Python 3.12+, uv, PostgreSQL for remotely hosted environments.
An external OIDC provider issuing RS256/ES256 tokens with the
mcp:odoo scope and audience equal to the MCP resource URL.
A dedicated low-privilege Odoo technical user and API key, stored in a deployment secret manager.
uv sync --locked --extra dev
uv run --locked ruff check .
uv run --locked ruff format --check src tests
uv run --locked mypy --ignore-missing-imports src/monynha_odoo_mcp
uv run --locked pytest -qCI uses only mock Odoo calls. No production credentials are needed.
stdioConfigure the environment in your shell or secret manager (never commit real values):
export MONYNHA_MCP_MODE=stdio
export MONYNHA_MCP_LOCAL_PRINCIPAL_ID=local-developer
export MONYNHA_MCP_LOCAL_CONNECTION_ID=my-odoo
export MONYNHA_MCP_LOCAL_ODOO_URL=https://odoo.example.com
export MONYNHA_MCP_LOCAL_SECRET_REF=env:MONYNHA_ODOO_KEY_LOCAL
export MONYNHA_ODOO_KEY_LOCAL=replace-with-a-secret-from-your-vault
uv run --locked monynha-odoo-mcpThis local profile starts read-only and uses the same validated Odoo client.
Your MCP host can launch the command via stdio.
The public URL must be the full HTTPS resource path, for example
https://mcp.example.com/mcp. Supply these environment variables:
Variable | Meaning |
| Enable remote transport |
| PostgreSQL SQLAlchemy URL; secret-managed |
| Public HTTPS MCP resource URL |
| Trusted external OIDC issuer |
| Must equal public URL |
| Issuer's HTTPS signing keys |
| Interface behind reverse proxy, normally |
| Optional JSON array of trusted browser HTTPS origins |
| Maximum Odoo response, default 2 MiB |
| Per principal/connection/operation budget, default 60 |
| Per-connection in-process limit, default 4 |
| Secret value referenced by each connection |
Before the first launch, run migrations with the same database URL:
uv run --locked alembic upgrade headCreate an organization, principal, membership, connection and read grant from an administrative shell:
uv run --locked monynha-odoo-admin organization add --id my-org
uv run --locked monynha-odoo-admin principal add --id oidc-subject
uv run --locked monynha-odoo-admin membership grant --principal oidc-subject --org my-org
uv run --locked monynha-odoo-admin connection add --id my-odoo --org my-org --url https://odoo.example.com --secret-ref env:MONYNHA_ODOO_KEY_LOCAL
uv run --locked monynha-odoo-admin policy grant --principal oidc-subject --connection my-odoo --operation read --model res.partner
uv run --locked monynha-odoo-admin connection test --id my-odoo --principal oidc-subjectThe CLI stores a reference to the API key. Supply its value separately
through an approved secret source. The OIDC token subject must match the
registered principal. Grants for create and update require deliberate
administrative commands; deletion and nested relational write commands are
unavailable. Non-idempotent writes persist an audit intent before dispatch.
If an Odoo write times out, check its records before retrying.
Run the service only behind HTTPS reverse proxy:
uv run --locked monynha-odoo-mcpMCP endpoint: /mcp
OAuth resource metadata: /.well-known/oauth-protected-resource/mcp
Liveness/readiness: /healthz, /readyz
For a containerized starting point, see Dockerfile and
docker-compose.example.yml. Apply migrations as a separate deployment
step and inject all secrets through Coolify, Vault or your platform's secret
manager. The rate limiter is in-process: run a single application worker or
enforce shared limits at the reverse proxy/API gateway when scaling to multiple
replicas. Configure browser origins only for clients you trust; that setting
does not replace OIDC authentication.
This project is an independent behavioral implementation. It does not use private code from third-party MCP services.
List connections accessible to the authenticated client.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Accessible to the authenticated client' adds a useful scoping/auth hint, but nothing is said about return shape, pagination, or whether results are filtered by permissions beyond the ambient auth context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the verb and resource, with zero filler. It is perhaps too terse to be maximally useful, but nothing in it is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description is the only source of behavioral information, and it omits what a 'connection' is (record/webhook/integration?), whether the list is paginated, and what fields each entry has. For a zero-param tool this is adequate to call but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; the schema having no properties is consistent with the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (list) and resource (connections) with scope limited to the authenticated client. It is distinguishable from connection_test by the name and the 'List' verb, though the description itself doesn't call out that sibling. Clear but without explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to call this versus connection_test or any other sibling. The listing intent is implied by the verb, but there are no conditions, prerequisites, or alternatives named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check connectivity to an authorized Odoo instance.
| Name | Required | Description | Default |
|---|---|---|---|
| connection_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses almost nothing: it doesn't say whether a failed check throws an error or returns a failure status, whether it times out, or what auth is required beyond 'authorized'. Only the read-only nature is weakly implied by 'check'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler. Efficient, though the terseness is partly the cause of the missing detail rather than a virtue on its own.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a connectivity-check tool the most important information is what a result looks like (success/failure signal), and there is no output schema and no description of the return. Combined with an undocumented parameter, the definition is not complete enough to invoke confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the single required parameter 'connection_id' is completely undocumented. The description does not clarify where this ID comes from (presumably connection_list) or what format it takes, leaving the parameter semantically opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Check connectivity to an authorized Odoo instance'), making the purpose immediately clear. It doesn't explicitly differentiate from sibling tools like connection_list or server_info_get, which also deal with connections, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this versus connection_list or server_info_get, and no stated preconditions or exclusions. Usage can only be inferred from the name, which is weak for a validation-style tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read accessible field definitions of one model.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | ||
| connection_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full disclosure burden. 'Accessible' hints that results are filtered by permissions, but the description says nothing about invalid-model behavior, whether an untested connection_id is accepted, or whether all fields are returned at once versus paginated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler, which is appropriate for the size of the tool. The terseness borders on under-specification, but no sentence is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With two required parameters at 0% schema coverage, no annotations, and no output schema, the description should explain the connection_id/model relationship and the shape of what comes back. Instead it supplies one clause, leaving the agent to guess how to populate connection_id.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description only implies that 'model' identifies which model's fields to read. The required 'connection_id' parameter is never explained — no hint about format, where to obtain it, or its relationship to connection_list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (read) and resource (field definitions of one model), which is clear and distinguishable from the sibling model_list. It stops short of naming the sibling explicitly, so differentiation is inferential rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no mention of when to prefer model_list or record_get, and no stated prerequisites (e.g., whether connection_test must pass first). Usage is only implied by the word 'accessible'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find Odoo models available to this connection.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| domain | No | ||
| connection_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It says nothing about whether results are paginated, whether 'find' implies search semantics, what authentication or permissions are needed on the Odoo connection, or roughly what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no wasted words, but the brevity is under-specification rather than efficient compression — nothing actionable is conveyed beyond the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no annotations, no output schema, and 0% schema descriptions, the definition leaves too much undocumented. An agent would have to open the schema and guess at domain syntax and pagination behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 3 params. 'this connection' weakly implies connection_id, but limit (default 50) and especially domain, an Odoo-specific filter syntax with no schema description at all, receive no explanation in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: find Odoo models scoped to a connection. An agent can tell this apart from record-level siblings, though it doesn't explicitly distinguish itself from model_fields_get, which operates on a single model.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this versus model_fields_get, record_search, or server_info_get. The natural workflow (list models, then fetch fields) is left entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read grouped aggregates via the Odoo ORM.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| model | Yes | ||
| domain | Yes | ||
| fields | Yes | ||
| offset | No | ||
| groupby | Yes | ||
| connection_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read operation via ORM but doesn't disclose permission requirements, connection behavior, pagination (limit/offset defaults), whether grouping is mandatory, or what the response contains. For a 7-parameter tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is front-loaded and waste-free, which is structurally good. But it is under-specified for a complex tool rather than appropriately concise, so it earns only a middling score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no annotations, no output schema, and zero parameter documentation, the description is completely inadequate. An agent cannot reliably construct domain, groupby, or fields arguments from this definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 7 parameters, including required ones like domain, fields, groupby, and connection_id. The description adds no meaning about what these parameters expect (e.g., domain syntax, groupby semantics, aggregate field behavior), so the agent has no documentation for any parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a verb ('Read') and a resource ('grouped aggregates') plus the backend (Odoo ORM), so the general purpose is identifiable. However, it doesn't differentiate this from siblings like record_count or record_search, which also read/aggregate Odoo data, leaving the agent to guess which tool fits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to choose record_aggregate over record_search, record_count, or record_get. No prerequisites, exclusions, or typical scenarios are stated, so usage must be inferred from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Count Odoo records matching a domain.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | ||
| domain | No | ||
| connection_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It does not state whether the operation is read-only, what permissions are required, how a null domain behaves, or what the count return looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no wasted words. It is concise, though its brevity reflects missing detail rather than efficient completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and zero schema description coverage across three parameters, the one-sentence description is not complete enough. An agent must infer required connection/model semantics and the meaning of a null domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should explain the parameters, but it only mentions the domain filter. It does not explain the required connection_id or model parameters, nor does it describe Odoo domain syntax.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: count Odoo records, scoped to records matching a domain. It does not explicitly differentiate from siblings like record_search or record_aggregate, but the counting purpose is clear from the text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus record_search, record_get, or record_aggregate. It only states what the tool does, leaving usage selection entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a record only when the connection policy allows it.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | ||
| values | Yes | ||
| connection_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It hints that writes can be blocked by policy, but doesn't say what happens on denial (error vs silent skip), whether the operation is reversible, what permissions are required, or what a successful response contains. For a mutation tool with zero annotation coverage this is thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler, so there is nothing to trim. But the brevity here reflects under-specification rather than disciplined conciseness – the one sentence is doing far too little work.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool takes a nested object payload, requires a connection reference, and returns nothing documented (no output schema). With no annotations and 0% parameter coverage, the description would need to explain the values/model mapping and the policy precondition mechanism; it does neither.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for three required parameters, including a nested free-form 'values' object and a 'connection_id'. The description adds no meaning to any of them – it never mentions model, values, or connection_id, so the agent must infer the entire payload shape from bare property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: 'Create a record'. That distinguishes it trivially from record_update and the read-side siblings (record_get, record_search). It doesn't name any sibling explicitly, but the operation is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a gating condition ('only when the connection policy allows it') but never explains how an agent is supposed to determine that – no mention of connection_test or connection_list as the way to check, and no alternative path when the policy disallows. The agent is left with a precondition it cannot evaluate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read selected Odoo record IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | ||
| model | Yes | ||
| fields | No | ||
| connection_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. 'Read' suggests a non-mutating operation, but it does not disclose permissions, missing-ID behavior, default field handling, or the shape of the result.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is front-loaded and free of filler. It is concise, though the brevity contributes to broader under-specification rather than making the definition complete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a four-parameter tool with no annotations, no output schema, and 0% schema coverage, the description is far too thin. It establishes the broad intent but omits parameter meaning, usage boundaries, and behavioral details an agent needs to invoke it reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needs to explain the four parameters. It only vaguely maps to 'ids' and says nothing about connection_id, model, or the optional fields parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource: reading selected Odoo records by ID. It broadly distinguishes this from search-style siblings like record_search, but it does not explicitly name alternatives or clarify whether the return is records or just IDs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives no guidance on when to use this tool instead of record_search, record_count, or the create/update siblings. The only usage signal is the phrase 'selected ... record IDs,' which is implied rather than explained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search records by Odoo domain and page through the results.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| model | Yes | ||
| order | No | ||
| domain | No | ||
| fields | No | ||
| offset | No | ||
| connection_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a read-only search and mentions paging, but does not state authentication needs, rate limits, read-only guarantees, or what happens with invalid domains. This is a significant gap for a parameter-rich tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no wasted words. However, for a seven-parameter tool, it is arguably too terse to be fully appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has seven parameters, no output schema, no annotations, and no schema descriptions. The description mentions only domain and paging, leaving most of the contract unexplained. It is not complete enough for an agent to invoke the tool confidently without inspecting the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain the parameters. It only gestures at domain and paging via limit/offset, while model, connection_id, fields, and order are left unexplained. It adds limited meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource: search records. It also adds the key mechanism, Odoo domain, and mentions paging. It does not distinguish this tool from siblings like record_get, record_count, or record_aggregate, which prevents a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool does but gives no guidance on when to choose it over record_get, record_count, record_aggregate, or other sibling tools. There are no exclusions, prerequisites, or alternative-selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update records only when the connection policy allows it.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | ||
| model | Yes | ||
| values | Yes | ||
| connection_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for a mutation tool. It hints at a connection-policy prerequisite, but does not disclose whether updates are partial or full, how existing values are treated, whether the operation is reversible, or what happens when policy denies the update.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted wording, but it is under-specified rather than appropriately concise. Essential structural details about batching, targeting, and values are absent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a complex mutation accepting a connection, model, ID list, and nested values object, with no annotations or output schema. The description provides only a vague policy condition and leaves nearly everything an agent needs to invoke it correctly undocumented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description says nothing about connection_id, model, ids, or values. For a tool with four required parameters and a nested values object, the description fails to compensate at all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb-resource pair, "Update records," which distinguishes it from record_create and read siblings by operation. However, it does not specify scope such as records selected by IDs, model context, or connection context, so the purpose remains somewhat vague for a batch mutation tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives only a conditional gate: update records "only when the connection policy allows it." It does not explain when to use record_update versus record_create, record_get, or record_search, nor does it describe prerequisites for the policy check.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show supported backend and version.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. 'Show' implies a read-only, side-effect-free call and it discloses the returned fields, but it says nothing about whether a live connection or credentials are required, or what happens if the backend is unreachable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence, front-loaded with the verb and the payload. Nothing redundant or wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does name the two return values (backend and version), which is the essential missing piece. For a zero-param informational tool this is nearly sufficient; only the auth/connectivity precondition is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there are no semantics to explain and the baseline of 4 applies. Nothing in the description misleads about inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'Show' plus the resource 'supported backend and version' tells the agent exactly what comes back. Sibling names (record_*, connection_*, model_*) make it clear this is not a data or connection operation, though the description never names that boundary itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied only: call it when you need to know the backend or version. There is no explicit 'use when' clause and no reference to alternatives such as connection_list or connection_test, which an agent might otherwise confuse with a health/info probe.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0connection_listconnection_testmodel_fields_getmodel_listrecord_aggregaterecord_countrecord_createrecord_getrecord_searchrecord_updateserver_info_getScored across 11 tools
Each tool targets a distinct Odoo operation: connection lifecycle, model introspection, or a specific record operation (create, update, get, search, count, aggregate). The record-oriented tools share a resource but have clearly separated semantics and input shapes, so an agent should not misselect. No two tools appear interchangeable.
All 11 tools follow a consistent noun_verb pattern (record_create, model_list, connection_test, server_info_get). Compound nouns like server_info and model_fields are handled predictably, with no mixing of camelCase, vague verbs, or inconsistent ordering.
Eleven tools is well-scoped for a generic Odoo MCP server covering connection checks, schema introspection, and core record operations. Each tool earns its place without obvious redundancy or filler.
The surface covers create, update, read, search, count, and aggregate, but there is no record_delete or bulk operation, leaving a notable gap in the CRUD lifecycle. Connection creation and model-level schema mutations are also absent, though those may be intentionally out of scope.
Odoo MCP Pack — ERP/CRM via Odoo's external JSON-RPC API.
Odoo virtual employee via MCP: query, create, modify records, workflows, PDFs, and activities.
Hosted MCP server for AI-driven data ops. Create apps, manage schemas, and CRUD structured data.
Build multi-tenant apps over MCP. Schemas, CRUD, deploys — access control enforced server-side.
