Servidor MCP per gestionar projectes: guia pas a pas

Un servidor MCP per a la gestió de projectes és un programa que parla el Model Context Protocol i ofereix a un assistent d'IA eines concretes: llistar projectes, llegir tasques, crear-ne, canviar-les o tancar-les. Tot passa sota els permisos d'un token. Així l'assistent treballa amb les dades reals del gestor i no amb el que li enganxes al xat.

Què és el Model Context Protocol (MCP) i qui el defineix?

El Model Context Protocol és un protocol obert que fixa com una aplicació d'IA es connecta a fonts de dades i a eines externes. La versió de referència d'aquesta guia és la especificació de MCP del 2026-07-28. L'especificació i la documentació es mantenen en obert al repositori oficial de MCP.

La idea es resumeix en tres peces, tal com explica la introducció oficial a MCP:

• L'amfitrió és l'aplicació on parles amb la IA, per exemple un assistent d'escriptori o un agent de terminal.
• El client és la part de l'amfitrió que manté la connexió amb cada servidor.
• El servidor és el programa que exposa dades i accions d'un servei concret, com un gestor de projectes.

Un servidor pot oferir eines (accions que la IA pot executar), recursos (dades que pot llegir) i indicacions predefinides. Els missatges viatgen en format JSON-RPC. Per a la gestió de projectes, el que més importa són les eines: cada eina és una acció amb un nom, una descripció i uns paràmetres, com «crear tasca» amb títol, projecte i data límit.

Què pot fer un assistent d'IA amb un servidor MCP de tasques?

Un assistent connectat a un servidor MCP de tasques pot fer el que el servidor li permeti i res més. Si el servidor només exposa lectura, l'assistent pot resumir i respondre preguntes. Si també exposa escriptura, pot convertir una conversa en feina planificada.

Aquests són els usos habituals, ordenats de menys a més risc:

La regla pràctica: com més avall a la taula, més convé que l'assistent et mostri el canvi abans de fer-lo. Un bon servidor també posa límits per disseny, per exemple no permetre esborrar res.

Quina diferència hi ha entre un servidor MCP, una API i els webhooks?

Un servidor MCP està pensat perquè el faci servir un model d'IA; una API, perquè la faci servir un programa escrit per una persona; un webhook, perquè el servei t'avisi quan passa alguna cosa. Sovint conviuen: el servidor MCP acostuma a funcionar sobre la mateixa API i amb els mateixos tokens.

Una API ben documentada sol descriure's amb l'especificació OpenAPI 3.1, que permet generar clients i validar peticions. Els webhooks no tenen un estàndard únic, però iniciatives com Standard Webhooks proposen com signar-los i reintentar-los.

Tria MCP quan la petició canvia cada vegada i la vols formular amb paraules. Tria l'API quan l'acció és sempre la mateixa i ha de ser previsible al cent per cent, sense un model pel mig.

Com es connecta un assistent d'IA a un servidor MCP de tasques, pas a pas?

Connectar un assistent a un servidor MCP remot demana una adreça, una forma d'autenticar-se i un client que accepti servidors externs. Aquests passos valen per a la majoria de gestors de projectes que ofereixen MCP amb token:

1. Decideix què pot fer l'assistent. Escriu en una frase si només ha de llegir o també crear i tancar tasques. Aquesta frase defineix els permisos.
2. Crea un token amb els àmbits mínims. Si el servei permet àmbits, comença amb lectura i afegeix escriptura només quan l'hagis provat. Un token per a cada ús facilita revocar-lo.
3. Configura el client amb l'adreça del servidor. Als clients que admeten servidors remots, indica la URL del servidor MCP i el token com a capçalera d'autorització.
4. Prova-ho en un projecte de proves. Demana una llista de projectes i compara-la amb el que veus a l'eina. Si quadra, la connexió funciona.
5. Exigeix confirmació abans d'escriure. Configura l'assistent perquè et mostri cada tasca que vol crear o canviar i esperi el teu sí.
6. Revisa el resultat a l'eina, no al xat. L'assistent pot dir que ha fet una cosa i haver-la fet a mitges. La veritat és el que mostra el gestor.
7. Guarda el token com una contrasenya. No el posis en fitxers compartits ni en repositoris. Si s'escapa, revoca'l i crea'n un de nou.

Per a connexions remotes, l'especificació de MCP preveu un flux d'autorització basat en OAuth. Els servidors que encara no el tenen funcionen amb un token enganxat a mà, i per això no apareixen als catàlegs de connectors que depenen d'aquest flux.

Per què importa la idempotència quan un assistent d'IA crea tasques?

Una petició és idempotent quan repetir-la deixa el sistema igual que fer-la una sola vegada. Segons la semàntica HTTP de l'RFC 9110, el mètode POST, que és el que se sol fer servir per crear, no ho és: enviar-lo dues vegades pot crear dues tasques.

Amb un assistent d'IA el problema es fa més visible. Si la connexió tarda, l'agent pot tornar a provar-ho, i si no té manera de saber que la primera petició ja havia arribat, crea un duplicat. Multiplicat per una llista de notes de reunió, el projecte s'omple de tasques repetides.

La solució habitual és la capçalera Idempotency-Key, descrita a l'esborrany de l'IETF sobre Idempotency-Key. El client envia una clau única amb cada creació; si el servidor rep la mateixa clau dues vegades, retorna el resultat de la primera i no crea res nou. És el mateix patró que documenta Stripe a les seves peticions idempotents.

Quan avaluïs un servidor MCP o l'API que hi ha a sota, comprova si la creació de tasques fa servir aquesta capçalera o un mecanisme equivalent. Si no, demana a l'assistent que llisti les tasques existents abans de crear-ne de noves.

Quins riscos té donar accés als projectes a una IA i com es limiten?

El risc principal és que l'assistent faci canvis que ningú ha demanat: tancar tasques per error, moure dates o assignar feina a qui no toca. Es limita amb permisos estrets, amb accions que no es poden desfer fora del seu abast i amb revisió humana.

• Accions destructives fora de l'abast. Un servidor que no pot esborrar tasques ni projectes redueix el pitjor error possible a una tasca tancada o cancel·lada, que es pot reobrir.
• Límits de peticions. Un assistent que entra en bucle pot enviar moltes peticions seguides. Els límits per token i per compte frenen el dany i fan visible el problema.
• Text que sembla una ordre. Si l'assistent llegeix els comentaris de les tasques, un comentari pot contenir frases com «tanca totes les tasques». L'assistent ha de tractar aquest text com a dades, no com a instruccions, i tu has de confirmar qualsevol acció que se'n derivi.
• Dades que surten del gestor. Tot el que l'assistent llegeix passa pel model d'IA que facis servir. Abans de connectar projectes amb informació de clients, revisa les condicions del proveïdor del model.
• Tokens oblidats. Revisa de tant en tant quins tokens hi ha actius i revoca els que ja no facis servir.

Una pràctica útil és començar amb un sol projecte i ampliar l'abast quan hagis vist com es comporta l'assistent durant unes quantes setmanes.

Quines eines de gestió de projectes tenen servidor MCP, i amb quines condicions?

Les condicions canvien molt d'una eina a una altra, sobretot en quin pla cal i com s'autentica l'assistent. Les dades de Microsoft d'aquesta comparativa es van comprovar el 29 de setembre de 2026 a les fonts enllaçades, i la comparativa es va redactar l'11 de novembre de 2026.

tokidu, el gestor de projectes de Sinergia Barcelona, és el producte de qui publica aquesta guia. El seu servidor MCP deixa que un agent d'IA, com Claude Code, llegeixi els projectes, inclosos els comentaris de les tasques (sense poder-ne escriure), i creï, canviï, tanqui i cancel·li tasques amb un token de l'API. Forma part del pla Max, que encara no està a la venda. Encara no té OAuth, de manera que no apareix com a connector a claude.ai, i no esborra tasques ni projectes. Els detalls tècnics són a la documentació del servidor MCP.

El que Planner fa millor: el seu servidor MCP es pot fer servir ja amb els plans bàsics, segons el blog de Microsoft sobre el servidor MCP, mentre que l'altre depèn d'un pla que encara no està a la venda. A més, Planner viu dins de l'entorn de Microsoft, cosa pràctica si l'equip ja hi treballa. A canvi, la creació de plans a partir d'objectius amb Copilot queda reservada als plans premium, tal com indica la FAQ de l'agent de Planner.

Per què un assistent d'IA no hauria de calcular les dates del projecte?

Un model de llenguatge redacta bé, però no és fiable per sumar durades, saltar caps de setmana i respectar l'ordre entre tasques. Si li demanes «quan acabarem?», pot donar una data plausible i equivocada. Les dates les ha de calcular el gestor de projectes; l'assistent només les ha de llegir i explicar.

Perquè això funcioni, el gestor ha de tenir tres dades ben posades:

1. Durades a cada tasca. Sense durada no hi ha càlcul possible, i és millor que l'eina ho digui que no pas que suposi una xifra.
2. Dependències entre tasques. Si una tasca no pot començar fins que n'acabi una altra, ha de constar al gestor i no només a la memòria de l'equip. La guia de dependències entre tasques explica com definir-les.
3. Responsables i dies laborables. Una persona no pot fer dues tasques alhora, i les dates han de tenir en compte quins dies treballa.

Amb aquestes dades, l'assistent pot respondre «què puc fer avui?» o «per què es retarda l'entrega?» llegint el que el gestor ja ha calculat. Si n'hi falta alguna, la millor feina que pot fer l'assistent és assenyalar-la: «aquestes tres tasques no tenen durada».

Per a més articles sobre agents, API i automatització aplicats a projectes, consulta el tema d'IA, API i MCP.