# Brainz (remote · brainz.brownmatter.ai)

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

- Trust score: 75/100 (medium)
- Change this week: +3
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-11-05

## Components

- remote · `brainz.brownmatter.ai`: 75/100 (this document), [markdown](https://verifymcp.io/servers/ai-brownmatter-brainz/brainz.md), [page](https://verifymcp.io/servers/ai-brownmatter-brainz/brainz)

## Channel facts

- Endpoint: `https://brainz.brownmatter.ai/mcp`
- Transports: `streamable-http`
- Auth: `required`
- Version: `0.1.0`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-11-05.

- **Endpoint Security**: 81/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - Authorisation is enforced on tool calls, advertised via RFC 9728 protected-resource metadata. Discovery is public, which costs nothing: no tool can be invoked without a token.
  - HTTPS enforcement could not be verified: the plaintext port answered with HTTP 406, which proves neither a plaintext path nor enforcement.
  - HSTS check failed: the Strict-Transport-Security header is absent.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
  - The authorisation server supports Client ID Metadata Documents, the current MCP client-registration mechanism.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 64/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 4116 tokens (~242/item across 17 items; 17 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 23/100
  - Stability observed for 7 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 100% of tool parameters carry a description.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - All 1 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.
  - An AI judge read all 18 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### How do I install the Brainz MCP server?

Brainz is a hosted endpoint at https://brainz.brownmatter.ai/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add --transport http ai-brownmatter-brainz 'https://brainz.brownmatter.ai/mcp'
```

### Cursor

```json
{
  "mcpServers": {
    "ai-brownmatter-brainz": {
      "url": "https://brainz.brownmatter.ai/mcp"
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "ai-brownmatter-brainz": {
      "type": "http",
      "url": "https://brainz.brownmatter.ai/mcp"
    }
  }
}
```

### Codex

```toml
[mcp_servers.ai-brownmatter-brainz]
url = "https://brainz.brownmatter.ai/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "ai-brownmatter-brainz": {
      "type": "remote",
      "url": "https://brainz.brownmatter.ai/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add ai-brownmatter-brainz --url 'https://brainz.brownmatter.ai/mcp' --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  ai-brownmatter-brainz:
    url: "https://brainz.brownmatter.ai/mcp"
```

### Netclaw

```json
{
  "McpServers": {
    "ai-brownmatter-brainz": {
      "Transport": "http",
      "Url": "https://brainz.brownmatter.ai/mcp"
    }
  }
}
```

### Vellum

```bash
assistant mcp add ai-brownmatter-brainz -t streamable-http -u 'https://brainz.brownmatter.ai/mcp'
```

### Other

```json
{
  "mcpServers": {
    "ai-brownmatter-brainz": {
      "type": "http",
      "url": "https://brainz.brownmatter.ai/mcp"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-11-04 (score 75, +1)

No change was recorded against any check on this day. Stability & Change Management went from 17 to 20. That category is still filling its 30-day observation window: 5 days of observed history at the previous scan, 6 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-11-02 (score 74, +1)

No change was recorded against any check on this day. Stability & Change Management went from 10 to 13. That category is still filling its 30-day observation window: 3 days of observed history at the previous scan, 4 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-11-01 (score 73, 0)

- [security] Tool “dream” rewrote its description, which is the text the model reads
- [functional regression] Schema quality: 3560 → 4116
- [functional] New tool “create_vault”
- [cosmetic] “dream” added an optional parameter “caps”
- [cosmetic] “dream” added an optional parameter “llm”
- [cosmetic] “dream” added an optional parameter “lossRail”
- [cosmetic] “dream” added an optional parameter “mode”
- [cosmetic] “dream” added an optional parameter “phases”
- [cosmetic] “dream” added an optional parameter “proposals”
- [cosmetic] “dream” added an optional parameter “runHourUtc”
- [cosmetic] “dream” added an optional parameter “thresholds”
- [cosmetic] “dream” reworded the description of “action”
- [cosmetic] “dream” reworded the description of “cadenceHours”
- [cosmetic] “dream” reworded the description of “enabled”
- [cosmetic] “dream” reworded the description of “id”

### 2026-10-30 (score 73, +1)

- [functional improvement] Stability: unverified → 0.03

### 2026-10-29 (score 72)

First indexed and scored.

## MCP tools (17)

### `search_concepts` (~186 tokens)

Search concepts

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.

Input parameters:

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

### `get_concept` (~97 tokens)

Get concept

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.

Input parameters:

- `id` (string, required): Exact concept id (slug), e.g. "lead-scoring".

### `get_related` (~158 tokens)

Get related concepts

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.

Input parameters:

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

### `get_context` (~182 tokens)

Assemble context bundle

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 `query` or `ids`.

Input parameters:

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

### `upsert_concept` (~525 tokens)

Create or update concept

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 edges. Returns the saved concept's metadata.

Input parameters:

- `body` (string, required): Markdown body. [[other-id]] wiki-links become graph edges.
- `codeAreas` (array): 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.
- `doneAt` (string): For tasks: ISO timestamp when completed.
- `id` (string): Concept id (slug). Omit to derive from title; pass an existing id to update.
- `product` (string): Product grouping key.
- `relations` (object): 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 cons…
- `status` (string): Lifecycle status (default "active").
- `tags` (array): Tags for filtering.
- `takenAt` (string): For tasks: ISO timestamp when claimed.
- `takenBy` (string): For tasks: label of the agent/orchestrator that claimed it.
- `taskStatus` (string): For type="task" concepts: lifecycle "open" | "taken" | "done" (default "open"). Prefer the task tools (create_task / take_task / complete_task) over setting this directly.
- `title` (string, required): Human-readable title (required, non-empty).
- `type` (string): 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 un…

### `delete_concept` (~123 tokens)

Delete concept

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 }.

Input parameters:

- `id` (string, required): Exact concept id (slug) to delete, e.g. "lead-scoring".

### `link_concepts` (~155 tokens)

Link concepts

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.

Input parameters:

- `from` (string, required): Source concept id (its file gains the relation).
- `relation` (string): 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 b…
- `to` (string, required): Target concept id.

### `list_concepts` (~112 tokens)

List concepts

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.

Input parameters:

- `product` (string): Only concepts of this product.
- `tag` (string): Only concepts carrying this tag.
- `type` (string): Only concepts of this type.

### `vault_stats` (~56 tokens)

Vault stats

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.

### `onboard` (~370 tokens)

Onboard this vault

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, given your repo's source areas (Brainz can't read the repo), which areas are covered or uncovered. {action: "complete", summary, areaList} marks the vault onboarded and stores the summary; it is rejected while too many areas are uncovered. Until onboarding completes, search_concepts and get_context results include a one-line note saying so.

Input parameters:

- `action` (string, required): "start" returns the onboarding playbook, "complete" marks the vault onboarded (requires `summary`), "status" reports onboarded state and concept counts.
- `areaList` (array): 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…
- `productName` (string): With "start": the product's name, echoed into the playbook heading.
- `repoHint` (string): With "start": where the codebase lives (path or URL), echoed into the playbook.
- `summary` (string): Required with "complete": 2–5 sentences on what was indexed and any notable gaps — stored as the product-onboarding-summary concept.

### `sync` (~454 tokens)

Sync this vault to the current code

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 gaps. {action: "status", areaList} reports onboarded state, last sync time, staleness, concept counts and coverage. {action: "complete", summary, areaList} stamps last_synced_at and appends the summary to the product-onboarding-summary concept (a running sync log). After ~14 days without a sync, get_context and search results include a one-line note saying so.

Input parameters:

- `action` (string, required): "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 summ…
- `areaList` (array): 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) — "complet…
- `changedPaths` (array): 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.
- `productName` (string): With "start": the product's name, echoed into the playbook heading.
- `summary` (string): 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).

### `dream` (~777 tokens)

Dream (nightly consolidation)

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 contradiction. A sweep that would touch too much of the vault is rejected; every applied dream keeps preimages and can be reverted. {action: "status"} shows schedule + last dream; {action: "run"} dreams now; {action: "diary"} reads the Dream Diary; {action: "revert", id} undoes one dream; {action: "configure", ...} sets the schedule, mode (apply, propose, light-only), phases, thresholds, caps, a stricter loss rail and the LLM choice; {action: "apply", id, proposals?} decides a proposed dream. Without an LLM only light runs.

Input parameters:

- `action` (string, required): "status" reports the settings, 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 recent Dream Diary en…
- `cadenceHours` (integer): With "configure": Hours between dreams (default 24).
- `caps` (object): With "configure": Most changes per dream: maxMerges 5 (1-20), maxPromotions 5 (1-20), maxLinks 10 (1-50), maxContradictions 3 (1-10).
- `enabled` (boolean): With "configure": Turn scheduled dreaming on or off.
- `id` (string): With "revert" or "apply": the dream id (from "diary" or "status").
- `limit` (integer): With "diary": how many entries to return (default 10).
- `llm` (object): With "configure": Cloud: which LLM the REM step uses — "auto" (default), "workers-ai", or "byok" (only the account's own key) — and a model id for the account's own key; null clears it.
- `lossRail` (object): With "configure": How much of the vault one dream may modify: maxTouchFraction (0.01-0.2) and minTouchAllowance (0-3). Can only be made stricter than the defaults.
- `mode` (string): With "configure": "apply" writes the changes that pass the gates (default); "propose" holds them in the Dream Diary until approved with {action: "apply"}; "light-only" never calls an LLM.
- `phases` (object): With "configure": Turn individual kinds of change on or off: merges, promotions, links, contradictions.
- `proposals` (array): With "apply": the proposal numbers (`n`) to approve; omit for all, [] to reject all.
- `runHourUtc`: With "configure": Preferred UTC hour for a dream when the cadence is 24h or more; null clears it.
- `thresholds` (object): With "configure": Minimum confidence (0.5-1) per kind: merge 0.8, promote 0.7, link 0.7, contradiction 0.6 by default.

### `list_tasks` (~115 tokens)

List tasks

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.

Input parameters:

- `domain` (string): Only tasks that are part_of this domain concept id.
- `taskStatus` (string): Only tasks in this lifecycle state ("open" | "taken" | "done"). Omit for all.

### `take_task` (~164 tokens)

Take a task off the pile

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_areas). complete_task marks it done.

Input parameters:

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

### `complete_task` (~96 tokens)

Complete a task

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.

Input parameters:

- `id` (string, required): Id of the task to mark done.
- `outcome` (string, required): A short account of what was done — appended to the task body as an Outcome section.

### `create_task` (~243 tokens)

Create a task

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 Kanban board.

Input parameters:

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

### `create_vault` (~136 tokens)

Create a vault

Create a new, empty vault owned by you and add it to this connection. Returns the new vault and the vaults this connection can now use. Once a connection covers more than one vault, every vault tool takes a `vault` argument (a slug or id) and list_vaults lists the vaults. Each account has a vault limit and an hourly creation limit.

Input parameters:

- `name` (string, required): The new vault's display name.
- `slug` (string): Optional slug (lowercase letters, digits, dashes). Derived from `name` when omitted; must not already be used by one of your vaults.

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/ai-brownmatter-brainz/brainz#diagnostics

## Score history

- 2026-11-05: 75
- 2026-11-04: 75
- 2026-11-03: 74
- 2026-11-02: 74
- 2026-11-01: 73
- 2026-10-31: 73
- 2026-10-30: 73
- 2026-10-29: 72

## Common questions

### What is the Brainz MCP server?

Brainz is an MCP server listed in the public MCP registry as ai.brownmatter/brainz. Shared product-knowledge graph for AI agent fleets, vault tools + agent self-signup over MCP. This page covers its hosted endpoint (https://brainz.brownmatter.ai/mcp).

### Is the Brainz MCP server safe to use?

Brainz scores 75 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the Brainz MCP server expose?

Brainz exposes 17 tools: search_concepts, get_concept, get_related, get_context, upsert_concept, and 12 more. Their descriptions and schemas cost roughly 3,949 tokens of context every time the server is loaded.

### Does the Brainz MCP server require authentication?

Yes. Brainz asked us for credentials when we connected, so you will need to authorise it in your MCP client before it can do anything.

### Is the Brainz MCP server still maintained?

Brainz is still listed as active in the MCP registry. We last reached this channel on 5 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

## Links

- Remote endpoint: https://brainz.brownmatter.ai/mcp
- Website: https://brainz.brownmatter.ai/
- Changelog RSS feed: https://verifymcp.io/servers/ai-brownmatter-brainz/brainz.xml
- Changelog JSON feed: https://verifymcp.io/servers/ai-brownmatter-brainz/brainz.json
- HTML version of this page: https://verifymcp.io/servers/ai-brownmatter-brainz/brainz