Name: Brainz
Author: brownmatter

Brainz MCP

Shared product-knowledge graph for AI agent fleets — vault tools + agent self-signup over MCP.

Tool-list grade A Remote · Streamable HTTP OAuth 2.1 16 tools v0.1.0

No reviews yet by brownmatter The publisher’s own endpoint — this marketplace is not in the path

93/100

tool-list score

tools declared

remote

at its publisher

—

calls last 7d

What it does

Shared product-knowledge graph for AI agent fleets — vault tools + agent self-signup over MCP.

Quickstart

# 1 — add it to Claude Code
claude mcp add --scope user --transport http brainz-mcp https://brainz.brownmatter.ai/mcp

# 2 — ask your agent for something these tools do
#   search_concepts, get_concept, get_related and 13 more

Brainz costs nothing on mcprush: there is no plan to choose here, no cap to set and nothing mcprush can bill you for.

Publishernot claimed

brownmatter1 server

1 category

All 1 server

Collected from a public index. Nobody has claimed this account, so nothing here was written by its author — claim it if it is yours.

Installation

Where are you running it?

Every route below installs the same thing and ends at the same approval screen. Nothing here runs on your machine and nothing runs on ours: this server answers at its publisher’s own address, and what you install is the connection straight to it.

Claude Codedeclared by this listing

This is a public server: it answers at its publisher’s own address and this marketplace is not in the path. Claude Code registers it in one command; --scope user makes it available in every project. The transport below is http, as the publisher's own manifest declares it. Its publisher asks you to sign in with OAuth: run /mcp in Claude Code and pick this server, and it opens a browser for that once.

claude mcp add --scope user --transport http brainz-mcp https://brainz.brownmatter.ai/mcp

Reconnect, or start a new session, and the tools appear in the model’s tool list.

Free on mcprush, and it answers at its publisher’s own address: this marketplace is not in the path, so there is no key of ours to hold and no card to add — the only sign-in is its publisher’s own, with OAuth.

What it asks of you

Nothing is required, but it can take Authorization header (Bearer bz_... vault API key (optional: clients that support MCP OAuth sign in instead). Without it, tools/list works and every tool call answers with an OAuth 401 challenge.) if you want to set it.

What it writes

One config entry pointing straight at the publisher’s own address — this marketplace is not in the path, and nothing from this listing executes on your machine.

What you approve

16 tools, with what each one reads, writes and reaches shown before you agree — the same list on every route above. Read the tool surface.

Tool surface

What the model actually sees. Descriptions are diffed on every release — see version history.

Only tools that write or reach the network

Search the product knowledge vault by free-text query. Useful when you need product knowledge but don't yet know which concept ids exist. Returns ranked hits (id, title, type, score, snippet) only; get_concept returns one full note and get_context an assembled briefing. An empty hit list means nothing matched.

Parameter	Type	Required	Notes
query	string	yes	Free-text search query, e.g. "lead scoring" or "session auth".
mode	string	no	Search mode. "hybrid" (default) fuses keyword and semantic ranking; semantic silently falls back to keyword if embeddings are unavailable.
product	string	no	Only return concepts belonging to this product.
tags	array	no	Only return concepts carrying ALL of these tags.
type	string	no	Only return concepts of this type.
limit	integer	no	Max hits to return (default 10).

Fetch one concept by exact id: full markdown body, metadata, and its direct graph neighbors (each with the relation that connects it). Use after search_concepts or when another note wiki-links an id you need in full. The neighbors list tells you what to fetch next. If you don't know the id, use search_concepts instead.

Parameter	Type	Required	Notes
id	string	yes	Exact concept id (slug), e.g. "lead-scoring".

Walk the knowledge graph outward from a concept and return everything within depth hops, with distance and the edge path that reached it. Use to map the blast radius before changing a feature (what depends on it, what constrains it, which decisions apply) or to discover structure that keyword search misses. Filter by relation names (e.g. depends_on) to follow only one kind of edge.

Parameter	Type	Required	Notes
id	string	yes	Concept id to start from.
depth	integer	no	How many hops to traverse (1-3, default 1).
limit	integer	no	Max related nodes to return.
relations	array	no	Only follow edges with these relation names, e.g. ["depends_on", "part_of"].

Assemble a markdown briefing of the concepts most relevant to a query and/or explicit ids, expanded through the graph and trimmed to a token budget. The briefing is self-contained, so it can be handed to another agent or pasted into a prompt as-is. The final JSON line reports which concept ids were included, whether the bundle was truncated, and its approximate token count. Provide at least one of

Parameter	Type	Required	Notes
query	string	no	Search query used to pick seed concepts.
ids	array	no	Explicit seed concept ids (kept first, in order).
product	string	no	Restrict expansion to concepts of this product.
depth	integer	no	Graph hops to expand from the seeds (default 1).
tokenBudget	integer	no	Approximate token cap for the bundle (chars/4, default 4000).

Write a concept note into the vault (creates or overwrites the markdown file, then reindexes it). Use to capture new product knowledge discovered during a task — a decision made, a constraint hit, a pattern adopted — so future agents can find it. Omit id to derive a slug from the title; pass an existing id to update that note. Body is markdown; [[wiki-links]] to other concept ids create graph ed

Parameter	Type	Required	Notes
id	string	no	Concept id (slug). Omit to derive from title; pass an existing id to update.
title	string	yes	Human-readable title (required, non-empty).
body	string	yes	Markdown body. [[other-id]] wiki-links become graph edges.
type	string	no	Concept type (default "concept"). The 11 built-in types are concept, domain, feature, story, spec, workflow, task, decision, constraint, pattern, glossary; a vault may also define custom types. An unk
status	string	no	Lifecycle status (default "active").
product	string	no	Product grouping key.
tags	array	no	Tags for filtering.
codeAreas	array	no	Rough codebase paths/globs where this knowledge lives, e.g. ["packages/core/src/vault.ts", "apps/web/src/routes/**"] — lets agents briefed by get_context know where to apply it.
taskStatus	string	no	For type="task" concepts: lifecycle "open" \| "taken" \| "done" (default "open"). Prefer the task tools (create_task / take_task / complete_task) over setting this directly.
takenBy	string	no	For tasks: label of the agent/orchestrator that claimed it.
takenAt	string	no	For tasks: ISO timestamp when claimed.
doneAt	string	no	For tasks: ISO timestamp when completed.
relations	object	no	Typed edges, e.g. {"depends_on": ["auth-system"]}. Conventions: part_of (feature/story/task → domain), realized_by (story → features), realizes (task → stories/features), governs (spec → what it const

Remove a concept from the vault and all of its outgoing edges. Use to clear a note that is wrong, obsolete, or junk (e.g. a probe or test node that shouldn't be in the graph). Idempotent: deleting an id that doesn't exist is a no-op success (deleted:false), not an error. Deletion is permanent — prefer upsert_concept to correct a note you want to keep. Returns { deleted, id }.

Parameter	Type	Required	Notes
id	string	yes	Exact concept id (slug) to delete, e.g. "lead-scoring".

Add a typed, directed edge between two existing concepts by editing the from note's frontmatter (e.g. lead-scoring depends_on contact-model). Use when you notice a relationship the vault is missing. Both concepts should already exist; use upsert_concept first if not.

Parameter	Type	Required	Notes
from	string	yes	Source concept id (its file gains the relation).
to	string	yes	Target concept id.
relation	string	no	Edge type, e.g. part_of \| realized_by \| governs \| depends_on \| constrains \| supersedes \| related_to (default). Domain→domain links (related_to / depends_on) are encouraged where two domains share a bo

Enumerate concept metadata (no bodies), optionally filtered by product, type, or a single tag. Use to get the lay of the land in an unfamiliar vault, to audit what exists (e.g. all decisions for a product), or when search vocabulary isn't matching. For content, follow up with get_concept or get_context.

Parameter	Type	Required	Notes
product	string	no	Only concepts of this product.
type	string	no	Only concepts of this type.
tag	string	no	Only concepts carrying this tag.

Summarize the vault: counts of concepts and edges, the products and tags in use, a breakdown by concept type, and whether semantic search is available. Useful for gauging how much knowledge is here and which product/tag filters exist.

No parameter schema on file.

Index an existing product's codebase into this vault. {action: "start"} returns the onboarding playbook: a method for surveying the codebase and recording its product knowledge (domains, features, stories, specs, workflows, decisions, constraints) as concepts via upsert_concept, each anchored to the code with codeAreas. {action: "status", areaList} reports onboarded state, concept counts and, give

Parameter	Type	Required	Notes
action	string	yes	"start" returns the onboarding playbook, "complete" marks the vault onboarded (requires summary), "status" reports onboarded state and concept counts.
productName	string	no	With "start": the product's name, echoed into the playbook heading.
repoHint	string	no	With "start": where the codebase lives (path or URL), echoed into the playbook.
summary	string	no	Required with "complete": 2–5 sentences on what was indexed and any notable gaps — stored as the product-onboarding-summary concept.
areaList	array	no	With "status" or "complete": the repo's top-level source areas (packages/, apps//src subtrees, major dirs) from your own repo walk — Brainz can't read the repo. "status" diffs concepts' code_areas a

Re-index an onboarded vault after the code changes (drift). {action: "start"} returns the sync playbook: the vault's last_synced_at, a coverage map over the concepts' code_areas, and a method for re-indexing only what changed (you run git — Brainz can't read the repo — and pass back changedPaths + areaList): update stale concepts in place, add concepts or tasks for new work, and report coverage ga

Parameter	Type	Required	Notes
action	string	yes	"start" returns the sync (re-onboard) playbook — a DRIFT playbook scoped to what changed since the last sync (NOT the full onboarding playbook). "complete" records last_synced_at and appends the summa
productName	string	no	With "start": the product's name, echoed into the playbook heading.
summary	string	no	Required with "complete": 2–5 sentences on what changed, what you updated, and what you indexed — APPENDED to the product-onboarding-summary concept as a running sync log (never overwritten).
areaList	array	no	With "start", "status", or "complete": the repo's top-level source areas from your own repo walk (Brainz can't read the repo). Used to compute the coverage map (covered vs uncovered areas) — "complete
changedPaths	array	no	With "start": paths you found CHANGED since last_synced_at (from your own git diff/log). The playbook focuses the fan-out on the areas these fall under.

Dreaming: a scheduled consolidation sweep over this vault. Light stages what changed since the last dream (near-duplicate concepts, finished task outcomes, hygiene counts); REM asks an LLM for proposals; deep applies the ones that pass threshold gates: merges duplicates (edges redirected, the other tombstoned), promotes outcome knowledge into concepts, adds missing links, and files a task for each

Parameter	Type	Required	Notes
action	string	yes	"status" reports whether dreaming is on, its cadence, the last/next dream and any sweep in flight. "run" starts (or continues) a sweep NOW and advances it as far as one request allows. "diary" returns
id	string	no	With "revert": the dream id to undo (from "diary" or "status").
limit	integer	no	With "diary": how many entries to return (default 10).
enabled	boolean	no	With "configure": turn nightly dreaming on or off.
cadenceHours	integer	no	With "configure": hours between dreams (default 24).

List the vault's work pile: task-type concepts with their lifecycle (open/taken/done), oldest first, including who has taken each one (takenBy). Filter by taskStatus or by the domain the tasks are part_of. Read-only; take_task is what claims a task.

Parameter	Type	Required	Notes
taskStatus	string	no	Only tasks in this lifecycle state ("open" \| "taken" \| "done"). Omit for all.
domain	string	no	Only tasks that are part_of this domain concept id.

Claim a task and get its briefing in one call. Pass an id to claim a specific task, or omit it to claim the next open task (oldest open by createdAt then id). Atomically flips the task to "taken" and records takenBy/takenAt; errors if it's already taken or done. Returns the task and a get_context-style briefing for its part_of domain plus the concepts it realizes / is governed_by (with code_area

Parameter	Type	Required	Notes
id	string	no	Claim this specific task by id. Omit to claim THE next open task (oldest by createdAt then id).
takenBy	string	no	Label for who's claiming it (agent/orchestrator name). Defaults to a generic label.

Mark a task done. Sets taskStatus=done + doneAt and appends outcome to the task body as an Outcome section. The result carries a one-line reminder that the rest of the graph is not updated automatically.

Parameter	Type	Required	Notes
id	string	yes	Id of the task to mark done.
outcome	string	yes	A short account of what was done — appended to the task body as an Outcome section.

Turn a finding into first-class work: creates a task-type concept with taskStatus=open and the given relations — part_of a domain, realizes stories/features, governed_by specs — plus codeAreas pointing at where the work lands. Use when you discover work that isn't reflected in the codebase yet (a gap, a needed fix, a follow-up). The task then shows up in list_tasks / take_task and on the Kan

Parameter	Type	Required	Notes
title	string	yes	Human-readable task title (required, non-empty).
body	string	yes	Markdown description of the work. [[wiki-links]] become edges.
domain	string	no	Domain concept id this task is part_of.
realizes	array	no	Story/feature concept ids this task realizes (creates realizes edges).
governedBy	array	no	Spec concept ids that govern this task (creates governed_by edges).
codeAreas	array	no	Rough codebase paths/globs where the work lands.
tags	array	no	Tags, e.g. a priority tag like "high" or an area tag.

Free

$0 forever

Every tool — any call limit is its publisher’s, not ours
No card, and mcprush charges nothing for it
Runs at its publisher’s own address — this marketplace is not in the path
Nothing to cap, because mcprush bills nothing

Nothing here is billable: mcprush charges nothing to install Brainz or to call it, at any volume.

ATool-list grade · score 93 / 100

Release 0.1.0 · scanned 30 Oct 2026

Graded from the tools this server lists, not from its source code.

Two independent axes, because powerful and malicious are different questions. The grade is threat only. The capability level is blast radius, and it is never a penalty on the grade — it is priced as one subtract-only term in the score, where you can see it.

Threat score100

Client score93

Findings0 threat · 1 capability

Capabilitymoderate

Coveragemanifest

Verificationnot in this report

Surface digest7410d10540f10f14f5b502156f655ae7de4d37b8012b61a2cd5579cb63b0e9c7

Score vectorthreat 100 → client 93

Term	Level	What it prices	Points
capability-exposure	moderate	capability blast radius (moderate) — client exposure if the model is manipulated	−3
coverage-honesty	manifest	inspection depth (manifest) — how much of the target the scan could see	−4

score = clamp(round(threatScore − E_cap − E_ver − E_cov), 0, 100). No model, no opinion, no network call at scoring time: the same methodology version against the same bytes always produces this number, and every line above is a field of the report rather than a summary of it.

What the scan could actually read

A grade is only as meaningful as its coverage, so the scanner publishes its own depth before it publishes its result.

The scan read each tool’s name, description, input schema and annotations exactly as the server listed them the last time it answered us; no code was reviewed. We ask the server again about once a month, and a list that changed is graded again.

Tool surfaceread

Implementation sourcenot available

Package metadatanot available

Live transportnot available

The implementation source was not read — this reflects the declared tool metadata only.

Capability — what it could do if the model were manipulated

Tags derived from each tool’s schema and the implementation, not from what the tool calls itself. moderate is the level these add up to.

Tool	Capability tags	Why the tag was assigned
search_concepts	no tags
get_concept	untrusted-input	untrusted-input: keyword "fetch"
get_related	no tags
get_context	no tags
upsert_concept	state-write	state-write: declares readOnlyHint: false, destructiveHint: true
delete_concept	state-write	state-write: declares readOnlyHint: false, destructiveHint: true
link_concepts	state-write	state-write: declares readOnlyHint: false
list_concepts	no tags
vault_stats	no tags
onboard	state-write	state-write: declares readOnlyHint: false
sync	state-write	state-write: declares readOnlyHint: false
dream	external-sink	external-sink: declares readOnlyHint: false, destructiveHint: true, openWorldHint: true
list_tasks	no tags
take_task	state-write	state-write: declares readOnlyHint: false
complete_task	state-write	state-write: declares readOnlyHint: false
create_task	state-write	state-write: declares readOnlyHint: false

Toxic-flow graph

The lethal trifecta, checked as a graph rather than as a checklist: untrusted input, a sensitive source and an external sink have to meet before there is a path worth worrying about.

flow-1

Untrusted input can drive an external action even though no sensitive source is exposed.

Supply chain and provenance

Integrityfirst-seen

Surface digest7410d10540f10f14

Scanned2026-10-30

This is the first scan of this surface here, so there is nothing yet to compare it against.

Every result on this tab comes from one deterministic pass over the published package — offline, rule by rule, and auditable line by line above. Same methodology version, same bytes, same score.