OpenAI, Agents SDK에 MCP 지원 추가

 (openai.github.io)
8P by GN⁺ | ★ favorite | 댓글 4개
  • MCP(Model Context Protocol) 는 LLM에게 도구와 컨텍스트를 제공하는 표준화된 방식임
  • USB-C 포트처럼, 다양한 데이터 소스나 도구와 AI 모델을 연결하는 표준 인터페이스 역할을 함
  • OpenAI Agents SDK는 MCP를 지원하여 다양한 MCP 서버와 통합 가능함

MCP 서버

  • 현재 MCP 사양은 사용하는 전송 메커니즘에 따라 두 가지 종류의 서버를 정의함:
    1. stdio 서버는 애플리케이션의 하위 프로세스로 실행되며, "로컬"에서 실행되는 것으로 생각할 수 있음.
    2. HTTP over SSE 서버는 원격으로 실행되며, URL을 통해 연결함.
  • MCPServerStdio와 MCPServerSse 클래스를 사용하여 이러한 서버에 연결할 수 있음.
  • 예를 들어, 공식 MCP 파일 시스템 서버를 사용하는 방법은 다음과 같음: 
    async with MCPServerStdio(  
    params={  
        "command": "npx",  
        "args": ["-y", "@modelcontextprotocol/server-filesystem", samples_dir],  
    }  
) as server:  
    tools = await server.list_tools()

캐싱

  • 에이전트가 실행될 때마다 MCP 서버의 list_tools()를 호출하는 것은 지연 시간을 초래할 수 있음. 특히 서버가 원격 서버일 경우 더욱 그러함.
  • 도구 목록을 자동으로 캐시하려면 MCPServerStdio와 MCPServerSse에 cache_tools_list=True를 전달할 수 있음. 도구 목록이 변경되지 않을 것이라고 확신할 때만 이를 수행해야 함.
  • 캐시를 무효화하려면 서버에서 invalidate_tools_cache()를 호출할 수 있음.
GeekNews Weekly에 포함된 글입니다. 에디터 코멘트 보기

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견

  • 오늘 MCP가 Streamable HTTP를 추가했음. 이는 원격 HTTP 서버에 항상 연결할 필요가 없다는 점에서 큰 진전임

    • 하지만 사양을 보면 LSP 스타일 패러다임을 원격 HTTP 서버에 도입하는 것이 많은 복잡성을 추가하고 있음
    • 전통적으로는 /get_weather에 { "location": "New York" }를 HTTP POST로 보내는 방식이었음
    • 복잡성을 줄이고 전통적인 HTTP 서버로 돌아가자는 제안을 했음. 세션은 Authorization 헤더로 협상하고 전통적인 엔드포인트를 사용함
    • 서버 구축이 훨씬 쉬워지고 웹 프레임워크가 사양에 맞게 업데이트될 필요가 없을 것임

  • MCP를 AI 애플리케이션의 USB-C 포트로 생각하라는 비유가 있음

    • 소프트웨어 엔지니어로서는 그 비유가 도움이 되지 않음

  • OpenAI가 이를 공식적으로 지지할지 궁금했지만, 이제 답을 얻었음

    • MCP는 LLM을 외부 도구에 연결하는 산업 표준이 되었음

  • OpenAPI를 지원하기를 바랐음. 몇 개의 MCP 서버를 만들었지만 덜 유연하고 문서화가 잘 안 되어 있는 API로 느껴짐

    • MCP가 OpenAPI보다 나은 점을 찾기 어려움. 코드가 조금 줄어들지만 선택지가 훨씬 줄어듦
    • 시간이 지나면 Swagger가 내장될 것임

  • MCP의 가치가 무엇인지 이해하기 어려움. 현대 AI 기술의 혼란 속에서 또 다른 산만함으로 느껴짐

    • MCP는 애플리케이션이 LLM에 컨텍스트를 제공하는 방식을 표준화하는 개방형 프로토콜임
    • 표준화할 것이 무엇인지 의문임. 우리는 임의의 토큰화된 문자열로 작동하는 텍스트-텍스트 변환기를 사용하고 있음
    • 도구/기능 호출 같은 것도 단순한 텍스트 위에 있는 영리한 휴리스틱임

  • AI 에이전트가 로컬에서 "도구"를 사용할 수 있는 아키텍처를 만들었음. 모든 종류의 LLM 및 LLM 서버와 작동함

    • 미들웨어로 작동하며 LLM 서버와 채팅 클라이언트 사이에서 스트림으로 작동함
    • 오픈 소스 프로젝트이며, 코드에 관심을 보이는 사람이 없어 리포가 업데이트되지 않음

  • MCP를 실제로 어떻게 사용하는지에 대한 비디오가 부족함. 프로그래머에게 실질적인 사용 사례가 부족함

  • MCP를 AI 애플리케이션의 USB-C 포트로 생각하라는 비유가 있음

    • USB 구현에 많은 고통이 따른다는 이야기를 많이 들었기 때문에 다른 비유를 찾는 것이 좋을 것임

  • MCP의 구버전인 HTTP+SSE를 대상으로 하고 있는 것 같음. 새로운 Streaming HTTP 버전이 아님

    • OAuth 2.1 지원, JSON-RPC 배칭 등도 있음

  • MCP를 간단하게 시도해보고 싶다면 <a href="https://skeet.build/mcp" rel="nofollow">skeet.build/mcp</a>를 만들었음

    • 복잡한 MCP 설정, 지원 부족, 자체 구축의 어려움 때문에 만들었음
    • 주로 다음과 같은 워크플로우를 위해 사용됨
      • PR 시작 시 요약 작성
      • Linear/Jira에 요약 슬랙 또는 댓글
      • Sentry에서 이슈 가져와서 수정
      • 버그 발견 시 Linear 이슈 생성
      • Linear 이슈 가져와서 첫 번째 패스
      • Notion 문서와 PRD 가져와서 코드 기반으로 API 참조 생성
      • 빠른 모델 개발을 위한 Postgres 또는 MySQL 스키마
    • 사용 용이성, 실용적인 개발자 워크플로우, 고품질의 MCP 서버에 중점을 두고 있음
답변달기
samchon   [-]

저도 OpenAPI function calling 이 낫지 않나 생각이 듭니다. 이거 MCP 프로토콜로 다시 만드는 것도 일이거든요.

답변달기
mangoblue   [-]

push 와 poll 차이 아닐까요. 모델, 서비스마다 function calling 하는 것보다 mcp 스펙을 호스팅하고 에이전트가 poll 해가는 방식이 3rd party 한테는 편리항거 같습니다

답변달기