Skip to main content

Why MCP on top of GraphQL Federation?

Many SAAS vendors (commerce platforms, CMS providers, payment services) are starting to ship their own MCP servers. While this may seem convenient, it introduces the same problem that GraphQL Federation solves for traditional channels: you lose the unified data model and business logic that you've built on top of these services.

Where vendor MCP servers make sense​

Vendor MCP servers are not without merit. They can be genuinely useful for administrative and operational tasks that happen outside the customer experience: managing product catalogues, configuring promotions, updating content, or querying analytics dashboards. These are tasks where you interact with a single vendor's back-office and don't need cross-service consistency or your own business rules applied on top.

The distinction matters: when an AI assistant helps a merchandiser update a product description in Storyblok, going directly to Storyblok's API is fine. But when an AI assistant helps a customer find and buy that product, it needs to go through your platform to get the right price, availability, and context.

The problem with vendor MCP servers for customer experiences​

When an AI assistant connects directly to a vendor's MCP server for customer-facing use cases, it bypasses everything your platform has built:

  • Custom data models: the domain-specific schemas you've designed through your subgraphs are ignored. The AI sees raw vendor data instead.
  • Cross-service orchestration: business flows that span multiple services (e.g., checking inventory in one system and pricing in another) can't work when each vendor is accessed in isolation.
  • Pricing and promotions: overrides, customer-group pricing, discount logic, and currency handling that live in your domain services are skipped.
  • Localisation: language, locale, and regional rules applied at the federation layer don't exist at the vendor API level.
  • Access control: authentication and authorization policies enforced by your gateway are bypassed entirely.

The result is an AI experience that is inconsistent with your storefront, mobile app, and any other channel, even though they all sell the same products to the same customers.

The Evolve approach​

By building MCP on top of Evolve's GraphQL Federation layer, AI experiences are completely consistent with every other channel. Your storefront, mobile app, and AI assistant all go through the same gateway, the same domain services, and the same business rules.

Evolve approach

Vendor MCP approach

Everything your team has implemented in the subgraphs (pricing logic, inventory rules, cart validation, promotions) is automatically available to AI clients without duplication. Adding an AI channel is not a separate integration, it's another client of the same architecture.

In practice​

This means that when you define an MCP tool like get_products, the AI gets exactly the same product data, with the same prices, availability, and localisation, as a customer browsing your storefront. If you change a pricing rule or add a new promotion, the AI channel picks it up immediately because it goes through the same code path.

The same applies in reverse: any new subgraph or integration you add to Evolve can be exposed to AI clients by simply writing a GraphQL operation and annotating it with @mcpTool. No separate vendor integration required.