MCP gives Claude the keys to Odoo. A Skill tells it which doors to open.
An Odoo Claude Skill is not an Odoo connector. It is a folder of instructions, scripts, and references that teaches Claude a repeatable procedure. MCP is the connection to live models, records, and actions. If Claude must both understand your process and touch your ERP, you need both.
The direct answer: use a Skill for procedural knowledge; use MCP for tool and data access. A Skill can teach Claude how your team approves a credit note. It cannot, by itself, read the invoice. MCP can expose the invoice and a draft-credit-note tool. It does not know your approval policy unless you encode it.
This distinction comes from Anthropic’s own Skills explanation: MCP supplies connectivity; Skills teach Claude what to do with that connectivity.
Odoo Skill vs Odoo MCP
| Odoo Claude Skill | Odoo MCP server | |
|---|---|---|
| Purpose | Procedures, conventions, checks, examples | Live tools, resources, and data |
| Typical file or endpoint | SKILL.md plus optional scripts/references | Local stdio process or remote HTTPS endpoint |
| Can read today’s stock? | No, unless another tool supplies it | Yes, if a stock-read tool is exposed |
| Can teach version-specific code? | Yes | Only indirectly through tool descriptions or prompts |
| Main risk | Bad instructions or stale version guidance | Excessive access, unsafe writes, leaked credentials |
A Skill is a just-in-time operating manual
Anthropic defines Skills as folders containing instructions, scripts, and resources. Claude first sees compact metadata, then loads the full instructions when the task matches. The Claude Code Skills documentation uses a SKILL.md file and supports direct invocation as well as automatic selection.
For Odoo development, a useful Skill can pin the target version, tell Claude to inspect manifests and inherited views before editing, require ACL and record-rule checks, ban sudo() as a default fix, and define the test command. That is valuable even when Claude never connects to a running database.
For business operations, a Skill might say: “When reviewing overdue invoices, group by company and currency, exclude disputed invoices, never post a payment, and cite the Odoo record ID.” The live invoice data still has to arrive through MCP or another tool.
MCP is the controlled opening into Odoo
An Odoo MCP server turns allowed ERP operations into tools Claude can discover and call: search partners, aggregate sales, inspect fields, or create a draft record. Underneath, it may use Odoo 19’s JSON-2 API, older RPC APIs, or the Odoo ORM inside an installed module.
The MCP server must enforce the boundary. A sentence in SKILL.md saying “never delete” is helpful guidance, not authorization. If deletion is unacceptable, do not expose an unlink tool. Use a dedicated Odoo user, model allowlists, record rules, read-only defaults, and audit logs. See Odoo MCP security.
Choose the smallest architecture that can do the job
1. Skill only: writing and reviewing Odoo code
Use a version-aware Skill when Claude is working in an Odoo repository and all required facts are in the codebase. Examples: scaffold an Odoo 19 module, review an access CSV, migrate a view, or check an Owl component. No production ERP connection is required.
2. MCP only: simple read-only questions
Use MCP alone for narrow, well-described tools: “show open quotations assigned to me” or “count low-stock products.” The tool schema and Odoo permissions may be enough.
3. Skill plus MCP: repeatable business workflows
Use both when the task has policy. A month-end Skill defines the sequence and exceptions; MCP exposes the journals, invoices, reconciliation candidates, and draft actions. The Skill orchestrates. The server authorizes.
Do not call a Skill “version agnostic” unless it detects the version
Odoo 17, 18, and 19 are close enough to tempt generic advice and different enough to break it. View syntax, controller types, ORM helpers, frontend conventions, and the external API evolve. A credible Odoo Skill should either target one version or inspect the repository/database and route to version-specific references.
- Odoo 17: keep examples and tests pinned to 17 rather than borrowing 19 APIs.
- Odoo 18: verify controller, ORM, and Owl guidance against the 18 branch.
- Odoo 19: use JSON-2 for new external integrations; Odoo documents XML-RPC and JSON-RPC as deprecated and scheduled for removal in Odoo 22.
A single article with a real version matrix is more useful than three pages that repeat the same installation command.
Write the guardrails before the clever instructions
- State the trigger. Which Odoo tasks should load the Skill?
- Detect version and edition. Community and Enterprise do not ship the same modules.
- Require evidence. Inspect fields, views, ACLs, record rules, and existing tests before changing code.
- Separate read from write. Production writes require explicit confirmation and server-side permission.
- Define completion. Name the tests, upgrade command, lint checks, and expected evidence.
- Keep secrets out. A Skill is not a credential vault. MCP tokens and Odoo API keys belong in approved secret storage.
FAQ
Is an Odoo Claude Skill the same as an MCP server?
No. A Skill supplies instructions and procedural knowledge. An MCP server supplies live tools and data. They complement each other.
Can a Claude Skill connect directly to Odoo?
Not by itself. A Skill can include scripts, but live ERP access still requires an authenticated interface such as an MCP server or Odoo API client. Do not place credentials in the Skill.
Do I need separate Odoo Skills for versions 17, 18, and 19?
You need version-specific guidance. That can be separate Skills or one router Skill that reliably detects the version and loads the correct references.
Build knowledge and access as separate layers
Teach Claude the procedure. Enforce the permission in Odoo.
That separation is what makes an agent useful without making it an administrator.