MCP server for Dolibarr with AI studio

MCP server for Dolibarr with AI studio: 18 tools, 33 models, OAuth 2.1, React apps, ECharts charts and a Dolibarr module builder

Plug an AI assistant into your Dolibarr — Claude, ChatGPT, Cursor, VS Code, or any client that speaks the Model Context Protocol — and let it work in your data the way a colleague would, one you have given an account to. The module brings a complete MCP server (JSON-RPC 2.0 over streamable HTTP, OAuth 2.1 with PKCE), 18 tools across reading, writing, code and building, and 33 Dolibarr data models known by heart, from the quotation to the payment. Then a studio for what the assistant builds next: React web applications, ECharts charts, and whole Dolibarr modules delivered as a zip. The point it all turns on: an assistant acts as the person who said yes, and never sees anything that person could not. 

Who is it for? Directors who would rather ask their figures a question than open ten lists, accountants chasing unpaid invoices, salespeople following their pipeline, project managers, warehouse staff — and integrators who want to build dashboards, customer portals and Dolibarr modules without starting from a blank page. One assistant plugged in, or twenty: the principle does not change.

A complete MCP server inside Dolibarr

• MCP protocol version 2026-07-28, still answering to 2025-06-18, 2025-03-26 and 2024-11-05: today's clients and yesterday's both connect with nothing to change.
• JSON-RPC 2.0 over streamable HTTP: initialize, ping, tools/list, tools/call, prompts/list, prompts/get, resources/list, resources/read, notifications, and batched calls.
• OAuth 2.1 with PKCE S256, resource indicators, dynamic client registration (RFC 7591), server metadata (RFC 8414) and protected-resource metadata (RFC 9728), token revocation (RFC 7009).
• A consent page written in plain words: before saying yes, the person reads the list of tools the assistant will be able to use, how many only read, how many can change something, and what stays true whatever happens.
• A personal token in a minute for a workstation, without the whole dance.
• Tokens are kept as a SHA-256 fingerprint only: a copy of the database hands nobody a working token.
• Authorization codes are single use: a second attempt revokes every token of that person-client pair, which makes an interception worthless. Refresh by rotation.
• HTTPS required by default, except from the machine itself. The module warns you of its own accord when the address it would give clients is not the right one.

Eighteen tools, in four families

• Reading (6 tools, on from the start): get_context says what this installation is, list_models and get_model_schema describe what is readable, search_read and read_record read, read_group adds up in groups.
• Writing (4 tools, off from the start): create_record, update_record, delete_record and execute_method, which does to a record what Dolibarr would — validate a proposal, approve a supplier order, close a project.
• Code and scripts (3 tools, off from the start): code_search and code_read over the folder the administrator opened, execute_script for the module's own small language.
• Building (5 tools, off from the start): manage_webapp, create_chart, manage_module, search_webapp_code and search_module_code.
• Every tool tells the client whether it only reads and whether it can destroy, so an assistant knows when it ought to ask first.
• A tool answers only when three things agree: it is on, the account holds the matching Dolibarr right, and the tool is open to it. Turning a tool on can therefore never give more than Dolibarr already gave.
• One button — « turn off everything that writes » — puts the server back to read-only in a single move.

Thirty-three Dolibarr data models

• Selling: third parties, contacts, commercial proposals, customer orders, customer invoices, invoice lines, contracts, shipments.
• Buying: supplier orders and invoices. Money: customer and supplier payments, bank entries, accounts, expense reports, donations.
• Products and stock: products and services, movements, warehouses, stock on hand. Projects: projects, tasks, time spent.
• People: users, members, leave. Day to day: events, tickets, interventions. Made in the studio: applications, charts, built modules.
• Every model is described in advance: its table, its key, its entity column, its dates, and the ways it knows how to be grouped. A table name written by hand leads nowhere.
• Models whose Dolibarr module is off at your installation are set aside of their own accord: the assistant sees only what actually exists.
• Group by a date by writing datef:month, datef:quarter, datef:week… and the results come back in the order of time.
• Grouping on fk_soc gives back the customer's name, not a row number: the module recognises the foreign keys it knows how to join.
• Nine models are read-only whatever happens — payments, bank entries, stock movements, time spent, invoice lines, users — because that is where Dolibarr keeps a consistency of its own.

A small sandboxed language, never PHP

• Odoo has safe_eval; PHP has no equivalent. So this module took the other road: it carries its own small language. No code written by an assistant is ever run as PHP.
• Variables, if/else, for … in, while, lists, maps, the ternary operator, negative indexes, comments — and about 75 functions over lists, text, numbers, dates and JSON.
• Reading the database: db.select, db.first, db.count, db.group, db.fields, db.models, and db.sql in SELECT only, with {{prefix}} and {{entity}} marks and a limit added for you.
• No import, no file, no shell, no $, no backticks, no eval: those words are refused before the script even begins.
• Three guards at once: a step counter, a clock, a memory limit. An endless loop is stopped where it stands, and Dolibarr carries on.
• No password, key or token column is readable, and eight whole tables are closed to any hand-written query.
• The web is out of reach unless an administrator has opened it and named the hosts allowed. It is closed from the start.

React web application builder

• A React 19 application kept inside Dolibarr: JSX pages, reusable components, endpoints, shared style and code, server-side storage.
• Pages run in the browser; what they need from the database they ask of their own endpoints, each a script that can only read. The page stays as free as you like, the door stays narrow.
• A small library handed to every page: Dolibarr.useCall (a hook giving loading, data, error), Dolibarr.call, Dolibarr.useRoute, Dolibarr.store, Dolibarr.money, Dolibarr.date, and React with its hooks.
• A router in two modes, a menu built from the pages, and a stylesheet provided so that a page looks like something without writing any CSS.
• A page that throws while it draws does not take the application down: the error shows where somebody can read it, and the rest carries on.
• Sharing by link with a time limit, closable at any moment, and installation on a phone in full screen.
• React and Babel come from a configurable CDN, or from a local copy dropped into the module: an installation with no internet works entirely.

ECharts chart builder

• Twenty shapes: bars, line, filled line, pie, ring, scatter, radar, gauge, funnel, heat map, tree map, sunburst, flow, network, box plot, candlestick, river, parallel, tree, picture bars.
• Six colour sets and eleven extensions: browsing a long series, colouring by value, a toolbox, mark lines and areas, brushing, calendar, timeline.
• The drawing and the numbers stay apart: the drawing is JSON, unable to do anything by itself; the numbers come from a script that can only read. Put together when the chart opens, they are always current.
• The module accepts three shapes of result and recognises which one it got: a list of rows, a map of labels to numbers, or several declared series.
• A hand-written ECharts option is cleaned before it is kept: a string trying to be a function, a script tag, a javascript address are all left behind.
• Sharing by link, a fold-out of the numbers underneath, and automatic refresh so a chart can sit on a workshop screen.
• ECharts comes from a CDN or a local copy, like React.

Dolibarr module builder

• Describe a module — what it holds, and what each thing has — and the studio writes a whole Dolibarr module.
• Out come: the descriptor Dolibarr reads, the SQL tables and their indexes, the classes extending CommonObject, the list pages with search, sort and paging, the card pages with create, edit and delete, the menus, the language files and the README.
• Fourteen kinds of field, four of them real Dolibarr links: a third party, a user, a project, a product — with a picker to fill in and a clickable link to read.
• Every object also gets, unasked, a numbered reference, a status, a note, the author, the dates and the entity column for multi-company.
• The code that comes out passes php -l, installs like any external module, creates its tables, declares its rights, and its pages genuinely work: this is not a mock-up.
• Packaged as a downloadable zip, so you can look at the files before installing them. Writing straight into the code folder exists but is off from the start.
• A module number is chosen so that it collides with no other module in the installation.

Ready-made prompts and resources

• Six prompts delivered: how selling went, who has not paid, how the stock looks, build a small board, build a module, answer from the data.
• A prompt is a text with blanks that a client asks for by name, fills in, and puts in front of its model: it is how you give the whole house tried ways of asking things.
• More are written in two fields: the text with its {{blanks}}, and the list of blanks with what they are and whether they must be given.
• Four resources offered for direct reading: the installation's context, the catalogue of models, the catalogue of tools, and the code of a web application.
• The server hands the client, at the very first exchange, a short set of instructions: start with the context, then the models, before reading anything. An assistant that follows it answers correctly the first time.

Security: what is possible and what is not

• It never acts as anybody but the person who said yes. Every token carries a Dolibarr user, every query filters on their entity. What that account cannot reach, the assistant cannot reach.
• It never runs PHP written by an assistant.
• It never reads a password, key or token column, whatever it is asked.
• From a script, it never runs anything but a SELECT.
• It keeps only a fingerprint of each token.
• It writes every call down: nothing an assistant did is invisible afterwards.
• It writes nothing into the code folder unless an administrator has turned that on on purpose.
• The server is closed on installation, and only the six reading tools are on when you open it. Nothing answers until you have decided that something should.

Administration, rights and restrictions

• Eight Dolibarr rights: read, connect an assistant, build web applications, build charts, build modules, share by link, read the log, change the settings.
• Restrictions take something away: a whole model, or one precise field, for reading, writing or removing — for everybody or for named people and groups.
• A careful set, ready in one click: the tools kept out of the bank, leave and expenses, and stopped from writing to payments and user accounts.
• Each tool opens to everybody or to a list of people and groups, independently of the others.
• Clients close or delete; tokens revoke one by one; and the whole server switches off with a single setting. All three take effect at once.
• A service keys page keeps API keys encrypted and never shows more than their last four characters again.
• Seven groups of settings, each explained in one sentence, with the limits that keep a careless question from becoming a slow Dolibarr.

A log of every call

• Every call is written down: the tool, the person, the client, what was sent, what came back, how many rows, how long, from where, and how it ended — answered, refused, or failed.
• Parameters are scrubbed before being kept: anything that looks like a secret is replaced with stars.
• Five figures at the top, a small diagram of calls by tool, and a list filterable by tool, by outcome, by word and by number of days.
• One call's detail shows what was sent, laid out, and what came back.
• Three uses: understanding what people actually do, tuning the restrictions from the refusals, and accounting for it the day somebody asks.
• Housekeeping runs on its own: trims the log, throws away expired tokens, closes stale links, forgets abandoned conversations.

Technical information

• Dolibarr 16 and above (tested on Dolibarr 23.0.4), PHP 7.4 to 8.4, MySQL/MariaDB.
• No Dolibarr module required: the server reads what is on at your installation and sets the rest aside.
• PHP extensions: JSON and mbstring, plus zip to package a built module. No external library to install on the server.
• React, Babel and ECharts come from a configurable CDN or from a local copy dropped into the module.
• 24 tables llx_mcps_*, one scheduled housekeeping job, and nothing changed in the Dolibarr core.
• Multi-company: tokens, clients, applications, charts, modules, restrictions and log all separated by entity.
• Five languages: French, English, Italian, German, Spanish.
• Delivered with a 43-page PDF documentation. GPL v3. Published by NEXT GESTION — www.nextgestion.com

Demo of the MCP Studio module
Login : demo
Password : demo