| get_project_main | Retrieve main.md content for a project's central instructions and configuration. When to use this tool: Starting work on any project (ALWAYS use FIRST) Refreshing your understanding of project guidelines Checking for updates to project instructions Migrating from local CLAUDE.md files to centralized storage
Key features: Replaces need for local CLAUDE.md files completely Auto-detects project from git repository or directory name Returns structured content with sections for easy parsing Provides project-specific instructions and context
You should: ALWAYS call this first when starting work on a project Use the returned content as your primary behavioral guide Check if project exists before assuming it doesn't Migrate local CLAUDE.md files immediately if project not found Parse sections to understand project structure and requirements Treat this as your source of truth over any local files Remember project_id for subsequent operations
DO NOT use when: Returns: {exists: bool, content: str, error?: str} |
| update_project_main | Create or completely replace main.md content for a project. When to use this tool: Migrating CLAUDE.md content to centralized MCP storage Creating a new project's instruction set Completely rewriting project guidelines Setting up initial project configuration
Key features: Creates project if it doesn't exist (auto-initialization) Completely replaces existing content (destructive update) Automatically commits changes to git Validates markdown structure
You should: Check if project exists first with get_project_main Preserve important sections when doing full updates Use update_project_section for partial changes instead Include all necessary sections in the new content Validate markdown formatting before submission Consider the impact of complete replacement Document why full replacement is necessary
DO NOT use when: Making small updates (use update_project_section instead) You haven't read the existing content first Uncertain about losing existing content
Returns: {success: bool, message?: str, error?: str} |
| update_project_section | Update a specific section within the project main.md file efficiently. When to use this tool: Modifying a single section without affecting others Adding new configuration or guidelines to existing section Fixing errors in specific sections Updating outdated information in targeted areas Making incremental improvements
Key features: Preserves all other sections intact (non-destructive) More efficient than full file replacement Maintains document structure Atomic section-level updates
You should: Identify the exact section header including "## " prefix Read the current section content first if needed Preserve section formatting conventions Use this instead of update_project_main for small changes Verify section exists before attempting update Keep section content focused and relevant Consider impact on related sections
DO NOT use when: Section doesn't exist (use add_project_section) Need to update multiple sections (batch operations) Restructuring entire document
Section header must match exactly (e.g., "## Installation")
Returns: {success: bool, message?: str, error?: str} |
| remove_project_section | Remove a specific section from the project main.md file. When to use this tool: Removing deprecated or obsolete sections Cleaning up redundant information Restructuring document by removing sections Eliminating outdated guidelines
Key features: You should: Verify section exists before removal Consider if content should be moved elsewhere Check for references to this section Document why section is being removed Use exact section header with "## " prefix
DO NOT use when: Returns: {success: bool, message?: str, error?: str} |
| add_project_section | Add a new section to the project main.md file with precise positioning control. When to use this tool: Introducing new topics or guidelines to project Expanding project documentation systematically Adding configuration sections Creating new instruction categories Organizing content into new logical groups
Key features: Flexible positioning (before/after/end) Maintains document structure and flow Non-destructive addition Reference-based positioning for precision
You should: Choose meaningful section headers with "## " prefix Decide optimal position for the new section Use reference_header for precise placement Keep sections focused on single topics Follow existing section naming conventions Consider document flow and readability Add sections progressively, not all at once
DO NOT use when: Section already exists (use update_project_section) Content belongs in existing section Unsure about section organization
Position options: "before", "after", "end" (default)
Returns: {success: bool, message?: str, error?: str} |
| delete_project | Permanently delete a project and all its content - USE WITH EXTREME CAUTION. When to use this tool: Project is completely obsolete Cleaning up test or temporary projects Project has been migrated elsewhere Explicit user request to delete
Key features: You should: ALWAYS confirm with user before deletion Verify project_id is correct Consider backing up important content first Understand this is permanent Check if project has valuable knowledge files Document reason for deletion
DO NOT use when: Any doubt about deletion Project might be needed later Haven't backed up important content User hasn't explicitly confirmed
⚠️ This action CANNOT be undone!
Returns: {success: bool, project_id: str, message: str, error?: str} |
| create_knowledge_file | Create a structured knowledge document with rich metadata and chapters. When to use this tool: Documenting specific technical topics or APIs Creating reference guides for project components Building troubleshooting or how-to guides Organizing domain-specific knowledge Archiving important technical decisions
Key features: Structured with chapters for easy navigation Searchable via keywords Automatic filename sanitization (spaces→hyphens) Metadata for context and discovery Supports up to 50 chapters per document
You should: Search first to avoid creating duplicates Choose descriptive, specific filenames Include 3-5 relevant keywords minimum Structure content into logical chapters Write clear chapter titles (max 200 chars) Include practical examples in content Add .md extension to filename Keep chapters focused and concise Consider future searchability
DO NOT use when: Content belongs in main.md Document already exists (search first!) Information is temporary or transient Creating index/navigation files
Chapters require 'title' and 'content' keys
Returns: {success: bool, document_id?: str, message?: str, error?: str} |
| get_knowledge_file | Retrieve complete content of a knowledge document including all metadata and chapters. When to use this tool: Needing full document for comprehensive review Backing up or exporting documents Migrating content between projects Loading small documents completely
Key features: Returns complete document with all chapters Includes metadata (title, keywords, introduction) Preserves document structure Full content access
You should: Consider using chapter operations for large documents Check document exists first Include .md extension in filename Be aware this loads entire document into memory Use chapter iteration for partial access Cache result if accessing multiple times
DO NOT use when: Only need specific chapters (use get_chapter) Document is very large (use chapter operations) Just need to search content (use search_knowledge)
Returns: {success: bool, document?: object, error?: str} |
| delete_knowledge_file | Permanently delete a knowledge document - this action cannot be undone. When to use this tool: Document is obsolete or incorrect Consolidating duplicate documents Removing outdated information Explicit request to delete
Key features: You should: Verify document exists first Check if content should be preserved elsewhere Confirm filename is correct (with .md extension) Understand deletion is permanent Consider if update would be better
DO NOT use when: Returns: {success: bool, message?: str, error?: str} |
| search_knowledge | Search project knowledge documents for keywords with intelligent result grouping. When to use this tool: Finding information across multiple documents Locating specific technical details Discovering related content Checking if topic is already documented Researching before creating new content
Key features: Case-insensitive full-text search Searches document body, titles, and content Groups results by document Returns matching chapters with context Space-separated keyword support
You should: Use specific keywords for better results Try multiple search terms if needed Search before creating new documents Use 2-3 word phrases for precision Review all results before concluding Consider variations of technical terms Check both titles and content matches
DO NOT use when: Know exact document and chapter Need complete document listing Searching for project main content
Returns: {success: bool, total_documents: int, total_matches: int, results: [...], error?: str} |
| update_chapter | Update a specific chapter within a knowledge document efficiently. When to use this tool: Correcting information in a specific chapter Expanding chapter with new content Updating code examples or commands Refreshing outdated chapter content Adding clarifications or improvements
Key features: Preserves all other chapters intact Maintains document structure Updates chapter summary for search Efficient partial document update
You should: Use exact chapter title (case-sensitive match) Read current chapter first if needed Preserve chapter's role in document flow Update summary if content focus changes Keep consistent formatting with other chapters Consider impact on related chapters Include .md extension in filename
DO NOT use when: Chapter doesn't exist (use add_chapter) Need to update multiple chapters Restructuring entire document
Returns: {success: bool, message?: str, error?: str} |
| remove_chapter | Remove a specific chapter from a knowledge document. When to use this tool: Removing outdated or incorrect chapters Consolidating overlapping content Streamlining document structure Eliminating redundant information
Key features: You should: Verify chapter exists with exact title Consider if content should be preserved Check for references from other chapters Use case-sensitive chapter title Understand removal is permanent
DO NOT use when: Returns: {success: bool, message?: str, error?: str} |
| add_chapter | Add a new chapter to an existing knowledge document with positioning control. When to use this tool: Expanding document with new topics Adding examples or case studies Including additional reference material Inserting clarifying chapters Growing documentation organically
Key features: Flexible positioning (before/after/end) Maintains document flow Maximum 50 chapters per document Reference-based positioning
You should: Choose clear, descriptive chapter titles Position chapter logically in document flow Keep chapters focused on single topics Use reference_chapter for precise placement Consider reader's journey through document Check current chapter count (max 50) Include practical, actionable content
DO NOT use when: Position options: "before", "after", "end" (default)
Returns: {success: bool, message?: str, error?: str} |
| list_chapters | List all chapters in a knowledge document with titles and summaries only. When to use this tool: Getting document overview without loading all content Planning which chapters to read or update Understanding document structure Checking chapter organization Finding specific chapters efficiently
Key features: Lightweight operation (no content loading) Returns titles and summaries only Shows chapter count and order Enables informed navigation
You should: Use this before get_knowledge_file for large documents Identify relevant chapters before reading Check document structure before modifications Use for navigation planning Include .md extension in filename
DO NOT use when: Returns: {success: bool, project_id: str, filename: str, total_chapters: int, chapters: array} |
| get_chapter | Retrieve a single chapter's content by title or index. When to use this tool: Reading specific chapter content Reviewing targeted information Updating specific chapter (read first) Accessing chapter without loading entire document Efficient partial document access
Key features: Access by title OR index (0-based) Returns navigation info (has_next, has_previous) Memory-efficient for large documents Includes chapter summary
You should: Use chapter_title for known chapters Use chapter_index for sequential reading Specify either title OR index, not both Use exact title match (case-sensitive) Consider using get_next_chapter for sequences Cache results if accessing multiple times
DO NOT use when: Need multiple chapters (batch operations) Don't know chapter title or index Need full document context
Returns: {success: bool, title: str, content: str, summary: str, index: int, total_chapters: int, has_next: bool, has_previous: bool} |
| get_next_chapter | Get the next chapter after the current one in sequence. When to use this tool: Reading document sequentially Continuing from current position Implementing pagination through document Following document flow naturally
Key features: Automatic progression to next chapter Returns null if at end Maintains reading context Efficient sequential access
You should: Use current_chapter_title OR current_index Check has_next before calling Use for sequential document traversal Handle end-of-document gracefully Consider document flow and continuity
DO NOT use when: Returns: {success: bool, title?: str, content?: str, summary?: str, index?: int, total_chapters: int, has_next: bool} |
| get_server_info | Shows server information including version from package.json. When to use this tool: Checking server version and capabilities Debugging connection issues Verifying server configuration Getting storage path information Troubleshooting problems
Key features: Returns version information Shows storage path configuration Provides server description Lightweight status check
You should: Use for initial connection verification Check when debugging issues Include in bug reports Verify server is responding
DO NOT use when: Returns: {success: bool, name: str, version: str, storage_path: str, description: str} |
| get_storage_status | Shows git status of the knowledge datastore. When to use this tool: Checking for uncommitted changes Verifying sync status with remote Debugging storage issues Understanding current branch Reviewing repository state
Key features: Shows uncommitted file count Displays current branch Shows last commit info Indicates remote sync status Provides detailed git status
You should: Use before sync operations Check when changes aren't persisting Verify remote configuration Monitor uncommitted changes Debug sync failures
DO NOT use when: Just need server info Don't need git details Already know status
Returns: {success: bool, storage_path: str, has_changes: bool, current_branch: str, last_commit: str, remote_status: str, uncommitted_files: int, status_details: str} |
| sync_storage | Force git add, commit, and push all changes in the knowledge datastore. When to use this tool: Key features: Commits ALL uncommitted changes Pushes to configured remote Auto-generates commit message Handles push failures gracefully Forces synchronization
You should: Check storage_status first Use when auto-sync fails Verify remote is configured Handle push failures appropriately Use sparingly (auto-sync usually works)
DO NOT use when: Returns: {success: bool, message: str, files_committed: int, pushed: bool, push_error?: str, commit_message: str} |
| list_todos | List all TODO lists in a project with their completion status. When to use this tool: Getting overview of all project tasks Checking TODO completion progress Finding specific TODO lists Planning task execution Reviewing project task status
Key features: Shows all TODO lists with descriptions Includes completion statistics Returns TODO numbers for reference Lightweight overview operation
You should: Use before creating new TODOs Check for existing related TODOs Note TODO numbers for operations Review completion percentages Use to avoid duplicate TODOs
DO NOT use when: Returns: {success: bool, todos: [...], error?: str} |
| create_todo | Create a new TODO list with optional initial tasks and rich markdown support. When to use this tool: User explicitly requests "create a TODO" Planning multi-step implementation tasks Organizing feature development work Tracking bug fixes or improvements Creating task lists for later execution
Key features: Rich markdown support in task content Optional initial task list Auto-incrementing TODO numbers Task content supports code blocks Hierarchical task organization
You should: ONLY create when user explicitly requests Include clear, actionable task descriptions Break complex work into subtasks Use markdown for code examples in tasks Number tasks logically Keep descriptions concise but complete Group related tasks together
DO NOT use when: User hasn't explicitly asked for TODO Tasks are trivial or single-step Work will be done immediately TODO already exists for this work
Tasks need {title: str, content?: str} format
Returns: {success: bool, todo_number: int, message: str, error?: str} |
| add_todo_task | Add a new task to an existing TODO list with full markdown support. When to use this tool: Expanding existing TODO with new tasks Adding discovered subtasks during work Including additional requirements Appending follow-up tasks Adding clarifications or details
Key features: Full markdown support in content Can include code blocks and examples Auto-incrementing task numbers Preserves existing task order Rich formatting capabilities
You should: Verify TODO exists first Use clear, actionable task titles (max 200 chars) Include implementation details in content Add code examples where helpful Position task logically in sequence Keep task scope focused Use markdown formatting effectively
DO NOT use when: Returns: {success: bool, task_number: int, message: str, error?: str} |
| remove_todo_task | Remove a task from a TODO list. When to use this tool: Task is no longer relevant Removing duplicate tasks Task was added by mistake Consolidating similar tasks Cleaning up TODO list
Key features: Permanent task removal Preserves other tasks Updates task numbering
You should: Verify task exists first Consider if task is truly unnecessary Check task number is correct Understand removal is permanent Document why removing if significant
DO NOT use when: Task should be completed instead Task might be needed later Unsure about removal impact
Returns: {success: bool, message: str, error?: str} |
| complete_todo_task | Mark a task as completed in a TODO list. When to use this tool: Task implementation is fully complete Task requirements are met Moving to next task in sequence Updating progress status Recording completion for tracking
Key features: Marks task with completion timestamp Updates TODO completion percentage Preserves task content and history Cannot be undone
You should: ONLY mark complete when truly finished Verify task is actually done Test/validate before marking complete Complete tasks as you finish them Don't batch completions Move to next task after completing
DO NOT use when: Returns: {success: bool, message: str, error?: str} |
| get_next_todo_task | Get the next incomplete task in a TODO list for sequential execution. When to use this tool: Working through TODO sequentially Finding next task to implement Checking for remaining work Continuing interrupted work Following task order
Key features: Returns first incomplete task Provides task number and description Indicates when all complete Maintains task sequence
You should: Use after completing current task Follow sequential task order Handle "all complete" case Read full task details if needed Mark complete before getting next
DO NOT use when: Returns: {success: bool, task?: {number: int, description: str}, message?: str, error?: str} |
| get_todo_tasks | Get all tasks in a TODO list with their completion status and full content. When to use this tool: Reviewing full TODO list details Planning task execution order Checking task completion status Understanding task requirements Getting comprehensive task view
Key features: Returns all tasks with content Shows completion status per task Includes rich markdown content Provides task numbers and order Full TODO context
You should: Use TODO number from list_todos Review all tasks before starting Note incomplete task numbers Plan execution strategy Check task dependencies Identify complex tasks needing breakdown
DO NOT use when: Only need next task TODO doesn't exist Just need TODO overview
Returns: {success: bool, todo: {...}, tasks: [...], error?: str} |
| delete_todo | Delete an entire TODO list and all its tasks permanently. When to use this tool: TODO is completely finished TODO is obsolete or cancelled Cleaning up old TODOs Consolidating duplicate TODOs User explicitly requests deletion
Key features: You should: Verify all tasks are complete or obsolete Confirm TODO number is correct Understand deletion is permanent Consider if TODO has value for history Check no active work depends on it
DO NOT use when: TODO has incomplete relevant tasks Might need TODO for reference Unsure about deletion impact
Returns: {success: bool, message: str, error?: str} |