OpenAI adiciona suporte a MCP ao Agents SDK

• MCP (Model Context Protocol) é uma forma padronizada de fornecer ferramentas e contexto para LLMs
• Assim como uma porta USB-C, ele atua como uma interface padrão para conectar modelos de IA a diversas fontes de dados ou ferramentas
• O OpenAI Agents SDK oferece suporte a MCP, permitindo integração com vários servidores MCP

Servidores MCP

• Atualmente, a especificação MCP define dois tipos de servidores, de acordo com o mecanismo de transporte utilizado:
  1. Servidores stdio são executados como subprocessos da aplicação e podem ser considerados como execução “local”.
  2. Servidores HTTP over SSE são executados remotamente e a conexão é feita por meio de uma URL.
• É possível conectar-se a esses servidores usando as classes MCPServerStdio e MCPServerSse.
• Por exemplo, a forma de usar o servidor oficial de sistema de arquivos do MCP é a seguinte:

  async with MCPServerStdio(  
      params={  
          "command": "npx",  
          "args": ["-y", "@modelcontextprotocol/server-filesystem", samples_dir],  
      }  
  ) as server:  
      tools = await server.list_tools()  
  

Cache

• Chamar list_tools() do servidor MCP sempre que o agente é executado pode causar latência, especialmente quando o servidor é remoto.
• Para armazenar automaticamente em cache a lista de ferramentas, é possível passar cache_tools_list=True para MCPServerStdio e MCPServerSse. Isso só deve ser feito quando houver certeza de que a lista de ferramentas não mudará.
• Para invalidar o cache, é possível chamar invalidate_tools_cache() no servidor.

[xguru]

Anthropic publica o Model Context Protocol como open source
Como desenvolver com o Model Context Protocol (MCP)
Explicação comparando MCP e API
Awesome MCP Servers - lista de servidores compatíveis com o Model Context Protocol

[GN⁺]

Comentários do Hacker News

• Hoje o MCP adicionou Streamable HTTP. Isso é um grande avanço, já que não é mais necessário manter conexão constante com um servidor HTTP remoto

  • Mas, olhando a especificação, trazer um paradigma no estilo LSP para um servidor HTTP remoto adiciona muita complexidade
  • Tradicionalmente, seria algo como enviar { "location": "New York" } via HTTP POST para /get_weather
  • Foi feita uma proposta para reduzir a complexidade e voltar a um servidor HTTP tradicional. A sessão seria negociada com o cabeçalho Authorization e usaria endpoints tradicionais
  • Isso tornaria a construção do servidor muito mais fácil e evitaria que frameworks web precisassem ser atualizados para se adequar à especificação

• Há uma analogia de que o MCP seria a porta USB-C das aplicações de AI

  • Como engenheiro de software, essa analogia não ajuda

• Eu me perguntava se a OpenAI daria suporte oficial a isso, e agora tenho a resposta

  • O MCP se tornou o padrão da indústria para conectar LLMs a ferramentas externas

• Eu esperava suporte a OpenAPI. Criei alguns servidores MCP, mas parecem APIs menos flexíveis e pior documentadas

  • É difícil encontrar em que o MCP é melhor que o OpenAPI. O código diminui um pouco, mas as opções ficam muito mais limitadas
  • Com o tempo, o Swagger acabará sendo embutido

• É difícil entender qual é o valor do MCP. Parece mais uma distração em meio à confusão da tecnologia moderna de AI

  • O MCP é um protocolo aberto que padroniza como aplicações fornecem contexto para LLMs
  • Fico em dúvida sobre o que exatamente precisa ser padronizado. Estamos usando transformadores de texto para texto que funcionam com strings tokenizadas arbitrárias
  • Coisas como chamada de ferramentas/funções também são apenas heurísticas inteligentes em cima de texto simples

• Criei uma arquitetura em que agentes de AI podem usar "ferramentas" localmente. Funciona com todos os tipos de LLM e servidores de LLM

  • Funciona como middleware e opera em fluxo entre o servidor de LLM e o cliente de chat
  • É um projeto open source, mas o repositório não é atualizado porque ninguém demonstra interesse no código

• Faltam vídeos mostrando como o MCP é realmente usado. Faltam casos de uso práticos para programadores

• Há uma analogia de que o MCP seria a porta USB-C das aplicações de AI

  • Como já ouvi muitas histórias sobre o sofrimento envolvido na implementação de USB, seria melhor encontrar outra analogia

• Parece que isso está mirando a versão antiga do MCP, HTTP+SSE, e não a nova versão Streaming HTTP

  • Também há suporte a OAuth 2.1, batching de JSON-RPC etc.

• Se você quiser testar o MCP de forma simples, eu criei <a href="https://skeet.build/mcp" rel="nofollow">skeet.build/mcp</a>

  • Foi criado por causa da configuração complexa do MCP, da falta de suporte e da dificuldade de montar algo por conta própria
  • É usado principalmente para fluxos de trabalho como os seguintes
    • Escrever um resumo ao iniciar um PR
    • Resumir no Slack ou comentar no Linear/Jira
    • Trazer issues do Sentry e corrigi-las
    • Criar uma issue no Linear ao encontrar um bug
    • Trazer uma issue do Linear e fazer uma primeira passada
    • Trazer documentação do Notion e PRDs para gerar referências de API com base no código
    • Esquemas Postgres ou MySQL para desenvolvimento rápido de modelos
  • O foco está na facilidade de uso, em fluxos de trabalho práticos para desenvolvedores e em servidores MCP de alta qualidade

[samchon]

Eu também acho que o function calling do OpenAPI talvez seja melhor. Até refazer isso com o protocolo MCP já dá trabalho.

[mangoblue]

Não seria a diferença entre push e poll? Em vez de cada modelo ou serviço fazer function calling, parece que, para terceiros, é mais prático hospedar a especificação MCP e deixar o agente fazer poll.