O que é um servidor MCP — e como fazer o primeiro que acende um LED num ESP32

Quase todo texto sobre MCP em português explica o protocolo com exemplos de banco de dados, planilha e API. Está certo — e deixa de fora a parte mais interessante: MCP também serve para hardware. O mesmo mecanismo que faz uma IA consultar um CRM faz ela ler um sensor, medir uma tensão e mover um servo. É disso que este artigo trata.

MCP em uma frase

O Model Context Protocol é um padrão aberto que descreve como um programa de IA conversa com ferramentas externas. Antes dele, cada aplicação inventava o seu jeito de dizer ao modelo "você pode chamar esta função". Com ele, quem escreve a ferramenta e quem escreve o aplicativo de IA seguem o mesmo contrato — e a ferramenta passa a funcionar em qualquer cliente compatível.

A analogia mais usada é a da tomada padronizada, e ela serve: o valor não está na tomada, está em não precisar de um adaptador diferente para cada aparelho.

As três peças

Para não se perder na documentação, guarde três nomes:

• Hospedeiro — o aplicativo com o qual você conversa. Pode ser um aplicativo de desktop, um editor de código ou um programa seu.
• Cliente — a parte do hospedeiro que fala o protocolo. Você raramente escreve isso.
• Servidor — o programa que você escreve. É ele que expõe as capacidades e faz o trabalho.

O servidor é sempre um processo separado. Ele pode rodar na mesma máquina, conversando por entrada e saída padrão, ou em outra máquina, por HTTP. Para bancada, o mais simples é o servidor rodar no seu próprio computador — o mesmo que tem o cabo USB ligado na placa.

O que um servidor expõe

Um servidor MCP pode oferecer três coisas. Para hardware, a primeira é a que importa:

1. Ferramentas (tools) — ações que o modelo pode executar: acender_led, ler_temperatura, mover_junta. É aqui que mora o perigo e a graça.
2. Recursos (resources) — dados que o modelo pode ler, identificados por um endereço. Um log de impressão, o datasheet da placa, a última bandeja produzida.
3. Prompts — roteiros prontos que o usuário escolhe. Menos usado no começo.

O primeiro servidor: um LED

O exercício mais honesto que existe. É pequeno, funciona em dez minutos e ensina o modelo mental inteiro. Você precisa de um ESP32 de prateleira, um cabo USB e um LED — o embutido na placa serve.

1. O firmware

A placa não precisa saber o que é MCP. Ela precisa receber um comando e responder. Um protocolo de uma linha por mensagem, em JSON, resolve e é fácil de depurar com qualquer terminal serial:

// entra {"cmd":"led","valor":1}  ->  sai {"ok":true,"led":1}
void loop() {
  if (!Serial.available()) return;
  String linha = Serial.readStringUntil('\n');
  if (linha.indexOf("led") < 0) return;
  int valor = linha.indexOf("\"valor\":1") >= 0 ? HIGH : LOW;
  digitalWrite(LED_PIN, valor);
  Serial.print("{\"ok\":true,\"led\":");
  Serial.print(valor == HIGH ? 1 : 0);
  Serial.println("}");
}

Teste pelo monitor serial antes de envolver qualquer IA. Se não funciona no terminal, não vai funcionar com o modelo — e você vai perder uma hora culpando o protocolo errado.

2. O servidor

O servidor é um programa comum. Ele abre a porta serial, declara as ferramentas e espera. Em Python, o esqueleto tem esta cara:

@servidor.ferramenta()
def acender_led(ligado: bool) -> str:
    "Liga ou desliga o LED da placa de testes."
    comando = {"cmd": "led", "valor": int(ligado)}
    porta.write(json.dumps(comando).encode() + b"\n")
    return porta.readline().decode().strip()

Três detalhes que decidem se vai funcionar bem:

• O nome da ferramenta é documentação. acender_led é melhor que set_gpio_2. O modelo escolhe a ferramenta lendo o nome e a descrição — não adivinhando.
• A descrição precisa dizer a unidade e o limite. "Tensão em volts, de 0 a 3,3" evita metade dos erros. "Valor" não evita nenhum.
• O erro tem que ensinar. {"erro":"pino 14 não é saída; use 2, 4 ou 5"} faz o modelo se corrigir sozinho. {"erro":"falhou"} faz ele tentar de novo igual.

3. Ligar no cliente

Você registra o servidor no aplicativo de IA que for usar — cada um tem o seu arquivo de configuração, e a documentação do seu cliente diz onde. Feito isso, a conversa muda de assunto:

Leia a temperatura a cada 5 segundos e acenda o LED quando passar de 30 °C.

E acontece. A primeira vez que uma frase digitada mexe em algo físico na sua mesa é um momento difícil de esquecer.

A parte que ninguém conta: segurança vem antes de potência

Um modelo de linguagem erra com confiança. Ele vai, em algum momento, pedir uma corrente que o seu circuito não aguenta ou deixar uma saída ligada por dez minutos. A defesa não é o prompt — é o firmware:

• teto de corrente e de tempo ligado, conferidos na placa, não no computador;
• watchdog que desliga tudo se o computador parar de responder;
• botão físico de parada, em série, que não passa por software nenhum;
• registro do que foi feito, com hora, para você saber depois o que aconteceu;
• nada que seja irreversível vira ferramenta sem confirmação humana.

Essa lista não é pessimismo: é o que separa um experimento divertido de uma bancada que você deixa ligada sem medo.

E o MHS?

Vale registrar, porque a dúvida aparece: em 27 de agosto de 2026 a Anthropic anunciou o MHS (Model Hardware Standard), uma prévia de pesquisa voltada a laboratórios, restrita a parceiros (informação verificada em 20/09/2026 — o status pode ter mudado desde então). Não é o que está aberto hoje, e não é por onde se começa. MCP é o que existe, funciona e está documentado. Quem aprende MCP agora não perde nada quando o resto abrir.

O próximo passo

Depois do LED vêm as perguntas boas: como a IA lê um sensor analógico sem se enganar com ruído, como ela varre um barramento I²C para descobrir o que está ligado, como conduzir um diagnóstico de placa com defeito. É exatamente esse caminho — do ESP32 de prateleira até um braço robótico obedecendo a uma conversa, com travas de segurança projetadas por você — que a gente percorre no curso.