expert-factory

expert-factory

Builds a queryable knowledge graph from a pack of repos, papers, and notes, and serves it to agents via MCP, enabling search, source reading, and neighbor exploration.

Category
Visit Server

README

expert-factory

ef builds a queryable expert out of a pack of material — cloned repos, fetched pages, papers, and your own notes — and serves it to an agent as one knowledge graph over stdio MCP, plus a skill that teaches the agent to use it.

uv tool install .          # or: pipx install .

One install carries the whole toolchain: ef imports graphify as a library, so there is no separate binary, interpreter, or container to line up.

Build a pack

Packs live in ./experts/<name>, resolved from the current directory — so a workspace is just a directory you cd into, and ef never searches upward.

ef clone research https://github.com/effect-ts/effect --title "Effect TS"
ef clone research https://github.com/some/monorepo --paths content/docs
ef add research https://arxiv.org/pdf/2501.12345
ef add research ~/Downloads/notes-on-fibers.md
ef build research

ef build extracts everything in the pack into a single graph and writes the skill. Semantic extraction is the default and spends LLM tokens; --code-only takes the cheap AST-only path and drops docs, papers and images from the semantic pass. --backend is required only when an LLM is actually invoked.

Each pack holds four content layers plus its graph and metadata:

Path Contents
repos/<owner>/<repo>/ Pristine clones, fast-forwarded by ef update
raw/ Fetched pages, papers and images, with provenance frontmatter
notes/ Markdown you wrote yourself
graph/ graph.json, GRAPH_REPORT.md, and converted/ PDF text sidecars
expert.json The authoritative source list: origin, lifecycle, checksums
SKILL.md Generated skill teaching agents the served tools

The graph sits at graph/ rather than inside a clone, so git status in a checkout stays clean and every clone can always fast-forward.

expert.json is authoritative, not a cache: every file in raw/ and notes/ needs an entry. ef build refuses on files with no recorded origin (listing them, and suggesting --adopt-all) and on entries whose file is gone, because a graph that misreports its own coverage is worse than one that fails to build.

Extraction deliberately ignores VCS ignore files. A pack holds material that is meant to stay uncommitted, so any sane workspace gitignores repos/ and graph/ — and since the extractor walks up to the VCS root, honoring those rules would let the line that keeps a pack out of git silently empty its corpus. The pack's generated .graphifyignore still applies, and it restates the credential patterns (.env, *.pem, id_rsa, …) that the clone's own .gitignore would otherwise have covered, so a stray secret is never sent to an LLM.

Serve a pack

ef run is a plain stdio process — no container, port, image, or daemon. It writes nothing and validates the pack before the MCP handshake, so being spawned in the wrong directory fails with a readable message instead of a dead transport.

{
  "mcpServers": {
    "research expert": {
      "command": "sh",
      "args": ["-c", "cd /abs/path/to/experts/research && exec ef run"]
    }
  }
}

The cd is the shell's job, not a cwd key: Claude Code ignores cwd on a stdio server and spawns the process wherever the client was launched, where ef run would find no manifest and exit. The pack is addressed by that one path, so moving or copying it only changes that line. Copy its SKILL.md to ~/.claude/skills/<name>-expert/SKILL.md (or the consuming project's .claude/skills/).

Tools: search (graph traversal), read_source (real text behind a node — code, a fetched page, a paper, or a note), neighbors (callers, imports, references), corpus_info (size, source composition, last reconciled).

Keep it fresh

ef update research    # pull every refreshable source, then refresh the graph
ef sync research      # rewrite manifest and skill from the graph on disk
ef list               # every pack: nodes, size, last reconciled, composition

ef update fast-forwards each git source (refusing rather than discarding local modifications), then picks a refresh path and prints which one and why:

  • noop — nothing changed upstream.
  • ast — only code changed. Cheap, no LLM.
  • semantic — a doc, paper or image changed. graphify's AST-only update deliberately preserves existing semantic nodes, so a doc change has to force the expensive path or the graph keeps describing text that is no longer there.

Fetched pages and papers are snapshots with no refresh lifecycle; a changed checksum is reported as information, not as a broken pack.

A refresh re-extracts only what changed: graphify's semantic cache is left readable, so unchanged files cost nothing the second time. --force bypasses that cache and rebuilds the whole corpus — correct after changing the backend, model or scope, and otherwise just an expensive way to get the same graph.

Both ef build and ef update then name the communities and rewrite GRAPH_REPORT.md, because extraction detects communities without naming them and never writes the report — skipping it would leave the pack describing a graph that no longer exists. The first labeling pass spends a few LLM calls; later ones reuse the saved names and only rename communities whose membership actually changed.

Layout

  • src/ef/workspace (cwd-based pack resolution), manifest, scoping, sources, extraction, skill, server, cli
  • tests/ — pytest against real entry points and emitted artifacts; no test spends an LLM token

Recommended Servers

playwright-mcp

playwright-mcp

A Model Context Protocol server that enables LLMs to interact with web pages through structured accessibility snapshots without requiring vision models or screenshots.

Official
Featured
TypeScript
Audiense Insights MCP Server

Audiense Insights MCP Server

Enables interaction with Audiense Insights accounts via the Model Context Protocol, facilitating the extraction and analysis of marketing insights and audience data including demographics, behavior, and influencer engagement.

Official
Featured
Local
TypeScript
Magic Component Platform (MCP)

Magic Component Platform (MCP)

An AI-powered tool that generates modern UI components from natural language descriptions, integrating with popular IDEs to streamline UI development workflow.

Official
Featured
Local
TypeScript
VeyraX MCP

VeyraX MCP

Single MCP tool to connect all your favorite tools: Gmail, Calendar and 40 more.

Official
Featured
Local
graphlit-mcp-server

graphlit-mcp-server

The Model Context Protocol (MCP) Server enables integration between MCP clients and the Graphlit service. Ingest anything from Slack to Gmail to podcast feeds, in addition to web crawling, into a Graphlit project - and then retrieve relevant contents from the MCP client.

Official
Featured
TypeScript
Kagi MCP Server

Kagi MCP Server

An MCP server that integrates Kagi search capabilities with Claude AI, enabling Claude to perform real-time web searches when answering questions that require up-to-date information.

Official
Featured
Python
Neon Database

Neon Database

MCP server for interacting with Neon Management API and databases

Official
Featured
Exa Search

Exa Search

A Model Context Protocol (MCP) server lets AI assistants like Claude use the Exa AI Search API for web searches. This setup allows AI models to get real-time web information in a safe and controlled way.

Official
Featured
Qdrant Server

Qdrant Server

This repository is an example of how to create a MCP server for Qdrant, a vector search engine.

Official
Featured
E2B

E2B

Using MCP to run code via e2b.

Official
Featured