Skip to main content
Glama
diaz3618

memory-bank-mcp

get_instructions

Retrieve comprehensive instructions for using the Memory Bank MCP server. Call at the start of every session to understand available tools and the recommended workflow for persistent memory storage.

Instructions

⚠️ CALL THIS FIRST. Get comprehensive instructions for using the Memory Bank MCP server. Call this tool FIRST at the start of every session to understand the available tools and recommended workflow.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • Tool definition/schema for 'get_instructions' - defines the tool name, description, and empty inputSchema (no parameters required). The description instructs users to call this FIRST at the start of every session.
    export const coreTools = [
      {
        name: 'get_instructions',
        description: '⚠️ CALL THIS FIRST. Get comprehensive instructions for using the Memory Bank MCP server. Call this tool FIRST at the start of every session to understand the available tools and recommended workflow.',
        inputSchema: {
          type: 'object',
          properties: {},
          additionalProperties: false,
        },
      },
  • The handler function `handleGetInstructions()` - returns static comprehensive Markdown instructions for using the Memory Bank MCP server. No Memory Bank initialization required. Contains the full tool reference, workflow, valid modes, core files, and quick-start checklist.
    export function handleGetInstructions() {
      const instructions = `# Memory Bank MCP Server — Instructions
    
    ## What is Memory Bank?
    Memory Bank is an MCP server that persists project context across AI sessions.
    It stores progress, decisions, tasks, and a knowledge graph in a \`memory-bank/\`
    folder inside your project so that every new session can pick up where the last
    one left off.
    
    ## Mandatory Workflow (every task, no exceptions)
    
    ### START of task
    1. Call \`get_instructions\` (this tool) — you only need to do this once per session.
    2. Call \`get_context_digest\` to load the compact summary of current project state
       (tasks, issues, recent progress, recent decisions, and knowledge graph summary).
    3. Call \`graph_search\` with a relevant query to find knowledge graph entities
       related to the current task.
    
    ### DURING task
    4. Call \`track_progress\` after completing milestones.
    5. Call \`log_decision\` when making architectural or design choices.
    6. Call \`add_session_note\` for observations, blockers, or questions.
    
    ### END of task
    7. Call \`update_active_context\` with updated tasks, issues, and next steps.
    8. Call \`track_progress\` with a final summary of what was accomplished.
    9. Update knowledge graph entities if the project structure changed
       (use \`graph_upsert_entity\`, \`graph_add_observation\`, \`graph_link_entities\`).
    
    ## If Memory Bank Contains Placeholder Text
    If any core file contains \`[Project description]\` or \`[Task 1]\` style placeholders,
    the Memory Bank has never been populated. You MUST fill all core files with real
    project data before doing any other work.
    
    ## Valid Modes
    The ONLY valid modes are: architect, code, ask, debug, test.
    There is NO "full" mode. All tools are available in every mode — modes control
    behavior guidelines, not tool access. Use \`switch_mode\` to change modes.
    
    ## Core Memory Bank Files
    These files live in the \`memory-bank/\` directory:
    - **product-context.md** — Project overview, objectives, technologies, architecture
    - **active-context.md** — Ongoing tasks, known issues, next steps, session notes
    - **progress.md** — Completed & pending milestones, update history
    - **decision-log.md** — Architectural/design decisions with context and alternatives
    - **system-patterns.md** — Architecture, code, and documentation patterns.
      **IMPORTANT:** Read this file when starting work to understand project conventions.
      Update it whenever you introduce new patterns, change architecture, or adopt new coding conventions.
    
    ## Complete Tool Reference
    
    ### 1. Instructions
    | Tool | Purpose |
    |------|---------|
    | \`get_instructions\` | Return these instructions (call once per session) |
    
    ### 2. Context Loading (read-only)
    | Tool | Purpose |
    |------|---------|
    | \`get_context_digest\` | Compact summary: recent progress, tasks, issues, decisions, graph overview |
    | \`get_context_bundle\` | Full content of ALL core files in one response (larger payload) |
    | \`get_memory_bank_status\` | Status of the Memory Bank (initialized, path, file list) |
    | \`list_memory_bank_files\` | List all files in the Memory Bank directory |
    | \`search_memory_bank\` | Full-text search across all Memory Bank files |
    
    ### 3. File Operations
    | Tool | Purpose |
    |------|---------|
    | \`read_memory_bank_file\` | Read single file. **Params:** \`filename\` (string) |
    | \`write_memory_bank_file\` | Write single file. **Params:** \`filename\`, \`content\` (strings), optional \`ifMatchEtag\` |
    | \`batch_read_files\` | Read multiple files. **Params:** \`files\` (string array, e.g., ["progress.md", "active-context.md"]) |
    | \`batch_write_files\` | Write multiple files. **Params:** \`files\` (array of {filename, content, ifMatchEtag?}) |
    
    ### 4. Progress Tracking
    | Tool | Purpose |
    |------|---------|
    | \`track_progress\` | Record a progress milestone. **Params:** \`action\` (string), \`description\` (string) |
    | \`add_progress_entry\` | Structured progress entry. **Params:** \`type\` (feature/fix/refactor/docs/test/chore), \`summary\`, \`details\`, \`files\`, \`tags\` |
    | \`update_active_context\` | Update active-context.md. **Params:** \`tasks\`, \`issues\`, \`nextSteps\` (all string arrays) |
    | \`update_tasks\` | Modify tasks list. **Params:** \`add\`, \`remove\`, or \`replace\` (string arrays) |
    | \`add_session_note\` | Add timestamped note. **Params:** \`note\` (string), \`category\` (observation/blocker/question/decision/todo) |
    | \`log_decision\` | Log a decision. **Params:** \`title\`, \`context\`, \`decision\` (all strings) |
    
    ### 5. Knowledge Graph
    | Tool | Purpose |
    |------|---------|
    | \`get_targeted_context\` | **Preferred.** Budgeted context via KG + excerpts. **Params:** \`query\` (string), optional \`budget\`, \`entities\` |
    | \`graph_search\` | Search entities. **Params:** \`query\` (string), optional \`limit\` |
    | \`graph_open_nodes\` | Expand nodes and neighbors. **Params:** \`nodes\` (string array), optional \`depth\` |
    | \`graph_upsert_entity\` | Create/update entity. **Params:** \`name\`, \`entityType\` (strings), optional \`attrs\` |
    | \`graph_add_observation\` | Add observation. **Params:** \`entity\` (name string), \`text\` (string) |
    | \`graph_add_doc_pointer\` | Link entity to file. **Params:** \`entity\`, \`docPath\`, optional \`heading\` |
    | \`graph_link_entities\` | Create relationship. **Params:** \`from\`, \`to\`, \`relationType\` (all strings) |
    | \`graph_delete_entity\` | Delete entity/observation. **Params:** \`entity\` (name string), optional \`observationId\` |
    | \`graph_maintain\` | Maintenance ops. **Params:** \`operation\` (rebuild/compact/stats) |
    
    ### 6. Modes
    | Tool | Purpose |
    |------|---------|
    | \`switch_mode\` | Switch to a mode: architect, code, ask, debug, or test |
    
    ### 7. Setup & Administration
    | Tool | Purpose |
    |------|---------|
    | \`initialize_memory_bank\` | Create a new Memory Bank in a directory |
    | \`set_memory_bank_path\` | Point to an existing Memory Bank directory |
    | \`migrate_file_naming\` | Migrate files from camelCase to kebab-case |
    | \`debug_mcp_config\` | Debug the current MCP configuration |
    
    ### 8. Backup & Restore
    | Tool | Purpose |
    |------|---------|
    | \`create_backup\` | Create a timestamped backup (use listOnly:true to list backups) |
    | \`restore_backup\` | Restore from a backup (auto-creates pre-restore backup) |
    
    ### 9. Multi-Store Management
    | Tool | Purpose |
    |------|---------|
    | \`list_stores\` | List all registered stores (use action:"register"/"unregister" to manage) |
    | \`select_store\` | Switch the active store (by path or storeId) |
    
    ### 10. Sequential Thinking
    | Tool | Purpose |
    |------|---------|
    | \`sequential_thinking\` | Record thinking step. **Params:** \`thought\`, \`thoughtNumber\`, \`totalThoughts\` (int), \`nextThoughtNeeded\` (bool). Use \`reset:true\` to clear |
    | \`finalize_thinking_session\` | Persist outcomes. **Params:** \`summary\` (string), optional \`decisions\`, \`tasks\`, \`progress\` |
    
    ## Quick-Start Checklist
    1. \`get_instructions\` — read these instructions (done!)
    2. \`get_context_digest\` — load current project state
    3. \`get_targeted_context\` or \`graph_search\` — find relevant context for your task
    4. Do your work, calling \`track_progress\` / \`log_decision\` / \`add_session_note\` as you go
    5. Use \`sequential_thinking\` for complex reasoning, then \`finalize_thinking_session\` to persist
    6. \`update_active_context\` — save updated tasks, issues, next steps
    7. \`track_progress\` — final summary of accomplishments
    `;
    
      return {
        content: [
          {
            type: 'text',
            text: instructions,
          },
        ],
      };
    }
  • Registration of the 'get_instructions' tool handler in the switch statement within `setupToolHandlers`. When the tool name is 'get_instructions', it calls `handleGetInstructions()` directly without needing Memory Bank.
    switch (request.params.name) {
      // Instructions (no Memory Bank required)
      case 'get_instructions': {
        return handleGetInstructions();
      }
  • Import of `handleGetInstructions` from CoreTools.ts, making it available for registration in the tool handler switch statement.
    import { coreTools, handleGetInstructions, handleSetMemoryBankPath, handleInitializeMemoryBank, handleReadMemoryBankFile, handleWriteMemoryBankFile, handleListMemoryBankFiles, handleGetMemoryBankStatus, handleMigrateFileNaming, handleDebugMcpConfig, handleGetContextBundle, handleGetContextDigest, handleSearchMemoryBank, handleCreateBackup, handleRestoreBackup, handleAddProgressEntry, handleAddSessionNote, handleUpdateTasks, handleBatchReadFiles, handleBatchWriteFiles } from './CoreTools.js';
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It describes the tool as providing instructions, implying a safe, read-only operation. Adds context about being the first call, which is helpful. Could be improved by explicitly stating it doesn't modify any state.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with a warning emoji. Front-loaded with important usage instruction. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters and no output schema, the description fully covers what the tool does (provides instructions) and when to call it. No gaps remain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters in schema, and schema description coverage is 100%. Baseline score is 4, and description does not need to add parameter details. It focuses on behavior.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it provides comprehensive instructions for the Memory Bank MCP server and emphasizes it should be called first. This is a specific verb+resource combination that distinguishes it from sibling tools that perform other tasks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'CALL THIS FIRST' and 'at the start of every session', providing clear when-to-use guidance. It doesn't mention when not to use it, but that's implicit given its role as a starting point.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/diaz3618/memory-bank-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server