14 - Tech-MCP: Complete Open Source Project Overview

Introduction: The Complete Journey

This is the final article in the series dedicated to the Model Context Protocol (MCP). Across 14 articles, we have traveled a complete path: from the theoretical foundations of the protocol to implementing a production-ready ecosystem with 31 MCP servers, 85+ tools, 6 shared packages, and a professional testing system.

In this article, we present a complete overview of the open source project Tech-MCP: the catalog of all servers organized by category, the technology stack, the overall architecture, lessons learned during development, and how to contribute to the project.

Tech-MCP by the Numbers

The Tech-MCP project is the result of a design and development process that produced a complete MCP ecosystem, covering the entire software development lifecycle. Here are the key numbers:

Overall Architecture

Tech-MCP is organized as a monorepo managed with pnpm workspaces and Turborepo. Shared packages provide cross-cutting functionality, while the 31 servers implement domain-specific business logic:

Tech-MCP/
├── packages/                    # 6 Shared Packages
│   ├── core/                    # Factory, shared types, startHttpServer()
│   ├── event-bus/               # EventBus interface + LocalEventBus + 29 events
│   ├── client-manager/          # McpClientManager for cross-server
│   ├── database/                # BaseStore SQLite, migrations
│   ├── testing/                 # TestHarness, MockEventBus, InMemoryTransport
│   └── cli/                     # CLI utility for server management
│
├── servers/                     # 31 MCP Servers
│   ├── scrum-board/             # Project Management
│   ├── agile-metrics/           # Project Management
│   ├── time-tracking/           # Project Management
│   ├── project-economics/       # Project Management
│   ├── retrospective-manager/   # Project Management
│   ├── code-review/             # Productivity
│   ├── dependency-manager/      # Productivity
│   ├── project-scaffolding/     # Productivity
│   ├── docker-compose/          # DevOps
│   ├── log-analyzer/            # DevOps
│   ├── cicd-monitor/            # DevOps
│   ├── db-schema-explorer/      # Database
│   ├── data-mock-generator/     # Database
│   ├── test-generator/          # Testing
│   ├── performance-profiler/    # Testing
│   ├── api-documentation/       # Documentation
│   ├── codebase-knowledge/      # Documentation
│   ├── regex-builder/           # Utility
│   ├── http-client/             # Utility
│   ├── snippet-manager/         # Utility
│   ├── standup-notes/           # Communication
│   ├── environment-manager/     # Communication
│   ├── incident-manager/        # Advanced
│   ├── decision-log/            # Advanced
│   ├── access-policy/           # Advanced
│   ├── quality-gate/            # Advanced
│   ├── workflow-orchestrator/   # Advanced
│   ├── insight-engine/          # Advanced
│   ├── mcp-registry/            # Advanced
│   ├── dashboard-api/           # Advanced
│   └── tech-radar/              # Advanced
│
├── docs/                        # Complete documentation
├── turbo.json                   # Turborepo configuration
├── pnpm-workspace.yaml          # Workspace definition
└── package.json                 # Root package
    

Complete Server Catalog

The 31 MCP servers are organized into 9 functional categories covering every aspect of the software development lifecycle. Each server is independent but can collaborate with others via EventBus and ClientManager.

Project Management (5 servers)

Productivity (3 servers)

DevOps (3 servers)

Database (2 servers)

Testing (2 servers)

Documentation (2 servers)

Utility (3 servers)

Communication (2 servers)

Advanced (9 servers)

Technology Stack

Tech-MCP's technology stack was chosen to maximize type-safety, development speed, and long-term maintainability:

The 6 Shared Packages

The shared packages provide the foundation upon which all 31 servers are built. Each package is published internally within the monorepo and consumed by servers via workspace:*:

Key Architectural Patterns

During the development of 31 MCP servers, recurring architectural patterns emerged that ensure consistency, testability, and maintainability:

1. Server Factory Pattern

Every server exposes a factory function with optional parameters for maximum flexibility:

export function createMyServer(options?: {
  eventBus?: EventBus;
  clientManager?: McpClientManager;
  storeOptions?: { inMemory?: boolean; dbPath?: string };
}) {
  const server = new McpServer({
    name: "my-server",
    version: "1.0.0",
  });

  const store = new MyStore(options?.storeOptions);

  // Register tools with optional dependencies
  registerAddItem(server, store, options?.eventBus);
  registerGetStats(server, store, options?.clientManager);

  // Collaboration: activated only if an event bus is present
  if (options?.eventBus) {
    setupCollaborationHandlers(options.eventBus, store);
  }

  return { server, store };
}
    

2. One File Per Tool

Each tool is isolated in its own file, registered as a pure function that receives its dependencies:

// tools/add-item.ts
export function registerAddItem(
  server: McpServer,
  store: MyStore,
  eventBus?: EventBus,
): void {
  server.tool(
    "add-item",
    "Add a new item to the store",
    { title: z.string(), content: z.string() },
    async ({ title, content }) => {
      try {
        const item = store.addItem({ title, content });
        eventBus?.publish("items:created", { id: item.id, title });
        return {
          content: [{ type: "text", text: JSON.stringify(item, null, 2) }],
        };
      } catch (error) {
        return {
          content: [{
            type: "text",
            text: `Error: ${error instanceof Error ? error.message : String(error)}`,
          }],
          isError: true,
        };
      }
    },
  );
}
    

3. Fire-and-Forget Collaboration

Events are published using the fire-and-forget pattern: the server publishes the event and continues without waiting for a response. This completely decouples the servers:

// The server publishes without waiting
eventBus?.publish("scrum:sprint-started", {
  sprintId: sprint.id,
  name: sprint.name,
});

// Another server reacts in its own collaboration.ts
eventBus.subscribe("scrum:sprint-started", (payload) => {
  store.autoCreateBudget(payload.sprintId, payload.name);
});
    

How to Contribute

Tech-MCP is an open source project and contributions are welcome. The contribution process follows a standard workflow:

Prerequisites

• Node.js >= 20.0.0
• pnpm >= 9.0.0
• Basic knowledge of TypeScript and the Model Context Protocol

Development Environment Setup

# 1. Fork and clone the repository
git clone https://github.com/<your-username>/Tech-MCP.git
cd Tech-MCP

# 2. Install dependencies
pnpm install

# 3. Full build of all packages and servers
pnpm build

# 4. Verify everything compiles correctly
pnpm typecheck
    

Types of Contributions

1. Adding a new MCP server: create a new server in the servers/ directory following the standardized structure (package.json, tsconfig.json, src/index.ts, src/server.ts, src/tools/, src/services/)
2. Adding a tool to an existing server: create the file in servers/<name>/src/tools/ following the registration pattern with optional dependencies
3. Adding an event: define the event in packages/event-bus/src/events.ts, publish in the appropriate tool, and subscribe in the collaboration handler
4. Implementing collaboration handlers: many collaboration.ts files contain placeholder handlers with void payload. Implementing the real logic is a valuable contribution
5. Writing tests: store unit tests, tool integration tests, cross-server wiring tests

Code Conventions

Review Process

1. Fork the repository on GitHub
2. Create a branch from main
3. Implement following the project conventions
4. Build and typecheck: pnpm build && pnpm typecheck
5. Commit with clear, descriptive messages
6. Open a Pull Request to main
7. Respond to review feedback

Areas Where Help Is Needed

The project has several areas where contributions are particularly welcome:

Roadmap and Future Developments

Tech-MCP is an evolving project. Planned development areas are organized by priority:

Priority 1: Redis EventBus

Currently the EventBus works only with LocalEventBus (in-process). For real-world deployments where each server is a separate process, an external message broker is needed. The Redis implementation will enable inter-process communication between MCP servers distributed across different machines.

Priority 2: MCP Resources and Prompts

Currently Tech-MCP exclusively uses the Tools primitive. The MCP specification also defines Resources (read-only data with URIs) and Prompts (templates for structured workflows). Adding these primitives would significantly enrich server capabilities.

Priority 3: Web Dashboard

A web dashboard for real-time visualization of all server statuses, published events, tool usage metrics, and health checks.

Priority 4: Plugin System

An architecture for third-party plugins with a registry, tool hot-reload, and a shared marketplace.

Lessons Learned

Building 31 MCP servers in a monorepo taught valuable lessons that apply to any medium-to-large scale software project:

1. Standardization Pays Off

Having a standardized structure for every server (factory function, one file per tool, isolated store, separate collaboration handler) drastically reduced the development time for new servers. After the first 5 servers, creating a new one required very little time because the pattern was well-established.

2. Shared Packages Are Essential

Extracting common logic into shared packages (core, event-bus, database, testing) eliminated code duplication and ensured consistency across all servers. Every change to a shared package automatically propagates to all servers that use it.

3. Tool Descriptions Are Critical

The AI chooses which tool to call based solely on its description. Vague descriptions produce underutilized tools; precise descriptions produce a smooth experience. Investing time in writing descriptions is a high-return investment.

4. Fire-and-Forget Simplifies Everything

The fire-and-forget pattern for events enormously simplified the architecture. Servers publish events without knowing who receives them, and collaboration handlers react without direct coupling. This made it possible to add new collaborations without modifying existing servers.

5. In-Memory Tests Are Key

The ability to instantiate every server with an in-memory database made tests fast, isolated, and reproducible. The investment in createTestHarness() and MockEventBus paid enormous dividends in development speed.

Series Summary

This 14-article series covered the entire journey from the MCP protocol to production. Here is a summary of the topics covered:

Conclusions

The Model Context Protocol represents a paradigm shift in the interaction between developers and artificial intelligence. It is not simply a wrapper around API calls, but a structured protocol that enables automatic discovery, strong typing, bidirectional communication, native composability, and inter-server collaboration.

With Tech-MCP, we have demonstrated that it is possible to build a complete ecosystem of 31 MCP servers, covering the entire software development lifecycle: from code management to project management, from testing to deployment, from monitoring to cross-project analysis.

The project is open source and continuously evolving. Every contribution, whether it is a new server, a test, a fix, or a new feature, is welcome. The future of human-AI interaction passes through open and composable protocols like MCP, and Tech-MCP aims to be a reference point for anyone wanting to explore this territory.

Thank you for following this series. The complete code, documentation, and contribution instructions are available on GitHub.