Skip to main content
Glama
TheAlchemist6

CodeCompass MCP

get_file_tree

Retrieve and filter directory structures from GitHub repositories to visualize file organization without analyzing content.

Instructions

🌳 Get complete directory structure and file listing with filtering options. Focused on file system structure without content analysis.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesGitHub repository URL
optionsNo

Implementation Reference

  • Defines the Tool object for 'get_file_tree' including name, description, and detailed inputSchema with url required and various filtering options.
    {
      name: 'get_file_tree',
      description: '🌳 Get complete directory structure and file listing with filtering options. Focused on file system structure without content analysis.',
      inputSchema: {
        type: 'object',
        properties: {
          url: {
            type: 'string',
            description: 'GitHub repository URL',
          },
          options: {
            type: 'object',
            properties: {
              max_depth: {
                type: 'number',
                description: 'Maximum directory depth to traverse',
                default: 10,
              },
              include_hidden: {
                type: 'boolean',
                description: 'Include hidden files and directories',
                default: false,
              },
              file_extensions: {
                type: 'array',
                items: { type: 'string' },
                description: 'Filter by file extensions (e.g., [".js", ".ts"])',
              },
              exclude_paths: {
                type: 'array',
                items: { type: 'string' },
                description: 'Paths to exclude from listing',
                default: ['node_modules', 'dist', 'build', '.git'],
              },
              include_file_info: {
                type: 'boolean',
                description: 'Include file metadata (size, modified date)',
                default: true,
              },
            },
          },
        },
        required: ['url'],
      },
    },
  • src/index.ts:236-240 (registration)
    Registers the consolidatedTools array (which includes get_file_tree schema) in response to MCP ListToolsRequestSchema.
    server.setRequestHandler(ListToolsRequestSchema, async () => {
      return {
        tools: consolidatedTools,
      };
    });
  • src/index.ts:260-262 (registration)
    Dispatches calls to 'get_file_tree' tool name to the handleGetFileTree handler function in the main CallToolRequestSchema switch statement.
    case 'search_repository':
      result = await handleSearchRepository(args);
      break;
  • Primary MCP tool handler that processes input arguments, calls GitHubService.getFileTree, formats response with metadata, and handles errors using standardized response format.
    async function handleGetFileTree(args: any) {
      const { url, options = {} } = args;
      
      try {
        const tree = await githubService.getFileTree(url);
        
        const response = {
          file_tree: tree,
          metadata: {
            max_depth: options.max_depth || 10,
            include_hidden: options.include_hidden || false,
            total_files: tree.length,
            filtered_extensions: options.file_extensions || null,
            excluded_paths: options.exclude_paths || ['node_modules', 'dist', 'build', '.git']
          }
        };
        
        return formatToolResponse(createResponse(response, null, { tool: 'get_file_tree', url }));
      } catch (error) {
        return formatToolResponse(createResponse(null, error, { tool: 'get_file_tree', url }));
      }
    }
  • GitHubService method that fetches the recursive git tree from GitHub API, parses repo details, builds structured FileNode tree using buildFileTree helper, and supports optional path filtering.
    async getFileTree(url: string, path?: string): Promise<FileNode[]> {
      const { owner, repo } = this.parseGitHubUrl(url);
    
      try {
        const { data: repoData } = await this.octokit.rest.repos.get({
          owner,
          repo,
        });
    
        const { data: treeData } = await this.octokit.rest.git.getTree({
          owner,
          repo,
          tree_sha: repoData.default_branch,
          recursive: 'true',
        });
    
        const fileTree = this.buildFileTree(treeData.tree);
        
        if (path) {
          return this.filterTreeByPath(fileTree, path);
        }
        
        return fileTree;
      } catch (error: any) {
        throw new Error(`Failed to fetch file tree: ${error.message}`);
      }
    }
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. While it mentions the tool is 'focused on file system structure without content analysis,' it doesn't describe what the output looks like (tree format, JSON structure), whether it's paginated, rate limits, authentication requirements, or error conditions. For a tool with 2 parameters (one being a complex nested object), this is insufficient behavioral context.

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?

The description is perfectly concise with two sentences that each earn their place. The first sentence states the core purpose with filtering context, and the second sentence provides important scope limitation. No wasted words, and the information is front-loaded appropriately.

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

Completeness2/5

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

Given the tool has 2 parameters (one complex nested object with 5 sub-properties), no annotations, and no output schema, the description is inadequate. It doesn't explain the output format, doesn't clarify the relationship between parameters, and leaves most behavioral aspects unspecified. For a tool that presumably returns structured directory data, this creates significant gaps for an AI agent.

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

Parameters3/5

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

Schema description coverage is 50% (only the 'url' parameter has a description in the schema). The description mentions 'filtering options' which aligns with the 'options' parameter, but doesn't explain what specific filters are available or their semantics. It adds minimal value beyond what's implied by the parameter names in the schema, resulting in a baseline score.

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 verb ('Get') and resource ('complete directory structure and file listing') with specific scope ('without content analysis'). It distinguishes from siblings like get_file_content (which retrieves file contents) and analyze_codebase (which performs content analysis). The emoji reinforces the tree structure concept.

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?

The description provides clear context about when to use this tool ('Focused on file system structure without content analysis'), which implicitly distinguishes it from content-focused siblings like analyze_codebase and explain_code. However, it doesn't explicitly state when NOT to use it or name specific alternative tools for different scenarios.

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/TheAlchemist6/codecompass-mcp'

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