Skip to main content
Glama
mdz-axo

PT-MCP (Paul Test Man Context Protocol)

by mdz-axo

extract_patterns

Identify and extract architectural, design, naming, and testing patterns from codebases to analyze project structure and coding practices.

Instructions

Identify and extract architectural and coding patterns from the codebase

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesRoot directory path
pattern_typesNoTypes of patterns to extract (architectural, design, naming, testing)
min_occurrencesNoMinimum occurrences to consider a pattern

Implementation Reference

  • Core handler function for the 'extract_patterns' tool. Scans the codebase, extracts architectural/design/naming/testing patterns from code files, aggregates occurrences, enriches with KG data using YAGO resolver, stores in database, and returns formatted markdown results.
    export async function extractPatterns(
      args: ExtractPatternsArgs
    ): Promise<{ content: Array<{ type: string; text: string }> }> {
      const { path, pattern_types = ['architectural', 'design', 'naming', 'testing'], min_occurrences = 3 } = args;
    
      const patterns: Record<string, DetectedPattern[]> = {
        architectural: [],
        design: [],
        naming: [],
        testing: [],
      };
    
      // Scan codebase for patterns
      const files = await getCodeFiles(path);
    
      for (const file of files) {
        const content = await readFile(file, 'utf-8');
        const relPath = relative(path, file);
    
        // Extract different pattern types
        if (pattern_types.includes('architectural')) {
          const archPatterns = extractArchitecturalPatterns(content, relPath);
          patterns.architectural.push(...archPatterns);
        }
    
        if (pattern_types.includes('design')) {
          const designPatterns = extractDesignPatterns(content, relPath);
          patterns.design.push(...designPatterns);
        }
    
        if (pattern_types.includes('naming')) {
          const namingPatterns = extractNamingPatterns(content, relPath);
          patterns.naming.push(...namingPatterns);
        }
    
        if (pattern_types.includes('testing')) {
          const testPatterns = extractTestingPatterns(content, relPath);
          patterns.testing.push(...testPatterns);
        }
      }
    
      // Aggregate and filter by min_occurrences
      const aggregated: Record<string, DetectedPattern[]> = {};
    
      for (const [type, typePatterns] of Object.entries(patterns)) {
        const grouped = groupPatterns(typePatterns, min_occurrences);
        aggregated[type] = grouped;
    
        // Enrich with knowledge graph
        for (const pattern of grouped) {
          await enrichPatternWithKG(pattern);
        }
      }
    
      // Store in database
      await storePatternsInDB(aggregated);
    
      // Format results
      const results = formatPatternResults(aggregated);
    
      return {
        content: [
          {
            type: 'text',
            text: results,
          },
        ],
      };
    }
  • Input schema definition for the extract_patterns tool used in tool listing (ListToolsRequest). Defines parameters: path (required), pattern_types (array), min_occurrences (number, default 3).
    inputSchema: {
      type: "object",
      properties: {
        path: {
          type: "string",
          description: "Root directory path",
        },
        pattern_types: {
          type: "array",
          items: { type: "string" },
          description: "Types of patterns to extract (architectural, design, naming, testing)",
        },
        min_occurrences: {
          type: "number",
          description: "Minimum occurrences to consider a pattern",
          default: 3,
        },
      },
      required: ["path"],
    },
  • Tool handler registration: switch case dispatching calls to extract_patterns to the imported extractPatterns function in registerTools(server).
    case "extract_patterns":
      return await extractPatterns(args as any);
  • src/index.ts:199-222 (registration)
    Tool registration in ListToolsRequest handler: defines name, description, and inputSchema for extract_patterns.
    {
      name: "extract_patterns",
      description: "Identify and extract architectural and coding patterns from the codebase",
      inputSchema: {
        type: "object",
        properties: {
          path: {
            type: "string",
            description: "Root directory path",
          },
          pattern_types: {
            type: "array",
            items: { type: "string" },
            description: "Types of patterns to extract (architectural, design, naming, testing)",
          },
          min_occurrences: {
            type: "number",
            description: "Minimum occurrences to consider a pattern",
            default: 3,
          },
        },
        required: ["path"],
      },
    },
  • Helper function to extract architectural patterns like MVC, Repository, Service Layer from file paths and content.
    function extractArchitecturalPatterns(content: string, file: string): DetectedPattern[] {
      const patterns: DetectedPattern[] = [];
    
      // MVC pattern
      if (file.includes('/controllers/') || content.includes('Controller')) {
        patterns.push({
          type: 'architectural',
          name: 'MVC',
          occurrences: 1,
          examples: [file],
          confidence: 0.85,
        });
      }
    
      // Repository pattern
      if (file.includes('/repositories/') || content.match(/class \w+Repository/)) {
        patterns.push({
          type: 'architectural',
          name: 'Repository Pattern',
          occurrences: 1,
          examples: [file],
          confidence: 0.9,
        });
      }
    
      // Service layer
      if (file.includes('/services/') || content.match(/class \w+Service/)) {
        patterns.push({
          type: 'architectural',
          name: 'Service Layer',
          occurrences: 1,
          examples: [file],
          confidence: 0.85,
        });
      }
    
      // Dependency injection
      if (content.includes('inject(') || content.includes('@Injectable') || content.includes('constructor(')) {
        patterns.push({
          type: 'architectural',
          name: 'Dependency Injection',
          occurrences: 1,
          examples: [file],
          confidence: 0.8,
        });
      }
    
      // Microservices
      if (file.includes('/microservices/') || file.includes('/services/') && content.includes('express')) {
        patterns.push({
          type: 'architectural',
          name: 'Microservices',
          occurrences: 1,
          examples: [file],
          confidence: 0.75,
        });
      }
    
      return patterns;
    }
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'identifies and extracts' patterns but doesn't explain what this entails—e.g., whether it scans files recursively, outputs results in a specific format, requires specific permissions, or has performance considerations like rate limits. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.

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 a single, efficient sentence: 'Identify and extract architectural and coding patterns from the codebase.' It's front-loaded with the core purpose, has zero wasted words, and is appropriately sized for the tool's complexity. Every part of the sentence contributes to understanding the tool's function.

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's complexity (analyzing codebases for patterns), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like how results are returned, what formats are supported, or any prerequisites. With no structured data to fill these gaps, the description should provide more context to be fully helpful 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?

The schema description coverage is 100%, with clear descriptions for all three parameters ('path,' 'pattern_types,' 'min_occurrences'). The description doesn't add any additional meaning beyond what the schema provides, such as explaining how 'pattern_types' are used or what 'min_occurrences' implies in practice. Given the high schema coverage, a baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.

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: 'Identify and extract architectural and coding patterns from the codebase.' It specifies the verb ('identify and extract'), resource ('architectural and coding patterns'), and target ('from the codebase'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate itself from sibling tools like 'analyze_codebase' or 'extract_api_surface,' which might have overlapping functionality.

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 sibling tools like 'analyze_codebase,' 'extract_api_surface,' and 'enrich_context,' there's no indication of how this tool differs in context or application. It lacks explicit when-to-use or when-not-to-use instructions, leaving the agent to infer usage based on the name and description alone.

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