MCP

Permisos MCP y alcance del proyecto

Comprende cómo el usuario de Taskavel conectado, la pertenencia a proyectos y los roles limitan el acceso MCP.

Taskavel MCP siempre actúa como un usuario autenticado de Taskavel. No crea un administrador de IA para todo el espacio de trabajo ni combina silenciosamente el acceso de otras cuentas. El cliente solo puede trabajar con proyectos que su usuario conectado posee o a los que pertenece, y las mismas comprobaciones de rol que protegen la aplicación web protegen las llamadas de herramientas MCP.

Este modelo importa cuando compartes un espacio de trabajo. Dar a un asistente una conexión MCP no le concede permiso para leer todos los proyectos de la organización. A la inversa, un proyecto que no aparece en una respuesta de herramienta suele ser un problema de pertenencia o cuenta, no una función MCP ausente.

Los roles siguen aplicándose

Los propietarios y administradores pueden realizar acciones administrativas como invitar o eliminar miembros. Propietarios, administradores y miembros pueden crear y actualizar trabajo normal de proyecto, incluidas tareas y comentarios. Los invitados pueden leer contenido de proyecto y observar tareas, pero no comentar, subir adjuntos ni modificar tareas.

Pide al cliente que muestre una denegación en vez de reintentar repetidamente una herramienta de escritura. Si una acción se deniega, confirma la cuenta conectada y el rol en Taskavel. No evites una restricción de rol tomando prestado el PAT o la conexión OAuth de otra persona. El propietario adecuado del espacio de trabajo debe ajustar la pertenencia cuando se pretenda un acceso más amplio.

Resuelve el objetivo antes de mutar

Muchas herramientas de Taskavel aceptan un nombre de proyecto o un ID exacto. Un nombre legible resulta cómodo pero puede ser ambiguo. Para cualquier cambio importante, haz que el cliente enumere proyectos o muestre candidatos coincidentes y utiliza el ID devuelto si es necesario. El mismo principio se aplica a columnas, hitos, etiquetas y tareas.

Una solicitud explícita es más segura y fácil de auditar: “En el proyecto Website, mueve la tarea #42 a Review” indica proyecto, tarea y resultado. Una solicitud vaga como “limpia el backlog” fuerza al cliente a adivinar límites y debe restringirse antes de actuar.

Clasificaciones de herramientas y eliminación

La referencia generada de herramientas MCP etiqueta cada acción como lectura, escritura o destructiva. Usa herramientas de lectura para establecer contexto antes de solicitar escritura. Trata las acciones destructivas como un punto de aprobación separado. En particular, la eliminación permanente solo se aplica después de archivar una tarea y exige confirmación explícita. Archivar primero te permite revisar antes de cualquier paso irreversible.

Lee aprobaciones seguras para las salvaguardas operativas y solución de problemas cuando un resultado falte o sea denegado.

Last reviewed 26 jul 2026