Loading ToolBench
여러 소스의 지식을 단일 Postgres 임베딩 테이블로 수집하고 하이브리드 검색을 MCP로 노출하는 지식 베이스
Mixed quality across 9 tools. Strengths: all tools have descriptions (some detailed); clear verb-noun naming (search, get_document, list_sources, record_decision, record_learning); structured JSON output. Weaknesses: descriptions are inconsistent in length and clarity; parameter descriptions vary widely; no documented output schemas; error handling guidance absent; Korean descriptions reduce LLM clarity; some parameters lack type info in visible schema. Tools 1-3 (spikes/s4_mcp/server.py) show less rigor than tools 4-9 (src/kb/mcp_server.py). Average tool score ~62, ranging 45 - 75.
문서 원문 조회. Slack 스레드면 증류 결과(distilled)도 포함된다. context=1이면 문서의 청크 목록(헤딩 단위)도 함께 반환한다.
인덱싱된 소스 카탈로그: 소스/구획별 문서 수·최근 갱신·설명("무엇을 잘 답하나"), 프로젝트 목록. 무엇이 검색 가능한지 파악할 때(도구 선택 전에) 먼저 호출하라.
작업 주제에 대해 과거에 밟은 문제를 확인한다. 새 작업을 시작하기 전에 호출하라.
최근 N일 내 갱신된 문서(커밋/스레드/문서). source로 필터 가능.
작업 중 내린 중요한 결정을 기록한다. 기록 즉시 팀 전체가 검색할 수 있다.
삽질/버그의 원인과 예방책을 기록한다. 기록 즉시 팀 전체가 검색할 수 있다.
Output schemas not documented. Tools return JSON but LLMs cannot infer field structure (e.g., search returns {document_id, score, source, title, url, snippet, matched, context} but this is only visible in code, not in tool definition). Agents must guess downstream field names.
Descriptions in Korean reduce clarity for non-Korean-speaking LLMs and violate the pattern that descriptions should be prompt-engineered for LLM consumption. Korean descriptions like '지식 베이스 하이브리드 검색' are not machine-parseable by most LLM tokenizers optimally.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 54 | 2026-07-28+ | v2 |
지식 베이스 하이브리드 검색 (전문검색 + 벡터 + IDF (+trgm/문맥), 가중 RRF 융합, Slack 나이 감쇠). 정확 토큰(에러 문자열, 설정 키, 호스트명)과 자연어 개념 질문 모두에 동작한다. source: 'slack' | 'markdown' | 'gitlog' | 'code' | 'note' 필터. project: 스코프 이름 (토큰에 기본 프로젝트가 있으면 자동 적용 — 전체를 보려면 project="*"). 노트 결과의 project 필드는 그 기록의 소속 프로젝트(null=팀 공용)다. 스코프 검색에서 다른 프로젝트의 노트는 하향되고 matched에 'other-project'가 붙는다 — 증상이 같아도 프로젝트가 다르면 원인이 다를 수 있으니 주의해서 읽어라. expand=1~2면 매치된 청크의 이웃 청크를 context 필드로 복원한다(잘린 문맥 방지). rerank=true면 소형 LLM이 상위 후보를 재채점한다 (느리고 비용 발생 — 정밀도가 중요할 때만). 반환: [{document_id, score, source, ..., snippet, matched, context}]
ripgrep으로 코드 정확 매칭. 정규식 지원.
주제에 대해 실증된 활동(스레드 참여, 커밋)이 있는 사람을 찾는다. 검색 상위 문서들의 참여자/작성자 메타데이터를 집계한 결과다.
Parameter descriptions lack constraint details. E.g., 'limit' has no min/max bounds stated (code shows max 20 for search, max 50 for recent_changes, but descriptions omit this). 'expand' parameter in search lacks explanation of what 0-3 levels do. 'rerank' lacks cost/latency warning.
Error handling absent. No guidance on what to do if search returns empty, if document_id is invalid, if record_decision fails. Tools return JSON but no error classification (retryable vs user-fixable vs fatal). E.g., get_document returns {"error": "not found"} but LLM doesn't know if this is transient or permanent.
Tool composition risk: search and search_code are separate tools but LLM must reason about which to use. No guidance on when to prefer ripgrep (search_code) over hybrid search. No batch variants for agents calling record_decision/record_learning in loops.