Skip to content
lci

MCP Server

lci mcp runs a Model Context Protocol server over stdio. It exposes 15 tools to AI assistants for searching and understanding a codebase without loading whole files into context.

Starting the server

Section titled “Starting the server”
Terminal window
lci mcp

Point your MCP client’s config at the lci binary with the mcp subcommand, for example in a Claude Code / Claude Desktop-style config:

{
  "mcpServers": {
    "lci": {
      "command": "lci",
      "args": ["mcp"]
    }
  }
}

Tool index

Section titled “Tool index”

| Tool | Output | Purpose | |------|--------|---------| | info | JSON | Per-tool help + server version | | search | JSON | Semantic + literal + regex content search | | find_files | JSON | File-path search (fuzzy / glob) | | get_context | JSON | Detailed context for object IDs or names, with call hierarchy + purity | | context | JSON | Save / load code-context manifests for agent handoff | | list_symbols | JSON | Enumerate + filter symbols (the “ls” for code) | | inspect_symbol | JSON | Deep inspect one symbol | | browse_file | JSON | Symbol outline for a file | | callers | JSON | Resolved call sites for a symbol | | index_stats | JSON | Index status + health | | debug_info | JSON | Deep diagnostics | | semantic_annotations | JSON | Query @lci: labels / categories | | side_effects | JSON | Function purity + side-effect analysis | | code_insight | LCF | Codebase intelligence (overview / stats / structure / git) | | git_analysis | JSON | Git change analysis (duplicates / naming / metrics) |

code_insight is the session-startup workhorse: repository map, health dashboard, entry points, complexity/coupling/cohesion statistics, module and feature breakdowns, naming vocabulary, and git change/hotspot analysis.

Conventions

Section titled “Conventions”
  • Invocation: standard MCP tools/call with a name and an arguments object. Every tool returns its payload as the text of a single content[] entry.
  • Output formats: most tools emit JSON. The analysis tools (code_insight) emit LCF (LCI Compact Format) — a token-dense, section-based text format (LCF/1.0\nmode=...\ntier=...\ntokens=...\n---\n followed by == SECTION == blocks).
  • Object IDs: search, list_symbols, inspect_symbol, code_insight, etc. emit short encoded object_id strings (e.g. VE, tG). Feed them to get_context {"id": "..."} (comma-separated for several) to drill in.
  • Errors: failures return a structured error result {"operation": "<tool>", "message": "...", "success": false} with the result flagged as an error. Tools fail fast — no fake/zeroed payloads.
  • Determinism: all list output is sorted with total-order tiebreakers (no hash-iteration order in user-visible output).
  • File attributes: every indexed file carries one attribute — production, test, benchmark, example, vendored, generated, docs, or one a project defines itself. Each attribute states which capabilities it activates: index, search, refs, analysis.

Analysis covers shipping code by default

Section titled “Analysis covers shipping code by default”

code_insight analyzes the files whose attribute activates analysis — production alone, until a project says otherwise. Its LCF header states the set (attributes=shipping), and == SUMMARY == names what was left out and where it lives:

excluded_from_analysis:
  test=195 (tests/ benchmarks/)
  benchmark=68 (benchmarks/)
  docs=1 (docs/)

Point it at the other trees with the attributes argument — "all", one attribute name, or a list:

{
  "name": "code_insight",
  "arguments": {
    "mode": "unified",
    "attributes": ["test", "benchmark"]
  }
}

A name the project does not have is an error listing the names it does have.

Defining attributes

Section titled “Defining attributes”

lci ships a default ruleset; .lci.kdl extends it, redefines a shipped attribute (patterns and capabilities are replaced, not merged), or declares attributes of your own. Lowest rank wins when several match one path.

attributes {
    test "src/legacy_tests/"        // extra pattern for a shipped attribute
    production "vendor/mycompany/"  // un-tag a builtin match


    internal-tooling rank=6 {       // an attribute of your own
        activates "index" "search"  // omit the line for the defaults;
        dir "scripts" "tools"       // list it empty to activate nothing
        glob "*.tmpl"
    }
}

An attribute that does not activate index keeps its files out of the index entirely; without search they stay indexed but never appear in results.

search example

Section titled “search example”
{
  "name": "search",
  "arguments": {
    "pattern": "myFunction",
    "output": "ctx",
    "max": 20
  }
}

search is in-memory content search (not file paths), designed for fast interactive use: literal match → semantic term and synonym expansion → regex fallback (flags=rx). Multiword semantic queries merge hits by source line and rank full term coverage above single-term matches. Identifiers containing every term rank highest: export dialog puts ExportDialog, exportDialog, and export_dialog ahead of separate or partial matches. Results carry the enclosing symbol’s metadata (object_id, symbol_name, symbol_type, is_exported).