LOREは、TypeScriptプロジェクト向けのプラグインベースのコード考古学エンジンです。ASTを解析し、依存関係をマッピングし、循環参照を検出し、非同期チェーンを追跡し、型の安全性をスコアリングします。そして、Model Context Protocol (MCP) を通じて、AIコーディングアシスタントにアーキテクチャの知見を提供します。
EliotShiftによって構築 · 16の実プロジェクトで実戦テスト済み · 合格率100%
AIコーディングアシスタントは高速にコードを書きますが、アーキテクチャの記憶が欠けています。以下のようなことを記憶できません：
どのファイルが密結合しているか
循環依存がどこにあるか
どの型が境界を越えて広がっているか
どのファイルが頻繁に変更されているか（ホットスポット）
アーキテクチャのレイヤーがどうなっているか
LOREは、CLI分析とMCPサーバー統合を通じて、AIアシスタントにコードベースのアーキテクチャに対する深い理解を与えることで、この問題を解決します。
Related MCP server: Continuum
# | アナライザー | 機能 |
1 | ASTパーサー | ts-morphと正規表現を組み合わせた完全なTypeScript/TSX解析 |
2 | 依存関係グラフ | プロジェクト全体のすべてのインポート、エクスポート、再エクスポートをマッピング |
3 | 循環依存検出器 | 循環参照を見つけ、深刻度順にランク付け |
4 | 依存関係方向チェッカー | レイヤー規則の強制（例：コントローラーからDBへのインポート禁止） |
5 | シャノンエントロピー | ファイルごとの複雑性スコアリング（単純 → 非常に複雑） |
6 | ホットスポット分析 | Gitチャーン検出 — 変更頻度が高すぎるファイルを特定 |
7 | インポート影響分析 | すべてのインポートの爆発半径（影響範囲）を表示 |
8 | 型安全性スコアラー |
|
9 | 隠れた結合検出器 | 共有型を通じた暗黙的な依存関係を見つける |
10 | AI推奨事項 | 優先順位付けされた修正提案（P0–P3） |
11 | ツール設定チェッカー | ESLint、Prettier、tsconfigの設定を検証 |
12 | 破壊的変更検出器 | リスクの高い非推奨パターンにフラグを立てる |
13 | アーキテクチャギャップファインダー | 不足している抽象化やパターンを特定 |
LOREをClaude Desktop、VS Code、Cursor、または任意のMCPクライアントに公開します：
ツール | 説明 |
| プロジェクト全体の分析 — スコア、違反、複雑性、ホットスポット |
| ヘルススコア：全体、型安全性、ツール、アーキテクチャ |
| 循環参照、レイヤー違反、アーキテクチャのギャップ |
| AIによる改善提案（P0–P3） |
| Gitチャーンが高いファイル（赤/黄/緑） |
| シャノンエントロピー複雑性レポート |
| ファイルのインポート、エクスポート、コンシューマー、複雑性 |
| 詳細な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ウェブサイト: eliotshift.github.io/lore-mcp
ページ | 説明 |
全機能の概要、バッジ、クイックスタート | |
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を再起動し、以下のように尋ねてください：
"プロジェクトのアーキテクチャを分析して" → LOREが
analyze_architectureを実行 "循環依存関係はどこにある？" → LOREがget-violationsを実行 "ホットスポットになっているファイルはどれ？" → LOREがget-hotspotsを実行 "AIからの推奨事項は何？" → 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。
解析 (Parse) — LOREは、ts-morphと正規表現を組み合わせたハイブリッドパーサーを使用して、すべての .ts/.tsx ファイルを解析します
グラフ構築 (Build Graph) — 型付きエッジ（import, type-ref, decorator, async-chain, implements, extends）を持つ依存関係グラフを構築します
プラグイン実行 (Run Plugins) — 13のアナライザーがプラグインパイプラインを通じて並列実行されます
スコアリング (Score) — ヘルススコア（型安全性、ツール、アーキテクチャ、総合0–100）を計算します
推奨 (Recommend) — AIエンジンが優先順位付けされた提案（P0 致命的 → P3 あれば望ましい）を生成します
提供 (Serve) — 結果は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.
