An online store that wants to be queried correctly by AI shopping agents or conversational assistants needs a clear set of WebMCP tools for an online store. These tools aren't simple technical functions, they are the touchpoints through which an agent understands what products exist, what availability they have, and how to complete an action on behalf of the user. In this article we walk through the practical list of tools we recommend, explain why descriptions matter as much as function names, and show what should never be exposed to an agent.
Why a store needs dedicated WebMCP tools
An e-commerce site has its own business logic: product variants, fluctuating stock, delivery rules that differ by region, and return policies specific to each product category. An AI agent cannot guess all of this from the HTML page alone, no matter how well structured it is.
That's why WebMCP tools for a store need to be designed as a dedicated interface, separate from the visual interface built for humans. They expose exactly the information an agent needs, in a predictable format, without ambiguity.
Product search with filters
This is usually the first tool an agent interacts with. Its role is to allow catalog search by keyword, but also filtering by category, minimum and maximum price, brand, stock availability, and, where relevant, specific attributes such as color or size.
Most parameters should be optional, with the exception of the search term or category, so that the agent can perform both a broad search and a very precise one. The returned result must contain enough data for the agent to present options to the user: name, price, availability, and a unique product identifier.
- Typical parameters: search term, category, minimum price, maximum price, brand, attributes, sorting, result limit.
- Useful response: a list of products with id, name, price, image (optional), and general stock status.
Product details
Once a product has been identified through search, the agent needs a separate tool for full details: description, technical specifications, available variants, exact price, and any active discounts. This tool typically takes a single required parameter, the product identifier.
It's important that the response also includes information that people see visually but an agent cannot infer, such as material, exact dimensions, or compatibility with other products. Without these details, the agent risks recommending products that don't match the user's requirements.
Stock check by variant
Many stores have products with variants: sizes, colors, capacities. A separate tool for checking stock by variant is essential, because the general availability of a product says nothing about a specific combination of attributes.
The parameters should include the product identifier and the relevant variant identifiers, and the response must be clear: in stock, limited stock with an approximate quantity, or unavailable. An agent that receives an ambiguous answer here will rightly avoid confirming an order.
Adding to cart
The add to cart tool is the first step in an action with a real effect on the user's session, which is why it needs to be built carefully. The basic parameters are the product identifier, the variant identifier, if applicable, and the desired quantity.
The response must explicitly confirm what was added, at what price, and the current state of the cart, including the subtotal. It's important that this tool doesn't go any further than the cart, meaning it should not automatically trigger payment or order completion, these must remain separate actions with explicit user confirmation.
Delivery policies
A dedicated delivery policy tool provides information about available methods, approximate costs, estimated timeframes, and any geographic restrictions. It can accept a locality or postal code as an optional parameter, in order to return more precise information.
Without this tool, the agent would be tempted to make up answers about delivery, which can create false expectations for the user. It's safer for the store to provide this data directly, through a clear tool, than to let the agent infer it from unstructured text.
Return policies
Just like delivery, the return policy should be exposed through a separate tool, with information about the legal or commercial return period, the conditions for accepting a returned product, and how refunds are processed. This tool can accept the product category as a parameter, if the policy differs between categories.
An agent helping a user decide whether to buy a product needs this information before checkout, not after. Including it as a distinct tool avoids situations where the agent gives incomplete or outdated answers.
WebMCP tools for online stores: why descriptions matter as much as names
A tool name like "search_products" tells an agent very little about what exactly it accepts and what exactly it returns. The description in the tool's schema is what explains the exact role, the limits, and the expected format of the parameters, and an agent relies on this description to decide when and how to use the function.
An incomplete or ambiguous description leads to misuse of the tool, even if the name seems obvious to a human developer. For example, if the "stock" parameter doesn't specify whether it refers to total stock or the stock of a specific variant, the agent may give incorrect information to the end user.
We recommend that each parameter have a short but precise description, including the expected format, the possible values, and what happens if the parameter is missing. This documentation discipline is exactly what we check when we analyze a tool through the WebMCP validator, because most practical issues don't come from missing functionality, but from insufficient descriptions.
Well defined parameters, not just present ones
It's not enough for a tool to accept the right parameters, the data type and constraints must also be clearly specified. A price parameter should explicitly indicate whether it accepts decimals, what currency it uses, and whether it can be negative in any particular case.
These details may seem minor, but the difference between a useful tool and one that generates constant errors lies exactly in these specifications. An agent cannot fix a vague schema on its own, it can only guess, and guessing is not a suitable strategy for a real store.
What tools should not be exposed: payment
Payment processing should not be exposed as a WebMCP tool accessible to an external agent, no matter how sophisticated the integration seems. Payment involves sensitive data, strong authentication, and, in most jurisdictions, compliance requirements that cannot be delegated to an AI agent without direct user oversight.
In addition, an error at this level has direct financial consequences, unlike an error in product search, which is easy to correct. Our recommendation is that payment completion should always remain an action performed directly by the user, in the store's standard interface, even if the rest of the journey is assisted by an agent.
What tools should not be exposed: account data
Account information, such as order history, personal data, or saved addresses, should not be exposed through a generic tool accessible to any connected agent. This data can be sensitive, and exposing it without a rigorous authorization mechanism opens up privacy risks that are hard to fully anticipate.
If a store still wants to offer access to this information for an agent explicitly authenticated by the user, a separate authorization mechanism is needed, with a limited and revocable scope. Until such a mechanism has been thoroughly tested and verified, the safest approach is not to expose this data through WebMCP tools at all.
How to check whether your tools are well built
Once you've defined your list of tools, the next step is practical verification: do they behave as described, do they return consistent data, and are the parameters correctly documented. A dedicated validator can quickly show you where the schema is ambiguous or where a response doesn't match what the description promises.
We recommend testing each tool separately, but also in combination, to see whether an agent can complete a full scenario, from search to cart, without getting stuck due to missing information. If you need an external assessment, you can look into an AI agent readiness audit before publishing your tools in production.
Correct implementation, not just theory
There's a clear difference between writing a correct schema and having a tool that behaves the same way in production, under real traffic and with real catalog data. Many problems only appear once stock changes frequently or when the catalog has inconsistent structures across categories.
If you're already working on the technical side of your store, a dedicated WebMCP implementation service for online stores helps you avoid exactly these pitfalls, starting from a list of tools designed for the specifics of e-commerce, not generically adapted from another type of site.
Maintaining tools once they're in production
A product catalog changes constantly, and so do delivery and return policies, so WebMCP tools need to be updated accordingly. A tool that worked correctly six months ago may no longer reflect the store's current reality if the data structure has changed in the meantime.
Periodically monitoring the responses and behavior of your tools is just as important as the initial implementation, because silent errors are hard to notice without regular checks. If you don't have internal resources for this process, one option is ongoing maintenance and monitoring of WebMCP tools.
Conclusion
A well thought out set of WebMCP tools for a store doesn't necessarily mean many functions, but clear functions, with precise parameters and complete descriptions, keeping sensitive actions such as payment and account data outside the direct reach of agents. Start with the basic tools described above, test them rigorously, and expand the list only when you have a concrete reason to do so.
