Servidor MCP para gestión de proyectos: guía paso a paso

Un servidor MCP para gestión de proyectos es un programa que publica tus proyectos y tareas siguiendo el Model Context Protocol. Así, un asistente de IA puede leerlos y actuar sobre ellos: consultar qué está pendiente, crear tareas o cerrar las terminadas. El asistente solo puede hacer lo que ese servidor expone y lo que permite su token.

¿Qué es el Model Context Protocol (MCP) y cómo funciona?

MCP es un protocolo abierto que define cómo una aplicación de IA se conecta a datos y herramientas externas. Lo resume la introducción oficial a MCP. Los detalles están en la especificación de MCP de 2026-07-28, y su desarrollo es público en el repositorio de la especificación MCP.

La arquitectura tiene 3 piezas:

• El anfitrión es la aplicación donde hablas con la IA, como un editor de código o un asistente de terminal.
• El cliente MCP vive dentro del anfitrión y mantiene la conexión con un servidor.
• El servidor MCP conoce tus datos y ofrece acciones sobre ellos.

Un mismo anfitrión puede tener varios clientes, cada uno conectado a un servidor distinto.

Un servidor MCP puede ofrecer 3 tipos de elementos:

• Herramientas: acciones que el modelo puede invocar, como «crear tarea».
• Recursos: datos que se leen, como la lista de proyectos.
• Plantillas de instrucciones: los prompts.

En un gestor de proyectos, casi todo el valor está en las herramientas y en la lectura de datos.

Los mensajes de MCP viajan en formato JSON-RPC. Un servidor puede ejecutarse en tu propio ordenador, comunicándose por la entrada y salida estándar. También puede funcionar en remoto, accesible por HTTP. Los gestores de proyectos en la nube usan normalmente la vía remota, porque los datos ya están en sus servidores.

¿En qué se diferencia un servidor MCP de la API de un gestor de proyectos?

Una API la llama un programa que alguien ha escrito con antelación; un servidor MCP lo usa un modelo de IA que decide en cada momento qué herramienta llamar. Muchos servidores MCP de gestores de proyectos son una capa encima de su propia API: comparten operaciones, permisos y límites.

La API encaja en integraciones fijas y repetibles, como copiar cada tarea cerrada a una hoja de facturación. MCP encaja en peticiones en lenguaje natural que cambian cada día, como «resume lo que se ha comentado esta semana en el proyecto de la web».

¿Qué puede hacer un asistente de IA con un servidor MCP de tareas?

Un asistente conectado por MCP puede hacer exactamente las operaciones que el servidor anuncia, y ninguna más. Cada operación tiene un riesgo distinto si el modelo entiende mal la petición:

Cerrar una tarea por error tiene un efecto en cadena si otras tareas esperan a que acabe: pueden quedar libres antes de tiempo. Si trabajas con esperas entre tareas, las guías sobre dependencias entre tareas explican cómo se encadenan. Por la misma razón, muchos servidores pensados para agentes no exponen el borrado.

¿Cómo se conecta un asistente de IA a un servidor MCP de gestión de proyectos?

La conexión se hace en el cliente: se le da la dirección del servidor y una forma de autenticarse. El orden recomendable es este:

1. Comprueba que el gestor tiene servidor MCP. Busca en su documentación la dirección del servidor, qué herramientas ofrece y en qué plan está incluido.
2. Crea un token con el mínimo de permisos. Si solo quieres consultas, crea un token de solo lectura; si el agente va a crear tareas, limita el token a eso.
3. Añade el servidor a tu cliente. En asistentes de terminal y editores se declara en su configuración de servidores MCP, con la dirección y el token. En asistentes web se añade como conector si el servidor admite autorización desde el navegador.
4. Revisa las herramientas que anuncia. El cliente muestra la lista; si aparece alguna que no esperabas, como borrar, desactívala o cambia el token.
5. Empieza con una petición de solo lectura. Pregunta por un proyecto concreto y compara la respuesta con lo que ves en el gestor.
6. Prueba una escritura pequeña. Pide que cree una sola tarea de prueba y comprueba en el gestor nombre, responsable y fechas.
7. Guarda el token como un secreto. No lo subas a un repositorio ni lo pegues en un chat; quien tenga el archivo de configuración tiene el acceso.

¿Qué permisos debe tener el token de un servidor MCP de tareas?

El token de un agente debe tener los ámbitos justos para su trabajo y ninguno más: un agente que redacta resúmenes no necesita escribir tareas. Los tokens con ámbitos permiten separar lectura y escritura, y crear un token distinto para cada agente o cada uso.

Un token por agente tiene 3 ventajas claras. Puedes revocar uno sin cortar a los demás. Sabes qué agente hizo cada cambio. Y un token filtrado expone menos datos.

La autorización con OAuth funciona de otro modo. La persona aprueba el acceso desde el navegador y el asistente recibe un permiso que se puede retirar sin tocar la configuración. La especificación de MCP describe cómo se autoriza a un servidor remoto. Un servidor que solo acepta tokens de API sigue siendo útil, pero exige pegar el token en el cliente, con el cuidado que eso implica.

¿Cómo evita un servidor MCP crear tareas duplicadas?

Un servidor evita los duplicados si la operación de crear es idempotente: repetir la misma petición no crea una segunda tarea. Esto importa con agentes, porque un modelo que no recibe respuesta a tiempo tiende a reintentar.

En HTTP, RFC 9110 sobre semántica HTTP define qué métodos son idempotentes. GET, PUT y DELETE lo son; POST, el método habitual para crear, no lo es. Para cubrir ese hueco existe la cabecera Idempotency-Key, descrita en el borrador del IETF sobre Idempotency-Key. El cliente envía una clave única con la petición, y si la repite, el servidor devuelve el resultado de la primera vez en lugar de crear otro registro.

Las peticiones idempotentes en Stripe son un ejemplo conocido de este patrón en una API pública. Si el gestor que usas no ofrece nada parecido, pide al agente que busque la tarea por nombre antes de crearla. No es infalible, pero reduce los duplicados.

¿Qué límites de peticiones tiene un servidor MCP de gestión de proyectos?

Los servidores MCP de gestores de proyectos suelen heredar los límites de peticiones de su API, por token y por cuenta. Un agente los alcanza con facilidad si recorre las tareas de una en una, porque cada lectura es una petición.

Tres hábitos ayudan a no chocar con el límite:

• Pide resúmenes por proyecto en lugar de recorrer cada tarea.
• Acota la petición a un proyecto o a unas fechas.
• Usa un token distinto para cada agente, así uno no agota el cupo de otro.

Cuando el servidor responde que hay demasiadas peticiones, lo correcto es esperar y reintentar más tarde, no insistir en bucle.

¿Qué servidores MCP de gestión de proyectos hay y en qué plan van?

Antes de conectar un agente conviene saber en qué plan está el servidor MCP de cada gestor, porque no siempre va en todos. Esta tabla está actualizada a 11 de noviembre de 2026. Los datos de Microsoft proceden de sus páginas, revisadas el 29 de septiembre de 2026.

La última fila corresponde a tokidu, el gestor de proyectos de Sinergia Barcelona, que es el producto de quien escribe este artículo. En esta comparación, Microsoft Planner tiene una ventaja clara: su servidor MCP ya se puede usar dentro de sus planes básicos, según el anuncio de Microsoft. Además, su Copilot crea planes desde objetivos en los planes premium, según las preguntas frecuentes de Microsoft. El servidor de la última fila va en el plan Max, que aún no está a la venta.

Ese servidor MCP del plan Max, que aún no está a la venta, funciona con un token de la API. Un agente como Claude Code puede leer los proyectos, incluidos los comentarios de las tareas, pero no puede escribir comentarios. También puede crear, cambiar, cerrar y cancelar tareas. No borra tareas ni proyectos. Todavía no tiene OAuth, así que no aparece como conector en claude.ai. Los detalles están en la sección MCP de la documentación, y los planes, en los planes y precios previstos.

¿Sustituye un servidor MCP a los webhooks de un gestor de proyectos?

No: un servidor MCP responde cuando el asistente le pregunta, mientras que un webhook avisa por su cuenta cuando ocurre algo. Si quieres que otra aplicación se entere al momento de que una tarea se ha cerrado, lo que necesitas es un webhook, no MCP.

La documentación de GitHub sobre webhooks explica el modelo: el servicio envía una petición HTTP a una dirección tuya en cuanto ocurre un evento. Standard Webhooks propone un formato común para esos envíos, con firmas basadas en HMAC según RFC 2104, que permiten comprobar que el aviso es auténtico.

Algunos destinos piden un formato propio. Los webhooks entrantes de Slack esperan un mensaje con su estructura, así que entre el gestor y Slack suele hacer falta un paso intermedio que traduzca el aviso.

¿Qué tareas de gestión de proyectos conviene delegar a un asistente por MCP?

Conviene delegar el trabajo mecánico que parte de un texto y acaba en tareas, y quedarse con las decisiones: prioridades, fechas límite y quién hace qué. Estos son usos razonables, presentados como ejemplos:

1. Notas de reunión a tareas. Pegas las notas y el agente crea una tarea por cada acción acordada, con su responsable si aparece en el texto.
2. Repaso de lo pendiente. Cada mañana pides qué tareas abiertas tiene un proyecto y cuáles llevan días sin cambios.
3. Resumen semanal. El agente lee las tareas cerradas y los comentarios de la semana y redacta un resumen para el cliente.
4. Cierre desde el trabajo técnico. Un agente de programación cierra la tarea correspondiente cuando termina el cambio que se le pidió.
5. Limpieza de duplicados. El agente propone qué tareas parecen repetidas, y tú decides cuáles cancelar.

En todos estos casos, lo que cambie el agente debe poder revisarse en el gestor. Hay más artículos sobre estos usos en los artículos sobre IA, API y MCP.

¿Qué 5 errores son habituales al conectar un asistente de IA por MCP?

Los errores más habituales tienen que ver con permisos amplios y con falta de revisión, no con la parte técnica de la conexión:

1. Dar un token con todos los permisos. Un agente que solo resume no debe poder escribir; separa los tokens por uso.
2. Pedir acciones vagas. «Ordena el proyecto» puede acabar en tareas cerradas o fechas movidas; nombra el proyecto y la acción concreta.
3. No revisar la primera escritura. La primera tarea creada revela si el agente entiende bien responsables y fechas.
4. Reintentar sin idempotencia. Si el servidor no protege la creación, cada reintento puede dejar una tarea duplicada.
5. Guardar el token en un repositorio. El archivo de configuración del cliente contiene el acceso; trátalo como una contraseña y revoca el token si se filtra.