Exposing Commerce Data to AI Agents: Building an MCP Server Over a Product Dataset

Introduction

You have a product dataset. Millions of SKUs, prices refreshed on a schedule, availability by location, history going back months. You already serve it over a REST API with a docs site, SDKs, and an OpenAPI file. Now an internal team wants an AI agent to answer questions like "which of our competitors dropped below our price on these 40 SKUs this week."

The REST API is not the blocker. The blocker is that nobody reads the docs — because the caller is a model, and the model does not browse your documentation site before making its first call.

This is the problem Model Context Protocol addresses. As of late 2026, MCP is the most widely adopted way to let an AI agent discover and call into a data source. This post is about the design decisions that determine whether your MCP server is useful or merely present. The spec is still moving, so treat the specific mechanics as things to verify against the current specification, and treat the design principles as the durable part.

What MCP actually changes

A REST API assumes a human integrator. Someone reads the docs, learns that GET /v2/products takes 14 query parameters, understands that region and marketplace are different things, writes the client, and ships it. The knowledge lives in the integrator's head and then in code.

An agent has no integration phase. It arrives at runtime with a user question and needs to work out, in that moment, what is available and how to call it. MCP gives it a standard way to ask: connect to the server, list the tools, read their descriptions and input schemas, pick one, call it, read the result.

The consequence is that your tool descriptions become your integration layer. They are not documentation alongside the product. They are the product surface. A poorly described tool is functionally an undiscoverable tool.

The second consequence is that the agent's context window is now part of your API contract. A REST client can stream a 50 MB response into a database. An agent pays for every token it reads and degrades as its context fills. Response size is a correctness concern, not just a performance one.

Tool granularity is the decision that matters

This is where most implementations go wrong, in one of two directions.

Direction one: one tool to rule them all. A single query_products tool with 20 optional parameters covering search, lookup, history, comparison, and availability. It mirrors your internal query layer nicely. It also fails, because the agent has to infer from a paragraph of prose which combination of parameters produces which behaviour. Agents are reasonable at choosing between clearly distinct options and poor at constructing valid parameter combinations for an under-specified interface.

Direction two: fifty thin endpoints. A one-to-one mapping of your REST routes onto MCP tools. Now the agent reads fifty descriptions before choosing, most of which are near-duplicates. Selection accuracy drops, and you have burned a large slice of context before any work happens.

The working middle is a small set of tools that each map to a distinct question a user would actually ask. For a commerce dataset, that is roughly five.

Each row is a different input shape and a different output shape. That is the test. If two candidate tools have the same inputs and the same output shape, merge them. If one tool needs a required parameter that is nonsense for another use case, split it.

Note what compare_products buys you. Without it, an agent comparing twelve SKUs makes twelve round trips, accumulates twelve verbose payloads, and then has to align them itself — often badly. With it, you do the alignment server-side and return one compact table. You have moved work from the model to your own code, where it is cheaper and more reliable.

Write descriptions for a model, not a developer

Human documentation can be terse because the reader will click through to examples. A model reads the description once and decides. Descriptions need to carry the selection criteria explicitly.

Weak:

Retrieves product pricing data.

Better:

Returns the current price, currency, seller, and delivery fee for one product identifier on one retailer. Use this when you already have an exact identifier. If you only have a product name or description, call search_products first to resolve it. Does not return historical prices — use get_price_history for that.

The improved version does three things the weak one does not: it states what comes back, it states the precondition, and it redirects the two most likely misuses. Pointing at sibling tools inside a description is one of the highest-leverage things you can do, because it reduces wrong-tool calls without adding tools.

Apply the same discipline to parameters. region should not be described as "the region." It should say what values are accepted, whether it is required, and what happens when it is omitted. Enumerate values in the schema where the set is closed and small. Every enum you provide is a class of invalid call the agent cannot make.

Response shaping: compact beats complete

A 500-row response is worse than a 20-row response with a continuation token. Not slightly worse — worse in outcome, because the agent that read 500 rows has less room left to reason about them.

Practical rules:

• Default limits, applied server-side. Cap at something like 20–25 items unless the caller explicitly raises it, and cap the ceiling too. Never let an omitted limit mean "everything."
• Flat over nested. Deep object graphs cost tokens in punctuation and keys. One row per product with scalar fields reads better than a tree.
• Prune fields by default. Your internal record may have 80 fields. Return the 12 that answer the question, and offer a verbose flag for the rest.
• Continuation tokens, not offsets. Opaque cursors survive an underlying dataset that changes between calls. Page numbers do not.
• Always include the result count and whether more exist. An agent that does not know it is seeing a truncated list will confidently report a partial answer.

The instinct to return everything comes from REST, where the client filters. Here the client pays to read. Filter on your side.

Auth, scoping, and the multi-tenant trap

An agent acting for a user must not be able to read another tenant's data. This sounds obvious and is routinely broken, because the natural implementation passes a service credential from the MCP server to your backend and resolves the tenant from a parameter the agent supplies.

Do not resolve tenancy from a tool argument. An agent can be persuaded — by a user, or by text it encountered somewhere in its context — to pass a different tenant identifier. Resolve tenancy from the authenticated session that opened the MCP connection, and treat any tenant-shaped tool parameter as something to ignore or reject.

Scope narrowly beyond tenancy too. If the connection belongs to a read-only analytics role, the tool list it sees should not include write tools at all. Filtering the advertised tool set by permission is better than advertising a tool that will fail: it keeps the agent from planning around a capability it does not have.

Rate limiting deserves a mention. Agents retry. An agent that gets an ambiguous error will often try again with slightly different parameters, several times, quickly. Per-connection limits and clear, specific error messages — "date range exceeds 365 days, reduce the range" rather than "invalid request" — cut retry storms substantially.

Freshness is a first-class field

Price data has an age. If the agent does not know the age, it will present a cached figure as current, and a human will act on it.

Attach an explicit observation timestamp to every price and availability value you return. Not a response timestamp — the moment that value was observed at source. Where your refresh cadence differs by retailer or by tier, say so in the payload. An agent that sees observed_at four hours old can caveat its answer. An agent that sees nothing cannot.

Caching is fine and necessary. Silent caching is not. Return the cached value, return its age, and let the caller decide.

You now have a caller that never files a bug report

A human integrator who hits a confusing tool opens a ticket. An agent works around it silently, picks a different tool, or returns a worse answer. You will not hear about it.

So instrument for it. Log, per call: which tool was selected, the full arguments, validation failures, result size, latency, and what the agent called immediately before and after. The sequences are the interesting part. A recurring pattern of search_products followed immediately by another search_products with rephrased terms means your search is not resolving what agents ask for. A tool that is advertised but never selected has a description problem, not a demand problem.

Track validation error rates per parameter. The parameter with the highest rejection rate is the one whose description or schema is unclear.

The honest caveat

MCP is consolidating but not settled as of late 2026. Transport options, authorization patterns, and the finer points of how capabilities are advertised are all areas where details have shifted and may shift again. Check the current specification before you finalise wire-level choices, and expect to revise them.

What will not shift: small tool sets beat large ones, descriptions are the interface, compact responses beat complete ones, tenancy comes from the session, freshness must be explicit, and you have to watch a caller that will not complain. Build against those and the protocol churn costs you an adapter layer rather than a rewrite.

If you are on the commercial side of this question — what changes when agents rather than humans do the comparing and buying — that is a different problem, covered in When the Buyer Is an Agent: What Agentic Checkout Changes for Brand Pricing.

Actowiz Solutions builds and maintains the underlying commerce datasets that make an agent-facing layer worth exposing: product, price, availability and history coverage across marketplaces and retailer sites, delivered with observation timestamps and consistent identifiers. We deliver through APIs, scheduled feeds, webhooks and SDKs, so the agent-facing layer you build sits on data that is already normalised and already dated.

FAQ

Q: What is an MCP server for product data?

A: It is a server that exposes a product and price dataset to AI agents through Model Context Protocol, so an agent can discover the available tools at runtime and call them without a human first reading API documentation. It typically wraps an existing data API rather than replacing it.

Q: How many tools should an MCP server expose over a commerce dataset?

A: A small number that each answer a distinct user question — commonly product search, product lookup by identifier, price history, availability by location, and multi-identifier comparison. Agents select tools by reading descriptions, so a handful of clearly differentiated tools outperforms dozens of thin ones.

Q: How should an MCP server signal how fresh a price is?

A: Return an explicit observation timestamp with every price and availability value, recording when the value was seen at source rather than when the response was generated. Without it, an agent will present cached figures as current, and callers will act on stale prices.

Conclusion

You can also reach us for all your mobile app scraping, data collection, web scraping, and instant data scraper service requirements!