
semhood
io.github.AhmeedGamilPublished by GitHub account AhmeedGamilv0.1.0Updated Oct 24, 2026
AST-based semantic code search; results ship with their call graph (calls + callers).
Overview
semhood is a local MCP server for AST-aware semantic code search, letting an assistant find code by intent and get each result with its call graph.
- What you can do
- Search the indexed codebase semantically, run several searches in one call, and look up symbols by exact name, with results grouped per query or symbol type and file locations attached. Retrieve a chunk's full source together with what it calls and what calls it, so callers and callees come back in one response. Check index status to confirm the project is indexed. Support agent-driven enrichment by listing chunks pending an LLM summary, saving summaries the agent writes, and checking enrichment progress.
- When to use it
- Useful when an assistant works in a codebase and should find relevant functions by describing behavior instead of grepping and reading many files, saving tokens. Best for indexed projects where call-graph context matters, such as tracing how a function is used or where a rule is enforced.
- Requirements
- Runs as a local process on the user's machine, launched with the semhood-mcp command; the package is on PyPI and can be run with uvx. Needs Python 3.11 or newer and a project indexed first with the semhood index command. The first index downloads an embedding model of roughly 420 MB. A background daemon holds the index and loads the model once. No API keys are needed for local embeddings; optional enrichment uses an LLM provider key such as ANTHROPIC_API_KEY or OPENROUTER_API_KEY, or the agent's
Installation
In SourceWeft
- Open semhood in the dashboard and add it to a workspace.
- Enable the server for the chats that should use its tools.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Other MCP clients
Follow the launch instructions in the repository.
README
semhood
Stop grepping. Find the exact code your AI agent needs by intent, not keywords. semhood is an AST-aware semantic code search engine that retrieves code by what it does, complete with call-graph context and optional LLM enrichment.
Runs fully offline with zero API keys — or plug in cloud embeddings — Voyage's code-specialized models, or OpenAI's strong general-purpose (natural-language) embeddings — for higher-quality retrieval. Optional LLM enrichment adds a logic summary and developer queries to each chunk that you commit once and share — and every result ships with its call graph (what it calls + what calls it).
[License: MIT] [Build Status] [MCP] [Tree-sitter]
Why semhood · Install · Quickstart · MCP Setup · Architecture · Config · Troubleshooting
semhood indexes your codebase the way a developer thinks about it: every function, method, and class becomes a chunk, with its call graph, docstring, and signature attached. You search by intent ("how do we retry transient payment failures?") and get back the few chunks that actually answer the question.
Two stages: structural (always, free, ~seconds) and enrichment (optional, LLM or code agent, drains a pending queue). The index is queryable after stage 1; stage 2 just makes natural-language matches sharper.
The package ships an MCP server so Claude Desktop, Cursor, Cline, Continue, Kiro, Zed, and any other MCP-aware client can call semhood as a tool — your AI agent gets search, find_symbol, and get_chunk_context next to its built-in read_file and grep.
What makes semhood different
Most code search embeds your raw source and hopes a natural-language query lands near it. semhood adds two things plain vector search and grep can't:
🧠 Enrichment that thinks like a developer
An LLM reads each function and class and writes two artifacts, each stored as its own search vector:
- A logic summary — what the code actually does, in plain language. Not its name, not its signature — its behavior.
- Predicted developer questions — the real questions an engineer would ask to find this code: "how do we retry a failed payment?", "where are customer emails validated?"
This is the part that makes retrieval click. When you search with a question, you're matching against questions the code was pre-labeled to answer — so the right chunk wins even when it shares zero keywords with your query. You generate the enrichment once, commit it to git, and your whole team — and every AI agent — retrieves better for free. → Portable enrichment
Why enrichment matters: some code has no words to search. Plain semantic search only works when the source contains language close to your question. Plenty of important code doesn't — terse names, raw math, business rules. Consider a function like:
Ask "how do we calculate compound interest?" and plain vector search comes up empty — there's no "interest", no "compound", nothing in the source that means anything close to the question. Enrichment reads the code and generates:
Now your question matches a pre-written question that means the same thing, and _calc ranks first — despite sharing zero words with your query. The cryptic-but-critical functions are exactly the ones plain semantic search misses and enrichment rescues.
🕸️ Every result ships with its call graph
Each chunk knows what it calls and what calls it. So a result isn't just "here's the function" — it's the function plus its neighborhood. One get_chunk_context call returns the body, calls, and called_by together, so your AI agent gets the caller/callee context in the same response instead of opening files and tracing references by hand.
Features
- Retrieval-boosting enrichment — an LLM gives each chunk a plain-language logic summary + predicted developer questions, indexed as their own vectors so question-style queries hit the right code even with zero shared keywords. Written once, committed to git, shared with the team.
- Call graph included — each result knows what it calls and what calls it, so your agent gets the neighborhood, not just the function
- AST-aware chunking via Tree-sitter — every function, method, and class becomes a first-class searchable unit
- Hybrid retrieval — dense vectors (
code,description,developer_queries) + BM25 sparse, all in one query - Token-efficient for AI agents — replaces dozens of
read_file+grepcalls with onesearch - MCP server out of the box — works with Claude Desktop, Cursor, Cline, Continue, Kiro, Zed
- 10 languages — Python, JavaScript, TypeScript, Java, Go, PHP, C#, Ruby, Rust, C++
- Free tier works — local embeddings + structural pipeline need zero API keys
- Incremental indexing —
--changedre-indexes only whatgit difftouched
Install
Prefer an isolated CLI install? pipx keeps semhood and its deps out of your global environment — recommended for a command-line tool:
Just want to try it without installing? With uv, run it straight from PyPI:
Requires Python 3.11+. First index downloads the embedding model (~420 MB for the default
all-mpnet-base-v2) and caches it.
60-second quickstart
No config files, no API keys, no setup. semhood works offline with a local
embedder by default. Just cd into any project and index it:
The first command auto-starts a background daemon that loads the embedding
model once and keeps it warm — so every later search (from any terminal or
your editor) is instant. Each project gets its own index automatically under
~/.semhood/indexes/, keyed by repo root. One global config lives at
~/.semhood/config.yaml (created on first run); there is no per-project
config file to manage.
CLI commands
All commands act on the current project (nearest git root of your cwd). Override with
--root /path/to/repo. They're thin clients to the daemon — no model loading, noconfig.yamlflag.
MCP — wire it into your AI editor
The package ships an MCP server (semhood-mcp) that exposes eight tools — five for search, three for agent-driven enrichment:
Register it once, globally — it then works in every project you open, with no per-project setup. This is the entire config — drop it into your editor's user-level MCP file:
Where that file lives, per editor (click to expand)
A few clients use a slightly different shape — e.g. VS Code's native MCP uses a top-level
"servers"key instead of"mcpServers". If yours differs, keep thecommand: "semhood-mcp"part and match the client's MCP docs for the wrapper.
That's the whole config — no config.yaml path, no per-project entry. The
server is a thin proxy: it forwards each call to the warm daemon, tagged with
the project the editor currently has open (its nearest git root). Most editors
launch the server with the workspace as the working directory, so this Just
Works; if yours doesn't, pass the root explicitly:
After restarting the editor, the agent sees semhood.search,
semhood.find_symbol, etc. The daemon loads the model once for the whole
machine — so no matter how many editors and terminals you have open, there's
one model in memory and every call is ~80 ms.
Teach the agent when to use it (optional)
The MCP server gives the agent the tools; a short skill teaches it to reach for semantic search before grep/read. Install it once, user-level, into every AI editor you use:
Supported: Claude Code (skill), Cursor & Windsurf (rules), Kiro (steering),
Codex (AGENTS.md). It writes to each editor's own convention at the user
level — so, like everything else here, it's set up once and applies to every
project. Re-run any time to update in place.
Why this matters for token usage
Without semantic search, an AI agent asked "where do we validate emails?" runs grep -r email, gets 200 hits, and reads dozens of files. With semhood it calls search("validate email"), gets 3 ranked chunks back as JSON (~500 tokens), and reads only what it needs.
Worked example — "How does the OrderService validate orders?"
I indexed sample_project/, then asked exactly that. The agent calls two MCP tools and is done — no read_file, no grep.
Step 1 — search narrows the question to a few candidates
The _validate method ranks #1. The class and place_order rank just below — useful context, not the answer.
Step 2 — get_chunk_context pulls the body, calls, and called_by without opening the file
That's the entire answer: three checks (non-empty, minimum total, email contains @), called once from place_order. Total cost: ~1.4 KB of JSON, two MCP calls, sub-second.
Compared to the grep-then-read alternative — open orders.py (3.5 KB), scan for validate, then trace into place_order to confirm the call — the MCP path uses roughly 40% of the tokens and skips file I/O entirely.
Two ways to enrich
Stage 2 (description / developer_queries vectors) needs an LLM. You pick how:
Option A — direct API
semhood calls Claude / GPT / OpenRouter / Ollama itself.
Best for CI, batch jobs, or users without an AI editor. Set llm.provider + llm.<provider>.api_key in config.yaml.
Option B — your AI agent does it
Skip the API key. The agent in your editor (Claude in Cursor, Kiro, Cline, Continue, etc.) loops over pending chunks via the MCP tools and writes summaries itself. No semhood-side LLM cost. Just say:
"enrich the codebase index"
The agent uses list_pending_enrichments → writes summary → save_enrichment → repeats until enrichment_progress reports zero pending. Uses the model + subscription you already pay for.
Portable enrichment — pay once, share, survive model changes
Enrichment (the LLM-written summaries + developer queries) is the only part of semhood that costs tokens. semhood persists that text to .semhood/enrichment.jsonl in your repo, keyed by each chunk's content hash — separate from the vector index (which lives in ~/.semhood/indexes/ and is disposable).
Commit .semhood/enrichment.jsonl to git. Doing so gives you:
- Share across a team — a teammate clones, runs
semhood index, and the enrichment is restored from the file and re-embedded locally. They pay zero LLM tokens for code that's already enriched. - Survive embedding-model changes — switch from a local model to Voyage/OpenAI, run
semhood index --reset, and your enrichment is re-embedded into the new vector space with no re-enrichment. (Without this, changing models meant re-paying for everything.) - Survive branch switches / reverts — old records are kept as a content-addressed cache, so checking out an older revision reuses its enrichment instantly.
It's content-addressed, so it's always safe: if a chunk's code changed, its hash misses and that chunk is simply re-enriched — stale summaries can never attach to changed code. Run semhood compact to prune records no longer referenced by any code. The file holds only text and contains no secrets.
OpenRouter — one key, every model
If you don't want to manage Anthropic + OpenAI + Google accounts separately, point semhood at OpenRouter:
Use any supported model slug. Same semhood enrich and semhood query commands as before.
Architecture
Three named dense vectors per chunk: code (always), description (post-enrichment), developer_queries (post-enrichment), plus a bm25 sparse vector. Pre-enrichment, search still works on code + BM25 alone.
Stage 1 (semhood index) parses files with Tree-sitter, builds the call graph, computes a source hash, embeds the raw source into the code vector, and upserts to Qdrant. No LLM calls. Every chunk lands in state pending.
Stage 2 (semhood enrich) drains the pending queue through an LLM, generating a logic_summary + 5–10 developer_queries per chunk, embedding them into the description and developer_queries vectors and mirroring the text to the portable .semhood/enrichment.jsonl store. State flips to fresh. Trivial chunks get a free template; tests get pattern-skipped.
Configuration
semhood uses one global config at ~/.semhood/config.yaml (created with
working defaults on first run) — the daemon loads it for every project. You can
still point at an explicit file with $SEMHOOD_CONFIG. Environment-variable
refs (${VAR}) resolve from ~/.semhood/.env, a local .env.semhood/.env,
or the real environment. Indexes are stored centrally under
~/.semhood/indexes/<id>/, one per project root — you don't set a path.
Supported languages
Troubleshooting
Status
Tune enrichment.llm_concurrency, or use the agent-driven enrichment flow if you hit rate limits.
Contributing
Issues and PRs welcome.
See open issues for things to pick up.
Developed and designed by Ahmed Gamil
MIT licensed — see LICENSE.
Source: README.md at commit f2f72f5
Tools
0Version history
1- v0.1.0LatestSep 16, 2026
Score
50% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
- Reached in the last 30 days25 pts
Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.
- Auth declared10 pts
Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.
- Tools listed15 pts
Answer tools/list without a credential, or ship a package that starts in a sandbox without one.
- DescriptionRequired15 pts
- Logo10 pts
- Documentation15 pts
- License10 pts