Open source · MCP · Machine-local

Project intelligence
for your agent in Cursor

guu is not a long-term memory file. Every agent you connect reads the same project context, learns from the work you do together, follows your coding style, and writes memory back only when that memory should change.

Agent · one build_context for this task
build_context ({ task: "Add refund email", mode: "implementation" })
  • memory Settled earlier, in another editor: prefer an absolute --root.
  • style GuuCode · this developer’s naming, tests, and commit habits.
  • workflow Brief once, then search. Gate before edits.
  • gate check_gate → PASS or WARN, then edit.

One context. Every agent.

Memory is one layer. guu also holds the compiled project, your coding style, and a rule for when that memory is allowed to change. Cursor, Claude Code, OpenCode, VS Code, and Antigravity pointed at the same project read and write the same guu.db.

Not only long-term memory

A memory note cannot tell an agent where a symbol lives or whether an edit is in scope. guu compiles catalogs, retrieves them for the task, and keeps decisions beside that map.

It learns from the work

When you settle a rule, a decision, or a preference with an agent, guu can extract a candidate from that text. Quality checks drop chat noise. What remains is available to the next agent, in any editor on this project.

Your coding style

GuuCode is a profile of how you write: naming, tests, commits, what you avoid. It is built from your commits, pull requests, and observations in session, then injected into every briefing.

Memory updates on purpose

After a change, an assessment decides whether feature memory, project knowledge, or neither should be written. A deterministic check is the floor. An optional local model can advise. It cannot suppress a required update.

The cold-start problem

The repository is already there. The agent still starts from zero, guesses the stack, and edits before anyone checked the scope.

It greps the tree and still invents routes, Shopify surfaces, and how the app is deployed.

Every new chat re-explains architecture and decisions you already settled.

Files change before identity, blast radius, or product intent has been looked at.

What your agent is given

Four layers. Knowledge describes the project. Memory keeps what you learned. Context fuses them for one task. The gate decides whether an edit may start.

Compiled knowledge

Scanners, parsers, and detectors turn the repo into catalogs: structure, architecture, domain language, patterns, Shopify, and Docker. guu.db is the source of truth. JSON beside it is an export.

Per-developer memory

Decisions, conventions, and lessons stay on the machine, with the files and commits they belong to. The next build_context only pulls memories that overlap the task.

One context pack

build_context runs once per task and returns context plus a context_id. Need more? search_knowledge and get_knowledge. Do not recompile unless the task or knowledge version changed.

A gate before edits

check_gate returns PASS, WARN, or FAIL. Implementation edits wait for PASS or WARN. Review, plan, and debug skip the coding gate. An empty store blocks until setup and analyze.

Core stack

Index the code. Search it. Do not guess it.

Native search stays on the machine. Tree-sitter reads the syntax, hybrid retrieval ranks the hits, and SQLite keeps the store. An LLM is optional for catalog enrichment, and it is not on the search path.

Parse

Tree-sitter

web-tree-sitter turns TypeScript, JavaScript, Ruby, Python, and Go into symbols and call edges. The agent looks up a name before it opens a file.

Retrieve

Hybrid search

BM25-lite and vector cosine run on one corpus, then fuse with reciprocal rank fusion. A lookup can also come from the graph, an exact match, or a symbol.

Embed

Hash embeddings

The native provider is hash: deterministic vectors, no model download, no API key. They live in a SQLite vector index (sqlite-vector).

Store

SQLite

node:sqlite is guu.db — catalogs, the knowledge graph, memories, and context sessions. Disk exports are written after the database commit.

Connect

MCP

One server for Cursor, Claude Code, OpenCode, VS Code, and Antigravity. Tools, guu:// resources, and prompts. Stdio on the laptop, HTTP when you host it.

Graph

Call graph

GitNexus or a code-review graph when the repo already has one. Otherwise guu’s own graph. Blast radius goes into check_gate only when that analysis actually ran.

How MCP steers the agent

The server does not paste the repository into the chat. It hands the agent a task pack built from knowledge and from memory that was already compiled, then stays available while the agent works.

01

Open on the task, not on the whole repo

The agent calls build_context once. The pack leads with memories that overlap this task — decisions and lessons from earlier sessions — and the files those memories name. Workflows, patterns, product intent, and your GuuCode style come with it. A different editor, started tomorrow, gets that same pack for the same project.

02

Stay close to the task

If the pack is thin, the agent searches with the same context_id: search_knowledge, get_knowledge, sitemap, and symbols. It does not call build_context again, and it does not guess routes, Shopify, or deploy layout that the catalogs already describe.

03

Edit only when the gate agrees

check_gate looks at the task, the files about to change, and memories that still cover those files. PASS or WARN, then the edit. FAIL stops it. Review, plan, and debug skip the coding gate. An empty store blocks until the project has been analyzed.

04

Learn, then decide what to keep

Durable lines from the conversation can be extracted as memory candidates. After the code change, the agent assesses the diff. Feature memory is written for a new behavior or a lesson. Knowledge is written when catalogs, routes, or stack facts moved. Neither is written when the turn did not earn it. The next agent — Cursor or Claude or OpenCode — starts from that store.

build_context({ task, mode }) search_knowledge({ context_id, query }) check_gate({ task, file_paths }) auto_feature_memory_update({ change_summary, files_changed })

The last call runs only when the assessment says the memory should change. apply_updates: false previews that decision without writing.

Install and connect MCP

Stdio is the default. The IDE spawns guu-mcp. Run this on the app repository the agent will edit, and pass an absolute --root.

01

Install the CLI

The package is @fordeer/cli on GitHub Packages. You need a token with read:packages. The binary is guu.

pnpm add -g @fordeer/cli guu --version && which guu-mcp
02

Create the store and the MCP entry

setup writes .guu-project.json, creates guu.db, and installs skill packs. An IDE flag also writes that agent’s MCP config. Without a flag, setup only prints the snippet.

guu setup --root "$APP" --cursor guu analyze --root "$APP" guu doctor --root "$APP"

The same pattern exists for --claude, --opencode, --vscode, and --antigravity. Add --cursor-global (and the matching global flag) only when that IDE is already installed and you want the user-level config too.

03

Point every agent at the same project

Server name should be unique per app. project and GUU_PROJECT name the data namespace under ~/.guu/data/<project>/. Tools run only when that namespace’s git signature matches this checkout.

{ "mcpServers": { "guu-your-app": { "command": "guu-mcp", "project": "your-app", "env": { "GUU_PROJECT": "your-app" } } } }

Cursor uses .cursor/mcp.json. Claude Code uses .mcp.json with the same shape. Antigravity uses .agents/mcp_config.json. OpenCode uses opencode.json with command as an array and environment instead of env. VS Code uses .vscode/mcp.json with servers and type: "stdio".

04

Smoke-test, then keep one transport

Enable the server in the IDE and restart MCP. In chat, ask the agent to call build_context with task check guu MCP. Expect contextReady: true and identityGate.ok: true.

Do not enable stdio and HTTP MCP for the same agent. HTTP is guu start --http, for a shared process — not the command inside Cursor or VS Code.

The MCP surface

33 tools · 10 resources. Tools, guu:// resources, and prompts. A peek is not a second briefing, and a briefing is not a dump of the store.

Context engine

build_context, search_knowledge, get_knowledge, update_knowledge. Modes cover implementation, bugfix, refactor, review, investigation, and architecture.

Locate before opening

query for sitemap, symbols, directory, routes, graph, and blast. Resources answer the same questions mid-task without recompiling context.

Gates and risk

check_gate before file edits. confirm for a large scope. impact for performance, race, and security risk. Optional GitNexus or CGC blast radius can be passed in — never invented.

Memory domain

Search, save, update, confirm, invalidate, and promote. A memory can point at repo files and commits. Closed memories stop warning the gate.

Lifecycle

analyze_project, enrich_project_knowledge, and update_project_knowledge match the CLI. If MCP times out, retry that command with --root.

After the edit

auto_feature_memory_update and auto_knowledge_update, then an assessment for docs and QA notes. The next session inherits the change.

A reply stays under 700 tokens

Measured with pnpm run measure:tokens on all 33 MCP tools. ~tokens is the compacted reply the agent actually receives, estimated as output characters ÷ 4. The heaviest sample is build_context at 637.

Token cost of each MCP tool from pnpm run measure:tokens
Tool Def Args Output ~tokens Sample
build_context 2706582548637curated
check_gate 25001782061515curated
impact 18071541910478curated
query 2905451905476curated
analyze_project 1101311187297curated
enrich_project_knowledge 735171144286curated
auto_feature_memory_update 868161947237curated
guu_code 8292785196auto
invalidate_feature_memory 52172480120curated
guu_product 13262412103auto
save_memory 15443838897auto
update_project_knowledge 508238596curated
save_feature_memory 199929938596curated
consolidate_feature_memory_episodes 10495032481curated
auto_knowledge_update 64516131579curated
agent_rules 857214336curated
list_agent_rules 404214336auto
search_memory 5884211629auto
maintain_memory 385211629auto
get_memory_graph 3065210226curated
extract_memory 30529624auto
confirm 477188922curated
get_knowledge 1254917318auto
search_knowledge 134926015auto
forget_agent_rule 47025714auto
remember_agent_rule 49324612auto
search_memory_for_context 36424511auto
get_memory 32724411auto
update_memory 450404411auto
confirm_memory 32424411auto
invalidate_memory 44724411auto
promote_memory 35024411auto
update_knowledge 45612297auto
Every tool once 306491549165114128

Def, args, and output are characters. Definitions load once when MCP connects. A normal step is one row, and that reply stays under 700 tokens. The last row sums all 33 tools called in one pass. curated uses a hand-written sample; auto uses arguments generated from the schema.

Context that fits the task

Not every catalog row belongs in the prompt. The briefing leads with memories that overlap the task and the files they name, then workflows and patterns. Style and product intent stay available without crowding out the evidence.

  1. 1
    Overlapping memories

    Decisions and rules with lexical overlap to this task. Zero-overlap rows stay out.

  2. 2
    The files those memories point at

    Related paths are promoted into the relevant-file list so the agent opens the right place first.

  3. 3
    Workflows and patterns

    How this codebase expects the change to be made, retrieved by type when the pack is not enough.

  4. 4
    A budget, then stop

    The reply is capped. Further detail comes from search and typed lookups, not another full compile.

Why not point the agent at the repo?

A README is a fine briefing for a small project. It stops scaling once the agent must find symbols, remember a decision, and refuse an edit that is out of scope.

Repo only
guu
First message
Grep, then guess
One build_context
Source of truth
Whatever fit in the prompt
guu.db on this machine
Finding code
Open files until something matches
Sitemap, symbols, semantic search
Decisions
Gone when the chat ends
Memory with files and commits
Before an edit
The agent just writes
check_gate PASS or WARN
After an edit
The next chat starts over
Memory and knowledge update

Use the README when the project is small and a paragraph is the whole briefing.
Use guu when several agents share a real codebase and the next task should be more accurate than the last one.

Two ways to run it

On the laptop
Stdio MCP

The default. The IDE spawns guu-mcp. Knowledge and memory stay under your data home. No Docker, no open port.

  • Cursor, Claude Code, OpenCode, VS Code, Antigravity
  • Skill packs and agent rules installed by setup
  • Local embeddings, optional model for enrichment
  • guu doctor for MCP, graph, embeddings, memory
Set up MCP
On a server
HTTP MCP

For a shared process: guu start --http, or the Docker image when an operator hosts it. Pick one transport per agent.

  • Streamable HTTP, separate from the IDE spawn
  • Auth token for the HTTP connection
  • Same tools, resources, and prompts
  • Do not also enable stdio for that agent
Operator guide

What you need

A normal developer machine. Enrichment can call a model; search and the hash embedding provider do not have to.

Node 20 or newer
Git Required. The identity gate compares the store signature to this remote.
Package manager pnpm 10 or npm. The CLI itself is a global @fordeer/cli install.
Registry GitHub Packages token with read:packages for the @fordeer scope.
Model Optional, for catalog enrichment: Ollama, OpenAI, OpenRouter, OpenCode Zen or Go, or another supported provider.