Toolport: 토큰 낭비 없이 원하는 만큼 MCP 서버 사용하기

좋네, 이 문제에 관심 있는 사람이 또 있다니 반갑네.

멀티 툴 호출: 각각의 호출이 메타 툴을 거쳐 독립적으로 하위 서버로 라우팅되니까, 서로 다른 서버에 대한 호출은 동시에 실행돼(stdio 서버는 어차피 한 번에 하나만 처리 가능하니까 서버별 락을 걸었음). 아직 내부 호출에 대한 배칭은 안 했어.

감사 추적에 동의해. 지금은 호출 로그(모든 호출, 어떤 서버인지, 타이밍, 어떤 클라이언트가 만들었는지)랑 실제 요청/응답 바이트를 보여주는 라이브 인스펙터가 있어. 네가 말한 '뭐가 보였는지 + 왜 이 도구가 선택됐는지 + 모델이 본 정확한 스키마'는 한 단계 더 깊은 내용인데 아주 좋은 아이디어야. 검색 단계 자체가 로그로 남는 호출이라 '뭐가 돌아왔는지'는 어느 정도 알 수 있지만, 순위나 선택 이유, 스키마 스냅샷을 보여주는 건 아직 안 되어 있어. 추가할게.

그럼 에이전트가 toolport_call_tool을 호출할 때, toolport_search_tool에서 발견한 대상 도구의 이름이 담긴 JSON이랑, 대상 도구의 인자(args)를 위한 JSON 객체를 제공해야 하는 거지?

잘 만들었네, 이거 진짜 오랫동안 찾고 있었음. pi 코딩 에이전트 지원도 추가해 줄 수 있음? 여기 사용자들 많이들 로컬 에이전트 코딩할 때 pi 쓰거든.

Toolport v1.2.0 버전이 Pi 지원과 함께 출시됨 https://github.com/tsouth89/toolport/releases

코드는 안 봤지만 괜찮다면 몇 가지 질문 좀 할게.

이게 그 악명 높은 회사의 '도구 검색 도구(Tool Search Tool)'랑 같은 개념이야?

그건 그렇다 치고, 스키마는 어떻게 처리해?

토큰을 잡아먹으니까 스키마를 안 보낼 것 같은데, 그러면 추론 엔진이 출력 구조가 올바른지 보장할 수가 없잖아. 그리고 에이전트들이 간접적으로 도구를 호출하는 방식에 익숙하지 않을 것 같기도 하고?? 그래서 좀…

좋은 질문이야. 맞아, Anthropic의 도구 검색 도구와 핵심 개념은 같아.

스키마에 대해서 말하자면, 검색 결과가 매칭된 각 도구의 전체 입력 스키마를 반환하니까 모델은 자기가 곧 사용할 몇 개의 도구에 대해서는 스키마를 받게 돼. 전부 다 미리 로드하는 대신 필요할 때만 로드하는 거지. 다만 내부 호출에 대한 문법 수준의 강제는 안 돼. 모델은 toolport_call_tool({name, arguments})라는 메타 도구를 호출하는데, 여기서 arguments는 열린 객체(additionalProperties: true)라서 제약이…

이거 그냥 fastmcp 쓰면 기본적으로 어느 정도 구현 가능한 거 아냐?