InnoShop: A Laravel 13 Storefront With MCP Wired Into the Admin

The Gap InnoShop Is Aiming At

Most self-hosted PHP storefronts treat AI as a peripheral: a chat widget on the product page, or a product-description generator in the admin. The model has no structured access to orders, inventory or customers, so it can only talk about the store rather than act inside it. InnoShop's pitch is different. The README describes it as integrating "multiple AI models and native MCP (Model Context Protocol) for intelligent automation", which places the AI layer at the protocol level rather than the widget level. MCP is the interface Anthropic published for exposing tools and resources to language models, and the repository carries mcp and mcp-server as topics, so the intent is that an external model can call store operations through a defined contract. The audience is narrow and identifiable: PHP developers who want a Laravel codebase they can extend, running a storefront they host themselves, in more than one language and currency. The README also states the project is "a culmination of 15 years of continuous industry development", a claim about lineage from a commercial product rather than about this repository's own history. Treat it as marketing context, not as evidence about the code you are about to install.

What The Laravel 13 Base Actually Buys You

The stack is conventional and that is the point. PHP 8.3 or newer, Laravel 13, MySQL 5.7 or 8.0 (SQLite is offered for local try-out), Composer 2.x and Node 18 with npm 9 or newer for asset builds. The required PHP extensions are listed explicitly: bcmath, cURL, dom, fileinfo, libxml, OpenSSL, PDO and simplexml. Nothing here requires a custom runtime or a container orchestration layer. If your team already runs Laravel applications, the operational shape of InnoShop is familiar: an .env file, an application key, a storage directory that needs write permissions, a queue and scheduler you would configure the same way you configure them for any Laravel app. The multi-language and multi-currency support is described as out of the box, and the README's flag strip lists twenty locales spanning Arabic, German, Japanese, Khmer, Thai, Vietnamese and others. That is a breadth claim from the README, not a statement about translation completeness in any given locale. Multi-currency in an e-commerce context usually implies per-currency pricing, rounding rules and exchange-rate handling, and the README does not document how those are modelled, so that is something to inspect in the panel rather than assume.

Three Install Paths And What Each One Skips

The README gives three routes and they are genuinely different in what they demand of the machine. The Composer route is marked recommended: composer create-project innoshop/innoshop, then cd innoshop and php artisan serve. According to the README, that single create-project call installs PHP dependencies, generates the application key, and runs npm install plus npm run build to compile front-end assets. That means Node is required on the build machine even though the running server only needs PHP. The ZIP route exists for hosts without Node: download innoshop-vX.Y.Z.zip from GitHub Releases, unzip it, then run chmod -R 775 storage bootstrap/cache and php artisan serve. The archive ships PHP dependencies and compiled assets pre-packaged, which is the right choice for a shared host or a locked-down server where you cannot run npm. The third route is for contributors: git clone, composer install, npm install, npm run build, cp .env.example .env, php artisan key:generate, php artisan serve. Note that the clone path requires you to copy the environment file and generate the key manually, while create-project does both for you. Whichever route you take, the README states an installation wizard opens in the browser to configure the database and create the admin account. There is no documented CLI installer, so provisioning is interactive unless you script around it.

The Plugin And Theme Boundary Is The Real Architecture

The README's most concrete architectural claim is "highly cohesive, low coupling modular design, making it simple and convenient for rapid plugin development", alongside plugin mechanisms and theme template development. That is the part that determines whether InnoShop is a product you configure or a codebase you inhabit. A storefront that lets you override templates is common. A storefront that defines a plugin contract for business logic is a different commitment, because it means order, payment and fulfilment behaviour can be added without forking core. The README does not enumerate the extension points, the hook names, or whether plugins are Composer packages, service providers, or something else. That absence matters. Before you plan custom work, you need to read the plugin documentation at docs.innoshop.cn and confirm which lifecycle events are exposed. If the hooks are thin, you will be patching core files, and every upgrade becomes a merge. The same caution applies to the MCP server. The repository topics include mcp-server, and the README states native MCP support, but it does not list which tools the server exposes or how authentication between a model client and the store is handled. Those are the two questions I would answer before writing any code.

Where The Documentation Stops Short

The README links to a documentation site and two API endpoints, front-api.innoshop.cn and panel-api.innoshop.cn, which suggests separate front and admin APIs rather than one unified surface. It does not describe the API's authentication scheme, versioning policy or rate limiting. For a headless build, that is the first thing you would need. There is also a demo instance with published credentials: frontend at demo.innoshop.cn, backend at demo.innoshop.cn/panel, account admin@innoshop.com, password 123456. Published demo credentials are useful for evaluation and are also a reminder that the demo is not a hardened environment; do not put anything real in it. What the README does not give you is any statement about test coverage, upgrade guarantees between minor versions, or a migration policy. With releases at v0.8.2, v0.9.0 and v0.9.2 across roughly three months, the cadence is active, and a 0.x version number is an honest signal that the maintainers are not yet promising API stability. Plan for that: read the release notes before each bump rather than assuming a drop-in upgrade.

The Licence Field Says NOASSERTION

This is the item I would resolve before anything else. The repository metadata reports the licence as NOASSERTION, which is GitHub's label for a licence file it could not match to a known template. At the same time, the README carries a badge reading "License OSL 3.0". Those two signals disagree, and the disagreement has practical consequences. OSL 3.0, the Open Software License, is a copyleft licence with a notably broad reciprocity clause: distributing modified versions generally carries obligations to make the corresponding source available under the same terms, and the licence text also addresses network use in ways that differ from permissive licences. If the badge is accurate, a business that modifies InnoShop and distributes it, or in some readings operates a modified version as a service, may face obligations that MIT or Apache-2.0 would not impose. I am not giving legal advice, and I cannot resolve the discrepancy from the material available. The action is simple: open the actual licence file in the repository and read it, then have whoever handles licensing at your organisation confirm it against your distribution model. Do not rely on the badge alone, and do not rely on the NOASSERTION label alone.

InnoShop Against A Conventional Storefront

The README positions InnoShop against WooCommerce and Shopify in its topic tags, so the comparison is invited. WooCommerce is a WordPress plugin: your storefront's data model, admin UI, extension ecosystem and hosting story all come from WordPress, which means a vast plugin market and a CMS-first mental model where products are a post type. InnoShop is a standalone Laravel application, so the data model is the application's own and extension happens through its plugin and theme system rather than through WordPress hooks and filters. That is the actual difference in approach: a plugin inside a CMS versus an application with its own extension contract. The trade-off runs both ways. WooCommerce inherits WordPress's enormous third-party surface and its security patch cadence, which is a benefit and a liability depending on how you manage updates. InnoShop gives you a cleaner Laravel codebase and a much smaller ecosystem, so anything non-standard in your business is your code to write. If your requirements are ordinary retail and you want the widest pool of ready-made extensions, the WordPress route is better supported. If your requirements include a custom operational model and you would rather write Laravel than fight a CMS, InnoShop's shape is more direct.

Maintenance Cost And Who Should Wait

Running InnoShop means running a Laravel application, and that is the honest framing of the maintenance bill. You own PHP version upgrades, Composer dependency updates, the Node build pipeline if you use the Composer or clone install paths, database backups and the queue and scheduler processes. The ZIP install path removes Node from the server entirely, which is a real reduction in surface area for teams without front-end tooling. Upgrades between InnoShop releases are the part I would watch. The project moved from v0.8.2 to v0.9.0 to v0.9.2 in about three months, and the README documents no upgrade procedure and no backward-compatibility promise. A team that customises core files instead of using the plugin system will pay for it at every bump. The teams that should adopt InnoShop now are those running a self-hosted Laravel shop with a genuine multi-region requirement and an appetite to read the source, or those specifically wanting to experiment with MCP-driven store automation and willing to work against an interface that is not yet documented in the README. Teams that should wait: anyone needing a certified payment integration matrix, anyone who cannot absorb a breaking change on a 0.x upgrade, and anyone whose legal review cannot clear an OSL 3.0 copyleft obligation. Start by opening the licence file, then the plugin documentation, then the MCP tool list. If all three are clear, the install is a single composer create-project away.

Editorial conclusion

Adopt InnoShop if you are a PHP team already comfortable with Laravel and you need a self-hosted storefront where the panel speaks to an MCP server rather than a bolted-on chatbot widget. Do not adopt it if you need a stable 1.x API surface, because the release line is still at v0.9.2 and the licence file is not machine-classified. Before committing, verify three things: the actual licence text in the repository, whether the MCP server exposes the specific store operations you intend to automate, and whether the plugin hooks cover your checkout and tax rules without patching core.

Official sources

1. innocommerce/innoshop on GitHub
2. Issues
3. Project website
4. README
5. Releases