krabby

// what it does

Built for agents that read code all day.

Capabilities are served to your LLM or agent through separate read-only, API, and administration MCP catalogs.

Queries are fast

Graph query tools are answered in-process by a native Go engine that reads graph.json directly and hot-reloads on rebuild — no per-graph subprocess is spawned.

query_graph · get_node · shortest_path

Builds are cheap

Code extraction is AST-based — no LLM key needed. The graphify CLI is only invoked to build graphs incrementally.

graphify update

Docs & RAG

With an LLM configured, krabby generates per-file Markdown docs plus a repo overview — browsable in the UI. The prompt is configurable.

optional · search_docs

Web sources

Custom web URL collections and Confluence spaces are converted to Markdown and indexed beside repo docs. Search one collection like web:wine or everything at once.

list_sources · confluence

Regex & semantic code search

A byte-trigram index answers RE2 patterns with exact file, line and column hits — signatures, punctuation and line anchors a term index cannot express. With a code embedder, the same chunks also serve ranked semantic snippets.

regex · optional semantic · code/search

Symbol navigation

Definitions and references are read from the repository graph, not guessed from text: a definition is a node with a path and a line, a reference is a real incoming edge you can filter by context to ask "who calls this". File discovery is a path pattern away.

find_definition · find_references · glob

// how it fits together

One Go binary between agents and repos.

krabby · pipeline

+-----------------------------------------+
| LLM/Agent  --MCP---> krabby (Go)        |
| CI/webhook  --HTTP-> krabby (Go)        |
|                                         |
|  |- /mcp       read-only code + docs   |
|  |- /mcp/api   API discovery + calls   |
|  |- /mcp/admin mutations + settings    |
|  |- REST API + provider-neutral hook    |
|  |- Registry (bw/BadgerDB)              |
|  |- Native graph query engine (Go)      |
|  `- Scheduler (cron + intervals)        |
+-----------------------------------------+

Registry in embedded BadgerDB (bw) tracks every repo and credential.
Plain files on disk under ~/.krabby — clones, graph.json, reports and vectors are all readable by other tools.
Provider-neutral webhook at /webhook/git accepts common server formats with bearer / shared-token auth.

What a real code question looks like.

Krabby does not replace your coding agent. It gives the agent a repeatable route from a question to the indexed source, structural relationships, and exact lines.

USER QUESTION

“Where is payment retry backoff implemented, and what calls it?”

The repository is already indexed as github.com/acme/payments. No LLM or embedding model is required for this flow.

1
Locate the implementation
The agent starts with ranked source search. It passes the full repository id so similarly named code in other repositories cannot leak into the answer.
search_code { repo: "github.com/acme/payments", query: "payment retry backoff" }
2
Prove the relationship
Once the exact symbol is known, graph-backed references answer who calls it. The call context excludes imports, field types, and unrelated name matches.
find_references { repo: "github.com/acme/payments", symbol: "retryWithBackoff", context: ["call"] }
3
Read only the evidence
The agent opens the matched file around the reported location, then answers with real paths and lines instead of pasting an entire repository into its context.
read_file { repo: "github.com/acme/payments", path: "internal/payment/retry.go" }

WHAT YOU GET

A short explanation tied to the implementation file, the callers found through graph edges, and exact source locations your team can verify. For an architecture question, the agent switches to query_graph; for an exact pattern, it switches to regex search.

Investigate a production error

Search the error literal in regex mode, read its handling branch, then use git_blame and git_diff to explain when and why it changed.

Plan a safe refactor

Find a definition, list only its call references, and ask the graph for dependencies before touching the implementation.

Understand an unfamiliar service

Search generated docs for orientation, inspect the graph's core nodes, then read the source behind only the relevant result.

// get running

From container to first answer in three steps.

The image includes Krabby, Graphify, git, and SSH. Start it, add a repository, then give your agent read-only access.

shell — Docker

mkdir -p krabby-data

docker run -d \
  --name krabby \
  -p 8080:8080 \
  -v "$(pwd)/krabby-data:/data" \
  ghcr.io/rytsh/krabby:latest

# open the UI and add your repositories
http://localhost:8080

OpenCode — opencode.json

{
  "mcp": {
    "krabby": {
      "type": "remote",
      "url": "http://localhost:8080/mcp"
    },
    "krabby-api": {
      "type": "remote",
      "url": "http://localhost:8080/mcp/api",
      "enabled": false
    },
    "krabby-admin": {
      "type": "remote",
      "url": "http://localhost:8080/mcp/admin",
      "enabled": false
    }
  }
}

1. Add content. Open localhost:8080 and add a public repository. For a private repository, store its host credential first.

2. Wait for Ready. Cloning, graph extraction, and source indexing run in the background. Generated docs and semantic search remain optional.

3. Ask a concrete question. Try “Find where retries are configured, show every caller, and cite file paths and lines.” Keep krabby-admin disabled after setup.

/mcpEveryday code work

Read-only code, graph, files, history, and docs. Keep this enabled.

/mcp/apiLive API work

Discovers catalogued endpoints and can call them. Enable only when needed.

/mcp/adminSetup and changes

Adds, refreshes, or deletes managed resources. Disable it for normal analysis.