Pesquise um servidor MCP para Amazon Seller e encontrará três tipos de resposta na primeira página: intermediários alojados que vendem a ligação, repositórios de código aberto que pode executar e diretórios que indexam ambos. Todos descrevem a mesma capacidade quase com as mesmas palavras — faça perguntas sobre a sua loja em linguagem natural e receba respostas a partir dos seus dados reais.
Essa capacidade é real e vale a pena. Também é mais limitada do que a frase sugere, e é na distância entre as duas coisas que reside a desilusão.
O que é, de facto, um servidor MCP para Amazon Seller
O Model Context Protocol é uma forma de um cliente de IA chamar ferramentas definidas por outra pessoa. Um servidor MCP para Amazon Seller é um pequeno programa que encapsula a Selling Partner API — SP-API — e expõe os seus pontos de acesso como ferramentas que o seu cliente pode chamar. Nada disto é específico da Amazon; a mesma abordagem está a ser aplicada à Shopify, ao eBay, ao Stripe e a uma centena de outras APIs.
Os exemplos usados para os vender são consistentes e honestos: vendas e unidades por plataforma de comércio eletrónico no mês passado, quais os SKUs em risco de rutura de stock, taxa de devolução por categoria nos últimos noventa dias. São todas consultas de leitura a pontos de acesso que já existiam. A camada MCP eliminou a etapa de exportar um relatório e abrir uma folha de cálculo.
As três formas, e o custo de cada uma
Um intermediário alojado. Um fornecedor executa o servidor e dá-lhe autorização. É a forma mais rápida de começar e a única opção sem um processo local. Em contrapartida, os seus dados de vendedor passam por um terceiro que agora precisa de avaliar, e paga por utilizador ou por chamada.
Um repositório que executa por sua conta. Há vários no GitHub, alguns escritos explicitamente para o Claude Desktop. Nada fica entre si e a Amazon, que é precisamente a ideia. Mas agora gere um serviço: manter o processo em execução, acompanhar alterações na SP-API e renovar credenciais quando expiram.
Um cliente que comunica nativamente através do protocolo. Sem servidor separado, porque o cliente já é um cliente MCP e inclui o conector. Menos componentes, mas está a escolher o cliente em vez de acrescentar algo ao que já tem.
A parte que costuma ser ignorada
Os três caminhos convergem no mesmo pré-requisito, e quase nenhum guia começa por ele: precisa de uma aplicação SP-API própria. Isso significa registo de programador, escolha das funções que a aplicação solicita e credenciais LWA que expiram e precisam de ser renovadas.
Duas consequências surgem tarde. Primeiro, as funções são concedidas por categoria, e as funções restritas que abrangem dados pessoais do comprador seguem um processo de aprovação separado que a maioria dos vendedores não obtém nem precisa de obter. Segundo, a SP-API tem limites de frequência por endpoint, pelo que uma pergunta de uma frase pode transformar-se numa sequência de chamadas limitadas, e um cliente que volta a tentar silenciosamente vai consumir tokens enquanto espera.
Nada disto é um argumento contra fazê-lo. É um argumento contra a ideia de que «se configura em dez minutos».
O limite do que a recuperação oferece
Suponha que tudo funciona. Tem uma janela de conversa que informa que a sua taxa de devolução por categoria é 8,4% e que quatro SKUs vão ficar sem stock dentro de três semanas.
Nenhum dos dois números é uma decisão. A taxa de devolução só importa quando sabe se se trata de uma reclamação sobre o tamanho, de uma falha na embalagem ou de uma promessa que o anúncio nunca deveria ter feito — o que está no texto das avaliações, não no endpoint de devoluções. A rutura só importa em relação a um prazo de aprovisionamento e a uma estação do ano. E quando decide reescrever o anúncio, o modelo precisa de saber que a Amazon quer títulos densos em palavras-chave e cinco pontos dentro de um limite de caracteres, que as alegações de eficácia exigem provas, e quais os superlativos que levam à remoção do anúncio.
Isso é conhecimento do domínio. O MCP é transporte. Nunca iria fornecer esse conhecimento, e esperar que o forneça é um erro de categoria.
Onde entra o Orkas
O Orkas é um cliente MCP, pelo que qualquer servidor descrito acima funciona com ele como funciona com outros clientes. Também inclui o seu próprio conector do Amazon Seller Central — através da sua própria aplicação privada da SP-API, com credenciais cifradas no seu dispositivo e sem solicitar nem expor informações de identificação pessoal do comprador — pelo que, para esta integração, não há um servidor separado para manter em execução.
A parte mais importante é a camada acima. O Orkas inclui quatro competências de merchandising que incorporam o conhecimento do domínio que o protocolo não tem: pesquisa de categoria com os pressupostos de margem por escrito, criação de anúncios com regras por plataforma e verificação de conformidade, planeamento criativo desde cartões com motivos de compra até instruções para imagens e guiões visuais de vídeo, e análise de avaliações que anonimiza identificadores antes de agrupar reclamações em aspetos que pode alterar.
Funcionam com o que puder fornecer. Com um conector configurado, os dados chegam através da API. Sem ele, leem os relatórios que exportou — que é como a maioria dos vendedores já trabalha, e um ótimo ponto de partida.
O que isto não cobre
Um servidor MCP, nosso ou de qualquer outra pessoa, lê os dados que a sua conta de vendedor já guarda. Não fornece volume de pesquisa do mercado em linha, histórico de BSR ou estimativas de vendas de concorrentes; esses são conjuntos de dados licenciados, e as ferramentas que os vendem não são substituídas por um protocolo. Se a sua pergunta precisa desses dados, compre esses dados. Se a sua pergunta é o que fazer com os números que já tem, então trata-se de outra ferramenta e de outro artigo.