MegaBrain
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| brain_consultA | MANDATORY PRE-FLIGHT CHECK: Call this before writing, designing, or refactoring code. Returns:
Args: context: The topic, stack, or task description (e.g., 'php mysql pdo', 'react button design', 'authentication') project: Project name/slug or 'global' |
| brain_record_experienceA | VACCINATE AGAINST MISTAKES: Call this whenever you spent >= 2 attempts fixing an error, encountered an unexpected runtime pitfall, or when the user says 'grava isso' / 'aprende isso'. Args: context: Stack/domain keywords (e.g., 'php mysql utf8mb4', 'docker windows networking') what_failed: The anti-pattern or rookie mistake the AI made fix_applied: The exact working solution or insight that solved it project: Project identifier or 'global' verified_snippet: (Optional) The working code block to also save as a Golden Pattern |
| brain_record_ruleB | Enforce a strict constraint that agents must always obey. Args: rule: The constraint statement (e.g., 'All code comments and docs must be in English') category: Category like 'language', 'architecture', 'security', 'git', 'style', 'general' project: Project identifier or 'global' severity: 'CRITICAL', 'HIGH', 'MEDIUM', or 'LOW' |
| brain_require_specA | Register a specification file that the agent MUST read before working on matching topics. Args: spec_path: Path to spec file (e.g., 'specs/design-tokens.md', 'docs/api.md') trigger_pattern: Comma-separated keywords triggering this requirement (e.g., 'design, ui, layout, componentes') instruction: Directive for the agent (e.g., 'Read design tokens before generating CSS') project: Project identifier or 'global' |
| brain_record_golden_patternB | Save a battle-tested code snippet that agents must copy/adopt instead of reinventing boilerplate. Args: title: Short descriptive title context: Stack/domain keywords (e.g., 'php mysql pdo') code_snippet: The exact verified working code explanation: Explanation of why this pattern is preferred project: Project identifier or 'global' |
| brain_list_rulesB | List all active rules for the given project including global rules. |
| brain_statsB | Get current knowledge base statistics. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| resource_rules | Read all global and project rules. |
| resource_stats | Read knowledge base statistics. |
TDQS
Scored across 7 tools
Most tools are clearly distinct (record_rule vs record_experience vs record_golden_pattern vs require_spec). However, brain_consult overlaps with brain_list_rules since consult already returns active rules, and record_experience with a verified_snippet partially duplicates record_golden_pattern, creating mild selection ambiguity.
All tools share a consistent brain_ prefix and snake_case verb_noun style (brain_record_rule, brain_list_rules, brain_require_spec). Minor deviations are brain_consult and brain_stats, which lack a noun object but remain readable and unambiguous.
Seven tools is well-scoped for a knowledge-base server covering retrieval, rule/spec/experience/pattern recording, and stats. Each tool maps to a distinct operation and none feels redundant or missing.
Write and read paths are covered (record rules/specs/experiences/patterns, consult, list_rules, stats), but there is no update or delete/retire operation for any stored artifact. Without lifecycle management, stale or wrong rules and vaccines cannot be corrected, which is a notable gap for a long-lived knowledge base.