Personal MCP Servers Monorepo

This repository hosts four independently runnable MCP servers, each focused on a narrow integration domain. The goal is to keep every server small, composable, and easy to evolve without coupling runtime state across domains.

Server matrix

| Server | Domain | Default Port | Primary Data Source | | --- | --- | ---: | --- | | github-lineage-server | SQL lineage discovery | 8101 | GitHub REST API + repository SQL files | | jira-server | Issue search/inspection | 8102 | Jira REST API | | python-etl-server | In-memory ETL pipelines | 8103 | CSV/JSON files + pandas | | tmc-talend-server | Talend runtime visibility | 8104 | Talend API / TMC endpoints |

Monorepo layout

.
├── github-lineage-server/
│   ├── app/server.py
│   ├── .env.example
│   ├── requirements.txt
│   ├── README.md
│   └── ARCHITECTURE.md
├── jira-server/
├── python-etl-server/
├── tmc-talend-server/
├── README.md
└── ARCHITECTURE.md

Runtime model

• Each folder starts its own FastMCP instance and exposes tools over streamable-http.
• Each server has its own environment configuration boundary (.env file local to that folder).
• No shared persistence layer is required; this keeps local setup friction low.
• Servers are intentionally stateless except python-etl-server, which keeps process-local DataFrame state.

Prerequisites

• Python 3.10+
• Network access to the corresponding external APIs where relevant
• Valid access tokens/credentials in each server's .env

Quick start

Run servers independently (recommended for development and debugging):

cd github-lineage-server
pip install -r requirements.txt
python app/server.py

cd jira-server
pip install -r requirements.txt
python app/server.py

cd python-etl-server
pip install -r requirements.txt
python app/server.py

cd tmc-talend-server
pip install -r requirements.txt
python app/server.py

Configuration strategy

• Keep .env.example as the source of truth for required keys.
• Copy .env.example to .env per folder.
• Never commit real secrets.
• Use least-privilege tokens (read-only where possible).

API and tool design principles

• Small tool surface: each server exports a focused set of MCP tools.
• Structured output: every tool returns JSON-serializable dictionaries/lists.
• Bounded pagination/limits: user-facing limit/max_results arguments are clamped.
• Graceful failure: API/network errors are surfaced in a debuggable payload.

Validation checklist

• Start each server and call its health tool:
  • GitHub: github_health
  • Jira: jira_health
  • Talend: tmc_health
• For ETL, run an end-to-end smoke flow: extract_* → transform → load_to_csv.
• Confirm ports 8101–8104 are reachable from your MCP client.

Extension roadmap

• Add auth abstraction modules per server for token rotation.
• Introduce per-server structured logging and request IDs.
• Add contract tests for tool payload schema stability.
• Add optional containerization for single-command startup.

Notes

• Keep each server independently deployable and versionable.
• Prefer backward-compatible tool argument changes to avoid client breakage.