Repository navigation
Releases
O'So MCP Server 1.4.0
Added
Private documents handed over safely. When the assistant gives you a private document, it hands over a link that opens in your own back office, signed in - never the file itself in the conversation. The link works only for the employee it was asked for, and only for fifteen minutes, after which you ask again. This adds a hidden back office page to the module, so a shop upgrading in place gains it on upgrade.
Order currency changed. The new tool somcp_set_order_currency changes the currency of an order that is not validated yet, as Change currency in the Payment block of the order page does: every amount of the order, its lines, its shipping and its invoices is converted at the shop's exchange rates of today, and the answer gives the totals before and after. A validated order is refused, as the back office refuses it, and asking for the currency the order already has changes nothing.
A note on an invoice. The new tool somcp_set_invoice_note sets the note printed on one invoice of an order, as Add note / Edit note on an invoice line of the Documents tab of the order page does. It is the note the customer reads on the invoice PDF, not the order's private note the shop keeps to itself; an empty note clears it. somcp_get_order now shows the note of each invoice, so the change can be read back.
Order product line edited. The new tool somcp_update_order_product changes the unit price, the quantity or the invoice of one product line of an order not delivered, as the Edit action of a line in the Products block of the order page does, and recomputes the totals. Only the fields given are changed; a quantity of 0 is refused and points to removing the line, and the assistant is told to say the new total before the change. On PrestaShop 9.2 and later, which edit the line together with its shipments, the tool refuses and points to the Edit action of the order page.
Order product line removed. The new tool somcp_delete_order_product takes one product line off an order not delivered, as the Delete action of a line in the Products block of the order page does, and recomputes the totals. Nothing is refunded and no credit slip is made: the assistant is told to say what the customer owes afterwards and to wait for your go-ahead. The last line of an order is refused, since an order left without a product cannot be put right; cancel the order instead. On PrestaShop 9.2 and later the tool refuses and points to the order page, like the other order line tools. The tools that add, edit and cancel order lines now point to one another when the request belongs to another of them.
Order address changed. The new tool somcp_set_order_address points the delivery or the invoice address of an order to another address of the same customer, as Select another address of the order page does. PrestaShop recomputes the taxes and the totals - a new country can change the tax - and the assistant is told to say the new total before the change. An address that is not the customer's is refused with the list of the ones that are.
Order carrier changed. The new tool somcp_set_order_carrier changes the carrier of a shipment of an order, as the Carrier field of the Edit shipping details window of the order page does. PrestaShop recomputes the shipping cost and the totals, and the assistant is told to say the new total before the change. Only the carriers the order may use are taken: any other is refused with the list of the ones that are. The tracking number is left as it is and no email is sent. somcp_get_order now gives the id_carrier of each shipment, so the assistant can tell whether a carrier is already in place.
Order status email resent. The new tool somcp_resend_order_status_email sends again the email of one past status of an order, as Resend email on a line of the Status tab of the order page does. The status line is taken from the order history, and the status is read from it; a status the shop does not email is refused rather than reported as sent. Every call emails the customer and the order records nothing, so the assistant is told to send it once.
Order discounts. The new tool somcp_add_order_discount adds a discount to an order, as the Add a discount button of the order page does: a percentage, an amount including taxes, or free shipping, on the whole order or on one of its invoices. The order totals follow, and the assistant is told to say the new total before adding it.
Order discounts removed. The new tool somcp_delete_order_discount removes a discount from an order, as the delete action of the discounts table of the order page does. The order totals follow, a free gift product given by the discount loses its unit, and the assistant is told to say the new total before removing it. A discount already removed is reported as such, and nothing changes.
Invoices generated. The new tool somcp_generate_order_invoice generates the invoice of an order that has none yet, as the Generate invoice button of the order page does: the invoice takes the shop's next number, and nothing is emailed. An order that already has one gets it back instead of a second invoice, and a shop with invoices turned off is told where to turn them on.
Cancelled products. The new tool somcp_cancel_order_products takes products off an order that is not paid yet, as the Cancel products button of the order page does: the chosen quantities are removed, the order total and the stock follow, and when no product is left the order goes to Canceled and the customer is emailed. A paid or delivered order, or a shop with merchandise returns off, is refused with the tool to use instead.
Products added to an order. The new tool somcp_add_order_product adds a product, or one of its combinations, to an order that is not shipped yet, as Add a product in the Products block of the order page does: the order total is recomputed, and on an invoiced order the line goes to the invoice you name or to a new one, with free shipping when asked. Left out, the price is the product's price for that customer. A shipped order, a product already in the order or a quantity the stock cannot cover is refused with the reason. On PrestaShop 9.2 and later, which add the product together with its shipments, the tool refuses and points to the button of the order page.
Returned products. The new tool somcp_return_order_products records the products a customer sent back on a delivered order and refunds them, as the Return products button of the order page does: the chosen quantities are counted as returned, go back in stock only when you say so, the shipping is refunded when asked, with a credit slip, a voucher or both. When merchandise returns are off or the order is not delivered yet, the refusal says which tool to use instead.
Standard refunds. The new tool somcp_issue_standard_refund pays back whole lines of a paid order that is not delivered yet, as the Standard refund button of the order page does: the chosen quantities go back in stock, the shipping is refunded when asked, with a credit slip, a voucher or both. When merchandise returns are off or the order is already delivered, the refusal says which tool to use instead.
Partial refunds. The new tool somcp_issue_partial_refund pays back part of a paid order, as the Partial refund button of the order page does: some units of a line, part of a line's price, part of the shipping, with a credit slip, a voucher or both. Each amount is given in the tax mode the order page shows, a line that is not one of the order's or an amount above what is left is refused instead of being lowered, and the answer gives the credit slip and the voucher created.
Create a catalogue price rule. The new tool somcp_create_catalog_price_rule creates one rule of Catalog > Discounts > Catalog Price Rules, with everything the form holds: name, currency, country, customer group, from quantity, a fixed price or the products' own, the reduction as an amount or a percentage, tax included or not, the period, and the condition groups that pick its products. The rule is applied at once, and the answer says how many products it reaches. A percentage is given as the same fraction the product tools use, and the price and reduction are checked exactly as for a product's own specific prices.
List the catalogue price rules. The new tool somcp_list_catalog_price_rules reads the rules of Catalog > Discounts > Catalog Price Rules - the discounts applied to products before the cart - as the list shows them: name, currency, country, customer group, from quantity, reduction and period, with the conditions that pick each rule's products. It filters by currency, country, group, reduction type, and by the rules in force right now, and reads a percentage as the same fraction the product tools report. Read only.
Change a voucher or a cart discount. The new tool somcp_update_cart_rule changes one rule of Catalog > Discounts > Cart Rules with everything somcp_create_cart_rule can write: the name in the languages given, the code, the dates, the quantities, the minimum amount, free shipping, the discount and what it applies to, and the gift. Only what is given changes, and the answer lists each change with its old and new value; a call that would change nothing writes nothing. It refuses what the back office refuses, checked on the rule as it will be, so a start date after the end date kept is refused. The rule's countries, carriers, groups, compatible rules, product selection and shops are left exactly as they were, and switching it on or off is left to the tool below.
Switch a voucher or a cart discount on or off. The new tool somcp_set_cart_rule_active is the Status switch of the list Catalog > Discounts > Cart Rules: it switches one rule on or off and change...
O'So MCP Server 1.3.1
Added
Install with Composer on PrestaShop 9. Agencies and automated deployments can now install the module with composer require novalo/prestashop-mcp-server from the shop's root folder: it lands in modules/somcp, exactly where the zip puts it, so a shop can move from one way to the other. The zip from the back office stays the usual way to install it, and the only one on PrestaShop 8, whose own packages refuse the PHP version the module needs.
Changed
The Assistant button stands out in the header. It used to be a grey link like View my shop beside it. It is now a soft orange button in the module's colours, which turns solid orange while the chat is open, so you see at a glance whether it is. The round button shown on pages without a header follows the same colours.
More room in the enlarged chat. Enlarged, the chat now shows the list of conversations open in a column beside it, and the panel grows by that column instead of the messages losing room; picking a conversation leaves the list open. Messages and the field to type in keep a margin on both sides, so lines stay easy to read. The tokens used are shown once, at the foot of that list, and "Powered by Neuron AI" is centred. On a screen too narrow for both, the list still slides over the chat as before.
Fixed
The PrestaShop Addons validator can check the module again. Its compatibility step stopped with an error on 1.3.0. The sign-in and consent pages used a way of writing PHP that only PHP 8.1 understands, which the validator's checks may not read; they are written the older way, and work exactly as before.
A lighter zip, without the libraries' own housekeeping. The libraries the module ships came with files their authors use for their own repository - code style and editor settings, test and CI configuration - and the Composer plugin used only by a Composer install. They are left out of the zip, which holds no hidden file besides the module's own .htaccess.
Install: download OSo-MCP-Server-1.3.1.zip and install it from Modules > Upload a module.
O'So MCP Server 1.3.0
Your assistants have to be connected again after this update. Every connection made so far was approved on a page that asked for a password alone, and none of them is kept. To connect an assistant again: turn on Consent page in the Access and security tab of the module, connect the assistant from Claude, ChatGPT or wherever you use it, then turn the page off again. The diagnostic shows when the page is off, with a link to the switch.
Added
A user guide in PDF. readme_en.pdf, attached to each release: requirements, installation, each settings tab, connecting an assistant step by step and the built-in assistant, with the path of every button and switch.
Create a voucher or a cart discount. The new tool somcp_create_cart_rule creates one rule of Catalog > Discounts > Cart Rules, with the fields of the Information, Conditions and Actions tabs: the name in each language, the code (or none, for a discount applied on its own), the validity dates, a single customer, the minimum amount, the quantities, free shipping, a percent or an amount off the order, a product, the cheapest product or the selected products, and a free gift. It refuses what the back office refuses, a code already used or a rule that gives nothing among them, and a gift with required customization fields on PrestaShop 8 as on 9. As on screen, a discount on one product limits the rule to carts that hold it, and the rules that restrict their compatibility accept the new one. The rule is created switched off unless asked otherwise, so the merchant reads it before customers can use it; restrictions stay in the back office. It joins the Boost sales prompt, needs the add right on Cart Rules and the new Sales - changes access.
Read one cart rule in full. The new tool somcp_get_cart_rule gives every field of a rule as the three tabs Information, Conditions and Actions of Catalog > Discounts > Cart Rules > Edit show it: the name in each language, the code, the validity dates, the minimum amount with its currency, tax and shipping, the quantities, each restriction (countries, carriers, customer groups, other cart rules, product selection, stores) with the names of what it is limited to, and what the rule gives, in the same words as the list. Read only, the current shop's rules only. It joins the Boost sales prompt and needs the view right on Cart Rules.
List the shop's vouchers and cart discounts. The new tool somcp_list_cart_rules lists the cart rules of Catalog > Discounts > Cart Rules, newest first, telling vouchers with a code from discounts applied on their own, with what each one gives in one line: the discount, free shipping, a free gift, how many uses are left, whether it has conditions to read, and the number of orders that already used it. Read only, the current shop's rules only. It joins the Boost sales prompt and needs the view right on Cart Rules.
Find the stock that never sells. The new tool somcp_list_unsold_products lists the active products of the shop that no valid order bought, as Products never purchased on Stats > Catalog statistics, with what the screen does not show: the quantity for sale, the cost price and what that stock is worth, the costliest first, and the date each product last sold. With no period it counts every order ever, as the screen; with one, the products not bought in it. It reads the orders of the current shop only, joins the Boost sales prompt and needs the view right on Stats.
Spot the products that are looked at but not bought. The new tool somcp_list_viewed_not_sold lists the products of the shop with their page views and what they sold over a period, most viewed first, as Stats > Product details shows one product at a time: Total Viewed, Total bought and the conversion rate side by side, so the products that draw interest and miss the sale stand out. Page views are counted only when Save global page views is on in the Data mining for statistics module; when it is off the answer says so rather than reading as nobody looked. It joins the Boost sales prompt and needs the view right on Stats.
See what visitors search for on the shop. The new tool somcp_list_search_terms lists what visitors typed in the shop's search box over a period, as Stats > Shop search: for each term, how many times it was searched and the most products it found. As on that page, only the terms searched more than once are listed unless asked otherwise, and it can keep only the searches that found nothing - what visitors looked for and the catalogue does not have. When the Shop search module is not active the answer says so, instead of an empty list that would read as nobody searched. It joins the Boost sales prompt and needs the view right on Stats.
Write an llms.txt for the shop. The tool somcp_generate_llms_txt writes an llms.txt at the root of the shop, the plain text summary some AI tools read at the root of a site, from the shop's own data: its name, a summary written with the merchant, the main categories, the policy and information pages and the contact page, in the language asked for. A file the merchant wrote by hand is replaced only when asked, and a shop whose root is not writable is told so without anything being changed.
See the carts that never became an order. The new tool somcp_list_abandoned_carts lists the carts that hold products and were left without an order, newest first, with the same rule as the Abandoned cart rows of Orders > Shopping Carts: no order, created more than 24 hours ago. For each cart it gives the customer's name, whether the visitor is still on the shop, the carrier, the products total tax excluded and included, and the three most expensive products left in it, plus the total value of every matching cart per currency. It can be narrowed to a period, to the carts of customer accounts or without one, to a customer's name or to the visitors online. Nothing is sent to anyone, no email, phone or address is given, and the Share this cart link never leaves the shop. It opens the Boost sales prompt and needs the new permission mcp.sales.read, which the consent screen describes as reading abandoned carts, searches, product views and promotions, and the view right on Orders > Shopping Carts.
The diagnostic checks the sign-in page. A new line, Sign-in page, opens the page where you approve an assistant, as your browser would, and turns red when something else answers in its place - typically another module that sends visitors without an account to a login, an age check or a country page. Left unnoticed, the assistant would wait on a page you never see.
Changed
Shorter audit and sales tools. Four tools that went a little over the length agreed for a tool description - the CMS pages SEO audit, the product completeness audit for answer engines, the llms.txt generator and the list of products viewed but not sold - now describe themselves in a few sentences, lighter for the assistant on every step. What matters is kept: the names of every check and figure, that a hand-written llms.txt is replaced only once you agree, that it is never retried blindly, and which tool to use instead.
A recorded payment now names who took it. The answer of somcp_add_order_payment, and each payment of somcp_get_order, now report the employee who recorded the payment on PrestaShop 9, as the Employee column of the Payment block shows it (nothing on PrestaShop 8, which has no such column). The payment method is best given as the name of the shop's payment module, so the Payment table and the order read the same method.
Shorter attribute tools. The seven tools of Catalog > Attributes & Features > Attributes - list, read, create and change the attribute groups and their values - now describe themselves in a few sentences, lighter for the assistant on every step. What matters is kept: that a group or a value is taken from the list and never guessed, that each field says whether you or the assistant fill it, that a new name, public name, type or colour shows on every product page or combination using it and is confirmed with you first, that a value used by a combination cannot move to another group, and which read checks a change.
Fixed
robots.txt is no longer rewritten on a shop in demo mode. The tool somcp_generate_robots_txt now refuses, with nothing changed, on a shop that runs in demo mode, as the Generate robots.txt file button of Shop Parameters > Traffic & SEO does.
The zip passes the PrestaShop Addons validator again. A folder added in this version had no index.php, and the anti-robot widget's script had no licence header at its top. Both are in place.
Security
A page to approve assistants that only opens when you open it. The page where an employee signs in and approves a new assistant is now off unless you turn on Consent page in Access and security, and while it is off every link to it is the shop's ordinary "page not found" - including one somebody sends you to have you approve their own assistant. Turn it on for the minutes you connect one: the assistants already connected keep working with it off.
A code by e-mail after the password. Once the password is accepted, the page asks for a 6-digit code e-mailed to that employee. A code works once and for ten minutes, a new one can be asked for after 30 seconds and a third after 45 more, and there is no fourth: once the third is mistyped five times or expires, the connection is closed and has to be started again from the assistant. A stolen password alone no longer connects anything, and an employee who receives a code they did not ask for knows their password is out.
Only the assistants you allow can be connected. The list of allowed return addresses (**Access and secu...
O'So MCP Server 1.2.2
Added
Switch off a whole group of tools at once. On Tools and prompts, the tools are now grouped by the permission an assistant is given for them - Orders - read, Orders - changes, Catalog - read and so on - and each group has its own two switches, one for the assistants connected over MCP and one for the built-in assistant. A group switched off holds back every tool in it, including the ones a later update adds to it, and every prompt that needs it; the assistants are no longer offered that permission when they connect. Switching the group back on gives each tool the switch it had. The built-in assistant can read and change these group switches too, after your approval.
See which products are ready for AI assistants. The new tool somcp_audit_product_entities scores each product of your catalogue on the data an answer engine needs to describe it - brand, barcode, manufacturer reference, features, a long enough description, a summary, images with captions, weight, condition, a real category and a meta description - and lists the least complete products first, naming for each one what is missing under the label of its product page. It reads one language and changes nothing; fill the gaps with the catalogue tools.
Check whether AI crawlers can read your shop. The new tool somcp_check_ai_crawler_access tells you, for each of the main AI crawlers (GPTBot, ClaudeBot, PerplexityBot, Google-Extended, Bingbot and more), whether your robots.txt lets it fetch your home page, a product page and a category page, with the exact rule that decides it, and whether those pages ask it not to index them. It reads your robots.txt and your pages and changes nothing; whether to open your shop to a crawler stays your choice, and the tool for writing the robots.txt is somcp_generate_robots_txt.
Check the pages buyers look for before they trust your shop. The new tool somcp_audit_store_policies looks for your legal notice, terms and conditions, shipping, returns, privacy, about us and contact pages, and says for each one whether it was found and how, whether it is Displayed, whether Indexation by search engines is on, how many words it has and whether your home page links to it. It also reports the settings these pages go with: the terms to accept at checkout, returns and their time limit, and the delivery time texts of your products. When several pages could be the same one, it lists them so you choose. It changes nothing, and what these pages say stays your responsibility.
Read your shop's llms.txt. The new tool somcp_get_llms_txt shows the llms.txt at the root of your shop, the plain text summary some AI tools look for, with its size, its last change and the address where it is asked for, and says whether it was written by O'So MCP Server. It warns when there is none, when your shop sits in a folder, when the file is too large, or when it does not start with a title line. llms.txt is a proposed convention, not a standard: no AI tool is bound to read it. The tool changes nothing.
Changed
The SEO settings read now cover the rest of the SEO and URLs page. The tool that reads the shop's SEO and URL settings now also reports the two Apache options (MultiViews and mod_security), the option that puts the attributes in the product meta title, the address pattern of the module pages, and, for each language, whether its addresses carry the ISO code - including, on PrestaShop 9, the option that keeps the default language without a prefix. Reading the settings still changes nothing, and an unexpected field is now refused instead of ignored.
The Tools and prompts lists are folded by group. Each group shows how many of its tools or prompts are on in each column, and opens with a click; the search opens the groups it finds something in. The Asks for and Requires columns are gone, to keep the lists readable: the back office right each tool needs is listed in the tools table of the project page, and a prompt held back by a group switched off says so on its row.
The project page is written for merchants. The front page of the repository now says what you can ask, the requirements, how to install the module in three steps from the release zip, which assistants work with it and how your shop stays protected, with the tools folded by back office page. The technical details and the installation from the sources moved to the contributing guide.
The category SEO audit judges a page like the product audit. The category SEO audit now looks at displayed categories only by default, with an option to include hidden ones, lets you limit it to the checks you want, and flags a meta description that is too short, so the same page gets the same verdict whether you audit it as a product or as a category.
The CMS page audit names the title and the meta title as the page form does. Each page in the CMS SEO audit now carries its page title, its meta title and the title search engines read under the same names the other page tools use, so an assistant fixing a field passes it back correctly instead of writing the page heading into the meta title. The audit also flags a meta description that is too short, as the other SEO audits do.
Any CMS page can have its SEO changed, not only those the audit flags. The tool that changes the meta title, meta description, friendly URL and indexation of a CMS page used to send the assistant to the CMS SEO audit to find the page, and the audit only lists the pages with a problem: asked to change a page with nothing wrong, the assistant could not find it. It now takes the page from the list of every CMS page and reads it before and after the change; the audit stays the way to find what needs fixing.
The brand audit checks the length of the meta title and meta description. The brand SEO audit now flags a meta title over 60 characters, which search results cut, and a meta description under 70 or over 160 characters, with the same limits as the product, category and page audits, so a brand is judged by the same rules as the rest of the shop.
Shorter feature tools. The seven tools of Catalog > Attributes & Features > Features - list, read, create and change the features and their values - now describe themselves in a few sentences, lighter for the assistant on every step. What matters is kept: that a feature or a value is taken from the list and never guessed, that each field says whether you or the assistant fill it, that renaming a feature or a value changes it on every product that carries it and is confirmed with you first, that a value typed on one product only is changed on that product, and which read checks a change.
Install: download OSo-MCP-Server-1.2.2.zip and install it from Modules > Upload a module.
O'So MCP Server 1.2.1
Added
A security and compatibility report with every release. Each version is now published only after the full test suite has passed on the exact code in the zip, and the release page carries a report of what was checked: every PrestaShop and PHP combination the module was installed and run on, each attack tried against a live shop and refused, the permissions of every tool, the code and dependency scans, and the SHA-256 of the zip, so you can check that the file you downloaded is the one that was tested. The report sits next to the zip on the release page, not inside the module.
Listing the customer groups. The new tool somcp_list_customer_groups lists the customer groups of the shop as Shop Parameters > Customer Settings > Groups shows them: name, discount, price display method, whether prices are shown, number of members and creation date, plus the groups used by default for visitors, guests and registered customers. The assistant now takes the group of a customer, of a category or of a specific price from this list instead of guessing it. It needs the view right on the Groups page and is part of the Find a customer and Manage products prompts.
Checking the shop's links. The new tool somcp_check_links walks the public pages of your shop from a starting page, as a visitor sees them, and lists the links that lead to an error page with the pages that contain them, the addresses that go through several redirects and the pages that take more than 2 seconds to arrive. Only your shop's own addresses are opened, at most 200 pages and one minute per check; links to other sites are counted, never followed. It needs the view right on Shop Parameters > Traffic & SEO and is part of the Audit and improve SEO prompt.
Checking the sitemap. The new tool somcp_audit_sitemap reads the sitemaps the Google sitemap module generated for your shop and tells you how many addresses each one holds, when it was last generated, which pages are left out on the module's screen and whether your robots.txt points search engines to it. It lists the active products missing from the sitemap and the disabled products still in it, and opens a sample of its addresses as a visitor to find those that answer an error. Only your shop's own addresses are opened, and the sitemap is never generated by the tool. It needs the view right on Shop Parameters > Traffic & SEO and is part of the Audit and improve SEO prompt.
Checking what a product page tells search and answer engines. The new tool somcp_audit_product_schema opens the public page of a product, or of one of its combinations, as a visitor sees it, and compares the structured data the theme prints there with the product page of your back office: name, brand, reference, MPN, barcodes, condition, price with tax, currency and stock. It lists each difference with the label of the field in your back office, and what your shop holds that the page does not print. When the theme prints no structured data at all, it says so: that comes from the theme, not from your products. Only your shop's own addresses are opened, and nothing is changed. It needs the view right on Catalog > Products and is part of the new Get recommended by AI assistants prompt, which guides the assistant through these checks and never promises that an assistant will cite your shop.
Changed
Each tool and prompt can be switched for the connected assistants and for the built-in assistant apart. On the Tools and prompts tab, the box in front of each tool and prompt is replaced by two switches on the right: one for the assistants connected over MCP, such as Claude or ChatGPT, and one for the assistant built into your back office. You can keep a tool for the built-in assistant, which asks before every change, and hide it from the assistants that connect from outside, or the other way round. Each list also has a search field, which finds a tool or a prompt by its name, its title, its publisher or the permission it needs. Nothing changes when you update: a tool or prompt you had switched off stays off in both columns, and the built-in assistant can switch either column when you ask it to.
The server address shows the shop's "page not found" in a browser. The address you give to an assistant used to answer a browser with a blank error page. It now shows the shop's usual page not found, like any other address that leads nowhere for a visitor. Assistants are not affected: they keep being answered as before.
Catalogue tools point plainly to the tool to use next. Seven category, feature and attribute tools still told the assistant to use a tool to read or add a value "when the shop offers it", although every one of those tools is there. The assistant could take it as a tool that may be missing and skip the step. They now name the tool plainly.
Shorter customer tools. The four tools of Customers > Customers - search, read, create and change a customer - and the list of customer groups now describe themselves in a few sentences, lighter for the assistant on every step. What matters is kept: which tool gives the customer and the group identifiers, that every value comes from you and is never invented, that no password goes through the conversation and no email is sent to the customer, and which read checks a change.
Shorter supplier tools. The five tools of Catalog > Brands & Suppliers > Suppliers - list, read, create, change, enable or disable a supplier - now describe themselves in a few sentences, lighter for the assistant on every step. What matters is kept: that the supplier identifier comes from the list and is never guessed, that a supplier name can exist twice so the list is read before a creation, who fills each field, that disabling is not a deletion, and which read checks a change.
Shorter brand tools. The six tools of Catalog > Brands & Suppliers > Brands - list, read, create, change, enable or disable a brand, and the SEO audit of brands - now describe themselves in a few sentences, lighter for the assistant on every step. What matters is kept: that the brand identifier comes from the list and is never guessed, that a brand name can exist twice so the list is read before a creation, who fills each field, that disabling a brand keeps its products on sale, and which read checks a change.
Shorter brand address tools. The five tools of the Brand addresses list of Catalog > Brands & Suppliers > Brands - list, read, add, change and delete an address - now describe themselves in a few sentences, lighter for the assistant on every step. What matters is kept: that the brand and the address identifiers come from the lists and are never guessed, that the same address can be added twice so the list is read first, that every field comes from you and is never invented, that customer and supplier addresses are refused, and which read checks a change.
Shorter theme, cache, tax, carrier and file tools. The two tools of Design > Theme & Logo - read the theme and change the layout of a page - and the lists of tax rules, carriers and Catalog > Files, with the Clear cache button of Advanced Parameters > Performance, now describe themselves in a few sentences, lighter for the assistant on every step. What matters is kept: that a page, a layout, a tax rule, a carrier or a file is taken from its list and never guessed, that a layout is confirmed with you before it changes, that clearing the cache clears it for every shop of the installation and slows the next pages, that a file's download link is public and stays with you, and which read checks a change.
Fixed
Inactive products that follow the shop's default behaviour are judged correctly. On PrestaShop 9, an inactive product left on the shop default in somcp_audit_product_seo was always reported as having no redirection, even when Shop Parameters > Product Settings > Default behavior for disabled products keeps its page shown with a 200 response. The audit now reads that setting: such a product is no longer reported, and when it is, the entry names both the product's choice and what the shop default applies, so you know which setting to change. Nothing changes on PrestaShop 8.
The module passes the PrestaShop Addons validator again. The check somcp_update_theme_setting makes before changing the theme, which refuses to change it on a shop in demo mode, was reported by the validator as a condition that can never be true. It now reads the shop's demo mode the way the other tools read the core's settings, and behaves as before.
The faceted search fields of attributes and features follow the module's state. With the faceted search module installed but disabled, the back office form no longer shows the URL and Meta title fields, yet somcp_get_attribute_group, somcp_get_attribute_value, somcp_get_feature and somcp_get_feature_value still returned them as empty texts, which the update tools then refused. They now return them as null whenever the module is not installed and enabled, as the create and update tools already did.
Attribute values with ; or # in their name are refused on PrestaShop 9. On PrestaShop 9, somcp_create_attribute_value and somcp_update_attribute_value accepted a name holding ; or #, which the back office form of an attribute value refuses there: the value was saved, then its edit page could not be saved again until it was renamed. Both tools now refuse these characters on PrestaShop 9 as the back office does, and say which characters the running version refuses. PrestaShop 8, whose form accepts them, is unchanged.
Install: download OSo-MCP-Server-1.2.1.zip and install it from Modules > Upload a module.
O'So MCP Server 1.2.0
Added
Reviewing the modules. The new tool somcp_list_modules lists the modules of the shop as Modules > Module Manager shows them, installed or only on disk: name, version, author, description, whether each one is installed, enabled and enabled on mobile, and whether its files are newer than the installed version and wait for an upgrade. It filters like the Status filter and the search field of the screen, and reads only the shop, never the marketplace. It comes with the new Review modules prompt and needs the new permission mcp.modules.read, which the consent screen describes as reading the modules of the shop, and the view right on Modules > Module Manager.
Reading one module. The new tool somcp_get_module reads one module of the shop as its card in Modules > Module Manager shows it - the same version, author, description and state as somcp_list_modules - and adds the hooks it is attached to on the current shop, as Design > Positions lists them. It joins the Review modules prompt and needs the same mcp.modules.read permission and view right on Modules > Module Manager.
Installing a module. The new tool somcp_install_module installs a module whose folder is already on the shop, as the Install button of its card in Modules > Module Manager does, and answers with the module as somcp_get_module reads it afterwards. A module already installed is refused and left as it is, so an install never turns into an upgrade, and nothing is uploaded or downloaded. It joins the Review modules prompt and needs the new permission mcp.modules.write, which the consent screen describes as installing modules already present on the shop, and the add right on Modules > Module Manager.
Enabling or disabling a module. The new tool somcp_set_module_active enables or disables an installed module on the shop, as the Enable and Disable buttons of its card in Modules > Module Manager do, and on PrestaShop 8 switches it on or off for mobile. A request that would change nothing is refused, since PrestaShop would still report a success and run the module's hooks; this module never disables itself. It answers with the module as somcp_get_module reads it afterwards. It joins the Review modules prompt and needs the mcp.modules.write permission, which the consent screen now describes as installing, enabling and disabling modules already present on the shop, and the edit right on Modules > Module Manager.
SEO of the shop's own pages. The new tool somcp_update_meta_page changes the Page title, Meta description and Rewritten URL of one of the pages listed under Shop Parameters > Traffic & SEO - contact, new products, best sales, search and the others - in the languages you approve, in the current shop only, and the Meta keywords on PrestaShop 8, the only version whose form has them. It checks a Rewritten URL as the form does - "Only letters and hyphens are allowed." - instead of reshaping what you approved, requires it in the shop's default language only, accepts the home page's empty one given back unchanged, refuses a friendly URL another page already uses, and warns that a new one makes the old address stop working. It takes the field names somcp_list_meta_pages returns. It joins the Audit and improve SEO prompt and needs the mcp.seo.write permission and the edit right on Shop Parameters > Traffic & SEO.
Reading one content page. The new tool somcp_get_cms_page reads one CMS page as its edit form under Design > Pages shows it: category, title, meta title, meta description, meta keywords (PrestaShop 8), friendly URL, the full page content, Indexation by search engines and Displayed, with the page's address on the storefront. What a page says can now be read and quoted, not only listed, and the SEO fields keep the names somcp_update_cms_seo takes, so a value read can be written back as is. It joins the Read content pages prompt and needs the mcp.content.read permission and the view right on Design > Pages.
Deep thinking, web search and memory, switched per conversation. The + menu of the built-in assistant now has switches for the conversation you are in. Deep thinking asks the assistant to think longer before answering, for Claude, Gemini and OpenAI's reasoning models; it is slower and uses more tokens, and what the assistant thought can be unfolded above its answer. Web search lets Claude and Gemini look things up on the web with the key they already have, and the pages used are listed in the conversation. Claude searches on its own: each search is billed by Anthropic on top of the tokens, and web search must be allowed in your Anthropic console. Gemini searches through a second call to the same model with Google Search, counted in the tokens like any answer. The other assistants - OpenAI, Mistral, DeepSeek, Grok, Cohere - can search too once you pick Claude or Gemini under Web search in the Built-in assistant tab: that assistant searches for them with its key, and its searches count in its tokens. The setting follows the shop levels like the others, and stays greyed until both a Claude or Gemini assistant and an assistant of another provider are set up. With web search on, the assistant can also open a page - one you give it, or one a search found - and read it.
The built-in assistant knows the module it belongs to. Asked how to switch its memory on, it used to search the web and answer about other products, or say it had no memory at all. It now knows it is the module's own chat, what its + menu does and where each setting lives, and points to the module's documentation for the installed version. For super administrators, the employees the settings pages are open to, it can read every setting of the module - each with its tab and label, and whether it is set for this shop, the group or all shops - with the assistants, tools and prompts, and change one setting at a time after you approve it, through the same checks as the settings page. It never reads nor writes an API key. These abilities, like asking another assistant and searching the web, belong to the chat alone: they are not in the module's tool list, and an assistant connected over MCP never sees them. Memory, offered when the memory is switched on in the module settings, can be switched off for one conversation: the assistant then works from that conversation alone, and nothing said in it is added to the memory - what was remembered before stays. A switch only shows when the assistant can use it, and one set away from how a conversation starts shows as a pill under the field, with a cross to undo it. The conversation keeps its switches when you come back to it.
A local assistant, running on your own computer. Add a local assistant in the Built-in assistant tab connects the chat to an AI on your computer - Ollama, LM Studio or any software that speaks the OpenAI API - through O'So AI Relay, a small program you download and run there. Your conversations and your shop data then go to your computer instead of an AI company, with no key to pay for. The relay calls your shop, never the other way round, so nothing has to be opened on your network, and it works whether your shop is hosted online or next to you. The screen opens on a code valid ten minutes, once, with the command to paste in the relay, and a progress bar that moves on by itself: the relay linked, your AI tested, the model to choose. Nothing to click while it waits; Retry shows only when a step gave up, such as a code that expired. Only the models of your AI able to call the shop's tools are offered. The list of assistants shows whether the relay is online, and Test the connection checks it. Removing the local assistant unlinks the relay at once. While nobody uses the chat, the relay asks your shop only every 15 seconds instead of keeping a request open, so it does not hold one of your shop's PHP processes; it is back to answering at once as soon as the chat is opened.
Deleting return statuses. The new tool somcp_delete_return_status deletes one return status the merchant created, as the Delete action of the return status list of Shop Parameters > Order Settings > Statuses does. The five statuses every shop starts with are refused, and so is a status a merchandise return still stands on, with the number of returns. The prompt Change an order status names it too.
Reading the storefront's main menu. The new tool somcp_list_menu_links lists the entries of the main menu as the Selected items of the Main menu module's configuration page show them, in order: categories, products, CMS pages and categories, brands, suppliers, shops and custom links, each with its name in the language asked for and the identifier the other tools take. It also lists the custom links of the Link list, in the menu or not, and names the entries that point to something deleted, which the screen hides. When the Main menu module is not enabled it says so instead of failing. It comes with the new Storefront menu and layout prompt and needs the new permission mcp.appearance.read, which the consent screen describes as reading how the storefront looks, and the view right on Modules > Module Manager.
Adding an entry to the storefront's main menu. The new tool somcp_add_menu_link adds one entry to the main menu, as Add then Save in the Menu Top Link panel of the Main menu module: a category, a product, a CMS page or category, a brand, a supplier, all brands or all suppliers, a shop or a custom link, at the end or at the position asked. A new custom link is created from its label and address in each language and put in the menu in the same call, where the screen leaves it outside the menu. An...
O'So MCP Server 1.1.3
Added
Sales summary over a period. The new tool somcp_get_sales_summary gives what the shop sold between two dates, counted as the Stats Dashboard and Sales and orders pages count it: valid orders by invoice date, amounts tax excluded in the shop's default currency. It returns the revenue, the sales after credit slips, the revenue tax included, the number of orders, the products bought, the average basket and the new customers, and on request the same figures for the period just before, to compare. It works even when the statistics modules are disabled. It needs the new permission mcp.stats.read, which the consent screen describes as reading the statistics, and the view right on the back office Stats page.
Best-selling products over a period. The new tool somcp_list_best_sellers lists the products that sold most between two dates, as Stats > Best-selling products shows them: reference, name, quantity sold, price sold, sales, quantity sold in a day, page views, available quantity and status, sorted by sales or by any of those figures, page by page. It counts the same valid orders by invoice date as the sales summary, in the shop's default currency, and works even when the statistics module is disabled. The sales report prompt now uses it for best sellers.
Sales report prompt. A guided task for sales figures, picked from the assistant's menu: turn the period into two dates and say which, give every amount with its currency and whether tax is included, and explain why the list of orders can differ by a few orders at the edges of a period.
Listing carriers. The new tool somcp_list_carriers lists the carriers of the shop as Shipping > Carriers shows them, enabled or not and in the same order, with their delay, logo, tracking URL and whether they are free, filtered by status, free shipping or part of the name. The carrier identifiers a product takes are read from it instead of guessed, and since PrestaShop gives a carrier a new identifier each time it is edited, the reference that stays the same is given too. The prompts Change an order status and Manage products name it.
Listing content pages. The new tool somcp_list_cms_pages lists the CMS pages of the shop as Design > Pages shows them, displayed or not: URL, title, meta title, position, category and the page's address on the storefront, filtered by category, by Displayed or by part of the title. The page categories come with it, so a category can be picked by its identifier. The title and the meta title keep the names the SEO tools use, so the assistant never writes one in place of the other. It needs the new permission mcp.content.read, which the consent screen describes as reading the content pages, and the view right on Design > Pages.
Content pages prompt. A guided task for the shop's CMS pages, picked from the assistant's menu: find the page the merchant means by its title, quote its texts rather than paraphrasing them, and tell the title from the meta title.
Creating return statuses. The new tool somcp_create_return_status adds one return status - a step a merchandise return goes through - with its name in the languages being filled and its colour, as the Add new return status form of Shop Parameters > Order Settings > Statuses does. A name another return status already has in that language is refused, so two steps can never wear the same label and be mistaken for each other. The prompt Change an order status names it too.
Changing return statuses. The new tool somcp_update_return_status changes the name or the colour of one return status, as its Edit form of Shop Parameters > Order Settings > Statuses does. Only what is given changes: a language left out keeps its text, and a call that would change nothing writes nothing and says so. A name another return status already has in that language is refused, as at creation. The prompt Change an order status names it too.
Creating order statuses. The new tool somcp_create_order_status adds one order status with every field of the Add new order status form of the same page: its name and email template in the languages being filled, its colour, its GIF icon - by address or by a file already on the shop - and the nine boxes that say what reaching the status sets off. A name another order status already has in that language is refused on both PrestaShop 8 and 9, so two statuses can never wear the same label. The prompt Change an order status names it too.
Changed
A brand or supplier logo can be a file already on the shop. The logo of somcp_create_manufacturer, somcp_update_manufacturer, somcp_create_supplier and somcp_update_supplier used to accept only a web address, so a photo attached in the built-in assistant or an image it had just generated could not become a logo. It is now given the way product images are: either its public https address (url) or the reference of a file already on the shop (upload_ref), and it goes through the same download and image checks as product images. The answer names the logo by the one that was given.
Reading an order gives what acting on it needs. somcp_get_order now returns the identifier of each product line, of each discount (with its invoice and whether it offers free shipping) and of each step of the status history, so that refunding a line, removing a discount or resending the email of a status can name what they act on. Each address now comes with its identifier, its alias, its region and the identification number when there is one, as the address blocks of the order page show them. A product line that is a pack lists the products in it, with their quantity and the stock available now, like the Products in pack window of the order page.
Features can be reordered. The order of the features - the drag and drop of Catalog > Attributes & Features > Features - could not be changed by the assistant: somcp_update_feature refused position. It now takes it, moves the feature to that place and shifts the others as the list does, and the answer gives the old and the new place.
Attribute values can be reordered. The order of the values of an attribute - the drag and drop of its list of values in Catalog > Attributes & Features > Attributes - could not be changed by the assistant: somcp_update_attribute_value refused position. It now takes it, moves the value to that place and shifts the others as the list does, also right after moving the value to another attribute, and the answer gives the old and the new place.
Attribute groups can be reordered. The order of the attribute groups - the drag and drop of Catalog > Attributes & Features > Attributes - could not be changed by the assistant: somcp_update_attribute_group refused position. It now takes it, moves the group to that place and shifts the others as the list does, and the answer gives the old and the new place.
Tax rules: found by name, in the order of the list. With the fifty or so rules a localization pack creates, the assistant had to read them all to find one. somcp_list_tax_rules now takes part of a rule name, as the Name filter of International > Taxes > Tax Rules does, and lists the rules in the order of that page - by identifier - instead of by name.
The diagnostic names the real cause. With friendly URLs off, the three address lines below also failed, each blaming something else - a rewrite rule, an error 503 - and sent the merchant after problems that did not exist. When a line every address depends on fails (the shop disabled, friendly URLs off, no valid certificate), the addresses are now marked Not checked and point to that line. Two lines are new: HTTPS certificate, which says when the certificate is expired, self-signed, issued for another domain or missing, and SSL in PrestaShop, red when SSL is off - only a warning on a shop running on a local address. A failing setting now comes with Go to the setting, which opens the PrestaShop page where it is changed, and an address answered by the maintenance page says so.
Meet our contributors: wider cards. On the cards after the top contributor, the number of contributions and the share of the commits were cut over four short lines. Every card now has the width of the top one, so each keeps to a line, and the others come six at a time with Previous and Next.
The list of files shows descriptions and can be filtered. somcp_list_attachments now returns the Description of each file beside its name, which tells two manuals or two data sheets apart, and filters on part of the Name or of the File as the list of Catalog > Files does. A language the shop does not have used to be silently replaced by another one; it is now refused with the list of the shop's languages, the shop default language is used when none is given, and the answer says which language the names and descriptions are in.
The attribute list shows what the back office shows. somcp_list_attributes now gives, for each attribute group, its type, its position and its number of values, and for each value its position and, in a colour group, its colour - the columns of Catalog > Attributes & Features > Attributes. Before, it gave only identifiers and names, so a group's order or a value's colour had to be read one by one.
The feature list shows what the back office shows. somcp_list_features now gives, for each feature, its position and its number of values - the columns of Catalog > Attributes & Features > Features - and on PrestaShop 9 the position of each value, with the values in the order of the back office. Before, it gave only identifiers and names, and on PrestaShop 9 listed the values in another order than the back office. somcp_get_feature_value also gives the position of the value on PrestaShop 9.
Fixed
**Su...
O'So MCP Server 1.1.2
Added
Listing return statuses. The new tool somcp_list_return_statuses lists the return statuses of the shop, the steps a merchandise return goes through, with each status's identifier, its name, its colour and whether it can be removed. The five statuses every shop starts with cannot be removed, on PrestaShop 8 and 9 alike. A language the shop does not have is refused, as in somcp_list_meta_pages. The prompt Change an order status names it too, so a return status is never mistaken for an order status. Thanks to @Ptraaah, whose first contribution this is.
Meet our contributors. The Help and updates tab now thanks the people who build the module: each one with their GitHub profile picture, their number of contributions and their share of the commits, and a link to their profile. The first card goes to the top contributor, whoever that is at the time. The others follow on one row, nine at a time with Previous and Next once there are more, and past ten people a last card leads to the full list on GitHub. The list is read from GitHub once a day, like the check for a new version, so a new contributor or a new profile picture shows without updating the module. With that check switched off, nothing is asked of GitHub, not even the pictures: the list shipped with the module is shown without them.
Fixed
Buttons of the update notice. On the notice of a new version, the icon of Download the zip and of See what is new ran into the first letter of the button. It now sits apart from the label, as on the other buttons.
Install: download OSo-MCP-Server-1.1.2.zip and install it from Modules > Upload a module.
Contributors
Assets 3
O'So MCP Server 1.1.1
Added
Changing a customer. The new tool somcp_update_customer changes one customer account, as Customers > Customers > Edit does: name, email, social title, birthday, enabled, partner offers, newsletter, groups and default group, the private note of the customer page, and the B2B fields when B2B mode is on. Only the fields given change, the answer lists each one with its old and new value, and a call that changes nothing writes nothing. The password is never touched. It needs the permission mcp.customers.write and the edit right on the back office Customers page.
Creating a customer. The new tool somcp_create_customer creates one customer account, as Customers > Customers > Add new customer does: name, email, guest account, social title, birthday, enabled, partner offers, newsletter, groups and default group, and the B2B fields when B2B mode is on. No password goes through the conversation: the customer chooses theirs with "Forgot your password?" on the shop, and no email is sent. It needs the new permission mcp.customers.write, which the consent screen describes as changing the customers, and the add right on the back office Customers page.
Changed
Listing suppliers: the columns and filters of the Suppliers list. The list of suppliers gave the identifier and name only, so a switched-off supplier could not be told apart without opening each one. Each supplier now comes with what Catalog > Brands & Suppliers > Suppliers shows: whether it is enabled and its number of products. The list can also be narrowed as on screen, to enabled or disabled suppliers and by part of the name.
Assistants named the same way everywhere. The module description, the settings page, the README and the bug form each named a different set of assistants, and some named one the others did not. They now all say Claude, ChatGPT or Le Chat, and the README keeps the one full list of compatible assistants, with the page where each AI provider of the built-in assistant gives out its API keys.
Fixed
The assistant's memory works in the installed module. With the memory switched on, the built-in assistant stopped with an error in a shop that installed the module from its archive: part of the library the memory relies on was left out of the package. The archive now carries it, and the checks run before each release look at the package as merchants receive it.
Security
A module's tools only ask for its own permissions. A module publishing tools or prompts through somcp could have them require one of somcp's own permissions, such as reading the orders, and declare no back office right. The merchant was then never asked about that module on the consent screen, and an employee without access to the Orders page could still use its tools. A tool or prompt that asks for a permission its module did not declare is now refused and noted in the somcp log.
Install: download OSo-MCP-Server-1.1.1.zip and install it from Modules > Upload a module.
O'So MCP Server 1.1.0
Added
Finding customers. The new tool somcp_search_customers lists the customers of the shop as Customers > Customers does, with the filters of that list: name, email or company, group, social title, enabled, newsletter, partner offers, guest accounts and registration dates. Each line gives the default group, what the customer spent, their registration and their last visit; customers deleted with their data kept are left out, as on screen. It comes with a new permission to grant, reading customers, and a new guide, Find a customer, which also opens their orders.
Reading a customer. The new tool somcp_get_customer reads one customer as their page in Customers > Customers shows it: the account with its private note and B2B fields, groups, addresses, a summary of the orders with the newest ones, carts, purchased and viewed products, the vouchers reserved to them, messages, last emails and last connections. Ask for them by identifier or by email; an email shared by several accounts is refused with the identifier of each, so the right person is picked. The guide Find a customer now opens it.
Changing Home and the order of categories. Changing a category used to refuse Home outright and could not change where a category stands in the list. Home can now be changed with the fields of its own form in the back office - name, Displayed, descriptions, images, SEO fields and group access - while it still cannot be moved, and on PrestaShop 9 only answers 404 or 410 while hidden. A category can also be given a new position among the categories of the same parent, as when you drag it in the list: the others shift, and with a new parent it is the place under that parent.
Product tags. Creating or updating a product can now fill its tags (the Étiquettes field), given as a comma separated list per language. They are written to the shop's own tag field, which is separate from the meta keywords and exists on every PrestaShop version; the shop creates the tags it does not have yet. On an update, the tags given replace the product's tags in those languages, and a language left out keeps the ones it had. Reading a product now returns its tags as well, so they can be read, changed and written back.
Tracking numbers. The new tool somcp_set_order_tracking sets the tracking number of an order's shipment, like the Tracking number field of the Edit shipping details window on the Carriers tab of the order page. As in the back office, a new number emails your customer the "in transit" message, with the tracking link when the carrier has one, and lets carrier modules know; giving the number the shipment already has changes nothing and sends nothing, and an empty number removes it without any email. When an order has several shipments, the assistant has to say which one. The carrier and the order status are never changed by it. It needs the permission mcp.orders.write and the edit right on the back office orders page.
Order messages. The new tool somcp_add_order_message adds a message to an order, like the Messages block of the order page. When it is shown to your customer, they see it in their account and receive the "New message regarding your order" email in the language of their order; a private message stays between you and your team, and nobody is emailed. The assistant has to say which of the two it is, there is no default. As on the order page, the message is limited to 1200 characters and refused if it holds a script, and it shows the name of the employee who wrote it. It needs the permission mcp.orders.write and the edit right on the back office orders page.
Order notes. The new tool somcp_set_order_note writes the private note of an order, the Order note (Order private note on PrestaShop 9) of the Status tab of the order page. Only your team sees it: your customer is never emailed. As on the order page, the new text replaces the previous one, so the assistant reads the current note first when it is asked to add to it; an empty note clears it, and giving the note the order already has changes nothing. On PrestaShop 8, a note too long for the shop to store is refused instead of being cut. It needs the permission mcp.orders.write and the edit right on the back office orders page.
Order payments. The new tool somcp_add_order_payment records a payment you received for an order - a bank wire or a cheque that arrived, a part payment - like the Payment block of the order page: amount, payment method, currency, date, transaction ID, and the invoice when the order has one. The amount paid of the order goes up, and the assistant tells you what is still due. The order status does not change: marking the order paid stays a separate step, which the assistant only takes if you ask. On PrestaShop 9, the payment shows the employee who recorded it. A zero or negative amount is refused. It needs the permission mcp.orders.write and the edit right on the back office orders page.
Product SEO audit. The new tool somcp_audit_product_seo lists the products whose search engine fields have a problem, language by language, and names the problem: a missing, too long or duplicated meta title, a missing, too short or too long meta description, a friendly URL shared with another product, a description under 150 words, an image without alternative text, no image, no brand, no EAN-13, UPC or ISBN, and, when you include inactive products, an inactive product that redirects nowhere. It counts each problem over your whole catalogue, and works just as fast on a large one. It only reads: nothing is changed. It needs the new permission mcp.seo.read, shown on the consent screen as reading how your shop appears to search engines, and the view right on the back office products page. The new prompt "Audit and improve SEO" guides the assistant through the audit, sorting what it finds by its effect on your sales and proposing every new title or description to you before anything is written.
Category SEO audit. The new tool somcp_audit_category_seo lists the categories whose search engine fields have a problem, language by language, and names the problem: a missing, too long or duplicated meta title, a missing or too long meta description, no description, a friendly URL shared with another category, a displayed category with no active product, and no cover image. It judges titles and descriptions exactly as the product SEO audit does, counts each problem over all your categories, and leaves out the root and Home categories, which have no page of their own. It only reads: nothing is changed. It needs the permission mcp.seo.read and the view right on the back office categories page.
CMS page SEO audit. The new tool somcp_audit_cms_seo lists the CMS pages (delivery, legal notice, about us...) whose search engine fields have a problem, language by language, and names the problem: a title too long or shared with another page, a missing or too long meta description, a content under 150 words, a friendly URL shared with another page, and a page set not to be indexed by search engines. The title checked is the one search engines read: the page's meta title when you filled it, its title otherwise. It judges titles and descriptions exactly as the product SEO audit does, and lists every page, shown or not. It only reads: nothing is changed. It needs the permission mcp.seo.read and the view right on the back office Pages page.
Brand SEO audit. The new tool somcp_audit_brand_seo lists the brands whose search engine fields or descriptions have a problem, language by language, and names the problem: no meta title, no meta description, no description, no logo, and a disabled brand that products of your shop still carry. Each brand comes with its number of products, the same figure as when you read the brand, so you can start with the ones that matter. It lists every brand, enabled or not. It only reads: nothing is changed. It needs the permission mcp.seo.read and the view right on the back office Brands page.
Shop pages and their SEO. The new tool somcp_list_meta_pages lists the pages of your shop shown under Shop Parameters > Traffic & SEO - home, contact, new products, best sales, search, account and checkout pages, and the pages of modules - with their meta title, meta description, friendly URL and public address, in the language you choose. The product, category and CMS page templates, which that page does not list because their texts come from each product, category or page, are shown as such rather than as pages with no title. It only reads: nothing is changed. It needs the permission mcp.seo.read and the view right on the back office Traffic & SEO page.
SEO and URL settings. The new tool somcp_get_seo_settings reads the settings that decide what your shop's addresses look like to search engines: friendly URLs, accented characters in URLs, the redirection to the canonical URL, HTTPS, the shop's domains, the URL patterns of product, category, brand, supplier and CMS pages, whether a robots.txt file is there and whether the sitemap module is installed and enabled, and the shop's languages. It points out what costs rankings: friendly URLs off, no canonical redirection, a shop not served in HTTPS, no robots.txt, no sitemap. It only reads: these settings stay yours to change in the back office. It needs the permission mcp.seo.read and the view right on the back office Traffic & SEO page.
robots.txt. The new tool somcp_get_robots_txt reads your shop's robots.txt file, the one PrestaShop generates from the Traffic & SEO page, and lays out its rules for each crawler and the sitemaps it declares. It points out what hurts your visibility: a group of rules that blocks the whole site, a rule that blocks your product or category pages (checked on the real address of one of your products and one of your categor...