Servidor MCP para xestión de proxectos: guía paso a paso

Un servidor MCP para xestión de proxectos é un programa que expón as túas tarefas a un asistente de IA mediante o Model Context Protocol, un estándar aberto. Co servidor conectado, o asistente pode ler proxectos, crear tarefas, cambiar datas ou pechalas cando llo pides, sempre dentro dos permisos do token que lle deas.

Que é un servidor MCP e que fai nun xestor de proxectos?

O Model Context Protocol (MCP) define como se conecta unha aplicación de IA a sistemas externos. O cliente é a aplicación onde falas co modelo; o servidor é o programa que lle ofrece datos e accións. A introdución oficial a MCP compárao cun porto USB-C para aplicacións de IA: un mesmo servidor serve para calquera cliente compatible.

Nun xestor de proxectos, o servidor traduce as peticións do modelo a operacións concretas: listar proxectos, ler as tarefas dun proxecto, crear unha tarefa nova ou marcala como feita. O modelo nunca ve a base de datos. Só ve as ferramentas que o servidor decide expor e só pode facer o que esas ferramentas permiten.

A especificación de MCP describe tres tipos de cousas que un servidor pode ofrecer: ferramentas, que son accións que o modelo executa; recursos, que son datos que o modelo le; e prompts, que son modelos de instrución reutilizables. As mensaxes viaxan en JSON-RPC, e o transporte pode ser local, pola entrada e saída estándar, ou remoto, por HTTP.

O protocolo é aberto: a especificación e a documentación publícanse no repositorio de MCP en GitHub, onde se poden seguir os cambios de cada versión. Por iso un servidor feito para un cliente funciona tamén noutros que implementen a mesma versión.

Que pode facer un asistente de IA coas túas tarefas a través de MCP?

Un asistente conectado por MCP pode facer as mesmas operacións que farías ti nun xestor de proxectos, pero a partir dunha frase. O límite real non é o modelo, senón as ferramentas que expón o servidor e os permisos do token.

As operacións de lectura son as máis seguras e as máis útiles para empezar:

• Resumir o estado dun proxecto: que está aberto, que se pechou e que vai tarde.
• Buscar tarefas por persoa, por data límite ou por palabra.
• Ler os comentarios dunha tarefa para entender por que está parada.
• Preparar o resumo da reunión semanal a partir das tarefas pechadas.

As operacións de escritura aforran traballo mecánico, pero cambian datos reais:

• Converter unhas notas de reunión en tarefas con título, responsable e data.
• Cambiar a data límite dunha tarefa cando cambia o prazo dun cliente.
• Pechar as tarefas que xa se fixeron ou cancelar as que deixaron de ter sentido.

O que un servidor non expón, o asistente non o pode facer, por moito que llo pidas. Se o servidor non ten unha ferramenta para borrar, o asistente pode propoñer o borrado, pero non executalo.

En que se diferencian MCP, unha API REST e os webhooks?

MCP, unha API e os webhooks resolven problemas distintos e adoitan convivir no mesmo produto. A diferenza principal é quen inicia a comunicación e para quen está pensada.

Unha API REST é a opción correcta cando a tarefa é sempre a mesma: por exemplo, crear as mesmas tarefas cada vez que entra un pedido. O programa fai exactamente o que está escrito, sen interpretar nada.

Os webhooks funcionan ao revés: é o xestor quen chama a un enderezo teu cando pasa algo. Iniciativas como Standard Webhooks propoñen asinar cada envío con HMAC para que o receptor comprobe a orixe. Algúns destinos esixen un formato propio: os webhooks entrantes de Slack esperan unha mensaxe con estrutura de Slack, polo que adoita facer falta un paso intermedio.

MCP encaixa cando a petición cambia cada vez e queres expresala con palabras: «pecha o que se fixo onte e móveme a revisión ao xoves». Moitos servidores MCP apóianse nunha API por debaixo, así que os límites e as regras desa API tamén se aplican ao asistente.

Como se conecta un asistente de IA a un servidor MCP en 5 pasos?

Conectar un servidor MCP remoto leva poucos minutos se o xestor ofrece un token de acceso. Os pasos son os mesmos na maioría de clientes, como Claude Code:

1. Localiza o enderezo do servidor. O xestor de proxectos publica a URL do seu servidor MCP na documentación; sen ese enderezo non hai conexión.
2. Crea un token co mínimo de permisos. Se o xestor permite ámbitos, empeza só con lectura e engade escritura cando confíes no fluxo.
3. Rexistra o servidor no cliente. Engade a URL e o token na configuración do cliente MCP, nunca nun ficheiro que se comparta nun repositorio.
4. Proba cunha pregunta de lectura. Pide algo como «lista os meus proxectos abertos» e comproba que a resposta coincide co que ves no xestor.
5. Activa as escrituras con revisión. Pide que o asistente amose o que vai crear ou cambiar antes de facelo, polo menos as primeiras semanas.

A especificación de MCP tamén contempla autorización con OAuth para servidores remotos. Cando un servidor aínda non a ofrece, a conexión faise co token e o cliente ten que permitir configuralo a man.

Que permisos convén dar a un axente de IA no xestor de proxectos?

A regra é dar ao axente o permiso máis pequeno que lle permita facer o traballo. Un token só de lectura chega para resumos, informes e preguntas sobre o estado dun proxecto.

O permiso de escritura merece unha decisión explícita. Un modelo pode interpretar mal unha frase ambigua, e «pecha o do cliente» pode significar unha tarefa ou dez. Revisar a lista de cambios antes de executalos evita a maioría de sustos.

O borrado é o permiso máis delicado. Pechar ou cancelar unha tarefa deixa rastro e pode desfacerse; borrala, non. Un servidor que non borra tarefas nin proxectos limita o dano dun erro do modelo.

Un token por uso é mellor que un token para todo. Se o asistente de informes e o script de facturación usan tokens distintos, podes revogar un sen romper o outro, e os límites de peticións de cada un non se mesturan.

Por que importa a cabeceira Idempotency-Key cando un axente crea tarefas?

A cabeceira Idempotency-Key evita que unha petición repetida cree dúas tarefas iguais. Os axentes de IA repiten peticións con frecuencia: se a resposta tarda ou se corta a conexión, volven intentalo, e sen protección cada intento crea unha copia.

A RFC 9110 define que un método é idempotente cando repetilo ten o mesmo efecto que facelo unha vez, e POST, o método habitual para crear, non o é. O borrador da IETF sobre Idempotency-Key propón que o cliente envíe un identificador único con cada creación para que o servidor recoñeza os reintentos.

O patrón está estendido en APIs públicas: a documentación de peticións idempotentes de Stripe explica que o servidor garda o resultado da primeira petición e devólveo igual se chega outra coa mesma clave. Nun xestor de proxectos, iso significa que un reintento devolve a tarefa xa creada en vez dunha nova.

Que servidores MCP para xestión de proxectos hai e que inclúe cada un?

Microsoft publicou un servidor MCP de Planner que funciona só cos plans básicos, segundo o seu anuncio no blog de Planner. A comprobación desta comparativa faise con data do 11 de novembro de 2026.

O outro servidor da táboa é o de tokidu, o xestor de proxectos de Sinergia Barcelona, que é o produto de quen escribe este artigo. O seu MCP forma parte do plan Max, que aínda non está á venda: un axente como Claude Code le os proxectos e os comentarios das tarefas e crea, cambia, pecha e cancela tarefas cun token da API. Os detalles técnicos están na documentación do servidor MCP e o encaixe nos plans, na páxina de plans previstos.

Planner ten dúas vantaxes claras. A primeira é que o seu servidor MCP xa se pode usar, mentres que o plan Max aínda non está á venda. A segunda é Copilot: nos plans premium de Planner crea un plan a partir duns obxectivos, segundo as preguntas frecuentes do axente de Planner.

A falta de OAuth tamén ten consecuencias prácticas: o servidor do plan Max, que aínda non está á venda, non aparece como conector na web de Claude e conéctase desde clientes que admiten configurar un token, como Claude Code. A creación de tarefas esixe a cabeceira Idempotency-Key, descrita na guía de idempotencia da API, e o uso ten límites de peticións por token, de 60 por minuto.

Que instrucións funcionan mellor cun asistente de IA conectado por MCP?

As instrucións que mellor funcionan nomean o proxecto, a acción e o criterio. «Arranxa o proxecto» deixa demasiado á interpretación; «no proxecto Web nova, pecha as tarefas con comentario de feito» dálle ao modelo algo comprobable.

Estes son exemplos de instrucións, pensados para copiar e adaptar:

• «Resume o proxecto Web nova: tarefas abertas, as que pasaron a súa data límite e quen ten máis carga.»
• «Le os comentarios das tarefas bloqueadas e dime que falta para cada unha.»
• «Converte estas notas de reunión en tarefas. Antes de crealas, amósame a lista con responsable e data.»
• «O cliente atrasou a entrega unha semana: propón as novas datas límite e non cambies nada ata que confirme.»
• «Cancela as tarefas da campaña de verán que sigan abertas e explica cales cancelaches.»

Pedir a lista antes do cambio é o hábito que máis erros evita. O asistente traballa igual de rápido, pero ti decides que entra no proxecto.

Que erros fan que un axente de IA desordene un proxecto?

Os erros máis frecuentes non veñen do protocolo, senón de como se usa. Estes catro son os que máis traballo dan despois:

1. Dar escritura desde o primeiro día. Un token con todos os permisos antes de probar a lectura multiplica o efecto de calquera malentendido.
2. Pedir accións ambiguas. «Pecha o do cliente» pode afectar a tarefas que non querías tocar; nomea o proxecto e o criterio.
3. Ignorar os reintentos. Sen unha clave de idempotencia, un corte de rede pode deixar tarefas duplicadas.
4. Compartir o token. Un token pegado nun ficheiro público dá acceso aos proxectos a quen o atope; gárdao fóra do código e revógao se se filtra.

Para seguir co tema, a sección sobre IA, API e MCP reúne os artigos que desenvolven cada parte desta guía, desde os tokens ata os webhooks.