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

Modelo Context Protocol dá a um cliente compatível uma forma padrão de descobrir ferramentas 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 pagamento 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 fornecedor ou um execute genérico. Cada ferramenta precisa de esquemas, âmbito da Store, risco, idempotência, tempo limite e falha clara. Resources podem explicar policy e catálogo, mas texto não confiável não concede ferramenta nem enfraquece validação.

Ferramentas 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 pagamento permitido ou ler seu pedido. O proprietário revisa rascunhos, alertas de inventário, descontos, pedidos e reconciliação apenas com o grant exato. Um Agent associado recebe só capacidades selecionadas e nunca herda responsabilidade, acesso ao fornecedor de pagamentos ou ferramentas 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 revisão verificações em rascunhos e idempotency keys para efeitos repetidos. Se o fornecedor der tempo limite, retorne unknown ou pending e reconcilie em vez de presumir sucesso.

Use OAuth ou identidade verificada com âmbito, 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 capacidade na execução. Grants devem ser revogáveis; separe leitura de write e falhe fechado para ferramentas desatualizado, 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 rascunho reversível e teste invalid, duplicate, desatualizado, entre contas, tempo limite e acesso revogado. Prostir Store está em Pré-visualização e foi desenhada para um commerce root, um Agent existente autorizado e https://{slug}.store.prostir.build/mcp; valide o adequação antes de trocar um caminho estável.