Context Layer for Odoo

Consuming the layer.

The five operations any AI reads the context layer through, and the surfaces that expose them: MCP, REST, Python, TypeScript, static context packs, and signed offline caches. What is implemented today, and how distribution opens.

Technical alpha · Odoo 19 Updated 2 August 2026

The context layer is designed to be read the same way regardless of which AI, connector, or transport you use. Everything reduces to five operations.

The five operations

Operation	What it answers
`get_context`	For this question, give me the smallest applicable, verified context pack.
`resolve_noun`	What model and record population does this business noun map to?
`explain_field`	What does this field actually mean, beyond its label?
`get_join_path`	What is the correct typed path from this model to that one?
`validate_write_intent`	Is this intended write risky, and what is the safe way to do it?

get_context is the main entry point; the other four are focused lookups an agent can call mid-reasoning. validate_write_intent is advisory: it can warn, but it never authorizes an action and never implies permission. Odoo remains the authority.

Surfaces

The same five operations are exposed through several surfaces, so the layer fits whatever an AI stack already speaks:

MCP: the operations exposed as tools to an MCP client, served locally.
REST: the same operations over HTTP, as POST /v1/<operation>.
Python: a runtime client, plus a public entry-validation API (below).
TypeScript: a dependency-free client wrapping the REST operations.
Static context packs: a request-scoped JSON artifact you assemble ahead of time and hand to a model, no live service required.
Signed offline caches: an entitlement-scoped, signed cache served locally, for air-gapped or offline use.

The reference clients

The public kit’s shapes are stable enough to show. The Python package exposes entry validation:

from ocl_spec import ValidationError, validate_entry

# `document` is your entry; `schema` is the loaded entry JSON Schema.
errors = validate_entry(document, schema)

The TypeScript client (OCLClient) wraps the REST operations:

const client = new OCLClient(baseUrl);

await client.getContext(question, scope);
await client.resolveNoun(noun, scope);
await client.explainField(model, field, scope);
await client.getJoinPath(fromModel, toModel, scope);
await client.validateWriteIntent(model, operation, scope);

scope carries the Odoo version, edition, and modules, so the layer returns only facts that apply to the database in question.

Available now vs verified runtime

The open standard is on GitHub, Apache-2.0: clone it, run the CLI, and wire the example MCP server (get_context, resolve_noun, explain_field) over ten candidate example entries today. See the Quickstart. The verified 44-entry runtime, the full five-operation service, and a hosted endpoint answer over your real Odoo 19 data and come with runtime access. The TypeScript client ships in the repo as the contract; it is not on npm yet, pending a stable endpoint. To run against real data, request verified runtime access.

Choosing a surface

Building an agent or assistant? Wire the example MCP server now (see the Quickstart), or use REST and call get_context per question against the verified runtime.
Working in Python? Validate your own entries today with ocl_spec; the runtime client arrives with runtime access.
Need offline or air-gapped? Use a static context pack or a signed offline cache. See Context packs and offline.

The format the operations speak is public and specified. See The open format.