acp-agentic-commerce/skills/acp-checkout-mcp/SKILL.md
Implement ACP checkout as an MCP server, exposing checkout operations as MCP tools. Use when building an MCP-based commerce server for AI agents that use tool-calling to complete purchases.
npx skillsauth add orcaqubits/agentic-commerce-claude-plugins acp-checkout-mcpInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Fetch live docs:
acp agentic commerce protocol MCP server implementation for MCP binding guidancehttps://developers.openai.com/commerce/specs/checkout/ for checkout operation semanticssite:github.com agentic-commerce-protocol MCP for any official MCP examplessite:github.com modelcontextprotocol python-sdk or typescript-sdk for current SDKACP's REST checkout operations can be exposed as MCP tools via an MCP server. This allows AI agents that use tool-calling (Claude, ChatGPT, Gemini) to invoke checkout operations directly as tools rather than making raw HTTP calls.
Each REST checkout operation becomes an MCP tool:
| REST Operation | MCP Tool Name | Description |
|---------------|---------------|-------------|
| POST /checkout_sessions | create_checkout_session | Create a new checkout session with items |
| POST /checkout_sessions/{id} | update_checkout_session | Update session (items, address, fulfillment) |
| GET /checkout_sessions/{id} | get_checkout_session | Retrieve current session state |
| POST /checkout_sessions/{id}/complete | complete_checkout_session | Submit payment to finalize |
| POST /checkout_sessions/{id}/cancel | cancel_checkout_session | Cancel the session |
Each MCP tool accepts JSON input matching the corresponding REST request body. The tool's inputSchema should be derived from the ACP OpenAPI spec's request schemas.
Each tool returns the CheckoutSession object (or error) as JSON, matching the REST response body.
AI Agent (Claude/ChatGPT)
↓ tool call (JSON-RPC)
MCP Server (your code)
↓ business logic
Checkout Service (same logic as REST)
↓ payment
PSP (Stripe)
The MCP server wraps the same business logic that the REST endpoints use. The checkout service layer should be shared between REST and MCP bindings.
idempotency_key as a tool parameterapi_version as a tool parameter or server configurationtype/code/message structureFetch the latest ACP OpenAPI spec and MCP SDK documentation for exact schemas and server setup before implementing.
development
Build with Spree's headless Next.js storefront — the official `spree/storefront` repo (Next.js 16 App Router with Server Actions and Turbopack, React 19 Server Components, Tailwind CSS 4, TypeScript 5, `@spree/sdk`, Sentry), server-only auth (httpOnly JWT cookies + publishable key), MeiliSearch faceted catalog, one-page checkout with Apple/Google Pay/Klarna/Affirm/SEPA, multi-region market routing, GA4 + JSON-LD SEO, and Vercel/Docker deployment. Use when forking or customizing the storefront, or evaluating headless adoption.
tools
Build Spree extensions as Rails engines — gem scaffolding, `bin/rails g spree:extension`, mounting routes/migrations/assets, the modern `prepend` decorator pattern (`*_decorator.rb` with `self.prepended(base)`), generators (`spree:model_decorator`, `spree:controller_decorator`), the four customization surfaces in preference order (Events > Webhooks > Dependencies > Decorators), Spree::Dependencies for swapping service objects, gem release/versioning, and the deprecated Deface engine. Use when building a reusable Spree extension or adding non-trivial customization to an app.
development
Build with Spree's event bus and Webhooks 2.0 — `Spree::Events` publication, `Spree::Subscriber` DSL with `subscribes_to` and `on`, wildcard matching, lifecycle events (`{model}.created/.updated/.deleted` via `publishes_lifecycle_events`), the canonical event catalog (order.*, payment.*, shipment.*, product.*), Webhooks 2.0 endpoints, HMAC-SHA256 signing (`X-Spree-Webhook-Signature`), exponential-backoff retries, and Sidekiq job orchestration. Use when wiring event-driven business logic, building webhook consumers, or replacing ActiveSupport callback chains.
tools
Cross-cutting Spree development patterns — the customization preference hierarchy (Events > Webhooks > Dependencies > Decorators), `Spree::Dependencies` service-object swapping, the `_decorator.rb` + `prepend` + `self.prepended` idiom, idempotent subscribers and webhook receivers, multi-store scoping discipline, prefixed IDs, calculator polymorphism (shipping/promotion/tax share the base), service-object composition with `dry-monads` or simple results, why to avoid `class_eval` reopening and Deface, and Spree-on-Rails idioms (Hotwire/Turbo Stimulus, ActiveStorage, Action Cable, Sidekiq). Use when designing the architecture of a Spree extension or solving cross-cutting concerns.