MCP-сервер Brownmatter

• Имя в реестреai.brownmatter/brainzподтверждён в реестре MCP

Имя в реестре лежит в пространстве brownmatter.ai. Реестр пускает в такое пространство только того, кто доказал владение доменом через DNS или HTTP.

• Состояниеотвечаетпроверено 2026-10-29
• Инструменты16
• Сервер называет себяbrainz-cloud
• Версия сервера0.1.0
• Версия протокола2025-06-18

2026-10-29 сервер ответил на initialize и tools/list без входа. Первый ответ за 598 мс.

• Инструменты делают assemble token-budgeted context briefings for subagent prompts; queue and claim agent tasks wired to specs and code areas, но не invite teammates to browse the same product knowledge graph.
• Проверок пока 6 из 7, нужных, чтобы судить о надёжности.

Вывод сделан правилами по замерам выше. Вероятный первый вызов выбрала модель по списку инструментов: прочитайте описание, прежде чем на него полагаться.

• Оценка INITE MCPчерез неделюдля оценки нужно 7 ежедневных проверок, пока 6
• Что агент может с ним сделать2 из 3 сценариев
• Отвечалидёт замерпроверок пока 6, долю покажем после 7
• Медиана первого ответа488 мс
• Место в контексте агента≈ 5 839 токеновописания всех инструментов (17), они занимают контекст агента на каждом ходу
• Описания инструментовA · 100 из 100
• Типизированные ответы0 из 17 инструментовобъявлен outputSchema: ответ приходит с типами и читается сразу

• Все инструменты проходят все шесть проверок.

Программа проверяет сервер раз в день: initialize и tools/list, без модели. Токены - это длина описаний из расчёта примерно четыре символа на токен. Оценка - среднее шести проверок имени, описания, схемы и аннотаций каждого инструмента. Она говорит, насколько понятно описаны инструменты, а не о том, работают ли они. Оценка складывается только из замеренного: отвечает ли сервер (25%), делает ли работу продукта (25%), описания (20%), контекст (10%), использование (10%) и насколько просто подключиться (10%). Незамеренная часть не учитывается, а скрытая инструкция ограничивает оценку 40 баллами. Состояние MCP-серверов вендоров: методика и цифры →

• 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_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…

• get_related

  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…

• get_context

  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…

• upsert_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…

• 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…

• 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…

• 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…

• 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

  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…

• sync

  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…

• dream

  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…

• 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…

• take_task

  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…

• complete_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.

• create_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…