Skip to main content
Glama
mdz-axo

PT-MCP (Paul Test Man Context Protocol)

by mdz-axo

analyze_codebase

Analyze codebase structure, dependencies, and metrics to understand project architecture and identify patterns for improved development workflows.

Instructions

Perform comprehensive codebase analysis including structure, dependencies, and metrics

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesRoot directory path to analyze
languagesNoLanguages to analyze (auto-detect if omitted)
depthNoAnalysis depth (1-5, default: 3)
include_patternsNoGlob patterns to include
exclude_patternsNoGlob patterns to exclude
analysis_typeNoAnalysis thoroughness levelstandard

Implementation Reference

  • Core handler function for the analyze_codebase tool. Performs comprehensive analysis: file traversal with glob/ignore, language detection by extension, LOC counting, directory structure, entry point detection, package.json parsing, and generates JSON summary with metrics.
    export async function analyzeCodebase(
      args: AnalyzeCodebaseArgs
    ): Promise<{ content: Array<{ type: string; text: string }> }> {
      const {
        path: projectPath,
        languages = [],
        depth = 3,
        include_patterns = ["**/*"],
        exclude_patterns = [
          "**/node_modules/**",
          "**/.git/**",
          "**/dist/**",
          "**/build/**",
          "**/.next/**",
          "**/__pycache__/**",
          "**/*.pyc",
          "**/venv/**",
          "**/.venv/**",
        ],
        analysis_type = "standard",
      } = args;
    
      // Validate path exists
      try {
        await fs.access(projectPath);
      } catch {
        throw new Error(`Path does not exist: ${projectPath}`);
      }
    
      // Load .gitignore
      const ignore = await loadGitignore(projectPath);
    
      // Find all files
      const files = await glob(include_patterns, {
        cwd: projectPath,
        ignore: exclude_patterns,
        nodir: true,
        dot: false,
      });
    
      // Analyze each file
      const fileInfos: FileInfo[] = [];
      const languageStats: Record<string, { files: number; lines: number }> = {};
      const entryPoints: string[] = [];
      let totalLines = 0;
      let totalSize = 0;
    
      for (const file of files) {
        const fullPath = path.join(projectPath, file);
        const language = detectLanguage(file);
    
        // Skip if language filtering is active and this language is not included
        if (languages.length > 0 && !languages.includes(language)) {
          continue;
        }
    
        // Get file stats
        const stats = await fs.stat(fullPath);
        const lines = analysis_type !== "quick" ? await countLines(fullPath) : 0;
    
        fileInfos.push({
          relativePath: file,
          language,
          size: stats.size,
          lines,
        });
    
        // Update language statistics
        if (!languageStats[language]) {
          languageStats[language] = { files: 0, lines: 0 };
        }
        languageStats[language].files++;
        languageStats[language].lines += lines;
    
        // Update totals
        totalLines += lines;
        totalSize += stats.size;
    
        // Check for entry points
        if (isEntryPoint(file) && path.dirname(file).split(path.sep).length <= depth) {
          entryPoints.push(file);
        }
      }
    
      // Calculate language percentages
      const languages_result: Record<string, { files: number; lines: number; percentage: number }> =
        {};
      for (const [lang, stats] of Object.entries(languageStats)) {
        languages_result[lang] = {
          ...stats,
          percentage: totalLines > 0 ? (stats.lines / totalLines) * 100 : 0,
        };
      }
    
      // Get directory structure
      const directories = analysis_type !== "quick" ? await getDirectories(projectPath, ignore) : [];
    
      // Load package info
      const packageInfo = analysis_type !== "quick" ? await loadPackageInfo(projectPath) : undefined;
    
      // Build result
      const result: AnalysisResult = {
        projectPath,
        totalFiles: fileInfos.length,
        totalLines,
        totalSize,
        languages: languages_result,
        structure: {
          directories,
          depth: Math.max(...directories.map((d) => d.split(path.sep).length), 0),
        },
        files: analysis_type === "deep" ? fileInfos : [],
        entryPoints,
        packageInfo,
        analysisType: analysis_type,
        timestamp: new Date().toISOString(),
      };
    
      return {
        content: [
          {
            type: "text",
            text: JSON.stringify(result, null, 2),
          },
        ],
      };
    }
  • Input schema definition for the analyze_codebase tool, used in the ListTools response to describe parameters, types, and validation rules.
    name: "analyze_codebase",
    description: "Perform comprehensive codebase analysis including structure, dependencies, and metrics",
    inputSchema: {
      type: "object",
      properties: {
        path: {
          type: "string",
          description: "Root directory path to analyze",
        },
        languages: {
          type: "array",
          items: { type: "string" },
          description: "Languages to analyze (auto-detect if omitted)",
        },
        depth: {
          type: "number",
          description: "Analysis depth (1-5, default: 3)",
          minimum: 1,
          maximum: 5,
          default: 3,
        },
        include_patterns: {
          type: "array",
          items: { type: "string" },
          description: "Glob patterns to include",
        },
        exclude_patterns: {
          type: "array",
          items: { type: "string" },
          description: "Glob patterns to exclude",
        },
        analysis_type: {
          type: "string",
          enum: ["quick", "standard", "deep"],
          description: "Analysis thoroughness level",
          default: "standard",
        },
      },
      required: ["path"],
    },
  • Tool dispatch registration in the CallToolRequestSchema handler. Routes calls to 'analyze_codebase' to the analyzeCodebase function.
    case "analyze_codebase":
      return await analyzeCodebase(args as any);
  • src/index.ts:47-47 (registration)
    Main server initialization calls registerTools(server), which sets up the tool handlers including analyze_codebase.
    registerTools(server);
  • TypeScript interface defining the input arguments for the analyzeCodebase handler function.
    interface AnalyzeCodebaseArgs {
      path: string;
      languages?: string[];
      depth?: number;
      include_patterns?: string[];
      exclude_patterns?: string[];
      analysis_type?: "quick" | "standard" | "deep";
    }
Behavior2/5

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

No annotations are provided, so the description carries full burden for behavioral disclosure. While it mentions 'comprehensive analysis,' it doesn't describe what this entails operationally - whether it's read-only, how long it might take, what resources it consumes, or what format the results take. For a complex analysis tool with 6 parameters, this leaves significant behavioral questions unanswered.

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 a single, efficient sentence that gets straight to the point without unnecessary words. It's appropriately sized for the tool's complexity, though it could potentially benefit from being slightly more specific about what 'comprehensive' means in practice.

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?

For a complex analysis tool with 6 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what the analysis produces, how results are structured, what 'comprehensive' entails, or how this differs from sibling tools. The agent would need to guess about the tool's behavior and outputs.

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?

With 100% schema description coverage, the input schema already documents all 6 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain how parameters interact, provide usage examples, or clarify the meaning of 'comprehensive analysis' in relation to the parameters. This meets the baseline for high schema coverage.

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

Purpose4/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 with specific verbs ('perform comprehensive codebase analysis') and resources ('structure, dependencies, and metrics'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'analyze_dependencies' or 'extract_patterns', which appear to offer more specialized analyses.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools like 'analyze_dependencies' and 'extract_patterns' that seem related, there's no indication of when this comprehensive analysis is preferred over more specialized tools or what specific scenarios warrant its use.

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/mdz-axo/pt-mcp'

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