MCP or REST for product data in a shopping assistant

For simlir, connecting is a configuration entry:

Once connected, a compatible client discovers three tools automatically:

What you gain is decision-making at the right layer. The model sees a shopper ask about a product, recognises that it needs evidence, calls the tool, and continues the conversation with structured results in hand. You did not have to predict that moment in advance.

What you give up is control over timing. The model decides when to call, which means it also decides when to spend credits. That is manageable — but it is a real difference.

What REST does

REST is the canonical contract surface. Four endpoints, standard HTTP, callable from any server or runtime, with a documented OpenAPI reference.

The fourth endpoint is the one teams overlook and then wish they had used from the start. Every search result carries a stable id that never changes. Cache it, and a later fetch of that exact product costs 1 credit instead of re-running a 2-credit search:

For a browsing interface where users click into results, revisit saved comparisons, or refresh a watchlist, that single pattern is usually the largest available saving.

Decision table by use case

Authentication and application boundaries

Authentication is identical on both routes: a Bearer token in the Authorization header. Keys are created in the dashboard and are hashed on our side, so they cannot be recovered — store them securely and create separate keys per application so you can revoke one without disturbing the others. Version 1 does not expose selectable scopes or a sandbox environment.

Rate limits also apply to both routes identically: a free account gets 10 requests per minute with a burst of 20 and a daily cap of 10; standard allows 1,000 per minute with a burst of 5,000 and no daily cap. These are request ceilings, not a data allowance — paid operations still consume credits. Every response carries X-RateLimit-Remaining and X-RateLimit-Reset.

Response consistency across both routes

This is the part that makes the decision low-risk: MCP and REST return the same product shape. The same identifiers, the same spec object, the same price snapshot with its as_of date, the same links, the same market echo.

Three behaviours are worth knowing because they hold on both routes:

• limit is a ceiling, not a promise. A post-search sanity filter can return fewer items or zero when the candidate page is clearly the wrong product type. Read meta.count.
• Market is required and never inferred. gl on REST search and lookup, market on image search and the MCP tools. The response echoes it; a mismatch is an integration bug.
• Scores are not interchangeable. relevance_score appears only on semantic search results (cosine similarity, 0–1). visual_similarity_score appears only on image results. Do not compare or blend them.

On lookup specifically, the response tells you how the match was made: requested_type echoes what you asked for, while resolved_type and matched_field tell you which field actually matched. Note that when you send type=mpn, the product field in the response is still model_number.

When to use both

Most production shopping assistants end up on both routes, and that is a healthy outcome rather than a sign of indecision. A typical division:

• MCP inside the conversation. The model calls the search tool when the shopper asks something that needs product evidence.
• REST around it. Your backend re-fetches cached product UUIDs to refresh a saved comparison, joins identifiers from a partner feed, runs a nightly price check, and serves the product detail pages.

Because both routes draw on the same credit balance and return the same shape, you can move work between them as your cost profile changes without touching your data layer.

Implementation checklist

• Decide who initiates the searchModel-initiated points to MCP; code-initiated points to REST.
• Create a separate API key per applicationKeys are hashed and unrecoverable, so revocation should be surgical.
• Never ship a shared key in a distributed client configKeep it server-side and expose your own interface instead.
• Send the market explicitly on every callgl or market, and compare it against the echoed value.
• Cache product UUIDs/v1/product at 1 credit beats repeating a 2-credit search.
• Use exact lookup when you already hold an identifier1 credit, no ranking ambiguity.
• Read meta.count, not the array length you requestedShort and empty pages are legitimate responses.
• Handle 402, 429, 502 and 503 distinctlyOut of credits, rate limited, embedding failure, service unavailable.
• Back off using X-RateLimit-ResetRather than a fixed retry interval.
• Log credits used per featureSo you can see which surface is driving spend before the invoice does.

Frequently asked questions