What Jedox MCP is, and how it actually works

· Jedox

Jedox MCP is Claude, running on your own licence, with a paid Jedox integration and a plugin layer that produces real cubes, dimensions, rules, Integrator XML and .wss reports. It genuinely accelerates a build. It is also vibecoding, and a planning model ends up in front of an auditor, so here is where that line sits.

Jedox MCP is the most interesting thing Jedox sells that has almost no public documentation. The product page describes it in the abstract, which makes it sound like a generic data connector. It is more specific than that, and more useful.

What you actually get is Claude running under your own Anthropic licence, locally, plus a paid integration into your Jedox environment, plus a plugin layer in between that knows how Jedox artefacts have to be shaped. You describe what you want. The agent produces the real thing: cubes, dimensions, rules, Integrator ETL projects as XML, and Web Spreadsheet reports as .wss files.

That middle layer is the whole point, and it is the part the marketing copy buries.

The protocol underneath

The Model Context Protocol is not a Jedox invention. Anthropic created it and released it in November 2024, and in December 2025 donated it to the Agentic AI Foundation, a directed fund under the Linux Foundation. OpenAI adopted it in March 2025. It is an open standard now, which is why a vendor can publish one interface instead of a bespoke plugin per AI tool.

The idea is simple: a model on its own can reach nothing. MCP is a common way for a system to say "here are the things you may do, described so any compatible client understands them". A server exposes tools (executable functions), resources (data to read for context) and prompts (reusable templates).

Two details matter if you are evaluating this properly. The current specification defines exactly two transports: stdio for a locally launched subprocess, and Streamable HTTP for a remote server. Any guide listing three, including HTTP+SSE, is describing 2025; that one was replaced in March 2025 and formally deprecated in July 2026. And since 28 July 2026 MCP is stateless: the initialize handshake and session header are gone, and every request carries what it needs. The local-subprocess transport is the relevant one here, which fits a setup where Claude runs on your own machine under your own licence.

The architecture in practice

  1. Claude, running locally: On your own Anthropic licence, not one Jedox resells
  2. The Jedox plugin layer: Versioned cookbooks that know how each artefact must be shaped
  3. The licensed Jedox integration: A paid add-on to the Full Suite user licence
  4. Your Jedox model: Cubes, dimensions, rules, Integrator XML, .wss reports

Jedox confirms the commercial half of that in their FAQ:

Jedox MCP is available as an add-on to the Full Suite user license and includes a versioned Jedox Claude Plugin that includes best practice cookbooks to speed structured and efficient model development for new use cases.

"A versioned Jedox Claude Plugin with best practice cookbooks" is the agent in the middle. The cookbooks are what stop a general-purpose model producing plausible nonsense: an Integrator project is XML with a specific structure, a .wss report has its own format, and a rule has to be written in Jedox's syntax with the right markers and order. A model guessing at those produces something that looks right and does not load. A model working from recipes produces something that does.

What it builds

What the agent produces connects to:

This is the part worth sitting with if you build Jedox solutions for a living. These are not summaries or suggestions. They are the actual artefacts: the XML an Integrator project is made of, the .wss file a report is, the rule text, the dimension structure.

That is also why the licence model makes sense. Claude is yours, under your own agreement, so your prompts and your model content are governed by the terms you already signed with Anthropic. Jedox charges for the integration into your environment, not for the model.

Jedox names ChatGPT, Gemini and Copilot alongside Claude as MCP-compatible tools on the product page. Take that as a statement about the protocol rather than about the packaging: the cookbooks that ship are a Claude plugin, and that is where the first-party experience is.

The documentation, or the absence of it

I went looking for a setup guide and there is none. As of 21 October 2026:

None of that makes the product less real. It is sold, licensed and demonstrated at Jedox events. It does mean scoping an engagement runs through your account team rather than a manual, and it means the governance questions below do not have published answers yet.

Governance: what is documented, and what is asserted

Jedox's pitch is "governed access". Worth separating the halves.

Documented, and genuinely solid. Jedox has a real rights model, independent of MCP: a chain of rights objects to roles to groups to users, with access levels N (none), R (read), W (write), D (delete) and S (splash, which writes to consolidated cells). Separate rights objects cover the database, cube, dimension, dimension element and cell data, and there is an audit object governing access to audit data. There is also a precedent for per-user context: Jedox OLAP connections in Integrator have a "use login credentials" option precisely so the connection runs as the current user with their rights applied.

Asserted, but not documented. Jedox says access "remains aligned with established roles, permissions, and security policies" and that writeback should follow defined approval processes. That is plausible and the precedent above makes it architecturally credible. But nobody has published how rights are evaluated per tool call, whether each call runs under a named Jedox user, what lands in the audit log, or whether writeback can reach consolidated cells.

The protocol will not settle it either. MCP's safety model lives in the client: the specification says a human should always be able to deny a tool invocation, and clients must treat tool annotations as untrusted unless the server is. The protocol gives you an approval prompt, not a permission model. Whether an agent may write to a consolidated cell is decided by Jedox.

Four questions before you let it write

  1. Under which identity does a tool call execute? A named Jedox user whose N/R/W/D/S rights apply, or a service account? This one answer decides whether "governed" means what you want it to mean.
  2. How does the integration authenticate? The MCP profile for remote servers is OAuth 2.1, with tokens audience-bound to the server and never in a query string. Ask whether that bar is met, or whether it is a stored username and password.
  3. What lands in the audit log? Can you reconstruct afterwards which agent changed which object, on whose authority.
  4. Can writeback reach consolidated cells, and can that be switched off? Splash rights exist for a reason, and an agent holding them is a different risk from one that does not.

Worth adding the general MCP cautions. Tool descriptions are text the model reads, which makes them a prompt injection surface. Over-broad permissions create a confused deputy problem, which is why the specification forbids passing tokens through and asks for minimal scopes.

Two things that share a name

Search for "Jedox MCP server" and you will find a community project on an MCP directory, published by an individual, exposing OLAP-level tools for listing databases, creating dimensions and setting cell values. It is a reasonable illustration of what a tool surface looks like.

It is not Jedox's product. Different author, no relationship. Be careful which one you are pointing at.

How this sits next to JedoxAI

Two different things. The JedoxAI agents, including the Knowledge Agent and Reporting Agent that shipped with 2026.1, run inside Jedox and are reached from the Jedox interface. They are covered in what shipped in 2026.1. Jedox MCP points the other way: a tool outside Jedox reaching in, to build things.

They overlap at the grounding layer, since both are about giving a model real structures rather than an export, and Jedox pairs them in demos. The boundary has never been defined publicly, so do not assume one is the other.

It accelerates the start, not the system

Here is the part I would want a client to hear before the demo.

It does work. Describe a dimension and you get a dimension. Describe a load and you get Integrator XML that runs. The time saving is real, and if your modellers currently spend three weeks standing up a structure, watching that happen in an afternoon is genuinely impressive.

It is also vibecoding, and that comparison is worth taking seriously rather than as an insult. In software, vibecoding is excellent at producing something that works, quickly, from a description. It is poor at producing something that is correct in every edge case, consistent with conventions you never stated, and maintainable by somebody else in two years. The failure mode is not code that crashes. It is code that runs and is subtly wrong.

A planning model has exactly that failure mode, and the consequences land somewhere specific. The numbers this model produces go into a statutory close. You will sit in front of an auditor and explain why a figure is what it is, which means explaining the rule that calculated it, the dimension the allocation ran across, and the load that populated it. "The agent built that" is not an answer. And unlike a side project, the whole company works in this thing: a dimension someone generated in a hurry becomes a hierarchy forty people enter numbers against, and a rule nobody reviewed becomes a number in a board pack.

So the line I would draw is this. Use it for the accelerated start: a first draft of a structure, a scaffold for an Integrator project, a report skeleton, anything in a sandbox where being roughly right fast is worth more than being exactly right slowly. Do not use it to produce the live system directly.

What that means in practice:

None of this is an argument against the tool. It is the same argument you would make about a fast, capable contractor who does not know your business: very useful, and not left alone with production.

What I would actually do

If you build Jedox solutions and your modellers spend weeks on structures, this is worth a conversation with your account team. The shape of it is sound: the agent drafts the artefact, a human reviews and commits it. Jedox quotes a "70-90% less time" figure for model building in their own demo sessions, with no published methodology behind it, so treat that as a claim rather than a benchmark.

What I would not do is point it at a production model before those four questions have written answers. Start where you would start any new developer: a sandbox database, a named user, a tight rights object, and someone reading every artefact before it is committed. The difference is that this developer writes a 400-line Integrator XML in a minute, which cuts both ways.

Treated as an accelerator it is a good deal. Treated as a shortcut to a finished system it will cost you the time it saved, somewhere further down the close.

Back to all posts