Skip to main content
Glama

Get Storage Status

get_storage_status

Check git status of the Knowledge MCP Server datastore to monitor uncommitted changes, verify remote sync, and debug storage issues. Use before sync operations or when changes aren't persisting.

Instructions

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:

  1. Use before sync operations

  2. Check when changes aren't persisting

  3. Verify remote configuration

  4. Monitor uncommitted changes

  5. 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}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • The primary handler implementation getStorageStatusAsync() that performs git commands to retrieve storage status including uncommitted changes, current branch, last commit, remote status, and detailed git status output.
    async getStorageStatusAsync(): Promise<string> {
      const context = this.createContext('get_storage_status', {});
    
      try {
        // Get git status
        let statusOutput = '';
        let hasChanges = false;
        try {
          const result = await gitCommandAsync(STORAGE_PATH, 'status', '--porcelain');
          statusOutput = result.stdout.trim();
          hasChanges = statusOutput.length > 0;
        } catch {
          // Git status failed, assume no changes
          hasChanges = false;
        }
    
        // Get current branch
        let currentBranch = '';
        try {
          const result = await gitCommandAsync(STORAGE_PATH, 'branch', '--show-current');
          currentBranch = result.stdout.trim();
        } catch {
          // No branch if no commits yet
          currentBranch = '';
        }
    
        // Get last commit info
        let lastCommit = 'No commits yet';
        try {
          const { stdout: logOutput } = await gitCommandAsync(
            STORAGE_PATH,
            'log',
            '-1',
            '--pretty=format:%h - %s (%cr)'
          );
          if (logOutput.trim()) {
            lastCommit = logOutput.trim();
          }
        } catch {
          // No commits yet
        }
    
        // Check if remote exists
        const hasRemote = await hasGitRemoteAsync(STORAGE_PATH);
    
        // Get remote status if available
        let remoteStatus = 'No remote configured';
        if (hasRemote) {
          try {
            const { stdout: remoteOutput } = await gitCommandAsync(
              STORAGE_PATH,
              'remote',
              'get-url',
              'origin'
            );
            remoteStatus = `Remote: ${remoteOutput.trim()}`;
    
            // Check if we're ahead/behind
            try {
              const { stdout: revListOutput } = await gitCommandAsync(
                STORAGE_PATH,
                'rev-list',
                '--count',
                '--left-right',
                'HEAD...origin/main'
              );
              const [ahead, behind] = revListOutput
                .trim()
                .split('\t')
                .map((n) => parseInt(n, 10));
              if (ahead > 0 || behind > 0) {
                remoteStatus += ` (${ahead} ahead, ${behind} behind)`;
              }
            } catch {
              // Can't determine ahead/behind status
            }
          } catch {
            // Error getting remote URL
          }
        }
    
        const result = {
          storage_path: STORAGE_PATH,
          has_changes: hasChanges,
          current_branch: currentBranch,
          last_commit: lastCommit,
          remote_status: remoteStatus,
          uncommitted_files: statusOutput.trim() ? statusOutput.trim().split('\n').length : 0,
          status_details: statusOutput.trim() || 'Working tree clean',
        };
    
        this.logSuccess('get_storage_status', {}, context);
        return this.formatSuccessResponse(result);
      } catch (error) {
        const mcpError = new MCPError(
          MCPErrorCode.GIT_ERROR,
          `Failed to get storage status: ${error instanceof Error ? error.message : String(error)}`,
          { traceId: context.traceId }
        );
        this.logError('get_storage_status', {}, mcpError, context);
        return this.formatErrorResponse(mcpError, context);
      }
    }
  • Registers the get_storage_status tool with the MCP server, specifying title, description from TOOL_DESCRIPTIONS, empty inputSchema, and handler delegation to serverHandler.getStorageStatusAsync().
    server.registerTool(
      'get_storage_status',
      {
        title: 'Get Storage Status',
        description: TOOL_DESCRIPTIONS.get_storage_status,
        inputSchema: {},
      },
      async () => {
        const result = await serverHandler.getStorageStatusAsync();
        return {
          content: [
            {
              type: 'text',
              text: result,
            },
          ],
        };
      }
    );
  • Detailed tool description including usage guidelines, when to use, key features, and expected output format implying the response structure.
      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:
    1. Use before sync operations
    2. Check when changes aren't persisting
    3. Verify remote configuration
    4. Monitor uncommitted changes
    5. 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}`,
Behavior4/5

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

With no annotations provided, the description carries full burden and does well. It explains what information the tool provides (uncommitted file count, current branch, etc.), when to use it (before sync operations, debugging), and what it returns. It doesn't mention rate limits or authentication needs, but for a read-only status tool, this is acceptable.

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

Conciseness4/5

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

The description is well-structured with clear sections (purpose, when to use, key features, usage instructions, exclusions, return values). While somewhat lengthy, every section adds value. The information is front-loaded with the core purpose first.

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?

For a 0-parameter tool with no annotations and no output schema, the description provides excellent completeness. It explains the tool's purpose, when to use it, what information it provides, and details the return structure. This fully compensates for the lack of structured metadata.

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?

The tool has 0 parameters with 100% schema description coverage, so the baseline would be 4. The description appropriately doesn't discuss parameters since none exist, which is correct for this case.

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 the tool's purpose: 'Shows git status of the knowledge datastore.' It specifies the exact resource (knowledge datastore) and action (shows git status). It distinguishes from siblings like 'get_server_info' by focusing specifically on git status rather than general server information.

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

Usage Guidelines5/5

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

The description provides explicit guidance with 'When to use this tool' (5 specific scenarios) and 'DO NOT use when' (3 exclusion criteria). It clearly differentiates from alternatives like 'get_server_info' by stating not to use when 'Just need server info' or 'Don't need git details.'

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

Related 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/sven-borkert/knowledge-mcp'

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