A practical MCP for Enterprise playbook for commerce agents

What Amazon vs Muse actually tells developers

Reports that Amazon has blocked Meta’s new Muse agent from shopping on amazon.com should surprise no one building commercial agents. Retailers have long defended their storefronts against automated access that looks like scraping, circumvents affiliate flows, or violates published terms. The lesson is not that agents are unwelcome; it’s that they must use the same sanctioned interfaces humans and partners use.

As a developer, I translate this into design rules: prioritise official APIs and affiliate or partner endpoints; when you must browse, do it with explicit user consent, a compliant user agent, and robots.txt awareness; and always put rate limits, budgets, and observability in front of the model. Architecturally, I anchor this on a tools-first pattern using the Model Context Protocol (MCP) so the agent can only act through approved surfaces with typed inputs and predictable outputs.

Architecture I ship for commerce agents: MCP for Enterprise at the core

The core pattern is straightforward:

– The LLM runs in a thin planning loop with tool-use enabled. It cannot make raw network calls.

– All capabilities are implemented as MCP tools. Each tool wraps a sanctioned API (merchant-owned, marketplace-owned, affiliate network, payments, shipping, tax).

– A compliance gateway mediates any browser automation: user intent capture, robots.txt checks, identity (distinct user agent), budgets per domain, and content redaction.

– A reliability layer enforces per-tool rate limits, exponential back-off, and circuit breakers. It also emits structured telemetry (OpenTelemetry traces, logs, metrics).

– A contracts layer validates every tool response against JSON Schemas (e.g., ProductOffer, Cart, Checkout) and applies fallback routes (cache, aggregator API, human-in-the-loop) when validation or policies fail.

This is not glamorous, but it is what keeps systems in production. The model becomes a planner that reasons over a clear set of legal capabilities. Everything else is policy and plumbing you can test.

Favour official APIs and wrap them as MCP tools

For marketplaces, use their published partner APIs. For Amazon that means PA‑API 5.0 for affiliate-style product search/details, or the Selling Partner API (SP‑API) if you’re an authorised seller. For first‑party stores, Shopify, BigCommerce, WooCommerce, and Magento all have robust, rate-limited APIs with clear terms. Payments, tax, shipping and address verification similarly have mature APIs.

I expose each of these as MCP tools with small, typed inputs. The LLM calls tools; tools call APIs. No raw HTTP from the model. The tool descriptions themselves become a compliance artefact: they tell your agent (and auditors) what it is allowed to do.

json{
  "tools": [
    {
      "name": "shopify.search_products",
      "description": "Search products in a first-party Shopify store by query.",
      "input_schema": {
        "type": "object",
        "properties": {
          "store_domain": {"type": "string"},
          "query": {"type": "string"},
          "limit": {"type": "integer", "minimum": 1, "maximum": 20}
        },
        "required": ["store_domain", "query"]
      }
    }
  ]
}

An MCP server can back that tool with a concrete API call. Example: a minimal Shopify Admin GraphQL query for product titles, handles and a first variant price. Keep tool outputs compact and stable; version the tool if you change the shape so the planner can learn reliably.

typescriptimport fetch from 'node-fetch';

type Product = { id: string; title: string; handle: string; price?: string };

export async function searchShopify(store_domain: string, query: string, limit = 5): Promise<Product[]> {
  const endpoint = `https://${store_domain}/admin/api/2024-07/graphql.json`;
  const token = process.env.SHOPIFY_ADMIN_TOKEN as string;
  const body = {
    query: `query($q:String!, $n:Int!){ products(first:$n, query:$q){ edges{ node{ id title handle variants(first:1){edges{node{price}}} } } } }`,
    variables: { q: query, n: limit }
  };
  const res = await fetch(endpoint, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json', 'X-Shopify-Access-Token': token },
    body: JSON.stringify(body)
  });
  if (!res.ok) throw new Error(`Shopify ${res.status}`);
  const data = await res.json();
  return data.data.products.edges.map((e: any) => ({
    id: e.node.id, title: e.node.title, handle: e.node.handle,
    price: e.node.variants.edges[0]?.node.price
  }));
}

Do the same for Amazon PA‑API: wrap it as a tool and sign requests correctly; respect their rate limits and attribution policies. The point is consistency: official API surfaces only, strongly typed, and rate-limited one layer deeper than the provider’s published caps.

Mediate any browser automation with user intent and robots.txt

Sometimes you won’t have an API for a particular store or page. In those cases, browsing can be acceptable if you do it the same way a privacy-conscious, well-behaved user would: explicit consent, correct identity, robots.txt compliance, and minimal surface area.

– Explicit intent: collect a human-readable reason and a scope-limited goal. Keep it in the trace so you can justify the action later.

– robots.txt: fetch and parse it. If the path is disallowed for your user agent, don’t go there. Even if allowed, limit crawling depth, don’t follow unbounded pagination, and respect crawl-delay if present.

– Identity: a descriptive user agent string for your product, and a contact page. Don’t spoof browsers.

– Minimalism: retrieve exactly what you need (e.g., the specific product page the user asked for), and cache responsibly so you don’t revisit needlessly.

pythonimport requests
from urllib.parse import urlparse

def is_allowed(url: str, user_agent: str = "*") -> bool:
    p = urlparse(url)
    robots = f"{p.scheme}://{p.netloc}/robots.txt"
    try:
        rules = requests.get(robots, timeout=5).text.splitlines()
    except Exception:
        return False  # be conservative when unsure
    ua_ok, disallows = False, []
    for line in rules:
        s = line.strip()
        if s.lower().startswith("user-agent:"):
            ua = s.split(":", 1)[1].strip()
            ua_ok = ua in (user_agent, "*")
        elif ua_ok and s.lower().startswith("disallow:"):
            disallows.append(s.split(":", 1)[1].strip())
    path = p.path or "/"
    return all(not path.startswith(d) for d in disallows if d)

def guarded_browse(url: str, user_intent: dict):
    if not user_intent or not user_intent.get("purpose") or not user_intent.get("user_ack"):
        raise ValueError("Explicit user intent required")
    if not is_allowed(url):
        raise PermissionError("robots.txt disallows this path")
    print("Proceed with headless browser here, with tight scopes and budgets")

If you integrate a headless browser like Playwright, put it behind a gateway that enforces these checks and maintains per-domain budgets. Make it boring: a state machine that fetches a single page, extracts a few fields according to a deterministic template, and stops.

Rate limits, per-domain budgets, and back-off that keep you welcome

Your reliability layer should assume that agents get enthusiastic. I cap tool call rates well below provider ceilings and implement per-domain budgets for any browsing. Keep a shared token bucket per provider domain so that even if several tools aim at the same backend, they respect a single envelope.

– Rate limits: token buckets with burst capacity and steady refill rates.

– Timeouts and retries: short timeouts, then jittered exponential back-off on 429/503, and a circuit breaker if a provider stays unhappy.

– Budgets: daily and per-session request budgets per domain and per user. When a budget is reached, fail closed with a human-readable explanation and an option to try an alternative route.

pythonimport time
from threading import Lock

class TokenBucket:
    def __init__(self, rate: float, capacity: int):
        self.rate, self.capacity = rate, capacity
        self.tokens, self.ts = capacity, time.time()
        self.lock = Lock()
    def consume(self, n: int = 1) -> bool:
        with self.lock:
            now = time.time()
            self.tokens = min(self.capacity, self.tokens + (now - self.ts) * self.rate)
            self.ts = now
            if self.tokens >= n:
                self.tokens -= n
                return True
            return False

def rate_limited(bucket: TokenBucket):
    def deco(fn):
        def wrap(*a, **k):
            while not bucket.consume():
                time.sleep(1.0 / bucket.rate)
            return fn(*a, **k)
        return wrap
    return deco

bucket = TokenBucket(rate=2.0, capacity=4)  # 2 req/s, burst 4
@rate_limited(bucket)
def fetch_offer(sku: str) -> str:
    return f"offer for {sku}"

Remember that budgets and rate limits are separate. Limits protect providers from bursts; budgets protect you from accidental cost or compliance exposure across a session or day. Both should be visible in telemetry so you can see when the agent is artificially constrained versus genuinely starved by provider caps.

Observability and contracts: the guardrails that fail gracefully

Every tool call should emit a trace with: correlation ID, tool name and version, input redacted of PII, provider domain, HTTP status, latency, retry count, and budget counters. Logs should be structured; traces should be sampled but include complete error paths. Metrics I watch are: tool success rate, 4xx/5xx split, 429s by provider, median and P95 latency, and cache hit rate.

On the data plane, define JSON Schemas for the core objects your agent reasons about, and validate at the edges. For example, a ProductOffer schema might include: product_id, title, currency, price, source, attribution, updated_at. When a response fails validation (missing currency, price not numeric, or wrong attribution), route to a fallback pipeline:

– Primary: first‑party or marketplace API (e.g., PA‑API).

– Secondary: a compliant aggregator or your own cache of recently seen offers.

– Tertiary: an affiliate deep-link or an explanation to the user with a request for permission to try a different store.

Contract validation prevents the agent from hallucinating gaps. It also lets you change providers without retraining prompts: the contract is stable, adapters do the grunt work.

Two further practices help in production:

– Version tools semantically (search_products:v2) and pin planners to versions in prompts. Roll forward with canaries.

– Add human-in-the-loop escalation for anything with payment or address data. Agents can assemble the cart; a human can click the final checkout if policy requires it.

What to do next: a developer’s checklist

If you’re building agentic commerce flows after the Muse news, here’s a pragmatic sequence I actually use:

1) Inventory capabilities and terms: list target stores/marketplaces and the official APIs or affiliate programs they publish. Note TOS, rate limits and attribution rules. If a surface doesn’t exist, mark it “browse-only with guard”.

2) Define contracts: write JSON Schemas for Product, ProductOffer, Cart, Checkout, FulfilmentQuote. Store them in a repo and add JSON Schema validation in your tool adapters.

3) Stand up an MCP server: expose only approved tools with input/output schemas. Start with search, product details, offer lookup, add-to-cart, payments intent, tax/ship quotes.

4) Implement adapters: call official APIs with correct signing, attribution and user identity. Unit test for real error codes (401, 403, 404, 409, 429) and make sure back-off and circuit breakers work.

5) Mediate browsing: build a small gateway that enforces user intent capture, robots.txt, identity, and per-domain budgets. Only then allow a headless browser to fetch a single page for a narrow extraction.

6) Observability: wire OpenTelemetry; emit traces, logs and metrics from tool entry/exit. Track budgets and expose dashboards. Alert on 429 spikes and contract validation failures.

7) Governance: document what each tool does, and keep the documentation with the tool manifest. Rotate credentials, encrypt secrets, and rotate user-agent strings responsibly without spoofing.

8) UX: make the agent explain its actions to the user in plain language, including when it can’t access a site for policy reasons. Offer alternatives (another merchant, a later retry, or a manual link).

If you want a partner to accelerate this, I can help as an Agentic AI Consultant. I typically engage as a Solution Architecture Consultant to stand up the tool layer and reliability envelope, and then provide focused LLM Consulting Services on the planning prompts, evaluation harness, and rollout strategy.