Meet dropins MCP for Edge Delivery

Meet @dropins/mcp.

I already wrote about the Commerce Developer Agent for App Builder. Same aio commerce extensibility tools-setup run, pick AEM Boilerplate Commerce, and you get this second server. npm currently ships 1.1.2.

It reads the drop-in packages in the repo and answers with real container names, slot names, and events. The agent does not have to guess.

This is not the App Builder pack

Two MCP servers land in the same installer. commerce-extensibility is events, webhooks, runtime actions. dropins is containers, slots, storefront events, design tokens, and block health. Ask a cart-slot question on the App Builder server and you get an IMS answer.

Adobe installs dropins MCP only for the AEM Boilerplate Commerce starter kit. Checkout and Integration kits skip it.

The hosted Developer Agent will not migrate a storefront onto Edge Delivery either. Adobe lists that under "not currently available." PDP work stays in the boilerplate repo.

What it reads

Drop-ins in this stack are npm packages under @dropins/storefront-*. The Commerce boilerplate already ships the B2C set. Each package has an initializer (scripts/initializers/), containers you render into an AEM block (CartSummaryList, SignIn, OrderSummary), and named slots on those containers.

The MCP reads that source. A generic model does not. I have watched agents invent LoginForm when the package exports SignIn. Same class of mistake as inventing cartItemActions when the cart container exposes Footer.

Adobe's connect-a-drop-in page is three imports. Auth looks like this:

import { SignIn } from '/@dropins/storefront-auth/containers/SignIn.js';
import { render as authRenderer } from '/@dropins/storefront-auth/render.js';
import '/scripts/initializers/auth.js';
 
export default async function decorate(block) {
  await authRenderer.render(SignIn, {
    routeForgotPassword: () => rootLink('/customer/forgot-password'),
    routeRedirectOnSignIn: () => rootLink('/customer/account'),
  })(block);
}

If the agent cannot produce that shape from the installed package, the MCP is not in the loop, or the skills were skipped.

How you get the server

Node 22+, a boilerplate storefront, an agent that loads MCP plus skills. Cursor is on Adobe's list.

From the project root:

npm install -g @adobe/aio-cli
aio plugins:install https://github.com/adobe-commerce/aio-cli-plugin-commerce
aio commerce extensibility tools-setup

Starter kit: AEM Boilerplate Commerce. Agent: Cursor. Restart Cursor. Skills land under .cursor/skills/. The installer starts @dropins/mcp with npx --yes @dropins/mcp, so there is no extra prompt.

Already in a boilerplate and you only want the MCP by hand:

{
  "mcpServers": {
    "dropins": {
      "command": "npx",
      "args": ["@dropins/mcp"]
    }
  }
}

That JSON is the dictionary. It is not the workflow. Adobe is blunt on the storefront AI install page: skip the skills, query tools raw, and the agent dumps a slot list into a random JS file. Put the priority in AGENTS.md. New work goes to /project-manager. Drop-in code goes to /dropin-developer. Questions about this storefront go to /researcher.

Login is optional for the storefront skills. aio auth login turns on live Commerce docs search. Without it, /researcher falls back to web search, and dropins MCP still answers from its local index. node_modules/@dropins/ TypeScript is the last fallback if the server is down.

npm update -g @dropins/mcp

The server prints a stderr warning on startup when a newer stable version exists.

Skills that call it

App Builder skills (/architect, /developer) do not write storefront blocks. These do.

Adobe's example prompt is the one I would paste first:

Use the planning workflow to add a social sharing button below the product title on the product detail page so shoppers can share products on social media.

It names an outcome, a page, and the planning workflow, so /project-manager runs before anyone writes JS. /researcher should then hit dropins:list_slots on product-details. If the agent skips that and starts editing CSS, stop it. A slot name that is not on the container will not render, and you will spend the next hour proving it.

Tools I would actually call

You can also ask for a tool by name. The skills page lists the ones the storefront skills use.

Use dropins:list_containers and dropins:list_slots for the cart drop-in. I need slot names and context shapes, not a tutorial.

Use dropins:explain_event_flow for wishlist/alert.

Run dropins:analyze_project and dropins:get_upgrade_diff. Tell me which drop-in versions drifted.

check_block_health is the one I care about after a package bump. It flags outdated container, slot, or API references in a block. That is the difference between "the docs still say Footer" and "this block calls a slot the 1.x cart package removed."

search_docs searches a local copy of storefront docs that ships with the server. It is not commerce-extensibility:search-commerce-docs, which needs IMS and hits Adobe's RAG over the wider Commerce set. Use both. Do not assume one covers the other.

A slot customization that is real

Tokens and CSS get you branding. Slots get you behavior. Adobe's cart boilerplate already shows the pattern: render WishlistToggle into the cart item Footer slot.

slots: {
  Footer: (ctx) => {
    const $wishlistToggle = document.createElement('div');
    $wishlistToggle.classList.add('cart__action--wishlist-toggle');
 
    wishlistRender.render(WishlistToggle, {
      product: ctx.item,
      removeProdFromCart: Cart.updateProductsFromCart,
    })($wishlistToggle);
 
    ctx.appendChild($wishlistToggle);
  },
}

Footer is a slot the cart container exposes. ctx.appendChild is one of the methods Adobe documents: prepend, append, replace, remove, onChange. They warn you not to call those methods inside onChange. Mount a wrapper once, then mutate it with normal DOM APIs. I have seen agents ignore that and leak nodes on every cart update.

If the MCP is working, /researcher confirms Footer and the shape of ctx.item before /dropin-developer writes the file. If it is not working, read the TypeScript in node_modules/@dropins/storefront-cart. That still beats prompting a model that has never opened the package.

What it will not do

It will not author the Universal Editor document for you. /content-modeler will sketch the table. It will not decide whether a slot is the right layer, or whether you should have stopped at a design token.

/tester wants a running npm start. Point it at a dead local server and you get a fake Core Web Vitals report.

Adobe's storefront AI page says the llms.txt fallback is weaker. It is not validated against this project's source. If MCP and skills are installed, do not paste that URL "just in case." You mix two sources and the agent picks the stale one.

Creating a new drop-in is a product decision. Adobe has a whole page on extend vs replace vs create. I would not prompt the MCP to invent one.

When I would actually use it

Day one on a client aem-boilerplate-commerce clone, before the first decorate function. analyze_project plus list_containers is faster onboarding than scrolling the drop-ins overview by hand.

I would use /researcher for any storefront change that injects into a container: extra PDP actions, cart line content, checkout extensions. Confirm the slot and the context shape, then write the block.

If you already set up the Developer Agent IDE pack for App Builder, rerun tools-setup in the storefront repo and pick the boilerplate kit. Same CLI. Different catalog of tools.

Official resources

• dropins MCP server
• Skills, prompts, and commands
• Install storefront AI integrations
• Boilerplate skills
• Drop-ins overview
• Connect a drop-in
• Container slots
• AEM Boilerplate Commerce
• @dropins/mcp on npm

If you try this on a real PDP, I want to hear which slot /researcher returned, and whether the first generated block compiled.