Skip to main content
Glama

analyze_project_ecosystem

Analyze project ecosystems to generate architectural decision records by examining codebases, dependencies, and technologies with recursive analysis.

Instructions

Comprehensive recursive project ecosystem analysis with advanced prompting techniques (Knowledge Generation + Reflexion)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
projectPathNoPath to the project directory to analyze (optional, uses configured PROJECT_PATH if not provided)
includePatternsNoFile patterns to include in analysis
enhancedModeNoEnable advanced prompting features (Knowledge Generation + Reflexion)
knowledgeEnhancementNoEnable Knowledge Generation for technology-specific insights
learningEnabledNoEnable Reflexion learning from past analysis outcomes
technologyFocusNoSpecific technologies to focus analysis on (auto-detected if not provided)
analysisDepthNoDepth of ecosystem analysiscomprehensive
includeEnvironmentNoAutomatically include comprehensive environment analysis (default: true)
recursiveDepthNoDepth of recursive project analysiscomprehensive
analysisScopeNoSpecific analysis areas to focus on (e.g., ["security", "performance", "architecture", "dependencies"])
conversationContextNoRich context from the calling LLM about user goals and discussion history

Implementation Reference

  • Core handler function that creates the CE-MCP OrchestrationDirective for comprehensive project ecosystem analysis. Defines sandbox operations for phased analysis including file scanning, environment config, knowledge enhancement, and context assembly.
    export function createAnalyzeProjectEcosystemDirective(
      args: CEMCPAnalyzeProjectEcosystemArgs
    ): OrchestrationDirective {
      const {
        projectPath,
        analysisDepth = 'comprehensive',
        includeEnvironment = true,
        knowledgeEnhancement = getKnowledgeEnhancementDefault(), // Environment-aware default
        // learningEnabled is used for future reflexion integration
        learningEnabled: _learningEnabled = true,
        technologyFocus = [],
        analysisScope = [],
      } = args;
      void _learningEnabled; // Mark as intentionally unused for now
    
      const operations: SandboxOperation[] = [
        // Phase 1: Load project structure
        {
          op: 'analyzeFiles',
          args: {
            patterns: ['**/*.ts', '**/*.js', '**/*.json', '**/*.yaml', '**/*.yml'],
            maxFiles: analysisDepth === 'basic' ? 50 : analysisDepth === 'standard' ? 100 : 200,
          },
          store: 'projectFiles',
        },
    
        // Phase 2: Scan environment configuration
        {
          op: 'scanEnvironment',
          store: 'environmentConfig',
        },
    
        // Phase 3: Load architectural knowledge (conditional on knowledgeEnhancement)
        ...(knowledgeEnhancement
          ? [
              {
                op: 'loadKnowledge' as const,
                args: {
                  domain: 'architecture',
                  scope: 'project',
                  technologies: technologyFocus,
                },
                store: 'architecturalKnowledge',
              },
            ]
          : []),
    
        // Phase 4: Load analysis prompt (lazy loading)
        {
          op: 'loadPrompt',
          args: {
            name: 'analysis',
            section: 'project_analysis',
          },
          store: 'analysisPrompt',
        },
    
        // Phase 5: Generate combined context
        {
          op: 'generateContext',
          args: {
            type: 'ecosystem-analysis',
            depth: analysisDepth,
            includeEnvironment,
            technologyFocus,
            analysisScope,
          },
          inputs: ['projectFiles', 'environmentConfig', 'architecturalKnowledge', 'analysisPrompt'],
          store: 'analysisContext',
        },
    
        // Phase 6: Cache the context for potential reuse
        {
          op: 'cacheResult',
          args: {
            key: `ecosystem-analysis:${projectPath}:${analysisDepth}`,
            ttl: 3600, // 1 hour cache
          },
          input: 'analysisContext',
        },
    
        // Phase 7: Compose final result
        {
          op: 'composeResult',
          inputs: ['projectFiles', 'environmentConfig', 'architecturalKnowledge', 'analysisContext'],
          return: true,
        },
      ];
    
      return {
        type: 'orchestration_directive',
        version: '1.0',
        tool: 'analyze_project_ecosystem',
        description: `Comprehensive ecosystem analysis for ${projectPath} with ${analysisDepth} depth`,
        sandbox_operations: operations,
        compose: {
          sections: [
            { source: 'projectFiles', key: 'projectStructure', transform: 'summarize' },
            { source: 'environmentConfig', key: 'environment' },
            { source: 'architecturalKnowledge', key: 'knowledge', transform: 'extract' },
            { source: 'analysisContext', key: 'analysisContext' },
          ],
          template: 'ecosystem_analysis_report',
          format: 'markdown',
        },
        output_schema: {
          type: 'object',
          properties: {
            projectStructure: {
              type: 'object',
              description: 'Summary of project files and structure',
            },
            environment: {
              type: 'object',
              description: 'Environment configuration analysis',
            },
            knowledge: {
              type: 'object',
              description: 'Architectural knowledge context',
            },
            analysisContext: {
              type: 'object',
              description: 'Combined analysis context',
            },
          },
        },
        metadata: {
          estimated_tokens: 4000, // Down from ~12K
          complexity: 'high',
          cacheable: true,
          cache_key: `ecosystem-${projectPath}-${analysisDepth}`,
        },
      };
    }
  • TypeScript interface defining the input arguments/schema for the analyze_project_ecosystem tool.
    export interface CEMCPAnalyzeProjectEcosystemArgs {
      projectPath: string;
      analysisDepth?: 'basic' | 'standard' | 'comprehensive';
      includeEnvironment?: boolean;
      knowledgeEnhancement?: boolean;
      learningEnabled?: boolean;
      technologyFocus?: string[];
      analysisScope?: string[];
    }
  • Tool registration in the central TOOL_CATALOG with metadata, description, input schema, and CE-MCP flag.
    TOOL_CATALOG.set('analyze_project_ecosystem', {
      name: 'analyze_project_ecosystem',
      shortDescription: 'Comprehensive project analysis with architectural insights',
      fullDescription:
        'Analyzes the entire project ecosystem including structure, dependencies, architecture patterns, and provides actionable recommendations. Supports knowledge enhancement and reflexion learning.',
      category: 'analysis',
      complexity: 'complex',
      tokenCost: { min: 8000, max: 15000 },
      hasCEMCPDirective: true,
      relatedTools: ['get_architectural_context', 'analyze_environment', 'smart_score'],
      keywords: ['project', 'analysis', 'architecture', 'ecosystem', 'comprehensive'],
      requiresAI: true,
      inputSchema: {
        type: 'object',
        properties: {
          projectPath: { type: 'string', description: 'Path to the project to analyze' },
          analysisDepth: {
            type: 'string',
            enum: ['basic', 'standard', 'comprehensive'],
            default: 'comprehensive',
          },
          includeEnvironment: { type: 'boolean', default: true },
          knowledgeEnhancement: { type: 'boolean', default: true },
          learningEnabled: { type: 'boolean', default: true },
          technologyFocus: { type: 'array', items: { type: 'string' } },
          analysisScope: { type: 'array', items: { type: 'string' } },
        },
        required: ['projectPath'],
      },
    });
  • Tool dispatch/registration in getCEMCPDirective switch statement that routes calls to the handler function.
    case 'analyze_project_ecosystem':
      return createAnalyzeProjectEcosystemDirective(
        args as unknown as CEMCPAnalyzeProjectEcosystemArgs
      );
  • Listed as CE-MCP enabled tool in shouldUseCEMCPDirective helper function that determines directive mode.
      'analyze_project_ecosystem',
      'suggest_adrs',
      'generate_rules',
      'analyze_environment',
      'deployment_readiness',
      // Phase 4.2 tools
      'smart_score',
      'perform_research',
      'generate_adrs_from_prd',
      'interactive_adr_planning',
      'mcp_planning',
      'troubleshoot_guided_workflow',
      // Phase 5: OpenRouter Elimination
      'tool_chain_orchestrator',
    ];
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 'recursive' analysis and 'advanced prompting techniques', it doesn't clarify what the analysis actually produces (output format), whether it's read-only or has side effects, performance characteristics, or authentication requirements. For a complex 11-parameter tool with no annotations, this is a significant gap in behavioral transparency.

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 captures the core functionality. While it could be more front-loaded with practical usage context, it wastes no words and gets straight to the point about what the tool does at a high level.

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 tool with 11 parameters, nested objects, no annotations, and no output schema, the description is inadequate. It doesn't explain what the analysis produces, how results are structured, whether there are side effects, or practical usage scenarios. The description fails to compensate for the lack of structured metadata about this sophisticated analysis tool.

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 100%, so the schema already documents all 11 parameters thoroughly. The description mentions 'advanced prompting techniques (Knowledge Generation + Reflexion)' which loosely relates to 'enhancedMode', 'knowledgeEnhancement', and 'learningEnabled' parameters, but doesn't add meaningful semantic context beyond what's already in the parameter descriptions. Baseline 3 is appropriate when schema does the heavy lifting.

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

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool performs 'Comprehensive recursive project ecosystem analysis' with 'advanced prompting techniques', which clarifies the verb (analyze) and resource (project ecosystem). However, it doesn't differentiate from sibling tools like 'analyze_environment' or 'analyze_content_security' - it's unclear what makes 'ecosystem' analysis distinct from other analysis tools in the server.

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 many sibling analysis tools (analyze_environment, analyze_content_security, analyze_deployment_progress, etc.), there's no indication of when 'project ecosystem analysis' is appropriate versus other specialized analyses. No exclusions, prerequisites, or alternatives are mentioned.

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/tosin2013/mcp-adr-analysis-server'

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