Panoramica: Cinque Server MCP per il Project Management Agile
Il project management agile e uno dei domini più complessi nello sviluppo software: richiede il coordinamento di sprint, task, metriche di performance, tracciamento del tempo, budget e retrospettive. Nella suite Tech-MCP, questi aspetti sono gestiti da cinque server MCP specializzati che collaborano attraverso l'EventBus, formando un ecosistema integrato di project management.
In questo articolo analizzeremo nel dettaglio ciascun server, i suoi tool con gli schema Zod, gli eventi pubblicati e sottoscritti, e il flusso di collaborazione che li unisce in un sistema coeso.
I Cinque Server PM della MCP Suite
| Server | Ruolo | Tool | Storage |
|---|---|---|---|
| scrum-board | Hub centrale Scrum | 7 | SQLite (3 tabelle) |
| agile-metrics | Analisi e previsioni | 4 | Stateless |
| time-tracking | Tracciamento tempo | 4 | SQLite (2 tabelle) |
| project-economics | Budget e costi | 4 | SQLite (2 tabelle) |
| retrospective-manager | Retrospettive agili | 5 | SQLite (3 tabelle) |
1. Scrum Board Server: l'Hub Centrale
Il server scrum-board e il cuore operativo dell'intera MCP Suite per il project management. Gestisce sprint, user story e task secondo la metodologia Scrum, fungendo da hub attraverso il quale transitano la maggior parte dei flussi di lavoro collaborativi. Praticamente ogni altro server PM interagisce con scrum-board, direttamente o tramite gli eventi che pubblica.
+---------------------------+
| SCRUM-BOARD SERVER |
| HUB CENTRALE |
+---------------------------+
/ | | | \
/ | | | \
v v v v v
+-------+ +-------+ +------+ +-------+ +-------+
|agile | |time | |retro | |standup| |project|
|metrics| |track. | |mgr | |notes | |econ. |
+-------+ +-------+ +------+ +-------+ +-------+
Tool del Server scrum-board
Lo scrum-board espone 7 tool che coprono l'intero ciclo di vita Scrum:
Tabella Tool: scrum-board
| Tool | Descrizione | Parametri Principali |
|---|---|---|
create-sprint |
Crea un nuovo sprint | name (string), startDate (string), endDate (string), goals (string[]) |
get-sprint |
Recupera i dettagli di uno sprint | sprintId (number) |
create-story |
Crea una nuova user story | title, description, acceptanceCriteria (string[]), storyPoints (number), priority, sprintId (opz.) |
create-task |
Crea un task per una story | title, description, storyId (number), assignee (opz.) |
update-task-status |
Aggiorna lo stato di un task | taskId (number), status (enum: todo | in_progress | in_review | done | blocked) |
sprint-board |
Vista Kanban dello sprint | sprintId (number, opzionale; default: sprint attivo) |
get-backlog |
Story non assegnate a sprint | Nessuno |
Schema Zod: create-sprint
Ogni tool definisce i propri parametri tramite schema Zod per la validazione automatica degli input:
// Tool: create-sprint
const CreateSprintSchema = z.object({
name: z.string().describe("Nome dello sprint"),
startDate: z.string().describe("Data inizio ISO (YYYY-MM-DD)"),
endDate: z.string().describe("Data fine ISO (YYYY-MM-DD)"),
goals: z.array(z.string()).describe("Obiettivi dello sprint")
});
Schema Zod: update-task-status
// Tool: update-task-status
const UpdateTaskStatusSchema = z.object({
taskId: z.number().describe("ID del task da aggiornare"),
status: z.enum(["todo", "in_progress", "in_review", "done", "blocked"])
.describe("Nuovo stato del task nel flusso Kanban")
});
Flusso Kanban dei Task
Ogni cambio di stato di un task segue il flusso Kanban standard. Da qualsiasi stato e possibile
transizionare verso blocked:
+-------+ +-------------+ +-----------+ +------+
| todo | --> | in_progress | --> | in_review | --> | done |
+-------+ +-------------+ +-----------+ +------+
| | |
+-------+-------+-------------------+
|
v
+--------+
| blocked|
+--------+
Database ScrumStore: tre tabelle SQLite
Lo ScrumStore gestisce tre tabelle interconnesse tramite foreign key:
+------------------+ +-------------------+ +------------------+
| sprints | | stories | | tasks |
+------------------+ +-------------------+ +------------------+
| id (PK) |<------| sprintId (FK) | | id (PK) |
| name | | id (PK) |<------| storyId (FK, NN) |
| startDate | | title | | sprintId (FK) |
| endDate | | description | | title |
| goals (JSON) | | acceptanceCriteria| | description |
| status | | storyPoints | | status |
| createdAt | | priority | | assignee |
+------------------+ | status | | createdAt |
| createdAt | | updatedAt |
+-------------------+ +------------------+
Sprint Board: Vista Kanban
Il tool sprint-board genera una vista Kanban completa, organizzando i task in colonne.
Se non viene specificato sprintId, recupera automaticamente lo sprint con stato active:
+--------------------------------------------------------------------+
| Sprint Board: Sprint 14 |
+--------------------------------------------------------------------+
| TODO | IN PROGRESS | IN REVIEW | DONE | BLOCKED |
|---------------|---------------|---------------|---------|----------|
| Task: Setup | Task: Login | Task: Test | Task: | Task: |
| OAuth | form UI | OAuth flow | DB | Deploy |
| | | | schema | (needs |
| Task: 2FA | Task: Token | | | infra) |
| research | refresh | | | |
+--------------------------------------------------------------------+
Eventi pubblicati da scrum-board
Lo scrum-board e il principale produttore di eventi della suite PM. Ogni operazione critica genera un evento che attiva reazioni a catena negli altri server:
Eventi del scrum-board
| Evento | Payload | Emesso da |
|---|---|---|
scrum:sprint-started |
{ sprintId, name, startDate, endDate } |
create-sprint |
scrum:task-updated |
{ taskId, status, previousStatus, storyId, sprintId } |
update-task-status |
scrum:sprint-completed |
{ sprintId, name, completedPoints } |
Chiusura sprint |
scrum:story-completed |
{ storyId, storyPoints, sprintId } |
Completamento story |
Eventi sottoscritti da scrum-board
Lo scrum-board e anche uno dei pochi server che riceve eventi da altri server, creando un ciclo di feedback bidirezionale:
Sottoscrizione: retro:action-item-created
Quando il retrospective-manager genera action item dalla retrospettiva, pubblica
retro:action-item-created. Lo scrum-board lo riceve e crea automaticamente
un task nel backlog, chiudendo il ciclo di miglioramento continuo.
Esempio: Workflow completo di uno Sprint
// 1. Creare lo sprint
{ "tool": "create-sprint",
"arguments": {
"name": "Sprint 14 - Autenticazione",
"startDate": "2025-02-03",
"endDate": "2025-02-14",
"goals": ["Implementare login OAuth", "Aggiungere 2FA"]
} }
// 2. Creare una user story
{ "tool": "create-story",
"arguments": {
"title": "Login OAuth Google",
"description": "Come utente voglio autenticarmi con Google",
"acceptanceCriteria": ["Redirect a Google", "Token salvato", "Sessione attiva"],
"storyPoints": 8,
"priority": "high",
"sprintId": 1
} }
// 3. Creare task per la story
{ "tool": "create-task",
"arguments": {
"title": "Configurare OAuth credentials",
"description": "Setup su Google Cloud Console",
"storyId": 1,
"assignee": "mario"
} }
// 4. Aggiornare lo stato del task
{ "tool": "update-task-status",
"arguments": { "taskId": 1, "status": "in_progress" } }
// 5. Visualizzare la board
{ "tool": "sprint-board", "arguments": { "sprintId": 1 } }
2. Agile Metrics Server: Analisi e Previsioni
Il server agile-metrics fornisce strumenti analitici per misurare e prevedere le prestazioni del team. Calcola velocity, genera dati di burndown, analizza cycle time e produce previsioni di completamento basate su simulazioni Monte Carlo.
Una caratteristica fondamentale e che il server e completamente stateless: non possiede database ne store interno. Riceve dati come input (tipicamente provenienti dallo scrum-board) e restituisce calcoli puri.
Tabella Tool: agile-metrics
| Tool | Descrizione | Parametri Principali |
|---|---|---|
calculate-velocity |
Velocity media con analisi trend | sprints (array di { name, completedPoints, totalPoints }) |
generate-burndown |
Dati per grafico burndown | totalPoints, sprintDays, dailyCompleted (number[]) |
calculate-cycle-time |
Statistiche cycle time | tasks (array di { taskId, startDate, endDate }) |
forecast-completion |
Previsione Monte Carlo | remainingPoints, velocityHistory (number[]), sprintLengthDays |
Schema Zod: calculate-velocity
const CalculateVelocitySchema = z.object({
sprints: z.array(z.object({
name: z.string(),
completedPoints: z.number(),
totalPoints: z.number()
})).describe("Lista sprint con punti completati e totali")
});
Schema Zod: forecast-completion
const ForecastCompletionSchema = z.object({
remainingPoints: z.number().describe("Punti rimanenti da completare"),
velocityHistory: z.array(z.number())
.describe("Storico velocity degli ultimi sprint"),
sprintLengthDays: z.number()
.describe("Durata di uno sprint in giorni")
});
Simulazione Monte Carlo
Il tool forecast-completion esegue 1000 simulazioni per prevedere
quando il lavoro rimanente sarà completato, considerando la variabilità storica della velocity:
Algoritmo Monte Carlo:
+-------------------------------------------------------+
| Per ogni simulazione (1..1000): |
| remainingWork = remainingPoints |
| sprints = 0 |
| while remainingWork > 0: |
| velocity = random(velocityHistory) |
| remainingWork -= velocity |
| sprints++ |
| record(sprints * sprintLengthDays) |
+-------------------------------------------------------+
| Ordina risultati |
| p50 = risultato al 50-esimo percentile |
| p85 = risultato all'85-esimo percentile |
| p95 = risultato al 95-esimo percentile |
+-------------------------------------------------------+
L'output fornisce tre livelli di confidenza:
{
"remainingPoints": 50,
"simulations": 1000,
"forecast": {
"p50": { "sprints": 2, "days": 28, "date": "2025-03-14" },
"p85": { "sprints": 3, "days": 42, "date": "2025-03-28" },
"p95": { "sprints": 3, "days": 42, "date": "2025-03-28" }
},
"confidence": "Con l'85% di probabilità, completamento entro 42 giorni"
}
Burndown Chart: Ideale vs Attuale
Il tool generate-burndown confronta la linea ideale con l'avanzamento reale,
indicando per ogni giorno se il progresso e on-track, behind o ahead:
Punti
40 |*
| * .
30 | * .
| * . * <-- attuale (in ritardo)
20 | * .
| * . *
10 | * . *
| * . *
0 |--------*------------------.--*-----> Giorni
1 2 3 4 5 6 7 8 9 10
* = linea ideale . = avanzamento reale
Cycle Time: Statistiche Dettagliate
Il tool calculate-cycle-time analizza i tempi di completamento dei task:
Metriche Cycle Time
| Metrica | Descrizione |
|---|---|
average |
Media aritmetica del cycle time |
median |
Valore mediano (p50) |
p95 |
95-esimo percentile |
min |
Tempo minimo di completamento |
max |
Tempo massimo di completamento |
Eventi sottoscritti da agile-metrics
Agile-metrics e un puro consumatore di dati. Non pubblica eventi, ma sottoscrive quelli dello scrum-board per reagire ai cambiamenti nello sprint in corso:
scrum:sprint-completed→ trigger per ricalcolo velocity e report di fine sprintscrum:task-updated→ aggiornamento dati burndown in tempo realescrum:story-completed→ aggiornamento punti completati per velocity tracking
3. Time Tracking Server: Tracciamento del Tempo
Il server time-tracking gestisce il tracciamento del tempo lavorato sui task, con supporto per timer live e registrazione manuale. Mantiene uno stato persistente tramite SQLite con due tabelle: una per i time entry e una per i timer attivi.
Il server implementa una protezione contro il doppio avvio: non e possibile avere più di un timer attivo contemporaneamente per lo stesso utente.
Tabella Tool: time-tracking
| Tool | Descrizione | Parametri Principali |
|---|---|---|
start-timer |
Avvia timer per un task | taskId (string), description (opz.), userId (opz.) |
stop-timer |
Ferma il timer attivo | userId (opz.) |
log-time |
Registrazione manuale tempo | taskId, durationMinutes (number), description (opz.), date (opz.) |
get-timesheet |
Timesheet filtrato per date | userId (opz.), startDate (opz.), endDate (opz.) |
Schema Zod: start-timer e log-time
const StartTimerSchema = z.object({
taskId: z.string().describe("ID del task da tracciare"),
description: z.string().optional()
.describe("Descrizione dell'attivita"),
userId: z.string().optional()
.describe("ID utente (default: 'default')")
});
const LogTimeSchema = z.object({
taskId: z.string().describe("ID del task"),
durationMinutes: z.number()
.describe("Durata in minuti"),
description: z.string().optional(),
date: z.string().optional()
.describe("Data ISO (YYYY-MM-DD)"),
userId: z.string().optional()
});
Flusso del Timer
Il flusso di start-timer include la protezione contro il doppio avvio.
Il stop-timer calcola automaticamente la durata e crea un time entry:
start-timer(taskId: "TASK-42")
|
v
Verifica: esiste timer attivo per userId?
|
+--[SI]--> Errore: "Timer attivo per TASK-15. Ferma prima quello."
|
+--[NO]--> Crea record in active_timers
startTime = new Date().toISOString()
stop-timer()
|
v
Cerca timer attivo per userId
|
+--[NON TROVATO]--> Errore: "No active timer found"
|
+--[TROVATO]
|
v
endTime = now()
durationMinutes = Math.round((endMs - startMs) / 60000)
|
v
INSERT INTO time_entries --> DELETE FROM active_timers
|
v
Pubblica time:entry-logged
Database TimeStore
Il TimeStore gestisce due tabelle SQLite:
- active_timers: timer attualmente in corso (
id,taskId,userId,startTime,description) - time_entries: registrazioni completate (
id,taskId,userId,startTime,endTime,durationMinutes,description,date)
Eventi del time-tracking
Evento Pubblicato: time:entry-logged
Ogni volta che un timer viene fermato o viene registrato tempo manualmente, il server pubblica
l'evento time:entry-logged con payload:
{
"taskId": "TASK-42",
"userId": "mario",
"durationMinutes": 45,
"date": "2025-02-07"
}
Questo evento viene intercettato da project-economics per convertire il tempo in costo e aggiornare il budget del progetto.
4. Project Economics Server: Budget e Costi
Il server project-economics gestisce il budget e i costi di progetto, fornendo visibilità sulla spesa, breakdown per categoria e previsioni di esaurimento budget. Include un sistema di alert automatico che pubblica un evento quando il budget utilizzato raggiunge o supera l'80%.
Tabella Tool: project-economics
| Tool | Descrizione | Parametri Principali |
|---|---|---|
set-budget |
Definisce il budget di un progetto | projectName, totalBudget (number), currency (default: 'EUR') |
log-cost |
Registra un costo | projectName, category, amount (number), description, taskId (opz.) |
get-budget-status |
Stato completo del budget | projectName |
forecast-budget |
Previsione esaurimento budget | projectName |
Schema Zod: log-cost
const LogCostSchema = z.object({
projectName: z.string().describe("Nome del progetto"),
category: z.string().describe("Categoria di spesa (es. sviluppo, infra, testing)"),
amount: z.number().describe("Importo in valuta del budget"),
description: z.string().describe("Descrizione del costo"),
date: z.string().optional().describe("Data ISO del costo"),
taskId: z.string().optional().describe("ID task associato")
});
Algoritmo di Forecast del Budget
Il tool forecast-budget calcola il burn rate giornaliero e stima
quando il budget si esaurira:
Algoritmo di previsione:
+---------------------------------------------------+
| 1. Trova prima e ultima data di costo |
| 2. daysTracked = (lastDate - firstDate) + 1 |
| 3. dailyBurnRate = totalSpent / daysTracked |
| 4. estimatedDaysRemaining = remaining / burnRate |
| 5. runOutDate = today + daysRemaining |
+---------------------------------------------------+
Budget Status con Breakdown
Il tool get-budget-status restituisce una vista completa del budget con breakdown
per categoria di spesa:
{
"projectName": "MCP Suite v2",
"totalBudget": 50000,
"currency": "EUR",
"totalSpent": 38500,
"remaining": 11500,
"percentageUsed": 77.0,
"breakdown": [
{ "category": "sviluppo", "total": 25000 },
{ "category": "infrastruttura", "total": 8500 },
{ "category": "testing", "total": 3000 },
{ "category": "design", "total": 2000 }
]
}
Eventi del project-economics
Sistema di Alert Automatico
| Evento | Payload | Condizione |
|---|---|---|
economics:cost-updated |
{ projectName, category, amount, totalSpent } |
Sempre (ogni log-cost) |
economics:budget-alert |
{ projectName, percentageUsed, remaining, totalBudget } |
Quando percentageUsed >= 80% |
Flusso degli Alert di Budget
log-cost("MCP Suite v2", "sviluppo", 5000, ...)
|
v
Calcola percentageUsed = totalSpent / totalBudget * 100
|
v
percentageUsed = 82% --> >= 80%?
|
+--[SI]--> Pubblica economics:budget-alert
| { projectName: "MCP Suite v2",
| percentageUsed: 82,
| remaining: 9000,
| totalBudget: 50000 }
|
+--[NO]--> Solo economics:cost-updated
Eventi sottoscritti da project-economics
time:entry-logged(da time-tracking) → converte tempo registrato in costo e lo aggiunge al progettoscrum:sprint-completed(da scrum-board) → trigger per report di fine sprint con analisi costi
5. Retrospective Manager Server: Retrospettive Agili
Il server retrospective-manager gestisce il ciclo completo delle retrospettive agili: dalla creazione della sessione con formato specifico, alla raccolta del feedback per categoria, al sistema di votazione, fino alla generazione automatica di action item dai temi più votati.
Supporta tre formati di retrospettiva standard:
Formati di Retrospettiva Supportati
| Formato | Categorie |
|---|---|
| mad-sad-glad | mad, sad, glad |
| 4Ls | liked, learned, lacked, longed-for |
| start-stop-continue | start, stop, continue |
Tabella Tool: retrospective-manager
| Tool | Descrizione | Parametri Principali |
|---|---|---|
create-retro |
Crea una retrospettiva | format (enum), sprintId (opz.) |
add-retro-item |
Aggiunge feedback (con validazione categoria) | retroId, category, content, authorId (opz.) |
vote-retro-item |
Aggiunge un voto a un elemento | itemId (number) |
generate-action-items |
Genera action item dai più votati | retroId, topN (default: 3) |
get-retro |
Retrospettiva completa | retroId (number) |
Schema Zod: create-retro e add-retro-item
const CreateRetroSchema = z.object({
format: z.enum(["mad-sad-glad", "4ls", "start-stop-continue"])
.describe("Formato della retrospettiva"),
sprintId: z.string().optional()
.describe("ID dello sprint associato")
});
const AddRetroItemSchema = z.object({
retroId: z.number().describe("ID della retrospettiva"),
category: z.string()
.describe("Categoria (validata dal formato della retro)"),
content: z.string().describe("Contenuto del feedback"),
authorId: z.string().optional()
.describe("Autore del feedback")
});
Validazione delle Categorie
Il server valida la categoria verificando che sia coerente con il formato della retrospettiva. Se la categoria non e valida, restituisce un errore:
add-retro-item(retroId: 1, category: "happy", content: "...")
|
v
Verifica formato retro #1 = "mad-sad-glad"
Categorie valide: ["mad", "sad", "glad"]
"happy" NON e valida
|
v
Errore: 'Invalid category "happy" for format "mad-sad-glad".
Valid categories: mad, sad, glad'
Generazione Action Item
Il tool generate-action-items seleziona i top-N elementi più votati e genera
un action item per ciascuno, pubblicando l'evento retro:action-item-created:
Top 3 votati --> Action Items:
1. [mad] Deploy troppo lento (8 voti)
2. [sad] Manca documentazione (6 voti)
3. [glad] Code review migliora qualità (5 voti)
|
v
Per ogni action item:
Pubblica retro:action-item-created
{ retroId, actionItemId, description, assignee }
|
v
scrum-board riceve --> crea task nel backlog
Database RetroStore: tre tabelle SQLite
- retros: sessioni di retrospettiva (
id,sprintId,format,status) - retro_items: feedback del team (
id,retroId,category,content,votes,authorId) - action_items: azioni concrete (
id,retroId,description,assignee,dueDate,status)
Flusso bidirezionale con scrum-board
Ciclo di Feedback: Sprint → Retro → Backlog
- Lo sprint si completa → scrum-board pubblica
scrum:sprint-completed - Il retrospective-manager riceve l'evento e crea automaticamente una retrospettiva
- Il team aggiunge item e vota
- Le action item generate vengono pubblicate come
retro:action-item-created - Lo scrum-board riceve l'evento e crea task nel backlog
Questo ciclo chiude il loop di miglioramento continuo: ogni retrospettiva genera azioni concrete che entrano nel workflow Scrum come task del backlog.
Flusso di Collaborazione: Come i 5 Server PM Interagiscono
Il valore reale di questi cinque server emerge dalla loro collaborazione tramite EventBus. Nessun server opera in isolamento: ogni evento pubblicato attiva reazioni a catena che creano un flusso di project management integrato e automatizzato.
Mappa Completa degli Eventi PM
| Evento | Produttore | Consumatori |
|---|---|---|
scrum:sprint-started |
scrum-board | agile-metrics, retrospective-manager |
scrum:task-updated |
scrum-board | agile-metrics, time-tracking, project-economics |
scrum:sprint-completed |
scrum-board | agile-metrics, retrospective-manager, project-economics |
scrum:story-completed |
scrum-board | agile-metrics |
time:entry-logged |
time-tracking | project-economics |
economics:budget-alert |
project-economics | (futuro: standup-notes) |
economics:cost-updated |
project-economics | (log e audit) |
retro:action-item-created |
retrospective-manager | scrum-board |
Diagramma di Collaborazione
+------------------+
| SCRUM-BOARD | (HUB CENTRALE)
| 7 tool |
+--------+---------+
|
| scrum:sprint-started
| scrum:task-updated
| scrum:sprint-completed
| scrum:story-completed
|
+-----+-----+-----+------------------+
| | | |
v v v v
+----------+ +------+ +---------------+ +----+
|agile- | |time- | |retrospective- | |... |
|metrics | |track.| |manager | | |
|4 tool | |4 tool| |5 tool | | |
|stateless | | | | | | |
+----------+ +--+---+ +------+--------+ +----+
| |
| time: | retro:action-
| entry- | item-created
| logged |
v v
+----------+ +------------------+
|project- | | SCRUM-BOARD |
|economics | | (riceve e crea |
|4 tool | | task backlog) |
+----+-----+ +------------------+
|
| economics:budget-alert
| economics:cost-updated
v
(alert e audit)
Scenario Integrato: Sprint Completo con tutti i Server
Ecco un esempio di come tutti e cinque i server collaborano durante il ciclo di vita di uno sprint:
-
Pianificazione: l'AI invoca
create-sprintsullo scrum-board. L'eventoscrum:sprint-startednotifica agile-metrics (nuova velocity) e retrospective-manager (contest per futura retro). -
Esecuzione: gli sviluppatori aggiornano lo stato dei task con
update-task-status. L'eventoscrum:task-updatedattiva il ricalcolo del burndown in agile-metrics e il time-tracking può avviare/fermare timer automaticamente. -
Tracciamento tempo: al
stop-timer, time-tracking pubblicatime:entry-logged. Project-economics riceve l'evento e converte il tempo in costo, aggiornando il budget. -
Budget alert: se la spesa supera l'80% del budget, project-economics pubblica
economics:budget-alertper notificare il team. - Chiusura sprint: al completamento dello sprint, agile-metrics ricalcola velocity e forecast, mentre retrospective-manager crea automaticamente una retrospettiva.
-
Retrospettiva: il team inserisce feedback, vota e genera action item.
L'evento
retro:action-item-createdcrea task nel backlog dello scrum-board, pronti per il prossimo sprint.
Architettura Interna dei Server PM
Tutti e cinque i server PM seguono la stessa struttura architetturale standardizzata,
condividendo pattern e convenzioni dal pacchetto @mcp-suite/core:
server-name/
src/
index.ts --> entry point
server.ts --> createXxxServer(), registra tool e collaboration
services/
xxx-store.ts --> Store SQLite (gestione dati persistenti)
tools/
tool-name.ts --> handler singolo tool con schema Zod
collaboration.ts --> setupCollaborationHandlers(eventBus, store)
Il pattern collaboration.ts e particolarmente importante: e il file che gestisce
la sottoscrizione e la pubblicazione degli eventi sull'EventBus, rendendo esplicito il contratto
di collaborazione di ogni server con il resto della suite.
Dipendenze dei Pacchetti Condivisi
I server PM utilizzano tre pacchetti condivisi della MCP Suite:
@mcp-suite/core: base per la creazione del server MCP, registrazione tool, gestione lifecycle@mcp-suite/event-bus: sistema di eventi tipizzati per la comunicazione inter-server@mcp-suite/database: wrapper SQLite con migrazioni automatiche (usato da 4 dei 5 server; agile-metrics e stateless)
Conclusioni
I cinque server di project management della MCP Suite dimostrano come il protocollo MCP possa supportare workflow complessi e realmente collaborativi. Lo scrum-board come hub centrale, agile-metrics per l'analisi predittiva con Monte Carlo, time-tracking per la gestione del tempo, project-economics per il controllo dei costi e retrospective-manager per il miglioramento continuo formano un ecosistema completo di gestione agile.
Il pattern chiave e la collaborazione event-driven: ogni server pubblica eventi che attivano azioni negli altri, creando catene di automazione che riducono il lavoro manuale e mantengono sincronizzato l'intero sistema. Il ciclo retrospettiva-backlog e un esempio perfetto di come i server MCP possano chiudere loop di feedback in modo completamente automatizzato.
Nel prossimo articolo esploreremo i server avanzati della suite: incident-manager, decision-log, access-policy, quality-gate, workflow-orchestrator, insight-engine e altri, scoprendo come gestire scenari ancora più complessi con pattern architetturali evoluti.
Il codice completo di tutti i server di project management e disponibile nel repository Tech-MCP su GitHub.