PrestaShop 9.2 Ask AI: Useful Questions, Actions and Limits

The most useful store assistant is one whose answer you can check. If a merchant asks for “recent problem orders,” the assistant must interpret both the time period and the meaning of a problem. A fluent answer can hide those assumptions unless the request is made precise.

PrestaShop presents Ask AI as a conversational interface in the Back Office, powered by the PrestaShop MCP Server. The 9.2 announcement material shows questions about store data and approval before actions. That establishes the product direction, not a guarantee that every imaginable task is supported by every installation. Official Ask AI announcement material.

For the 9.2 RC1 available on September 26, 2026, evaluate it in staging. The examples below are candidate prompts to try if the connected tools support them. They are not a promised list of built-in commands.

Agencies connecting additional tools should review the MCP integration boundaries, especially the separation between interpreting a request and authorizing its execution.

Understand what the assistant must resolve

A merchant’s sentence passes through several decisions. The assistant needs to identify the requested operation, understand its scope, obtain data or propose an action, and explain the result. Each step can be wrong even when the final answer sounds confident.

“Last month” needs a timezone and a date boundary. “Sales” might mean paid orders, placed orders or an amount excluding cancellations. “Our shop” might refer to one shop in a multistore installation or the whole business. None of those meanings should be left implicit when the answer informs a decision.

The MCP connection is the bridge to supported store tools. It does not mean the assistant has unlimited access to every database table, module or business process. If the necessary tool is absent, the appropriate outcome is a limitation or a narrower task, not an invented result.

Before evaluating usefulness, record the installed assistant and connector versions and the available integration setup. A missing capability may be a configuration issue, a permission boundary or an unsupported operation. Those require different responses.

Ask questions with a checkable scope

A strong request names the shop, time interval, status conditions and desired output. For example:

For shop A, list orders created from September 1 through September 7 in the store’s configured timezone that are currently in the named pending status. Return identifiers and a count. Do not change anything.

This is a test prompt, not a claim that those exact filters are implemented. If the assistant cannot apply a condition, ask it to say which condition is unavailable.

Compare that with “Which orders need attention?” The broader question may be useful in conversation, but it cannot be accepted as a report until “attention” is defined. Staff might mean unpaid orders, delayed shipments, customer complaints or missing addresses.

For catalog work, request a small sample before a broad list. Ask for the identifier and the reason each record matched. This makes it easier to distinguish a genuine data condition from an inference based on a name or description.

Keep the first evaluation dataset small enough to verify manually. If five synthetic records should match, an answer of four is a useful diagnostic signal. A plausible total across thousands of records is much harder to validate.

Treat the answer as a view over evidence

An answer should make its boundaries visible. Which shop was queried? Were results paginated? Was a date interpreted inclusively or exclusively? Did a tool return no records, or did it fail before returning data?

Ask for clarification when these details matter. A confident “none found” is not equivalent to a successful exhaustive query unless the assistant actually completed the relevant retrieval. Similarly, a total derived from one page should not be presented as a total for the whole store.

For numerical answers, independently reproduce a small sample using the Back Office or an existing trusted report. Differences do not automatically mean the assistant is wrong; the reports may use different definitions. Resolve the definition before comparing the arithmetic.

Do not ask the assistant to infer business facts unavailable in the store. It may identify a low-stock condition if the necessary data is available, but supplier reliability or future demand requires additional evidence. Keep observed store data separate from recommendations.

A useful staff habit is to save the question and its scope alongside the result. That makes a later discrepancy easier to investigate than a screenshot of the answer alone.

Separate proposed changes from completed changes

For a write operation, ask for a preview of the affected records and intended values where the product supports that workflow. Review the scope before approving the action.

A bounded request is easier to assess:

Show the proposed change for these two synthetic product identifiers in shop A. Explain the field and resulting value before applying it.

The important parts are the explicit record set, the shop and the field. “Fix all incorrect descriptions” leaves the meaning of incorrect and the size of the operation undefined.

After approval, verify the committed result in the store. A conversational completion message should not be the only evidence that the operation succeeded. If the tool timed out, determine whether the change happened before trying again. Repeating a write can have different consequences from repeating a read.

For bulk changes, decide how partial success will be handled. If one record fails validation, does the product stop, continue or report a mixed result? Verify the actual behavior with disposable records. Do not assume a conversational action is transactional merely because it was expressed in one sentence.

Permissions and connected data deserve deliberate setup

Use an account and integration configuration appropriate to the task. A read-only reporting evaluation should not need broad write authority. Where the product allows narrower capabilities, choose them and confirm the boundary by attempting an unauthorized test operation.

Do not infer the connector’s complete permission behavior from the employee interface alone. Verify how the installed components authenticate and which identity authorizes the store operation. If that relationship is unclear, resolve it before delegating consequential actions.

Review what information is sent to the configured AI provider. Product descriptions and customer notes can contain content that was not written by your staff. Such text is data to analyze, not authority to change the assistant’s instructions or approve an action.

Avoid pasting secrets or payment credentials into conversation. For the pilot, use synthetic customer records and the minimum data needed to evaluate the task. These are practical setup choices, not a claim about a particular provider’s retention terms.

The official Marketplace listing identifies the PrestaShop MCP Server product, but the retrieved public page did not expose a complete technical permission specification. Treat detailed authorization behavior as something to verify in the installed product documentation. Official MCP Server listing.

Build an answer key for the pilot

Create a synthetic set containing five records that match the chosen condition and two that almost match. One near-match can belong to a different shop; the other can fall just outside the date interval. Record the expected identifiers before asking the question.

This fixture tests interpretation more effectively than a store where every record happens to qualify. If the assistant includes a near-match, ask which condition it applied and compare that explanation with the tool result. If it omits a matching record, investigate pagination, filters and permissions separately.

For the reversible action, record the original value and the expected new value. Verify both the target record and one non-target record after execution. Then use the supported interface to restore the fixture. The pilot should leave a reusable case, not a collection of unexplained edits.

Have a second employee repeat the same bounded task using their normal permissions. A different outcome can be legitimate, but the reason should be understandable. Staff need to know when an answer is scoped to their access rather than to all business data.

Run a small merchant pilot with explicit outcomes

Choose three tasks with different failure modes: a filtered read, an explanation of a known record and a reversible action on a synthetic record. Have staff write the expected result before using the assistant.

For each task, record correctness, required clarification and whether the final result was independently verified. Note unsupported conditions separately from incorrect answers. A tool that clearly states a limitation is easier to operate than one that silently substitutes a different task.

Include an ambiguous prompt intentionally. The desirable behavior is to clarify material ambiguity or make an assumption explicit before a consequential action. Do not reward the assistant for acting quickly on an unclear scope.

Also include a denied operation and an unavailable service. Staff need to recognize those outcomes without interpreting them as an empty result or a successful change.

The pilot’s output should be a short operating guide: which tasks are useful, how to phrase them, how to verify them and when to use the ordinary Back Office workflow instead. That guide is more valuable than a collection of impressive but unrepeatable demonstrations.

Ask AI may reduce navigation and make some store questions easier to express. Its value comes from accurate scope and verifiable execution. Begin with small questions, make actions explicit and let observed capability define the operating boundary.

For the underlying platform context, see our PrestaShop 9 API automation examples and apply the version-specific checks above to the installation you are evaluating.