Construindo um Servidor MCP: Um Exemplo Prático

Na semana passada, Greg Isenberg lançou um episódio do The Startup Ideas Podcast sobre distribuição em 2026. A tese: a IA comoditizou o código; o diferencial agora é a distribuição. Sua Estratégia #1 — de sete — foi "servidores MCP como sua equipe de vendas."

Eu comecei a construir um uma semana antes do episódio ser lançado. Então, em vez de teorizar, aqui está o exemplo prático: como é um servidor MCP comercial acabado, quanto custa enviar um e o que está realmente acontecendo no dia 7.

O que eu construí

Toolstem é um servidor MCP de dados financeiros. Ele expõe três ferramentas para agentes de IA:

• get_stock_snapshot(ticker) — cotação atual, principais índices, desempenho recente
• dcf_analysis(ticker, assumptions) — fluxo de caixa descontado com total transparência das suposições
• compare_stocks(tickers[]) — avaliação lado a lado entre N tickers

Está hospedado como um ator pago na Apify Store a $0,005 por chamada de ferramenta. Sem assinatura. Sem contratos. Sem chamadas de vendas humanas. Um agente o descobre, faz a chamada, é cobrado por chamada. O pagador do agente (um humano ou outro agente) eventualmente paga a passagem do agente.

Todo o processo é sem rosto. Não há foto do fundador. Não há LinkedIn do fundador. A marca é uma marca azul-escura e uma tipografia de ações. Este é o modelo operacional: IA compra de IA.

Por que o MCP é o verdadeiro jogo de distribuição

Esta é a parte que Greg acertou exatamente e a maioria das análises não.

Uma empresa SaaS típica gasta um terço ou mais da receita em ir ao mercado — representantes de vendas, marketing de conteúdo, conferências, anúncios pagos. Esse é o custo de lutar pela atenção humana.

Quando o comprador é um agente de IA, você não luta pela atenção. A estrutura do agente aponta para um diretório. O diretório expõe uma lista de ferramentas. A descrição da ferramenta e o esquema são todo o discurso de venda. Não há funil de conscientização, não há SDR, não há demonstração, não há sequência de e-mails. É uma das superfícies de distribuição mais sem atrito já construídas para software — se você realmente puder estar nesses diretórios com uma especificação limpa.

A formulação de Greg em o episódio: construir um servidor MCP em 2026 é como construir para mobile em 2010 — os primeiros a se moverem possuem o espaço do diretório.

Isso está correto, com duas ressalvas.

Ressalva 1: Muitos diretórios MCP existem; o jogo do diretório é real. Smithery, Glama, mcp.so, PulseMCP, o registro oficial modelcontextprotocol/servers, awesome-mcp-servers, a Apify Store. Cada um tem diferentes requisitos de submissão, diferentes sinais de classificação, diferentes públicos. Listar seu servidor em 6 deles leva uma semana. Este é um custo real.

Ressalva 2: A cópia publicitária "vibe codificada em um fim de semana" é enganosa. Um MCP demonstração pode ser codificado em um fim de semana. Um comercial — com a cobrança PPE configurada corretamente, um teste de fumaça que realmente captura regressões contra o deploy ao vivo, um pipeline de lançamento que não envia builds quebrados, uma demonstração padrão para as sondas de entrada vazia que as verificações de saúde do diretório disparam em você — leva mais tempo. Não semanas. Mas também não um fim de semana.

Arquitetura em três frases

O servidor MCP é um ator TypeScript rodando na Apify. As ferramentas envolvem a API gratuita da Financial Modeling Prep (limite de 250 chamadas/dia, 512MB/30d de largura de banda). A cobrança Pay-Per-Event da Apify é acionada em cada chamada de ferramenta bem-sucedida; a plataforma cuida da cobrança, cobra o chamador e paga mensalmente.

Fonte: github.com/toolstem/toolstem-mcp-server. Exemplos: github.com/toolstem/toolstem-mcp-examples.

Números do dia 7, honestamente

Esta é a seção que todo post de lançamento convenientemente ignora.

O episódio de Greg usa o exemplo de um MCP fintech que atingiu "150 instalações em 30 dias, $0 de gasto com anúncios, vibe codificado." Se isso for verdade, o criador fez algo certo que eu ainda não fiz. Estou passando esta semana tentando descobrir o que.

O que eu acho que é a lacuna

A distribuição é exatamente o que Greg disse que é: o trabalho. Construir foi a parte fácil. A construção levou ~2 dias de vibe-coding mais ~5 dias de endurecimento (testes de fumaça, pipeline de lançamento, publicação OIDC, demonstração padrão para sondas). A distribuição vai levar mais tempo do que a construção.

Aqui está o trabalho, classificado pelo que eu acho que vai mover mais a agulha:

1. Estar em todos os diretórios. Smithery e Glama estão ao vivo. mcp.so, PulseMCP, modelcontextprotocol/servers, awesome-mcp-servers todos em andamento esta semana. Isso é principalmente clerical.

2. Otimizar o README para motores de busca. O episódio menciona isso como Estratégia #4. Agentes de IA lendo o README para decidir se chamam a ferramenta precisam de uma prosa clara, estruturada e pronta para citação. Não cópia de marketing. Semântica direta.

3. SEO programático na documentação. Estratégia #2 do episódio. Cada ferramenta recebe uma página dedicada visando [nome da ferramenta] para agentes de IA. Cada comparação de ticker recebe uma página. Construa uma vez, compõe para sempre. (Peter Levels, segundo o mesmo episódio: referências de IA passaram de 4% para 20% em um mês.)

4. Enviar o segundo vertical rapidamente. A vantagem do primeiro a se mover nos diretórios é por vertical. MCP de arquivos da SEC a seguir; clima e probabilidades de esportes depois disso.

5. Karma nas comunidades certas. r/mcp, r/LocalLLaMA, o Discord da Anthropic. Não estou postando links — respondendo perguntas de forma substancial ao longo de semanas. Esta é uma distribuição lenta. É também a mais durável.

Não estou pagando por anúncios. Não estou comprando uma newsletter (ainda — essa é a Estratégia #6 do episódio e vou revisitar a $1K MRR). Não estou fazendo uma jogada de artefato viral. O plano é diretórios + AEO + presença na comunidade + envio de um segundo vertical.

O que eu diria a alguém construindo um esta semana

Três coisas.

Um: Construa para o leitor agente, não para o leitor humano. Nomes de ferramentas, descrições, esquemas de parâmetros — o agente tem que decidir se chama sua ferramenta apenas a partir do texto. Sem marketing. Sem esperteza. Linguagem funcional direta. Leia de volta como se você fosse Claude tentando escolher entre três ferramentas que parecem semelhantes.

Dois: Acertar a cobrança ou não importa. O ID de evento PPE da Apify em sua configuração deve corresponder exatamente ao eventName em sua chamada Actor.charge(). Eu enviei uma versão onde esses não correspondiam e descobri isso através de teste de fumaça, não de reclamação de usuário. Teste o caminho de cobrança antes de comercializar a listagem.

Três: Não subestime o trabalho de distribuição. O que Greg disse é verdade. A construção é a parte fácil. A distribuição é o que realmente importa.