MCP and a living knowledge base for Ozon digital goods
Ozon MCP
An MCP server for one Ozon seller cabinet with a knowledge base on the digital-goods lifecycle: card, stock, order, activation code and delivery
- 0 ★ on the repository
- Last commit
Broad access
Why this level
- It has confirmed changing digital-item stock in a real seller cabinet via an API write
- The documentation states intent to carry write access through the full order-shipment-code cycle
A similar tool with a larger community: Ozon MCP Server for buyer-side search, 88 ★ on the repository
Install
- Works in
- Services
Manual install
Deploy your own server instance with your Ozon Seller and Performance keys in environment variables, never commit them to git, and follow the discover-read-validate-write-verify-document cycle before any write operation.
Access and checks
How we reviewBroad accessThe tool can change data, run commands or handle secrets.
- It has confirmed changing digital-item stock in a real seller cabinet via an API write
- The documentation states intent to carry write access through the full order-shipment-code cycle
This is third-party code. Review the repository files before installing.
What it does
The project is both a working MCP server wired to one specific kvantexpert.ru seller cabinet, and a documented knowledge base in docs/ on how Ozon digital goods work: card lifecycle, characteristics and dictionaries, an API operation map, and the digital-delivery mechanics. Every new operation follows a discover-read-validate-write-verify-document cycle rather than a guess: on a reference card it has been confirmed that a digital item's stock actually flips from 0 to 1 through the MCP, and this is independently verified with a direct call to the Ozon API. The full order-shipment-code-delivery chain has not yet been proven on a real shipment and is honestly marked unverified in the docs.
Who it is for. For developers studying how publishing and delivering Ozon digital goods actually works through an MCP, including documented failed attempts.
Good fit when
- You need an example of a genuinely verified, not theoretical, path for creating an Ozon digital good
- You are interested in the discover-read-validate-write-verify-document methodology for risky API operations
- You want to deploy a similar server for your own seller cabinet
Not a fit when
- You are looking for a ready multi-tenant service: the public endpoint runs on the author's own account and cabinet, not yours
- You need a finished code-delivery-to-buyer chain: it isn't proven in practice yet
- You have no Ozon Seller and Performance keys of your own to deploy this for yourself
Example request
Check how the digital-good lifecycle in Ozon currently works per the project's documentationMCP
- Transport
- http
- Authentication
- API key
Limitations
The public MCP endpoint at kvantexpert.ru runs on the author's own account and credentials: it is not a multi-tenant service, but a personal working instance documented for continued development. Only the card-to-stock chain is confirmed, the full code delivery to a buyer (order-shipment-code-delivery) has not been proven on a real shipment. The README explicitly requires never publishing Client-Id, Api-Key, cookies, tokens or real digital codes to the repository.
How to disable. Disconnect the ozon-mcp.kvantexpert.ru server from your MCP client, or stop your own deployed instance.
FAQ
Can I connect to the public endpoint and use it for my own store?
No, the public https://ozon-mcp.kvantexpert.ru/mcp runs on the project author's own cabinet and keys, it does not accept your own credentials.
Is full digital code delivery to a buyer confirmed?
No, only the card-to-stock chain is confirmed, the full cycle through code delivery is honestly marked unverified in the docs.
How is this Ozon MCP different from other Ozon servers?
The project is both a working MCP server for one Ozon seller account and a documented knowledge base in docs/ on the lifecycle of digital goods: card, stock, order, activation code and delivery. It targets a narrow case and does not fit as a general server for any store.
Can I connect to the public endpoint and is digital code delivery confirmed?
The server is attached to a specific seller account, so for your own store deploy your own instance. Full code delivery to the buyer was not verified everywhere, the scenario status is described in the repository knowledge base. Risk is high.
Discussion
No questions or reviews yet.
Related
All Ozon toolsOzon buyer account MCP
Ozon MCP
An MCP server for one ozon.ru buyer account: orders, cart, favorites, selections, and, when explicitly allowed, placing and paying for an order
An MCP server with 9 read-only tools over the Ozon Seller API v3: products, FBS and FBO orders, analytics, finance and returns
An MCP server for the Ozon Seller API with a catalog of 441 methods, read and write access classes, and keys stored outside the repository
Ozon MCP
ozon-mcp
MCP server for Ozon Seller API and Performance API: method search, calls guarded against accidental writes and ready analytics workflows
Ozon Seller MCP server
mcp-ozon-seller
MCP server for Ozon Seller API: products, prices, stocks, FBO and FBS orders, seller analytics and finances
Ozon MCP Server for buyer-side search
Ozon MCP Server
Buyer-side Ozon MCP server: product search, product pages with prices and stock, customer reviews
Comparison with similar tools
Cards that share the main search query, and how they differ.
| Tool | Official | Authentication | Repository stars | Main difference |
|---|---|---|---|---|
| MCP and a living knowledge base for Ozon digital goods (this card) | no | API key | 0 | |
| Ozon MCP | no | API key | 26 | Seller and Performance API for agents |
| Ozon buyer account MCP | no | not required | 9 | orders and cart |
README in short
The README describes the project as working documentation meant to be resumed a month or a year later with an AI assistant, gives the public MCP endpoint, a list of secrets never to publish, a reference digital-good card with confirmed and unconfirmed steps, the discover-read-validate-write-verify-document methodology, and a requirement to log both successful and negative test results in docs/.