Frequently Asked Questions

LORE (LORE Oriented Runtime Engine) is a code archaeology and intelligence tool designed for AI-native development. It runs 13 deep analyzers on your codebase to understand its architecture, dependencies, and potential issues. When connected to an AI assistant via MCP, it gives Claude, Cursor, or Windsurf real structural understanding of your project rather than relying on file-by-file reading.

Code archaeology is the practice of deeply analyzing a codebase to understand its history, structure, and hidden relationships. Just as archaeologists dig through layers to understand ancient civilizations, LORE digs through your code to uncover hidden coupling, circular dependencies, complexity hotspots, and architectural patterns that aren't obvious from surface-level code reading. The name reflects LORE's philosophy: understanding the past of your codebase is essential for building its future.

Yes, LORE is completely free and open source under the MIT license. You can use it in personal projects, commercial applications, and enterprise environments without any cost or licensing restrictions. The MIT license is one of the most permissive open source licenses, allowing you to use, modify, and distribute the software freely.

LORE is built by Sami Benali (GitHub: EliotShift). It is an independent open source project maintained with care. Contributions, bug reports, and feature suggestions are welcome through the GitHub repository at github.com/EliotShift/lore-mcp.

LORE provides the richest analysis for TypeScript and JavaScript projects, with full support for .ts, .tsx, .js, and .jsx files. TypeScript projects benefit from additional type-aware analyzers including Type Safety Score and AST-based analysis. JavaScript projects still receive comprehensive structural analysis including dependency graph, circular dependency detection, entropy scoring, and coupling analysis. Support for additional languages (Python, Go, Rust) is on the roadmap.

LORE has been tested on projects ranging from 50 to 500+ files. The initial analysis on a 500-file project typically takes under 10 seconds. Subsequent runs use cached results and are significantly faster (under 2 seconds for incremental updates). For very large monorepos (1000+ files), you can use the .loreignore file to exclude generated code, test files, and directories that don't contribute meaningful architectural insight, which can dramatically reduce processing time.

LORE ships with 13 built-in analyzers organized into categories: Structure (Dependency Graph, Coupling Matrix, Import Impact, Middleware Chain), Quality (Circular Dependencies, Type Safety Score, Gap Analysis), Complexity (Entropy Scoring), Risk (Hotspot Analysis, Hidden Coupling, Breaking Changes), Intelligence (AI Recommendations), and Config (Tooling Config). Each analyzer can be run individually or as part of the full analysis pipeline. See the Commands page for details.

No, LORE is a read-only analysis tool by default. It only reads your source files to build its understanding of the architecture. It never modifies, deletes, or creates source code files. The only files LORE creates are in the .lore/ directory (cached analysis results, configuration, and reports) and the optional .loreignore file. The lore doctor --fix command can suggest and apply configuration fixes, but never touches your source code.

Absolutely. LORE supports JSON output (lore status --json) and SARIF format (lore status --sarif) which are ideal for CI/CD integration. The SARIF output is compatible with GitHub Code Scanning, allowing you to view LORE findings directly in your repository's Security tab. You can set quality gates in your CI pipeline based on LORE scores, such as failing the build if the type safety score drops below a threshold or if new circular dependencies are introduced.

MCP is an open standard by Anthropic that allows AI assistants to communicate with external tools and data sources. Think of it as a USB-C port for AI: a universal way to connect Claude, Cursor, Windsurf, and other AI tools to specialized services. When LORE runs as an MCP server, it exposes its analysis capabilities as tools that the AI can call directly, giving the AI assistant real-time access to your codebase's architecture without you manually copying analysis output.

Currently, the most popular MCP-compatible AI assistants include Claude Desktop (by Anthropic), Cursor (the AI-first code editor), and Windsurf (by Codeium). Any application that implements the MCP client specification can connect to LORE. The ecosystem is growing rapidly, and more tools are adding MCP support regularly. Check the official MCP documentation for the latest list of compatible clients.

Yes, you can configure multiple LORE instances in your MCP configuration, each pointing to a different project directory. Each instance runs independently with its own analysis cache and configuration. This is useful if you work on multiple projects simultaneously and want Claude or Cursor to have architectural understanding of each one. However, most users configure a single LORE instance per AI assistant session, pointing to their active project.

No. LORE runs entirely locally on your machine. All analysis happens within your process — no code, file contents, or analysis results are ever sent to external servers. When LORE runs as an MCP server, the analysis results are passed directly to your local AI assistant (Claude Desktop, Cursor, etc.) through the MCP protocol's local communication channel. Your code never leaves your machine.

No. The AI Recommendations analyzer uses local heuristic algorithms to generate improvement suggestions based on the analysis results. It does not call any external AI API. The recommendations are generated by pattern matching against known best practices and common code smells, not by sending your code to a cloud service. This ensures that LORE's recommendations work offline and maintain complete privacy.

If you discover a security vulnerability in LORE, please report it responsibly by opening a GitHub issue with the "security" label, or by contacting the maintainer directly through GitHub. Security issues are taken seriously and will be addressed promptly. Please do not publicly disclose vulnerabilities before giving the maintainer a reasonable opportunity to fix them.

There are several ways to get help: open a GitHub Issue for bugs or feature requests, start a GitHub Discussion for questions, or check the Commands and MCP Setup documentation pages for detailed guides. The community is active and responsive to questions.