07 - Productivity Servers: Code Review and Scaffolding

Introduction: MCP Servers for Developer Productivity

In the Productivity category of the Tech-MCP project, we find three MCP servers designed to automate repetitive tasks that every developer faces daily: code review, dependency management, and new project creation. These servers operate as pure functions, with no internal state or database, making them lightweight, predictable, and easy to integrate into any workflow.

The problem they solve is concrete: manual code reviews are slow and subjective, dependency vulnerabilities often go unnoticed, and the initial configuration of a new project requires time and attention to avoid mistakes. By automating mechanical checks, these servers allow developers to focus on business logic and architectural decisions.

Server 1: code-review

The code-review server provides static analysis tools oriented toward the code review process. It automates mechanical checks that a human reviewer would tend to overlook: forgotten debug statements, hardcoded credentials, overly complex functions, and problematic patterns. Each detected issue is classified with a severity level (error, warning, or info), allowing developers to prioritize fixes.

Stateless Architecture

The server has no store or internal services. Each tool operates as a pure function that receives an input and produces a JSON result. There is no database, no cache, no shared state between calls. This architectural choice guarantees idempotency: the same request always produces the same result.

            MCP Request
                 |
                 v
      +---------------------+
      |   Tool Dispatcher   |
      +---------------------+
       /        |         \
      v         v          v
analyze-   check-     suggest-
diff       complexity  improvements
  |            |           |
  v            v           v
parseDiff  calculate   checkMagicNumbers
detectIss  Complexity  checkLongFunctions
ues                    checkDeepNesting
                       checkDuplicatePatterns
                       checkUnusedVariables
    

Tool Table

Tool: analyze-diff

The analyze-diff tool receives a string in git diff format and analyzes it line by line, searching for problematic patterns. The internal flow follows these steps:

1. The diff string is split into lines
2. Modified file names are extracted from +++ headers
3. Hunk headers are parsed to track line numbers
4. Each added line (+) is tested against issue patterns
5. Consecutive blocks of over 50 added lines are flagged

Example request and response for analyzing a diff containing issues:

// Request
{
  "tool": "analyze-diff",
  "arguments": {
    "diff": "--- a/src/app.ts\n+++ b/src/app.ts\n@@ -10,3 +10,5 @@\n+console.log('debug');\n+const password = 'secret123';\n+debugger;"
  }
}

// Response
{
  "stats": { "filesChanged": 1, "linesAdded": 3, "linesRemoved": 0 },
  "totalIssues": 3,
  "issuesBySeverity": { "error": 2, "warning": 1, "info": 0 },
  "issues": [
    { "type": "console-statement", "severity": "warning", "line": 10 },
    { "type": "hardcoded-credential", "severity": "error", "line": 11 },
    { "type": "debugger-statement", "severity": "error", "line": 12 }
  ]
}
    

Tool: check-complexity

The check-complexity tool calculates the cyclomatic complexity of a code snippet by counting decision points. Complexity starts at 1 (the main path) and increments for each branching construct found.

The code is first cleaned of comments and strings to avoid false positives, then standard decision patterns are counted: if, else if, for, while, case, catch, &&, ||, ?:.

The calculated complexity is automatically classified into four levels:

• <= 5: Low - simple and readable code
• <= 10: Moderate - manageable complexity
• <= 20: High - candidate for refactoring
• > 20: Very high - requires urgent decomposition

// Request
{
  "tool": "check-complexity",
  "arguments": {
    "code": "function process(data) {\n  if (data.valid) {\n    for (const item of data.items) {\n      if (item.active && item.count > 0) {\n        switch(item.type) {\n          case 'A': break;\n          case 'B': break;\n        }\n      }\n    }\n  }\n}",
    "language": "javascript"
  }
}

// Response
{
  "totalComplexity": 7,
  "rating": "moderate - manageable complexity",
  "breakdown": [
    { "pattern": "if", "count": 2, "description": "If statements" },
    { "pattern": "for", "count": 1, "description": "For loops" },
    { "pattern": "case", "count": 2, "description": "Switch case branches" },
    { "pattern": "&&", "count": 1, "description": "Logical AND operators" }
  ],
  "lineCount": 12,
  "language": "javascript"
}
    

Tool: suggest-improvements

The suggest-improvements tool runs five independent checks on the source code, looking for patterns that indicate potential quality and maintainability issues:

1. Magic numbers: numbers with 2+ digits not declared as constants (excluding common values like 0, 1, 2, 10, 100, 1000, 24, 60, 1024)
2. Long functions: functions with more than 30 lines, detected by counting curly braces
3. Deep nesting: more than 4 levels of curly brace nesting (deduplicated every 5 lines)
4. Duplicate code: identical lines (more than 10 characters) appearing 3 or more times
5. Unused variables: variables declared but referenced only once in the code

Suggestions are sorted by severity: high > medium > low.

// Request
{
  "tool": "suggest-improvements",
  "arguments": {
    "code": "function calc(x) {\n  const result = x * 3.14159;\n  const temp = 42;\n  return result * 86400;\n}",
    "language": "typescript"
  }
}

// Response
{
  "totalSuggestions": 2,
  "suggestionsBySeverity": { "high": 0, "medium": 2, "low": 0 },
  "suggestions": [
    { "type": "magic-number", "severity": "medium", "message": "Magic number 3.14159 found" },
    { "type": "magic-number", "severity": "medium", "message": "Magic number 86400 found" }
  ]
}
    

Tool Registration in the Server

The code-review server tools are registered following the standard Tech-MCP pattern. Each tool declares its input schema with Zod and implements a handler that returns the result as JSON text content:

server.setRequestHandler(ListToolsRequestSchema, async () => ({
  tools: [
    {
      name: 'analyze-diff',
      description: 'Analyze a git diff string for common issues in added code',
      inputSchema: {
        type: 'object',
        properties: {
          diff: { type: 'string', description: 'The git diff string to analyze' }
        },
        required: ['diff']
      }
    },
    {
      name: 'check-complexity',
      description: 'Calculate cyclomatic complexity of a code snippet',
      inputSchema: {
        type: 'object',
        properties: {
          code: { type: 'string', description: 'The code snippet' },
          language: { type: 'string', description: 'Programming language' }
        },
        required: ['code', 'language']
      }
    },
    {
      name: 'suggest-improvements',
      description: 'Suggest improvements for magic numbers, long functions, deep nesting',
      inputSchema: {
        type: 'object',
        properties: {
          code: { type: 'string', description: 'The code snippet' },
          language: { type: 'string', description: 'Programming language' }
        },
        required: ['code', 'language']
      }
    }
  ]
}));
    

Events Published by code-review

The server publishes two events on the EventBus, consumable by other servers in the Tech-MCP suite:

The server does not subscribe to any events: it is purely reactive to tool calls. The standup-notes and agile-metrics servers can consume these events to aggregate code quality metrics and generate automatic reports.

Server 2: dependency-manager

The dependency-manager server is dedicated to managing and analyzing dependencies of a Node.js project. It addresses three critical problems in modern software development: security vulnerabilities in dependencies, packages declared but never imported, and copyleft license incompatibilities that may impose restrictions on software distribution.

Architecture and System Dependencies

Unlike code-review which operates entirely through regex, the dependency-manager server interacts with the filesystem and child processes. It remains stateless nonetheless: no data is retained between calls.

  projectPath
      |
      +-- package.json  <--- read by all 3 tools
      |
      +-- node_modules/ <--- read by license-audit
      |     +-- pkg-a/
      |     |     +-- package.json ("license" field)
      |     +-- pkg-b/
      |           +-- package.json
      |
      +-- src/           <--- scanned by find-unused
            +-- index.ts
            +-- app.ts
            +-- utils/
    

Tool Table

Tool: check-vulnerabilities

The check-vulnerabilities tool is a structured wrapper around npm audit --json. The operational flow includes:

1. Verify the existence of package.json in the specified path
2. Execute npm audit --json with a 60-second timeout
3. Handle non-zero exit codes (npm audit exits with an error if it finds vulnerabilities)
4. Parse the JSON output in npm v7+ format
5. Group by severity: critical, high, moderate, low, info
6. Publish a code:dependency-alert event for each critical or high vulnerability

// Request
{
  "tool": "check-vulnerabilities",
  "arguments": {
    "projectPath": "/home/user/my-project"
  }
}

// Response
{
  "project": "my-project",
  "totalVulnerabilities": 5,
  "severityCounts": {
    "high": 2,
    "moderate": 2,
    "low": 1
  },
  "vulnerabilities": {
    "high": [
      {
        "name": "lodash",
        "severity": "high",
        "title": "Prototype Pollution",
        "url": "https://github.com/advisories/GHSA-xxxx",
        "range": "<4.17.21",
        "fixAvailable": { "name": "lodash", "version": "4.17.21" }
      }
    ]
  },
  "metadata": {
    "totalDependencies": 142,
    "devDependencies": 38,
    "prodDependencies": 104
  }
}
    

Tool: find-unused

The find-unused tool performs a recursive scan of source files to identify dependencies declared in package.json but never actually imported in the code. The analysis covers:

• ES module imports: import ... from 'package'
• CommonJS: require('package')
• Dynamic imports: import('package')
• Scoped packages: correct handling of @scope/package

The directories node_modules, dist, build, .git, and coverage are automatically excluded from scanning. Analyzed files include the extensions .ts, .js, .tsx, and .jsx.

// Request
{
  "tool": "find-unused",
  "arguments": {
    "projectPath": "/home/user/my-project"
  }
}

// Response
{
  "project": "my-project",
  "sourceFilesScanned": 47,
  "summary": {
    "totalDependencies": 12,
    "totalDevDependencies": 8,
    "unusedDependencies": 2,
    "unusedDevDependencies": 1
  },
  "unusedDependencies": ["moment", "lodash"],
  "unusedDevDependencies": ["@types/lodash"],
  "note": "Dependencies may be used in config files, scripts, or other non-source files."
}
    

Tool: license-audit

The license-audit tool examines the licenses of every dependency by directly reading the package.json files inside node_modules. This check is particularly relevant for commercial projects, where using copyleft licenses could impose unwanted restrictions.

// Request
{
  "tool": "license-audit",
  "arguments": {
    "projectPath": "/home/user/my-project"
  }
}

// Response
{
  "project": "my-project",
  "summary": {
    "totalDependenciesChecked": 20,
    "uniqueLicenses": 4,
    "copyleftCount": 1,
    "notFoundInNodeModules": 0
  },
  "copyleftWarnings": [
    { "name": "some-gpl-lib", "version": "2.1.0", "license": "GPL-3.0" }
  ],
  "byLicense": {
    "MIT": [{ "name": "express", "version": "4.21.0" }],
    "ISC": [{ "name": "glob", "version": "10.3.0" }],
    "GPL-3.0": [{ "name": "some-gpl-lib", "version": "2.1.0" }]
  }
}
    

Events Published by dependency-manager

Like code-review, this server does not subscribe to any events. The standup-notes and agile-metrics servers can receive alerts to track vulnerability trends over time.

Server 3: project-scaffolding

The project-scaffolding server automates the creation of new projects and components from predefined templates. Every new project normally requires manually creating package.json, tsconfig.json, folder structures, and boilerplate files: a repetitive and error-prone process that this server completely eliminates.

Available Templates

The server offers four built-in templates covering the most common use cases in modern TypeScript development:

Tool Table

Tool: scaffold-project

The scaffold-project tool generates an entire project from a selected template. The core mechanism is placeholder substitution: each template file contains placeholders like {{projectName}}, {{author}}, {{description}}, and {{license}} that are replaced with the provided values.

  1. Template validation
         |
         v
  2. Prepare placeholder values
     { projectName, author, description, license }
         |
         v
  3. For each file in the template:
     a. Calculate path: outputDir/projectName/relativePath
     b. Create directory (mkdir recursive)
     c. Substitute placeholders in content
     d. Write file to disk
         |
         v
  4. Return list of created files
    

// Request
{
  "tool": "scaffold-project",
  "arguments": {
    "template": "express-api",
    "projectName": "user-service",
    "outputDir": "/home/user/projects",
    "options": {
      "author": "Mario Rossi",
      "description": "User management microservice",
      "license": "MIT"
    }
  }
}

// Response
{
  "template": "express-api",
  "projectName": "user-service",
  "outputDir": "/home/user/projects/user-service",
  "filesCreated": [
    "package.json", "tsconfig.json", "src/index.ts", "src/app.ts",
    "src/routes/health.ts", "src/middleware/error-handler.ts",
    ".gitignore", "README.md"
  ],
  "totalFiles": 8
}
    

Tool: scaffold-component

The scaffold-component tool generates individual files for components, services, controllers, or models. It supports both TypeScript and JavaScript and produces code with a standard structure ready for use:

// Request
{
  "tool": "scaffold-component",
  "arguments": {
    "type": "service",
    "name": "User",
    "outputDir": "/home/user/projects/user-service/src/services",
    "language": "typescript"
  }
}

// Response
{
  "message": "Generated service file: /home/user/projects/user-service/src/services/User.service.ts",
  "filePath": "/home/user/projects/user-service/src/services/User.service.ts"
}
    

Event Bus Integration

The project-scaffolding server neither publishes nor subscribes to events. It is a purely generative server that operates on explicit user request. However, generated projects can be immediately analyzed by the other productivity servers:

• dependency-manager: to verify vulnerabilities and licenses of the newly generated project's dependencies
• code-review: to analyze the quality of code generated from templates
• codebase-knowledge: to map the new project's structure with architecture-map

Interactions Between Productivity Servers

The three productivity servers collaborate in a complementary way. While independent, the output of one can feed the inputs of others, creating an automated workflow:

+----------------------+                          +---------------------+
| project-scaffolding  |  generates project  ---> | dependency-manager  |
|                      |  for analysis            |  (check-vulnerab.)  |
+----------------------+                          +---------------------+
         |
         |  generates code     --->  +---------------------+
         +-------------------------> | code-review         |
                                     | (analyze/suggest)   |
                                     +---------------------+

+------------------+     code:commit-analyzed       +-------------------+
|   code-review    | -----------------------------> |   standup-notes   |
|                  |     code:review-completed       |   agile-metrics   |
+------------------+ -----------------------------> +-------------------+

+---------------------+    code:dependency-alert    +-------------------+
| dependency-manager  | --------------------------> | standup-notes     |
|                     |                             | agile-metrics     |
+---------------------+                             +-------------------+
    

Common Pattern: Stateless Servers and Pure Analysis

All three productivity servers share a fundamental architectural pattern: they are completely stateless. They use no database, maintain no cache, and have no internal services with persistent state. Every tool call is independent and self-contained.

This approach offers several advantages:

• Idempotency: the same request always produces the same result, facilitating testing and debugging
• Scalability: no shared state bottleneck, servers can be instantiated in parallel
• Simplicity: no database migrations, no session management, no cleanup needed
• Reliability: a crash causes no data loss because there is no state to preserve

The code-review server operates entirely through regex and pattern counting. The dependency-manager server reads from the filesystem and invokes npm audit as an external process. The project-scaffolding server writes files to disk from in-memory templates. None of the three requires additional infrastructure configuration.

Conclusions

The three Tech-MCP productivity servers demonstrate how MCP can automate repetitive tasks in software development without requiring complex infrastructure. The code-review server automatically detects common issues in code reviews, dependency-manager keeps vulnerabilities and licenses under control, and project-scaffolding eliminates boilerplate when creating new projects.

The stateless pattern adopted by all three servers makes them particularly well-suited for integration into CI/CD pipelines and automated workflows, where predictability and the absence of side effects are fundamental requirements.

In the next article, we will explore the DevOps servers in the Tech-MCP suite: docker-compose for container management, log-analyzer for application log analysis, and cicd-monitor for monitoring build and deploy pipelines. We will see how these servers integrate with the productivity servers through the EventBus to create a fully automated development workflow.

The complete source code for all three servers is available in the Tech-MCP GitHub repository.