MCP para ecommerce: como a IA usa ferramentas da Store com segurança

Model Context Protocol dá a um cliente compatível uma forma padrão de descobrir tools nomeadas, ler resources limitados e chamar um servidor com argumentos estruturados. Ele não torna uma Store segura, não autoriza pagamento e não substitui checkout sozinho. O servidor MCP identifica o ator, valida cada entrada, aplica políticas do produto e da Store e retorna resultado tipado. O modelo é um cliente pedindo uma capacidade, não o dono do estado comercial.

Publique ações estreitas como search_catalog, get_product, create_cart_draft, request_checkout, get_order_status ou draft_catalog_update. Não exponha queries brutas, HTTP arbitrário, segredos do provider ou um execute genérico. Cada tool precisa de schemas, scope da Store, risco, idempotência, timeout e falha clara. Resources podem explicar policy e catálogo, mas texto não confiável não concede ferramenta nem enfraquece validação.

Tools de comprador e de gestão do criador vivem em superfícies de autoridade diferentes. O comprador pode buscar, comparar, preparar carrinho de uma Store, iniciar checkout permitido ou ler seu pedido. O proprietário revisa drafts, alertas de inventário, descontos, pedidos e reconciliação apenas com o grant exato. Um Agent associado recebe só capacidades selecionadas e nunca herda ownership, acesso ao provider de pagamentos ou tools de outra Store.

Produtos, preços, inventário vendável, pedidos, pagamentos, reembolsos, fulfillment, clientes e consentimento ficam nos serviços comerciais autoritativos. MCP traduz uma solicitação tipada e relata o resultado confirmado; não cria outra verdade da conversa. Use revision checks em drafts e idempotency keys para efeitos repetidos. Se o provider der timeout, retorne unknown ou pending e reconcilie em vez de presumir sucesso.

Use OAuth ou identidade verificada com scope, menor privilégio, sessões curtas, confirmação explícita para writes importantes e auditoria imutável com ator. Valide Store, identidade, valor, moeda, revisão de preço, estado e capability na execução. Grants devem ser revogáveis; separe read de write e falhe fechado para tools stale, ausentes, cross-Store ou ambíguas. Confirmação não substitui validação no servidor.

Codex, ChatGPT, GitHub Copilot e outros clientes variam em transporte, autenticação, discovery, approvals e administração; confira o cliente e plano exatos. Comece com catálogo ou status do pedido somente leitura, acrescente uma ação draft reversível e teste invalid, duplicate, stale, cross-account, timeout e acesso revogado. Prostir Store está em Preview e foi desenhada para um commerce root, um Agent existente autorizado e https://{slug}.store.prostir.build/mcp; valide o fit antes de trocar um caminho estável.