Por que MCPs genéricos de clima falham na navegação marinha (use boias NDBC)

Temos uma diretriz principal nesta pilha: se uma ferramenta utilizável já existe, melhore-a; construa a sua própria apenas como último recurso, e quando você mantiver a sua, registre por que cada alternativa falhou. Este post é essa auditoria para weather-mcp — um servidor MCP de clima marinho — em relação ao ecossistema weather-MCP, e a única mudança de capacidade que surgiu disso.

A versão curta: existem três servidores MCP de clima perfeitamente bons, e nenhum deles faz o que um navegador realmente precisa. As razões se generalizam para qualquer chamada "adotar um servidor MCP ou manter o seu próprio", então a auditoria é o post. Então a correção — analisar um segundo formato de arquivo NDBC para separar ondas de swell de ondas de vento — é pequena o suficiente para ser colada na íntegra, e trouxe à tona dados que o arquivo padrão havia descartado.

O problema, como você o procuraria

Você quer um agente para responder "o que os mares estão fazendo onde estamos?" e você vai procurar um MCP de clima marinho. Você encontra alguns. Cada um retorna uma previsão. Nenhum deles retorna o que uma boia a 12 milhas náuticas de distância está medindo agora. Essa lacuna — previsão vs. observado — é todo o trabalho, e é a única coisa que o ecossistema ignora.

Aqui está o que está disponível, e o que cada um está faltando para uso marinho.

Os candidatos

Três servidores reais, todos dignos do seu tempo pelo que foram construídos:

cmer81/open-meteo-mcp           ~13 ferramentas, JSON bruto do Open-Meteo direto
weather-mcp/weather-mcp         ~12 ferramentas, formato próprio, global; marinho = Open-Meteo
RyanCardin15/NOAA-Tides...      Estações CO-OPS: níveis de água + correntes, não boias

E o nosso:

sailingnaturali/weather-mcp     4 ferramentas, Python, 2 dependências de tempo de execução (httpx + mcp)
  get_marine_forecast            Open-Meteo vento/swell/onda de vento/mares/pressão
  get_marine_forecast_premium    Mistura Stormglass — 10 tokens/dia UTC, hits de cache grátis
  get_nearest_buoy_observations  NDBC observações de vento + ondas por lat/lon, com direção + idade
  get_stormglass_quota_status    leitura do livro de tokens, sem rede

Mapeado contra o que um navegador precisa:

O weather-mcp/weather-mcp README é admiravelmente honesto sobre a lacuna — para o mar, ele se direciona para a API Open-Meteo Marine, que é um modelo de previsão, não uma observação. Nenhum desses é um servidor ruim. Eles foram construídos para um agente de janela de chat que faz perguntas gerais sobre o clima. Estamos construindo para um agente de voz em um pequeno modelo local fazendo navegação. Alvo diferente, restrições de vinculação diferentes.

Três eixos de falha que se generalizam

Remova as especificidades marinhas e a auditoria se resume a três coisas que um servidor genérico não pode dar a um agente, além de uma que prejudica especificamente modelos pequenos.

1. Verificação de verdade de boia — observações, não apenas previsões

A doutrina central é "previsão vs. observado, priorize a observação." Uma previsão diz que os mares deveriam estar a 1,5 m; uma boia a 12 nm a montante diz que eles estão a 2,4 m e aumentando. O agente deve dizer a segunda coisa. Nenhum MCP de clima genérico faz observações — todos são APIs de previsão. A rede em tempo real NDBC é a fonte de dados, e envolvê-la é toda a razão pela qual nosso servidor existe.

2. Design de ferramenta ciente de cota

O provedor premium (Stormglass) tem uma parede dura de nível gratuito: 10 solicitações por dia UTC. Um agente que não pode ver esse orçamento irá queimá-lo em uma sessão de chat. Portanto, o orçamento deve ser expressável na própria superfície da ferramenta — uma ferramenta paga e uma ferramenta "quantos tokens restam?", emparelhadas:

# get_stormglass_quota_status — sem rede, apenas lê o livro
def get_stormglass_quota_status(quota: StormglassQuota) -> dict:
    ...   # usado / restante para o dia UTC atual

"Esta chamada custa 1 de 10 tokens diários; hits de cache são grátis" é uma propriedade de design da superfície da ferramenta, não uma nota de rodapé em um README. Nenhum servidor genérico modela custos, porque para uma API de previsão gratuita não há custo a ser modelado.

3. O contrato de exibição

Cada valor que nossas ferramentas retornam carrega uma string display pré-formatada e segura para TTS que o agente fala verbatim — porque modelos locais pequenos distorcem reformatando, e um motor de texto-para-fala pronuncia incorretamente unidades e códigos brutos. (Já escrevemos antes sobre por que a formatação pertence à camada da ferramenta, não ao prompt.) Um servidor que retorna JSON bruto da API empurra essa formatação para o modelo — a camada exata que falha. Servidores genéricos retornam cargas úteis brutas ou quase brutas. Isso é correto para um modelo de fronteira em uma janela de chat e desqualificante para o nosso.

E: inchaço de contagem de ferramentas

4 ferramentas vs. ~13, ~12, 25+. O campo MCP convergiu em um número real aqui: a precisão da seleção de ferramentas em modelos menores degrada à medida que a superfície cresce, e o conselho comum é manter um servidor na faixa de 5–8 e dividir domínios além de ~15. Uma superfície de 4 ferramentas curada não é minimalismo por si só — é a coisa que mantém um modelo de 8B escolhendo a ferramenta certa.

A decisão: manter, com recibos

De acordo com a diretriz, cada alternativa recebe uma razão registrada:

• open-meteo-mcp — cobre apenas o lado de previsão do Open-Meteo, retorna JSON bruto (quebra o contrato de exibição), ~13 ferramentas. Sem boias, sem premium, sem observações.
• weather-mcp/weather-mcp — mesmas lacunas, mais ferramentas, marinho é apenas previsão segundo seu próprio README.
• NOAA-Tides — níveis de água e correntes CO-OPS; sobrepõe-se ao domínio de um servidor de marés, não a um servidor de observação de ondas. Sem ondas de boia, sem previsões.
• Divisão (previsão de alguém + nossas boias) — dobra a superfície de configuração e a ferramenta mais chamada perde o contrato de exibição.

Mantenha a nossa. Agora feche sua maior lacuna documentada.

A reviravolta honesta: uma adoção em nível de biblioteca que também rejeitamos

"Preferir adotar" não para em servidores — há uma biblioteca que faz exatamente a análise NDBC que fazemos manualmente: CDJellen/ndbc-api, um pacote Python bem mantido para dados NDBC. A diretriz diz para usá-la. Nós não usamos, e a razão é uma cláusula que...