mozg

Install

Works with Claude Code, VS Code, Cursor, Windsurf. Read the repository before you give any tool access to your data.

npx agentmarket install connector/mozg-sh-mozg

About

Use cases: knowledge-base, deep-research

No reviews yet. Installed it? Reviews come from verified installers only. How reviews work

Permissions

What this server can do and what it asks for, from its tool list and install config. Checked Oct 25, 2026.

Tools

10 read · 6 write · 1 delete · 4 not yet classified

Secrets

1 (API keys, tokens or passwords)

Install scripts

Nothing to install (hosted)

Runs as

Hosted (remote endpoint)

Tools (21)

Read from the source code; the running server may differ. Descriptions are the server’s own words; hidden characters are shown as [U+…].

• brain_add_source

  Feed raw material into a brain: documentation pages by URL, or a block of text. The material is read and turned into searchable notes in the background — this returns as soon as the work is queued, so tell the user it is processing rather than waiting for notes to appear. When the user gives ONE link and means the whole documentation behind it ("learn https://example.com/docs"), pass that single URL with crawl: true — every page in that section is discovered and read, via the site's sitemap, its GitHub repository, or by following links. Prefer this over brain_write when you have primary materi…

• brain_brief

  Get a compact map of one brain: its goal, the categories of knowledge it holds, its known gaps, and any unfinished work an earlier session left here. Cheap — call it before searching so you know whether this brain can answer the question at all and which words it uses. Do not skip this and guess at search terms.

• brain_create

  Create a new brain. Use when the user asks to start one, or when you notice they are explaining the same project-specific context repeatedly and no existing brain covers it — offer first, do not create unasked. The goal matters more than the name: it becomes an exam the brain is scored against, so write it as an outcome ("answer questions about our webhook retries and idempotency") rather than a subject ("webhooks"). Creating the same title twice returns the existing brain instead of a duplicate. The full procedure — what the exam measures and the four mistakes that leave a brain at 40% — is a…

• brain_feedback

  Report how a specific note held up in real use. Negative: the note is wrong, outdated or misleading — after you verified it against reality (the API answered differently, the docs changed, the code contradicts it); the note keeps answering until its owner reviews the report. Positive: the note proved correct and useful for your task. Both shift how the note ranks in future searches. Say what you observed, not just that you agree or disagree. Do not use this for notes that are merely incomplete — brain_write a better one instead; on a brain you only read that becomes a proposal for its owner, w…

• brain_find

  Find WHICH brain can answer something, when you do not already know one exists. brain_search needs a brain by name; this needs only the question, and searches every public brain at once. Call it before answering from memory about any library, framework, API or platform — the catalogue holds brains on things your training data has moved on from, and the only reason not to use one is that nobody told you it was there. Returns the brains that actually matched, with the evidence they matched on, so you can judge rather than trust the name. Then brain_search that handle, or library_add it to keep i…

• brain_handoff

  The baton between sessions and agents. Before stopping mid-task, LEAVE a handoff: where you stopped, what is done, what the next session must know — then any agent (this one tomorrow, or a different tool entirely) LISTs open handoffs when it starts and TAKEs one to continue from that exact point. Working state only — durable lessons belong in brain_write. Handoffs expire after 7 days.

• brain_list

  List the knowledge brains available to you. Call this once at the start of a session, or whenever the user names a brain (e.g. "use mozg:design"). Returns each brain's handle, what it is for, and how well it is trained.

• brain_read

  Read the full text of one note returned by brain_search, when the excerpt is not enough to act on.

• brain_refresh

  Bring a brain you own up to date with its sources: re-read the pages whose text changed since last time, and re-walk any crawled site for pages that did not exist before. Use it when the user says a library released a version, or when an answer from the brain turns out to be one release behind. Cheap by construction — every page is fetched and hashed, but only a page that actually changed is re-read by a model, and the notes from a changed page are superseded rather than deleted. Queued, not instant: it reports what it started, and the exam re-sits itself after.

• brain_search

  Search a brain for knowledge relevant to your current task. Call this BEFORE answering, whenever the question names a file, a version, an API, a config key or a convention — or asks how something is done "here", "in this project" or "in our setup". Those are the answers your training data has an outdated version of and will give confidently. Skip it for general programming questions this brain has no stake in. Prefer several short, specific queries over one long one. Returns ranked excerpts with note ids — excerpts are cut short; brain_read gives the full note.

• brain_verify

  Check a claim against the brain before acting on it or presenting it as fact. Returns supported / contradicted / not_covered with the evidence notes. Use it on your own drafted answer when the stakes are real — a migration step, a money path, an API contract. A claim the brain cannot confirm is flagged to the brain's owner as a gap.

• brain_write

  Save a durable lesson back into the brain: a convention you confirmed, a correction to something the brain had wrong, a pitfall you hit. The moment to call it is when you have just worked something out that took real digging and would take the next session the same digging. Write one self-contained fact per call — it will be read alone, months later, by someone with none of this conversation, so name the file, version or number it turns on and say why, not only what. Do not save what the repository or this chat already records, and never save credentials, tokens or personal data. Works on brai…

• brain_write_batch

  Save several lessons at once — the same rules as brain_write, up to 25 notes per call. Prefer this when a training session produced a set of notes: one call instead of many. Each note is scanned, deduplicated and saved on its own, so one rejection loses nothing else — read the per-note results in the reply and only redo the ones that failed. On a brain you only read, the batch becomes proposals for its owner.

• gen_plan

  Change what a project's set contains, before any of it is bought. Describe one asset in particular, clear that description so it is drawn from the game's world instead, or drop an asset from the set. Still free. Use it when the user says what a specific symbol should be.

• gen_project

  Plan a set of game art on gen.mozg.sh: create a project, or read one back. Free — a project is a folder and a plan, and nothing is charged until gen_run. Call it with a title and style to start one, with an id to read it, or with neither to list what the studio already has. Creating one fills it with the usual slot set (the value ladder, a background, a reel frame and a lobby tile), which you then edit.

Signals

Stars

8

Forks

1

Open issues

0

Last commit

Oct 7, 2026 (21 days ago)

Last release

Aug 4, 2026 (2 months ago)

From GitHub (fetched Oct 24, 2026).

Details

Registry name

sh.mozg/mozg

Version

0.1.0

Auth

Bearer token

License

AGPL-3.0

Repository

github.com/egorfedorov/mozg

Website

mozg.sh

First seen

Oct 24, 2026

Last checked

Oct 24, 2026

Source

Official MCP Registrygithub-graphql