TypeScript code relationship analyzer exposing Entity/Relationship/Evidence queries and context building via MCP tools
ContextSource MCP provides 6 well-structured tools for code relationship analysis with complete JSON Schema definitions and detailed descriptions in Korean. All tools have explicit input schemas with typed parameters, enums, and constraints (e.g., limit bounds 1-200, depth 0-5). Descriptions are substantive (100-300+ chars) and reference internal requirements (FR-Q2, ADR-0012). However, descriptions lack explicit guidance on WHEN to use each tool vs. alternatives, error recovery paths are minimal, and output schemas are not formally documented in the tool definitions themselves. Tool names follow verb_noun convention (search_, get_, build_) and are unambiguous. Parameter naming is consistent (id, limit, depth, direction). No security issues detected (read-only operations, no secrets exposed). Composition is sound, tools chain naturally (search_entities → get_entity → get_callers/get_callees → get_subgraph). Main gaps: no tool annotations (readOnlyHint present in metadata but not in schema), limited error guidance, and output structure not formally specified in tool definitions.
search_entities와 같은 방식으로 검색어에 맞는 seed Entity를 찾고, 거기서 양방향으로 뻗어나가며 발견한 Entity를 관계 우선순위(CALLS>IMPLEMENTS/EXTENDS>IMPORTS>DECLARES)와 hopDepth·confidence로 랭킹해 반환한다(ADR-0012, BENCHMARK.md 5.6). 각 항목은 왜 포함됐는지 설명하는 reason 문장과 그 근거(Evidence)를 함께 준다. query는 자연어 질문 자체가 아니라 그 질문에서 뽑아낸 검색어다 — 서버는 질문을 해석하지 않는다. tokenBudget(문자수/4 근사치)을 넘기 전까지 우선순위 순서대로 채우고, 넘으면 그 자리에서 멈춘다(truncated:true).
이 Entity가 호출하는(나가는 CALLS) Entity 목록을 Evidence와 함께 반환한다 (FR-Q3).
이 Entity를 호출하는(들어오는 CALLS) Entity 목록을 Evidence와 함께 반환한다 (FR-Q3).
Entity 상세 정보와 들어오는/나가는 관계 개수를 반환한다 (FR-V2).
지정한 Entity를 기준으로 direction/depth 안의 서브그래프(Entity+Relationship+Evidence)를 반환한다. 영향 분석(direction=in)이나 구조 설명에 사용한다 (FR-Q4, FR-AI1). maxNodes와 includeSnippets=false로 토큰 예산을 제어할 수 있다 (FR-AI3). 전체 그래프 덤프는 제공하지 않는다.
Entity를 이름(부분 일치)/종류/파일 경로(접두 일치)로 검색한다. 관계 탐색의 시작점으로 사용한다 (FR-Q2).
Output schemas not formally documented in tool definitions. Tools return JSON but LLMs cannot see expected field structure, types, or required vs. optional fields. Downstream tool chaining requires guesswork.
Tool annotations (readOnlyHint, idempotentHint) present in metadata but not exposed in MCP tool schema. LLMs cannot see that all tools are read-only and safe to retry.
Error handling lacks recovery guidance. 'ENTITY_NOT_FOUND' error shown but no suggestion to call search_entities first or alternative actions. Descriptions do not explain prerequisites or dependencies between tools.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
Descriptions in Korean only. While technically complete, non-Korean-speaking LLM clients and developers cannot understand tool purpose, constraints, or usage patterns. Descriptions should be in English for maximum interoperability.
Parameter descriptions lack format/constraint details. E.g., 'id' parameter described as 'Entity의 canonical id' with example format but no formal pattern or validation rule. LLMs cannot reliably construct valid IDs.