MCP Servers for E-commerce: What One Can Expose for Your Store

An MCP server for an online store is a small service that exposes selected store data and actions to an AI assistant. Typical things to expose are products, orders, inventory, customers and support content. Good servers expose only what a task needs, and they start read-only.

This article gives generic examples. It does not describe any specific vendor's product. Names such as get_order are illustrations, not real tool names.

The three building blocks again

An MCP server offers three kinds of things to an AI app:

• Tools are actions the model can request, with typed inputs.
• Resources are readable data, such as documents or records.
• Prompts are reusable instruction templates.

For a store, tools do most of the work. Resources suit static or slow-changing content. Prompts help with repeated tasks.

Products and catalogue

Product data is the safest place to begin. It is mostly public already.

Example tools:

• search_products with inputs such as a text query, a category and a price range.
• get_product with a product ID or SKU. It returns title, description, variants, price and image URLs.
• list_products_missing_fields to find items without a description, image or weight.

Example resources:

• The full category tree.
• The brand style guide for product descriptions.

A useful task here: "Find all products in the garden category with no description and draft one for each." The AI reads the data. A person reviews the drafts before anything is saved.

Orders

Order data is more sensitive. It includes names, addresses and email addresses, which are personal data under GDPR.

Example tools:

• get_order by order number. Return status, line items, shipping method and totals.
• list_orders with filters for date range and status, such as unshipped or refunded.
• get_order_timeline to show events like payment, packing and shipping.

Think about which fields you really need to return. For a question like "how many orders are unshipped?", a count is enough. The AI does not need customer addresses.

Inventory

Stock data is useful for planning and low-risk to read.

Example tools:

• get_stock_level by SKU and location.
• list_low_stock for items below a reorder threshold you define.
• get_stock_history to show changes over a period.

A useful task: "Which of my top sellers will run out in the next month?" For that, the AI combines stock data with sales data. Both can come from read-only tools.

Customers and support

Customer data needs the most care. Think twice before you expose it.

Example tools:

• get_customer_summary returning order count and total spend, without full contact details.
• find_orders_by_email for support agents, with access restricted to staff accounts.

Example resources:

• Your returns policy and shipping policy as text.
• A list of frequently asked questions.

With policies as resources, an AI can draft a support reply that matches your actual rules. A person still sends the reply.

Reports and analytics

Aggregated data carries less personal risk than raw records.

Example tools:

• get_sales_summary for a date range, grouped by product, channel or country.
• get_return_rate_by_product to spot items with many returns.
• get_top_search_terms from your shop search.

Write actions: expose with care

Some servers also let the AI change things. Examples are:

• update_product_description
• create_draft_discount_code
• add_order_note
• issue_refund

These carry real risk. A wrong price or an unwanted refund costs money. If you expose write tools, follow these rules:

• Prefer draft or pending states over live changes.
• Require human approval for refunds, price changes and customer emails.
• Limit each tool to the narrowest action possible. A tool called add_order_note is safer than a general update_order.
• Set clear limits, such as a maximum refund amount.
• Log every call.

How to decide what to expose

Use this short process:

1. List the tasks you want help with. Be specific.
2. For each task, list the data the AI needs.
3. Expose only that data, in the smallest form that works.
4. Mark each tool as read-only or write.
5. Start with read-only tools. Add write tools one at a time.
6. Review logs and adjust.

Where MCP servers come from

You have three common options:

• Build your own. You control exactly what is exposed. It takes developer time.
• Use a server from your platform or plugin vendor. Check carefully what it exposes and how it logs in.
• Use a community or third-party server. Review the code or the vendor first. A server that holds your shop credentials is a trusted component.

Whichever route you take, read the tool list before you connect. A tool list tells you what the AI can do.

Frequently asked questions

What should a first store MCP server expose?

Start with product search and order status lookups, read-only. These are common questions and carry limited risk. Return only the fields the question needs.

Can an MCP server expose my whole database?

Technically it could, but it should not. Expose specific, named tools with typed inputs. Do not give the AI a general query tool for your live database.

Should customer data be exposed through MCP?

Only when a task needs it, and with the fewest fields possible. Customer data is personal data under GDPR. Restrict access, log it, and check your obligations with a qualified adviser.

Do MCP servers handle payments?

No. MCP covers tool and data access. Payment is handled by checkout protocols such as ACP, UCP and AP2. A store may use both for different jobs.