frigg

Frigg is a local-first, read-only MCP server built in Rust for code understanding. It scans local repositories, stores synchronized indexes in local SQLite, and gives AI agents fast, source-backed search and navigation across Rust, PHP, Blade, TypeScript / TSX, Python, Go, Kotlin / KTS, Java, Lua, Roc, and Nim, even when the relevant answer lives in another adopted repository. All supported languages participate in text search, symbol search, structural search, document outlines, and hybrid retrieval. Blade support is source-based and bounded.

It is built for the moment when an agent needs more than rg/fd/ast-grep: definitions, references, implementations, callers, structural queries, document outlines, and better answers to “which files matter here?”. Under the hood Frigg combines deterministic file manifests, Tree-sitter AST parsing, optional SCIP overlays for more precise navigation, and optional semantic retrieval. It is not a replacement for shell tools or your IDE. It is a context engine that brings more IDE-like code intelligence into MCP.

What To Use Frigg For

Use Frigg when the question is repository-aware and you want source-backed navigation instead of another raw repo scan.

jumping from a broad question to real code quickly with source-backed discovery, outlines, definitions, references, implementations, and call relationships
asking natural-language questions without giving up concrete anchors, matched paths, and navigable files
keeping one fast local index warm across one or more adopted repositories, so agents can move across shared code, related services, or neighboring projects without rebuilding context from scratch
getting a more IDE-like flow for agents in the terminal: discover the area, open the file, inspect symbols, and continue navigating from there

Installation

Cargo

Published crate:

cargo install frigg

Local checkout:

cargo install --path crates/cli

Homebrew

brew install bnomei/frigg/frigg

GitHub Releases

Download a prebuilt archive or source package from GitHub Releases, extract it, and place frigg on your PATH.

From source

git clone https://github.com/bnomei/frigg.git
cd frigg
cargo build --release -p frigg

For local performance work, Frigg also ships a small Criterion harness:

just bench
just bench native_lexical_search

Bundled Skill

Frigg ships a search-and-navigation skill in skills/frigg-mcp-search-navigation.

Use it as the repo-backed instruction bundle for any assistant that supports local or Git-backed skills. It explains:

when to use Frigg instead of plain shell reads or scans
how to adopt repositories and move through search, symbol, and navigation flows
how to treat lexical-only hybrid results, call-graph answers, and other weaker surfaces
how to use read_match, structural queries, and bounded follow-up tools efficiently

Quickstart

1) Prepare a repository

cd /absolute/path/to/repo
frigg init
frigg verify

Optional prewarm:

frigg reindex

When you run these commands inside the repository root, Frigg now uses the current directory as the default workspace root. If you run them from somewhere else, pass --workspace-root explicitly.

2) Start the recommended Frigg service

frigg serve

Keep that process running in its own terminal tab or background session. This is the Frigg service your MCP client connects to. frigg serve can start with zero startup roots, so you can keep one shared Frigg service running and let clients adopt repositories as needed. The usual flow is:

run frigg init / frigg verify inside each repository you care about
keep one frigg serve process running
point your MCP client at that running Frigg service

If you already know which repositories you want globally known at startup, you can still pass them explicitly:

frigg serve \
  --workspace-root /absolute/path/to/repo-a \
  --workspace-root /absolute/path/to/repo-b

frigg serve defaults to loopback HTTP on 127.0.0.1:37444. Startup roots become globally known repositories immediately, but watch leases are session-driven and start only after a session adopts a repository. The MCP endpoint is:

http://127.0.0.1:37444/mcp

3) Add Frigg to your MCP client

Point your MCP client at the loopback HTTP endpoint of the running Frigg service:

http://127.0.0.1:37444/mcp

Claude Code

claude mcp add --transport http frigg http://127.0.0.1:37444/mcp

OpenCode

opencode mcp add

Then choose a remote MCP server and enter:

name: frigg
url: http://127.0.0.1:37444/mcp

Codex

codex mcp add frigg --url http://127.0.0.1:37444/mcp

Other JSON-configured clients

Example MCP client config for an HTTP / streamable MCP connection:

{
  "mcpServers": {
    "frigg": {
      "transport": "streamable_http",
      "url": "http://127.0.0.1:37444/mcp"
    }
  }
}

The exact file name and field names vary by client, but the important part is that the client connects to the running Frigg service at that URL. In other words: this setup assumes frigg serve is already running in another terminal or background process. You are connecting to Frigg here, not asking the MCP client to spawn it.

How Frigg Uses Your Workspace

For each indexed repository, Frigg creates and maintains:

.frigg/storage.sqlite3: the local SQLite database for manifests, snapshot-scoped retrieval projections, search state, navigation data, semantic data, and provenance

Frigg can also read:

your source files under the configured workspace roots
optional .frigg/scip/*.scip or .frigg/scip/*.json artifacts for more precise definitions, references, implementations, and call navigation

Frigg does not modify your source tree during plain session adoption. workspace_attach by itself does not create .frigg state. Frigg writes .frigg/storage.sqlite3 only when indexing/preparing/reindexing paths run.

Showcases

The showcases/ directory contains 52 public example catalogs for real repositories. Each JSON file records realistic questions and the kinds of paths a good Frigg answer should surface.

Use Cases

Standard code search and navigation

Once Frigg is running, the normal workflow is:

Let your agent adopt repositories session-locally with workspace_attach. workspace_attach reports whether the session attached a fresh workspace or reused an already-adopted one, and it returns a compact precise-index summary for the selected repo. That summary now exposes state, failure_tool, failure_class, failure_summary, recommended_action, and generation_action so clients do not need to parse nested generator detail first.
Use search_hybrid as the discovery surface for broad questions, then pivot into read_match, read_file, document_symbols, go_to_definition, or search_symbol when you need precise anchors and deeper navigation.
Use workspace_prepare or workspace_reindex only when you intentionally want to initialize or refresh repository state from inside the client.
Use inspect_syntax_tree before search_structural whenever the tree-sitter node shape is unclear.

read_file and read_match now default to text-first output: the main MCP content block is the bounded source slice, and structured_content only keeps compact identity metadata such as repository, path, and effective line window. When a caller needs the older structured JSON payload with content, pass presentation_mode=json. In the extended profile, explore(operation=zoom) follows the same text-first default, while explore(operation=probe|refine) stays structured by default.

inspect_syntax_tree and search_structural accept include_follow_up_structural=true as an opt-in. When enabled, Frigg returns typed follow_up_structural suggestions that are replayable search_structural invocations derived from the resolved AST focus, not from the user's original query. Omitting the flag keeps the normal response shape unchanged. Phase 1 covers inspect_syntax_tree and search_structural; phase 2 extends the same contract to document_symbols, find_references, go_to_definition, find_declarations, find_implementations, incoming_calls, and outgoing_calls. The phase 2 surfaces require stable path, line, and column anchors, and they omit suggestions when no usable AST focus can be resolved. search_hybrid and search_symbol remain deferred.

search_structural now defaults to one row per Tree-sitter match instead of one row per capture. Use primary_capture when your query has helper captures but you want one specific capture to anchor the visible row, or switch to result_mode=captures when you want raw capture rows for debugging.

Typical prompts:

“Where is authentication bootstrapped?”
“Show me implementations of ProviderInterface.”
“Who calls handleWebhook?”
“Which files are relevant to the checkout flow?”

Optional semantic search

Semantic retrieval is off by default. When enabled, it improves recall for natural-language queries, but Frigg still grounds answer

Frigg

Install / Use

README