Skip to content
Tekai

MCP and Skills in MACH: Access Is Not the Hard Part

April 1, 2026 MCP and Agent Skills in the MACH ecosystem ai-ml
#mcp#agent-skills#mach#composable-commerce#ai-agents#developer-experience#integration

MCP and Skills in MACH: Access Is Not the Hard Part

The most expensive part of MACH delivery is not calling vendor APIs. It is connecting vendors through bespoke integration, configuring vendor systems to fit business needs, and maintaining the glue between them. MCP standardises how agents reach individual vendors. Skills can help agents navigate the harder layers — the planning, configuration, and cross-vendor orchestration that consume most delivery budgets.

The Real Cost of Composable Delivery

The promise of MACH is composability: pick the best vendor for each capability, connect them through APIs, and move faster than teams locked into monoliths. The reality is that the connecting is where the money goes.

A mid-market composable implementation runs GBP 250,000–600,000, with the biggest cost being engineering and orchestration work, not platform licensing. [16] Companies routinely spend $100,000 on a commercetools license and then discover they need $500,000 in engineering talent to make it work with their existing systems. [17] One retailer evaluated replacing a single search component (3% of platform costs) with a best-of-breed alternative and found they would need 12 additional people to manage the switch. [18]

Annual maintenance compounds the problem. A five-system composable stack can cost $400,000 per year in integration maintenance alone, excluding delayed releases and developer burnout. [19] Industry estimates put ongoing maintenance at 20–40% of the initial build cost, every year. [16][20]

These costs do not come from a lack of API access. They come from three layers of work that are genuinely hard:

Architectural planning. Which services to decompose, which integration patterns to use, which consistency model to apply (strong for financial transactions, eventual for catalog updates), how to handle distributed transactions with saga patterns and compensation logic. Getting these decisions wrong is expensive to fix post-launch. [21]

Vendor configuration. Setting up content types in Contentful, designing product types and attribute structures in commercetools, configuring auth flows in Auth0, tuning search relevance in Algolia. This is not “configuration” in the toggle-a-setting sense. It is substantive delivery work that requires business domain knowledge combined with vendor-specific expertise. In commercetools, product data modeling is an explicit architectural exercise where too much attribute separation creates “an unmanageable CMS structure” while too little “negatively impacts reusability and scalability.” [22] In CMS platforms, content modeling bottlenecks are a documented delivery risk — the structure depends on design, business logic, and CMS limitations discovered late in the process. [23]

Bespoke integration code. The glue between vendors — middleware, BFF layers, event pipelines, data mapping between incompatible models. Each arrow in a service diagram is an API call or event that needs to work reliably at scale. A simple schema change in the PIM “cascades through the commerce platform, affects the search functionality, and hinders the personalization engine. A straightforward update becomes a multi-week engineering project.” [19]

34% of brands attempting composable commerce report lacking the talent with the required technical expertise [24] — and that expertise is vendor-specific: knowing how Contentful’s content model works, how commercetools product types are structured, how Algolia indexes should be configured for the business’s catalog shape.

What MCP Solves — and What It Does Not

MCP (Model Context Protocol) is an open standard for connecting AI agents to external systems. [1] An MCP server exposes a vendor’s capabilities — tools, resources, documentation — so an agent can query data, inspect schemas, and perform operations through a consistent interface.

This is real progress. commercetools’ Commerce MCP exposes 95+ tools covering products, carts, orders, customers, payments, discounts, and inventory. [3] Stripe’s MCP server provides 30+ tools for payment operations. [14] An agent can now query live vendor systems through natural language rather than requiring bespoke API integration per agent per vendor.

But MCP addresses a specific layer — standardising access to individual vendor APIs — and the hardest parts of MACH delivery sit elsewhere.

MCP does not solve cross-vendor orchestration. It standardises access to one vendor’s API. A stack of commercetools + Contentful + Algolia + Stripe requires separate MCP servers for each, and MCP provides no mechanism for coordinating across them: no service discovery, no cross-server sequencing, no intermediate data transformation, no partial failure recovery. [25]

MCP does not make planning decisions. It does not help you decide which integration pattern to use, how to model your product catalog, whether to use event-driven vs. request-driven communication, or how to handle eventual consistency between a commerce platform and a search index.

MCP does not cover configuration-as-delivery. It can execute API calls against a CMS or commerce platform, but it cannot make the business decisions about what content types to create, how product attributes should be structured, or which auth flow fits the business requirements.

MCP does not solve the maintenance problem. When a vendor’s API version changes and breaks downstream consumers, MCP does not detect, diagnose, or fix the cascade. The median enterprise runs 10 upgrade projects annually, with 27% conducting more than 20, and upgrade delivery consuming over a third of IT team time. [26]

In practice, some MCP servers go beyond raw API access. Clerk’s MCP already delivers SDK snippets and framework-specific code patterns [9] — guidance, not just data. But the broader pattern is that MCP gives agents a standardised way to reach vendors individually, not a way to navigate the multi-vendor integration and configuration work that dominates delivery budgets.

Where Skills Fit

Agent Skills are reusable task playbooks for AI coding agents — a packaging format for instructions, metadata, code templates, scripts, and examples that agents can discover and load on demand. The format was released by Anthropic in December 2025 and adopted across 30+ compatible agents. [2]

Skills are structured documentation. The value is not the format itself but what it makes possible: packaging vendor-specific procedural knowledge so agents can apply it consistently at task time. That matters because the most time-consuming parts of MACH delivery are precisely the ones that require opinionated, vendor-specific guidance.

Where Skills can help:

Vendor configuration guidance. A skill can encode how to model product types in commercetools for a B2B catalog, how to structure content types in Contentful for a multi-locale storefront, or how to configure Auth0 organisations for multi-tenant access. These are decisions that currently live in vendor docs, architecture guides, and the heads of experienced consultants. Packaging them as Skills makes them discoverable by agents at the point of implementation, not just when a developer thinks to search for the right docs page.

Integration pattern selection. When connecting two vendors, the choice of pattern (direct API, event-driven, BFF, saga) depends on the specific combination and the business requirements. Skills can encode vendor-recommended integration patterns — for example, how to sync commercetools products to Algolia, or how to map Contentful content models to commercetools catalog structures — so agents have a starting point better than inference from general training data.

Cross-vendor implementation sequences. A skill can bundle the steps for a multi-vendor task: set up the content model in Contentful, create matching product types in commercetools, configure the webhook bridge, test the sync. MCP gives the agent access to each system individually; a skill gives the agent the sequence for working across them.

Maintenance and upgrade procedures. When a vendor ships a breaking API change, a skill can encode the migration path: which fields changed, which code patterns need updating, what tests to run after migration. This does not eliminate the maintenance burden, but it reduces the per-incident cost of figuring out the correct response.

What Skills do not solve

Skills do not eliminate the need for architectural planning. The decision of which services to decompose, which consistency model to use, and where to draw service boundaries requires senior human judgment informed by business context that no packaging format can replace.

Skills do not make vendor configuration automatic. A skill can guide an agent through product data modeling, but the business decisions — which attributes matter, how products are categorised, what content structure serves the editorial workflow — still require human input.

Skills do not solve the organisational challenges of composable delivery: governance, ownership clarity, cross-team coordination, and the discipline required to maintain naming conventions, service boundaries, and API versioning standards across a multi-vendor stack. [27]

And the packaging format itself has risks. A March 2026 security audit found 140,963 issues across 22,511 skills, including 1,184 malicious skills on the ClawHub registry — the “ClawHavoc” incident. [15] The ecosystem’s curation and security scanning infrastructure is immature. First-party vendor Skills are lower risk; community Skills should be treated with the same scrutiny as any other dependency.

Where MACH Vendors Stand Today

Most MACH vendors have invested in MCP — standardised access to their APIs. Fewer have invested in packaging opinionated implementation guidance for agents, whether as Skills, rich MCP resources, or other formats.

Commerce and Content:

  • commercetools offers Commerce MCP (95+ tools for live operations) and Developer MCP (documentation and APIs accessible to AI assistants). [3] Strong on access; the product data modeling guidance that teams struggle with most lives in docs, not yet packaged for agents.
  • Contentful provides an MCP server for content operations and positions MCP as “the new AI connection standard.” [6] Content modeling — the hard part — is not yet agent-accessible as structured workflow.
  • Contentstack has published an MCP server, though it is explicitly marked as experimental and not yet officially recommended for production. [10]

Identity and Auth:

  • Auth0 has shipped both an MCP server [7] and Agent Skills [8] — one of the few vendors to have explicitly invested in both access and structured implementation guidance.
  • Clerk provides an MCP server that delivers SDK snippets and code patterns [9], alongside Agent Skills via the open specification. The MCP server already blurs the line between access and guidance.
  • Kinde has published an MCP server for management API operations. [11]

Payments and Promotions:

  • Stripe exposes 30+ tools through its MCP server. [14]
  • Talon.One has announced an MCP server for campaign and loyalty data, currently in early access with read-only capabilities. [13]

Media:

  • Cloudinary offers five MCP servers in beta covering asset management, metadata, analysis, and workflows. [12]

Cloud Infrastructure:

  • Google Cloud automatically enabled MCP servers for supported services in March 2026. [4]
  • AWS has its MCP Server in preview with CloudWatch integration. [5]

The gap

The vendors most exposed to agent-assisted delivery are those in high-configuration domains — commerce platforms where product data modeling is an architectural exercise, CMS platforms where content modeling is a delivery bottleneck, and identity providers where auth flow configuration is security-critical. These are the vendors where packaging implementation guidance would most reduce delivery cost and error rates. Most of them have shipped access. The guidance layer is still largely unpackaged.

Whether that guidance arrives as Agent Skills, as richer MCP resources, or as some other format matters less than whether it arrives at all. The Agent Skills specification is the most portable packaging option available today (publish once, reach 30+ agents), but portability is not the only criterion. What matters is that the knowledge reaches the agent in a form that is structured, versioned, and discoverable at task time.

A Concrete Scenario

Requirement: Launch a B2B storefront on Next.js with commercetools for commerce, Contentful for content, Auth0 for B2B login with organisation-based access, and Stripe for payments. The product catalog needs to support configurable industrial parts with variant-level pricing.

With MCP only

The agent can query each vendor’s API and documentation through their respective MCP servers. A capable model with good vendor docs may produce reasonable code for each individual integration. But:

  • Product data modeling — the agent must decide how to structure Product Types, attributes, and variants in commercetools for configurable industrial parts. This is an architectural decision with downstream consequences for search, pricing, and inventory. MCP can execute the API calls; it does not guide the modeling choices.
  • Content-commerce mapping — connecting Contentful content models to commercetools catalog structure requires decisions about what lives where, how references work, and how to keep them in sync. MCP talks to each system independently; the mapping logic is bespoke.
  • Auth flow configuration — setting up Auth0 organisations for B2B multi-tenancy, configuring PKCE flows for Next.js, and protecting routes correctly requires vendor-specific security knowledge that goes beyond API access.
  • Cross-vendor orchestration — checkout spans Stripe, commercetools, and potentially Auth0 for access-gated pricing. MCP provides no coordination mechanism across these systems.

The agent produces code. Some of it works. Some of it will break when products have 50+ configurable attributes, when content editors need to preview commerce data, or when a B2B customer switches organisations mid-session.

With MCP plus vendor Skills

The agent loads structured workflows for each vendor integration:

  1. commercetools product modeling skill guides attribute structure decisions for configurable parts — when to use separate product types vs. variant attributes, how to handle variant-level pricing, which patterns scale beyond 10,000 SKUs
  2. Contentful-commercetools integration skill encodes the recommended content-commerce mapping: reference fields, webhook sync setup, preview configuration
  3. Auth0 B2B skill sequences the multi-tenant setup: organisation configuration, PKCE flow for Next.js App Router, middleware scaffolding, token handling, route protection
  4. Stripe checkout skill provides the integration pattern for commercetools-Stripe payment orchestration

Not all of this comes from Skills. The model’s own capabilities handle code generation and framework knowledge. MCP provides live environment data. The Skills’ contribution is the vendor-specific decisions that would otherwise require a consultant who has done this integration before: which product modeling pattern for this catalog shape, which content-commerce sync approach, which auth middleware pattern for this framework version.

The output still requires human review — especially the product data model (which encodes business decisions) and the auth configuration (which is security-critical). A skill can encode vendor best practice, but it can also encode a vendor’s preferred happy path at the expense of edge cases.

Trade-offs

AdvantageDisadvantage
Skills package vendor-specific guidance that currently lives in docs and consultants’ headsSkill quality is unaudited; the ecosystem’s security and curation infrastructure is immature
Portable across 30+ agents — publish once, reach most of the tooling marketTwo layers to maintain (MCP server + Skills); vendors must keep both current as APIs evolve
Reduces reliance on the model’s training data for vendor-specific decisionsMay create false confidence — developers might skip reviewing agent output in high-stakes domains
Directly addresses the expertise gap (34% of brands lack vendor-specific talent)Skills encode individual vendor guidance; cross-vendor orchestration remains largely unsolved
Low incremental effort for vendors already maintaining MCP serversThe specification is young (December 2025); the boundary between “skill” and “tool” is still being negotiated

Key Takeaways

  • The hard part of MACH delivery is not API access. It is architectural planning, vendor configuration, bespoke integration code, and ongoing maintenance. These layers account for the majority of delivery cost — $500K+ engineering on top of $100K licensing is a documented pattern, not an edge case.
  • MCP solves a real but narrow problem. It standardises how agents reach individual vendor APIs. It does not help agents plan multi-vendor architectures, configure vendor systems to fit business needs, orchestrate across vendors, or manage integration maintenance.
  • Skills can address some of what MCP cannot — particularly vendor configuration guidance, integration pattern selection, and implementation sequencing. They are most valuable in high-configuration domains (commerce product modeling, CMS content modeling, identity flow setup) where vendor-specific expertise is scarce and the cost of getting it wrong is high.
  • Skills are not the only mechanism. Rich MCP resources, starter repos, CLI scaffolding tools, and curated prompt libraries can all deliver implementation guidance. Skills are the most portable option today, but what matters is that the guidance reaches the agent in structured, discoverable form — not which format wins.
  • The biggest gap is cross-vendor orchestration. Neither MCP nor Skills currently solve the coordination problem across a multi-vendor stack. MCP talks to vendors individually. Skills encode workflows per vendor or per integration pair. The full orchestration layer — sequencing across three or four vendors, handling partial failures, maintaining consistency — remains bespoke engineering work.
  • Vendor configuration is delivery work, not setup. Designing product types, content models, auth flows, and search relevance for a specific business is substantive, non-trivial work. The vendors that package guidance for this work — in whatever format — will reduce the most expensive part of composable delivery.

References