Brainz
REMOTE · BRAINZ.BROWNMATTER.AI
Shared product-knowledge graph for AI agent fleets — vault tools + agent self-signup over MCP.
Available components
Last scanned (10 hours ago)
Scores higher than 64% of remote servers
Reachable. Last reached 5 Nov 2026.
Category Memory and Knowledge
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. How we score → Why this is hard to score →
Endpoint Security81
- The endpoint's TLS certificate is valid, in date, and uses a strong key. View diagnostics → Pass
- 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. View diagnostics → Pass
- HTTPS enforcement could not be verified: the plaintext port answered with HTTP 406, which proves neither a plaintext path nor enforcement. View diagnostics → Unverified
- HSTS check failed: the Strict-Transport-Security header is absent. See how to fix → View diagnostics → Fail
- DNSSEC check failed: this domain isn't protected by DNSSEC. See how to fix → View diagnostics → Fail
- The authorisation server supports Client ID Metadata Documents, the current MCP client-registration mechanism. View diagnostics → Pass
Transport & Reachability100
- Verified streamable-http transport via a live MCP handshake. View diagnostics → Pass
Schema Quality & AI Usability64
- AI-judged instruction clarity (excellent).Pass
- 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. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management23
- Stability observed for 7 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage100
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 100% of tool parameters carry a description.Pass
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- All 1 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.Pass
- An AI judge read all 18 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 4 Nov 26 +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.
- 2 Nov 26 +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.
- 1 Nov 26 0
- Tool “dream” rewrote its description, which is the text the model reads security
- Schema quality: 3560 → 4116 ▼ functional
- New tool “create_vault” functional
- “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” cosmetic
- 30 Oct 26 +1
- Stability: unverified → 0.03 ▲ functional
- 29 Oct 26 72
First indexed and scored.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 5 Nov 2026 · Probed https://brainz.brownmatter.ai/mcp
TLS valid
Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .
| Subject | Issuer | Valid from | Valid until | Key | Signature | Serial |
|---|---|---|---|---|---|---|
| CN=brownmatter.ai | CN=WE1,O=Google Trust Services,C=US | 7 Sept 2026 | 6 Dec 2026 | ECDSA 256 | ECDSA-SHA256 | bd02ed9a7a7c99b7138fd8f6f5b001a0 |
| SANs: brownmatter.ai, brainz.brownmatter.ai, *.brainz.brownmatter.ai | ||||||
| CN=WE1,O=Google Trust Services,C=US (CA) | CN=GTS Root R4,O=Google Trust Services LLC,C=US | 13 Dec 2023 | 20 Feb 2029 | ECDSA 256 | ECDSA-SHA384 | 7ff31977972c224a76155d13b6d685e3 |
| CN=GTS Root R4,O=Google Trust Services LLC,C=US (CA) | CN=GlobalSign Root CA,OU=Root CA,O=GlobalSign nv-sa,C=BE | 15 Nov 2023 | 28 Jan 2028 | ECDSA 384 | SHA256-RSA | 7fe530bf331343bedd821610493d8a1b |
Background: What to check on a remote MCP endpoint →
DNSSEC insecure
Validation of brainz.brownmatter.ai. — Not signed
| Zone | DS | Keys | Algorithms | Outcome |
|---|---|---|---|---|
| . | trust_anchor | 20326, 38696 | 8, 8 | Verified |
| ai. | present | 1814, 3799 | 8, 8 | Verified |
| brownmatter.ai. | absent | Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation |
Authentication Enforced and verified
The endpoint asked for a token and published valid RFC 9728 metadata describing how to get one.
| Result | Enforced and verified |
|---|---|
| Enforced | On tool calls |
| HTTP status | 200 |
WWW-Authenticate challenge Bearer resource_metadata="https://brainz.brownmatter.ai/.well-known/oauth-protected-resource/mcp", scope="vault"
Bearer resource_metadata="https://brainz.brownmatter.ai/.well-known/oauth-protected-resource/mcp", scope="vault" Protected resource metadata
| Document | https://brainz.brownmatter.ai/.well-known/oauth-protected-resource/mcp |
|---|---|
| Retrieved | Yes |
| Resource | https://brainz.brownmatter.ai/mcp |
| Authorisation server | https://brainz.brownmatter.ai |
Background: How OAuth 2.1 works in the 2026 MCP spec →
Transports 2 probes
| Transport | URL | Outcome | Status | Location |
|---|---|---|---|---|
| streamable-http | https://brainz.brownmatter.ai/mcp | Verified | 200 | |
| http (plaintext) | http://brainz.brownmatter.ai/mcp | Inconclusive | 406 |
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
complete_task Complete a task ~96
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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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. |
No output schema declared.
No examples provided.
create_task Create a task ~243
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.
| Name | Type | Req | Description |
|---|---|---|---|
| body | string | yes | 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 | yes | Human-readable task title (required, non-empty). |
No output schema declared.
No examples provided.
create_vault Create a vault ~136
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.
| Name | Type | Req | Description |
|---|---|---|---|
| name | string | yes | 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. |
No output schema declared.
No examples provided.
delete_concept Delete concept ~123
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 }.
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | Exact concept id (slug) to delete, e.g. "lead-scoring". |
No output schema declared.
No examples provided.
dream Dream (nightly consolidation) ~777
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.
| Name | Type | Req | Description |
|---|---|---|---|
| action | string | yes | "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. |
No output schema declared.
No examples provided.
get_concept Get concept ~97
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.
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | Exact concept id (slug), e.g. "lead-scoring". |
No output schema declared.
No examples provided.
get_context Assemble context bundle ~182
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`.
| Name | Type | Req | Description |
|---|---|---|---|
| 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). |
No output schema declared.
No examples provided.
get_related Get related concepts ~158
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.
| Name | Type | Req | Description |
|---|---|---|---|
| depth | integer | – | How many hops to traverse (1-3, default 1). |
| id | string | yes | 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"]. |
No output schema declared.
No examples provided.
link_concepts Link concepts ~155
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.
| Name | Type | Req | Description |
|---|---|---|---|
| from | string | yes | 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 | yes | Target concept id. |
No output schema declared.
No examples provided.
list_concepts List concepts ~112
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.
| Name | Type | Req | Description |
|---|---|---|---|
| product | string | – | Only concepts of this product. |
| tag | string | – | Only concepts carrying this tag. |
| type | string | – | Only concepts of this type. |
No output schema declared.
No examples provided.
list_tasks List tasks ~115
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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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. |
No output schema declared.
No examples provided.
onboard Onboard this vault ~370
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.
| Name | Type | Req | Description |
|---|---|---|---|
| action | string | yes | "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. |
No output schema declared.
No examples provided.
search_concepts Search concepts ~186
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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | 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. |
No output schema declared.
No examples provided.
sync Sync this vault to the current code ~454
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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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 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). |
No output schema declared.
No examples provided.
take_task Take a task off the pile ~164
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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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. |
No output schema declared.
No examples provided.
upsert_concept Create or update concept ~525
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.
| Name | Type | Req | Description |
|---|---|---|---|
| body | string | yes | 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 | yes | 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… |
No output schema declared.
No examples provided.
vault_stats Vault stats ~56
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.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
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.
remote · brainz.brownmatter.ai
claude mcp add --transport http ai-brownmatter-brainz 'https://brainz.brownmatter.ai/mcp'
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.