KDnuggets mostra como subir um servidor MCP stateless em Python com acesso via HTTP

Em 9 de outubro de 2026, o KDnuggets publicou um guia passo a passo intitulado «Build Your First MCP Server in Python (Stateless Spec Edition)». O texto mostra como escrever um servidor MCP em Python e expor via HTTP os três primitivos do Model Context Protocol: ferramentas (tools), recursos (resources) e prompts. A ênfase está na palavra stateless: o servidor não guarda a sessão entre as chamadas. O anúncio é curto, e os detalhes da edição da especificação precisarão ser conferidos na documentação oficial. Mesmo assim, a direção é clara: o protocolo usado para conectar agentes a sistemas externos está ficando mais simples de operar.

Por que o estado é a maior dor

O MCP foi concebido como uma forma única de conectar a um modelo de linguagem funções e dados externos. As primeiras implementações usavam stdio e conexões de longa duração. Para um protótipo local, isso é conveniente. Em produção, os problemas aparecem: a sessão precisa ser mantida em algum lugar, as requisições têm de ser roteadas para a mesma instância, o escalonamento horizontal fica mais complicado, e as plataformas serverless lidam mal com conexões longas.

A abordagem stateless elimina essas restrições. Cada requisição HTTP é autossuficiente: chega, é processada e recebe uma resposta. O servidor pode ficar atrás de um balanceador de carga comum, rodar em várias cópias e ser reiniciado sem perda de contexto. Se ainda for necessário manter estado, ele fica em um armazenamento externo, e não na memória do processo.

O que há no guia

O material é voltado a quem está montando o primeiro servidor MCP. Segundo o que consta no anúncio:

• Linguagem: Python
• Transporte: HTTP
• Primitivos: 3 (tools, resources, prompts)
• Modo: stateless, sem sessões entre requisições
• Fonte e data: KDnuggets, 9 de outubro de 2026

Os primitivos têm papéis distintos, e confundi-los na hora de projetar sai caro. Tools são funções que o próprio modelo chama: busca, requisição a uma API, gravação em banco de dados. Resources são dados endereçáveis por URI: arquivos, documentos, linhas de tabelas. Prompts são modelos de instruções prontos, que normalmente quem escolhe é o usuário ou o aplicativo cliente.

Vale notar que o guia opta por HTTP em vez de um processo local. Um servidor assim fica acessível a vários clientes e equipes, pode ser protegido com autenticação e monitorado como qualquer outro serviço de rede.

Como usar isso na prática

O melhor é começar pequeno. Crie uma ferramenta com assinatura e descrição claras: o modelo escolhe as funções justamente pela descrição, e um texto vago resulta em chamadas erradas. Depois, adicione um recurso e um prompt para ver os três primitivos em funcionamento. Teste o servidor com um depurador como o MCP Inspector antes de conectá-lo a um agente real.

Antes de ir para produção, vale verificar três coisas. Primeiro: a versão da especificação e a versão do SDK. A «edição stateless» significa que parte dos exemplos antigos pode se comportar de outra forma. Segundo: onde fica guardado tudo o que antes vivia na sessão. Carrinhos, tokens e resultados intermediários precisam ir para o Redis ou para um banco de dados. Terceiro: a autenticação e a limitação de permissões das ferramentas. Um servidor que pode gravar no banco de dados não deve ficar aberto para toda a internet.

Para equipes que desenvolvem agentes, o guia serve como ponto de partida. Ele não substitui a especificação, mas apresenta um esqueleto mínimo funcional, a partir do qual é possível evoluir para integrações próprias.