MCP para ecommerce: cómo usar herramientas Store con IA de forma segura

Model Context Protocol ofrece a un cliente compatible una forma estándar de descubrir tools con nombre, leer resources acotados y llamar a un servidor con argumentos estructurados. No vuelve seguro un Store, no autoriza un pago ni sustituye por sí solo el checkout. El servidor MCP debe identificar al actor, validar cada entrada, aplicar la política del producto y del Store y devolver un resultado tipado. El modelo es un cliente que solicita una capacidad, no el dueño del estado comercial.

Publica acciones estrechas como search_catalog, get_product, create_cart_draft, request_checkout, get_order_status o draft_catalog_update. No expongas consultas crudas, HTTP arbitrario, secretos del proveedor ni un execute genérico. Cada tool necesita schemas de entrada y salida, scope del Store, riesgo, idempotencia, timeout y fallo claro. Los resources pueden explicar política y catálogo, pero un texto no confiable no concede herramientas ni reduce controles.

Las tools de comprador y las de gestión del creador pertenecen a superficies de autoridad distintas. Un comprador puede buscar, comparar, preparar un carrito de un Store, iniciar un checkout permitido o leer su propio pedido. Un propietario revisa drafts, alertas de inventario, descuentos, pedidos y conciliación solo con el grant exacto. Un Agent vinculado recibe únicamente las capacidades seleccionadas y nunca hereda ownership, acceso al proveedor de pagos ni tools de otro Store.

Productos, precios, inventario vendible, pedidos, pagos, reembolsos, fulfillment, clientes y consentimiento permanecen en servicios comerciales autoritativos. MCP traduce una solicitud tipada y comunica el resultado confirmado; no crea una segunda verdad desde la conversación. Usa revisión optimista para drafts e idempotency keys para reintentos. Si un proveedor agota el tiempo, devuelve unknown o pending y reconcilia en vez de asumir éxito.

Usa OAuth o una identidad verificada y acotada, privilegio mínimo, sesiones breves, confirmación explícita para escrituras importantes y auditoría inmutable con actor. Valida Store, identidad, importe, moneda, revisión de precio, estado y capability al ejecutar. Los grants deben poder revocarse; separa read de write y falla cerrado ante tools obsoletas, ausentes, cross-Store o ambiguas. Confirmar no sustituye la validación del servidor.

Codex, ChatGPT, GitHub Copilot y otros clientes difieren en transporte, autenticación, discovery, approvals y controles administrativos; verifica el cliente y plan exactos. Empieza con catálogo u order status de solo lectura, añade una acción draft reversible y prueba casos inválidos, duplicados, stale, cross-account, timeout y acceso revocado. Prostir Store está en Preview y se diseña para un commerce root, un Agent existente autorizado y https://{slug}.store.prostir.build/mcp; valida el encaje antes de reemplazar una ruta estable.