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., "@@aiotic/mcp find the endpoint contract for creating a purchase order"
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.
The Model Context Protocol server for the AIOTIC Integrator Guide. It gives your coding assistant (Claude Code, Cursor, VS Code or any other MCP client) exact answers while you integrate AIOTIC purchase-order processing with your ERP: it searches the guide, returns endpoint contracts and schemas from the public OpenAPI document and hands out payload examples. On your own machine it can also look at your test tenant.
Documentation: https://developers.aiotic.ai/ai/mcp-server — tools, security model, setup per assistant.
Changes: CHANGELOG.md.
Questions and problems: open an issue in this repository.
The entry differs per assistant: Claude Code and Cursor read mcpServers, VS Code reads servers.
Claude Code, in .mcp.json in your project:
{ "mcpServers": { "aiotic": { "command": "npx", "args": ["-y", "@aiotic/mcp"] } } }Cursor, in .cursor/mcp.json in your project, or in ~/.cursor/mcp.json for every project:
{ "mcpServers": { "aiotic": { "type": "stdio", "command": "npx", "args": ["-y", "@aiotic/mcp"] } } }VS Code, in .vscode/mcp.json in your project:
{ "servers": { "aiotic": { "type": "stdio", "command": "npx", "args": ["-y", "@aiotic/mcp"] } } }Other assistants and where their configuration lives: MCP server in the guide. Node.js 20 or newer. There is nothing else to configure: docs mode needs no key and sends nothing anywhere.
Each version carries one edition of the guide and of the API document, so pin a version
("args": ["-y", "@aiotic/mcp@<version>"]) when you want the same answers every time. The server reports the edition
to your client when it connects.
Prefer no installation at all? The hosted endpoint https://mcp.aiotic.ai/mcp runs the same server in docs mode and
always serves the latest revision of the guide. For Claude Code:
{ "mcpServers": { "aiotic": { "type": "http", "url": "https://mcp.aiotic.ai/mcp" } } }The guide has the entry, a one-line command or a one-click link for every other assistant: Connect your coding assistant.
Related MCP server: MCP Server for Odoo
Tool | What it returns |
| Best-matching sections with page, heading and snippet |
| Every page of the guide with section, title and summary |
| One page as Markdown |
| Method, path, summary and authentication per endpoint, plus the outbound webhooks |
| The full contract: parameters, request and response schemas, examples |
| One schema from the OpenAPI components |
| Payload samples |
| Status values, their meaning and the transitions between them |
Set AIOTIC_BASE_URL and AIOTIC_API_KEY in the server's environment and the assistant can also read your test
tenant or the mock from the AIOTIC Python SDK: orders and
their status, rejected e-mails, customers, products and customer item mappings.
{ "mcpServers": { "aiotic": {
"command": "npx", "args": ["-y", "@aiotic/mcp"],
"env": { "AIOTIC_BASE_URL": "http://localhost:8080", "AIOTIC_API_KEY": "mock-integration-key" } } } }That is the entry for Claude Code and Cursor; in VS Code the same command, args and env go under servers,
with "type": "stdio".
Read tools are on. Write tools need AIOTIC_MCP_ALLOW_WRITES=true. Deletes and send_order_to_erp also need
AIOTIC_MCP_ALLOW_DANGEROUS=true and confirm: true in the call.
Keys come from the environment, never from tool arguments, and are removed from everything the server returns.
Tenant tools exist on the stdio transport only. Use a test tenant: whatever key you put in an assistant's environment, the assistant can use.
npx -y @aiotic/mcp --http 3333 # http://127.0.0.1:3333/mcp and /healthz, docs mode onlyThe HTTP transport refuses to start when any tenant variable is set. Behind a reverse proxy, set
AIOTIC_MCP_TRUST_PROXY to the peers whose X-Real-IP and X-Forwarded-For headers may be believed: 1
(loopback), gateway (the container's default gateway), private, CIDR ranges or any.
Variable | Purpose | Default |
| Address the server listens on |
|
| Requests per client address: a burst, then a steady rate |
|
|
| any host |
| Browser origins that may call; a request with any other | none |
| Largest request body, in bytes |
|
| File with addresses and CIDR ranges to refuse | none |
| Usage log, one JSON line per request; | off |
| Days the usage log is kept |
|
| Size limits of the usage log, per day and in total |
|
| MMDB country database for the usage log | none |
npm ci
npm test # builds, then runs the smoke test over stdio and HTTPThis repository is published release by release from the AIOTIC documentation sources, one commit per release, and
each release is published to npm from here by .github/workflows/publish-npm.yml. Pull requests cannot be merged here
directly; please open an issue and we will take the change into the next release.
MIT, see LICENSE.
DELETE /customer/{number}. Requires AIOTIC_MCP_ALLOW_DANGEROUS=true and confirm:true.
Inputs: number (required), confirm.
DELETE /customer-product/{customer_number}/{customer_item_number}. Requires AIOTIC_MCP_ALLOW_DANGEROUS=true and confirm:true.
Inputs: customer_number (required), customer_item_number (required), confirm.
DELETE /product/{item_number}/{language_code}. Requires AIOTIC_MCP_ALLOW_DANGEROUS=true and confirm:true.
Inputs: item_number (required), language_code (required), confirm.
GET /customer/{number}.
Inputs: number (required).
Full contract of one endpoint by operationId (e.g. sendOrderToErp, uploadOrder, upsertCustomer) or "METHOD /path", or a webhook name (erpReceiveOrder, processingCompleted). Schemas are inlined.
Inputs: ref (required).
Real payload samples. Names: erp-receive-request, erp-receive-response-accepted, erp-receive-response-rejected, order-status, upload-response-split, raw-upload-rejection, customer-upsert, product-upsert, customer-product-upsert, sync-events.
Inputs: name (required).
GET /order/group/{email_group_id}.
Inputs: email_group_id (required).
GET /order_status/{request_id} — status, extracted purchase order (result), erp_ref, errors.
Inputs: request_id (required).
Return one guide page as Markdown. Paths look like /receiving/erp-receive-endpoint or /sdk/pipeline. Use list_pages to discover paths.
Inputs: path (required).
GET /product/{item_number}/{language_code}.
Inputs: item_number (required), language_code (required).
One JSON schema from the API components, with $refs inlined. Names: Address, ClassifiedEmail, Customer, CustomerListResponse, CustomerProduct, CustomerProductListResponse, CustomerProductUpsert, CustomerSearchResponse, CustomerUpsert, EmailClassificationResponse, ErpAddress, ErpCustomer, ErpOrderItem, ErpPurchaseOrder, ErpReceiveRequest, ErpReceiveResponse, ErpRecipient, ErpSendResponse, ErpShippingDetails, ErrorResponse, FetchAllEmailsResponse, HTTPValidationError, OrderCustomer, OrderGroup, OrderItem, OrderListResponse, OrderRef, OrderRetryBody, OrderStatus, OrderStatusValue, OrderUploadBody, OrderUploadResponse, ProcessingWebhookRequest, Product, ProductListResponse, ProductUpsert, PurchaseOrder, RawEmailClassifyBody, RawEmailUploadBody, RawUploadRejection, RejectedEmailListResponse, ReprocessResponse, ShippingDetails, ShippingRecipient, Supplier, SystemStatus, ValidationError.
Inputs: name (required).
Status values, which are sendable / landed / terminal, and the transitions between them.
Inputs: no named parameters.
GET /customer-product/list with optional filters.
Inputs: size, item_number, customer_number.
Every public AIOTIC endpoint (method, path, summary, auth) plus the outbound webhooks you implement. Optional tag filter: health, orders, order-status, erp, rejected, customers, products, customer-products, email-watcher, webhooks.
Inputs: tag.
GET /order_status/list — newest first.
Inputs: page, size.
All pages of the guide with section, title and one-line summary, in reading order.
Inputs: no named parameters.
GET /product/list.
Inputs: page, size, language_code.
GET /rejected/list.
Inputs: size, status.
POST /rejected/{request_id}/reprocess. Requires AIOTIC_MCP_ALLOW_WRITES=true.
Inputs: request_id (required).
POST /order/retry/{request_id}. Requires AIOTIC_MCP_ALLOW_WRITES=true.
Inputs: request_id (required).
GET /customer/search/{query} — fuzzy search over your customer records, comparable to how AIOTIC matches order senders.
Inputs: query (required), top_k.
Full-text search over the guide (sections). Returns page, heading, URL and a snippet. Use before answering any AIOTIC integration question.
Inputs: query (required), limit.
POST /erp/send/{request_id} — calls the tenant's ERP receive endpoint. Requires AIOTIC_MCP_ALLOW_DANGEROUS=true and confirm:true.
Inputs: request_id (required), confirm.
GET /healthcheck and /system-status of the configured tenant (no key needed).
Inputs: no named parameters.
POST /order/upload with one text/markdown file built from the given content — for exercising the flow against the mock/test tenant. Requires AIOTIC_MCP_ALLOW_WRITES=true.
Inputs: content (required), filename (required), request_id.
PUT /customer/{number}. Requires AIOTIC_MCP_ALLOW_WRITES=true.
Inputs: data (required), number (required).
PUT /customer-product/{customer_number}/{customer_item_number}. Requires AIOTIC_MCP_ALLOW_WRITES=true.
Inputs: item_number (required), language_code (required), customer_number (required), customer_item_number (required).
PUT /product/{item_number}/{language_code}. Requires AIOTIC_MCP_ALLOW_WRITES=true.
Inputs: description (required), item_number (required), language_code (required), remark.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Scored across 28 tools
Tools are largely distinct: documentation tools (search_guide, get_page, list_pages) vs. contract tools (list_endpoints, get_endpoint, get_schema, get_example) vs. domain operations are clearly separated by resource and action. The only mild overlap is among the order-flow write tools (retry_order, upload_order, send_order_to_erp, reprocess_rejected_email), but their descriptions distinguish them well enough.
The set follows a consistent snake_case verb_noun pattern (list_orders, get_customer, upsert_product, delete_customer, search_customers). The main deviation is tenant_health, which uses a noun_noun form rather than a verb prefix, but everything else is predictable.
At 28 tools this is heavy and sits at the upper edge of what an agent can scan efficiently. The breadth is partly justified by the wide domain (full docs surface plus orders, customers, products, and rejected-email operations), and most tools earn their place, but the count is borderline excessive.
Coverage is strong: full CRUD for customers, products, and customer-products, plus order lifecycle (upload, retry, send, status, group), rejected-email handling, and comprehensive docs/contract tooling. Minor gaps remain (no explicit order deletion, webhook configuration management, or batch operations), but core workflows have no dead ends.
Connect AI to store orders, products and inventory with scoped access and human approvals.
Connect AI to Odoo ERP 14-20: search, create, update and manage records in natural language.
Gives AI agents direct access to your Sanity projects and guidance for working with them
Read, write and run Odoo actions from any AI app, as each user, with approval rules per colleague.
