LORE는 TypeScript 프로젝트를 위한 플러그인 기반 코드 고고학 엔진입니다. AST를 파싱하고, 의존성을 매핑하며, 순환 의존성을 감지하고, 비동기 체인을 추적하며, 타입 안전성을 점수화하고, **MCP(Model Context Protocol)**를 통해 AI 코딩 어시스턴트에게 아키텍처 지능을 제공합니다.
EliotShift 제작 · 16개의 실제 프로젝트에서 검증됨 · 100% 통과율.
AI 코딩 어시스턴트는 빠르게 코드를 작성하지만 아키텍처 메모리가 부족합니다. 다음과 같은 내용을 기억하지 못합니다:
어떤 파일들이 밀접하게 결합되어 있는지
순환 의존성이 어디에 존재하는지
어떤 타입들이 경계를 넘어 퍼져 있는지
어떤 파일이 너무 자주 변경되는지(핫스팟)
아키텍처 계층이 무엇인지
LORE는 CLI 분석 및 MCP 서버 통합을 통해 AI 어시스턴트에게 코드베이스 아키텍처에 대한 깊은 이해를 제공함으로써 이 문제를 해결합니다.
Related MCP server: Continuum
# | 분석기 | 기능 |
1 | AST 파서 | ts-morph + 정규식 하이브리드를 사용한 전체 TypeScript/TSX 파싱 |
2 | 의존성 그래프 | 프로젝트 전반의 모든 import, export, re-export 매핑 |
3 | 순환 의존성 감지기 | 순환 참조를 찾고 심각도별로 순위 지정 |
4 | 의존성 방향 검사기 | 계층 규칙 강제 (예: 컨트롤러 → DB import 금지) |
5 | 섀넌 엔트로피 | 파일별 복잡도 점수 산정 (단순 → 매우 복잡) |
6 | 핫스팟 분석 | Git 변경 이력 감지 — 너무 자주 변경되는 파일 |
7 | Import 영향 분석기 | 모든 import의 영향 범위 표시 |
8 | 타입 안전성 점수 |
|
9 | 숨겨진 결합 감지기 | 공유 타입을 통한 암시적 의존성 발견 |
10 | AI 권장 사항 | 우선순위가 지정된 수정 제안 (P0–P3) |
11 | 도구 설정 검사기 | ESLint, Prettier, tsconfig 설정 검증 |
12 | 브레이킹 체인지 감지기 | 고위험 폐기 패턴 플래그 지정 |
13 | 아키텍처 격차 탐색기 | 누락된 추상화 및 패턴 식별 |
Claude Desktop, VS Code, Cursor 또는 모든 MCP 클라이언트에 LORE를 노출하세요:
도구 | 설명 |
| 전체 프로젝트 분석 — 점수, 위반 사항, 복잡도, 핫스팟 |
| 상태 점수: 전체, 타입 안전성, 도구, 아키텍처 |
| 순환 의존성, 계층 위반, 아키텍처 격차 |
| AI 개선 제안 (P0–P3) |
| Git 변경 빈도가 높은 파일 (빨강/노랑/초록) |
| 섀넌 엔트로피 복잡도 보고서 |
| 파일 import, export, 소비자, 복잡도 |
| 심층 TS 분석: 프레임워크, 계층, 비동기 체인, 타입 흐름 |
리소스 | 설명 |
| 최신 분석 결과 (JSON) |
| 심층 아키텍처 그래프 (JSON) |
| 환경 및 캐시 상태 (JSON) |
lore [path] Analyze project (default: cwd)
lore analyze [path] Explicit analysis
lore init Extract architectural decisions
lore status View decisions by category
lore diff Diff against saved baseline
lore doctor Environment + tooling check
lore doctor --fix Auto-fix project setup
lore ignore List/manage ignore patterns
lore watch Watch + re-analyze on change
lore mcp inspect Inspect MCP server setup
lore mcp config Claude Desktop config snippet
lore version Show version페이지 | 설명 |
전체 기능 개요, 배지 및 빠른 시작 | |
npm, npx 및 Docker 설치 | |
모든 CLI 명령어: init, status, doctor, watch, diff 등 | |
Claude Desktop, Cursor 및 Windsurf 설정 | |
Express, NestJS, Next.js 등의 실제 분석 사례 | |
자주 묻는 질문 |
npm install -g lore-mcp# Analyze current project
lore
# Analyze a specific project
lore ./my-typescript-project
# Check environment and auto-fix
lore doctor --fix
# Watch for changes
lore watch --filter src/
# Diff from last baseline
lore diffClaude Desktop 설정에 다음을 추가하세요:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"lore": {
"command": "npx",
"args": ["-y", "lore-mcp"]
}
}
}또는 전역으로 설치된 경우:
{
"mcpServers": {
"lore": {
"command": "lore",
"args": ["mcp"]
}
}
}Claude Desktop을 재시작한 후 다음을 질문하세요:
"Analyze my project architecture" → LORE가
analyze_architecture실행 "What are the circular dependencies?" → LORE가get-violations실행 "Which files are hotspots?" → LORE가get-hotspots실행 "What are the AI recommendations?" → LORE가get-recommendations실행
lore-mcp/
├── src/
│ ├── algorithm/ # LoreGraph, AST parser, async chain builder, type tracker
│ ├── algorithms/ # AI recommendations, hotspot analysis, entropy, scoring
│ ├── analyzer/ # Dependency parsers, circular deps, direction, imports
│ ├── commands/ # CLI: doctor, diff, ignore, init, status, watch
│ ├── core/ # Plugin system, pipeline runner, graph engine
│ ├── lib/ # Hidden coupling, gaps, middleware chain, ontology
│ ├── mcp/ # MCP server + architecture bridge
│ ├── output/ # Formatter, markdown, SARIF, logger
│ ├── plugins/built-in/ # 13 built-in analysis plugins
│ ├── storage/ # Cache and decision store
│ ├── types/ # TypeScript type definitions
│ ├── cli.ts # CLI entry point
│ └── index.ts # MCP server entry point
├── package.json
└── tsconfig.jsonLORE는 플러그인 기반 아키텍처를 사용합니다. 모든 분석기는 플러그인입니다:
interface LorePlugin {
name: string;
version: string;
analyze(context: AnalysisContext): Promise<PluginResult>;
}내장 플러그인: circular-deps, coupling-matrix, dep-direction, entropy, gaps, hidden-coupling, hotspot, import-impact, middleware-chain, breaking-changes, type-safety, tooling-config, ai-recommendations.
파싱 — LORE는 ts-morph + 정규식 하이브리드 파서를 사용하여 모든 .ts/.tsx 파일을 파싱합니다.
그래프 구축 — 타입이 지정된 엣지(import, type-ref, decorator, async-chain, implements, extends)를 사용하여 의존성 그래프를 구성합니다.
플러그인 실행 — 13개의 분석기가 플러그인 파이프라인을 통해 병렬로 실행됩니다.
점수 산정 — 상태 점수(타입 안전성, 도구, 아키텍처, 전체 0–100)를 계산합니다.
권장 사항 — AI 엔진이 우선순위가 지정된 제안(P0 중요 → P3 권장)을 생성합니다.
제공 — 결과는 CLI 출력, MCP 도구 또는 SARIF 형식을 통해 제공됩니다.
프로젝트 | 파일 수 | 결과 | |
Express | 42 | 100% 통과 | |
Next.js | 68 | 100% 통과 | |
Fastify | 55 | 100% 통과 | |
NestJS | 38 | 100% 통과 | |
Prisma | 45 | 100% 통과 | |
Zod | 35 | 100% 통과 | |
TypeORM | 60 | 100% 통과 | + 9개 더 |
16개 테스트 프로젝트 모두: 100% 통과율, 충돌 없음.
Node.js >= 18.0.0
TypeScript 프로젝트 (.ts 및 .tsx 파일 분석)
Git (선택 사항, 핫스팟 분석용)
ripgrep (선택 사항, 더 빠른 파일 검색용)
구성 요소 | 기술 |
언어 | TypeScript 5.5+ |
AST 파싱 | ts-morph 21 |
프로토콜 | Model Context Protocol (MCP) SDK 1.0 |
전송 | Stdio (Claude Desktop / IDE 호환) |
검증 | Zod 스키마 |
출력 | ANSI 터미널, Markdown, SARIF |
MIT © 2025 EliotShift
Get all architectural decisions for this project. Call this at the START of every session to understand the codebase.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Filter by category (optional) | |
| query | No | Search for specific decisions (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool retrieves decisions but doesn't describe key behaviors: whether it returns all decisions at once or paginates, what format the output is in, if there are rate limits, or authentication requirements. The instruction to call at session start implies it's foundational but lacks operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and front-loaded: two sentences with zero waste. The first sentence states the purpose, and the second provides usage guidance, both earning their place without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool that likely returns complex data (architectural decisions). It covers purpose and high-level usage but lacks details on output format, error handling, or behavioral constraints. For a retrieval tool with 2 parameters and no structured output info, this is minimally adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both optional parameters ('category' and 'query') with descriptions. The description doesn't add any meaning beyond what the schema provides—it doesn't explain how filtering or searching works, example categories, or query syntax. Baseline 3 is appropriate when the schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get all architectural decisions for this project.' It specifies the resource (architectural decisions) and scope (this project). However, it doesn't explicitly differentiate from sibling tools like 'get_gaps' or 'record_decision' beyond implying this is for retrieval rather than recording.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Call this at the START of every session to understand the codebase.' This gives clear context for when to use it (session initialization). However, it doesn't specify when NOT to use it or mention alternatives like the sibling tools, leaving some gaps in comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find architectural gaps — decisions that were made but may not be fully implemented.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'Find architectural gaps' but does not disclose behavioral traits such as what data sources are used, whether it's a read-only operation, potential side effects, or output format. This leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of finding architectural gaps, no annotations, and no output schema, the description is incomplete. It lacks details on how gaps are identified, what the output includes, or any behavioral context, making it insufficient for an agent to fully understand the tool's operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description does not add parameter details, but this is acceptable as there are no parameters to explain, maintaining clarity without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Find') and resource ('architectural gaps'), explaining these as 'decisions that were made but may not be fully implemented.' It distinguishes from siblings like 'get_context' and 'record_decision' by focusing on gap identification rather than context retrieval or decision recording.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. The description implies usage for finding architectural gaps but does not specify prerequisites, exclusions, or comparisons to sibling tools, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record an architectural decision. Call this whenever you make a technical choice that affects the codebase structure.
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | Category: database, authentication, architecture, api, testing, deployment, security, performance, other | |
| decision | Yes | Short description of the decision made | |
| reason | Yes | Why this decision was made | |
| alternatives | No | Alternatives that were considered and rejected | |
| constraints | No | Constraints or rules that should not be violated | |
| author | No | Who made this decision |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the action ('record') but doesn't disclose behavioral traits like how the decision is stored, if it's immutable, requires permissions, or has side effects. This is a significant gap for a tool with mutation implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the purpose and usage without any wasted words. It's appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description adequately covers purpose and usage but lacks details on behavior, return values, or error handling. For a mutation tool with 6 parameters, it's minimally viable but has clear gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters. The description adds no additional meaning beyond implying the tool is for recording decisions, which aligns with the schema but doesn't enhance parameter understanding. Baseline 3 is appropriate as the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('record') and resource ('architectural decision'), specifying it's for technical choices affecting codebase structure. It distinguishes from siblings like 'get_context' and 'get_gaps' by focusing on recording rather than retrieving, but doesn't explicitly differentiate beyond that.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context on when to use ('whenever you make a technical choice that affects the codebase structure'), which implicitly distinguishes it from sibling tools that likely retrieve information. However, it lacks explicit exclusions or named alternatives for similar recording tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.5get_contextget_gapsrecord_decisionScored across 3 tools
Each tool has a clearly distinct purpose: get_context retrieves existing decisions, get_gaps identifies implementation issues, and record_decision logs new choices. There is no overlap in functionality, making tool selection straightforward for an agent.
All tools follow a consistent verb_noun pattern (get_context, get_gaps, record_decision) with clear, descriptive names. The naming style is uniform and predictable throughout the set.
Three tools are appropriate for the server's purpose of managing architectural decisions, covering retrieval, gap analysis, and recording. While slightly minimal, each tool serves a distinct and necessary function without redundancy.
The tool set covers the core lifecycle of architectural decisions: retrieving context, identifying gaps, and recording new decisions. A minor gap exists in updating or deleting decisions, but agents can likely work around this for basic workflows.
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
AI Agent with Architectural Memory. Impact analysis (free), tests and code from the graph (pro).
Shared memory for coding agents. Stop re-explaining your codebase every session.
Codebase intelligence for AI agents — dead code, blast radius, ownership.
