Taskavel MCP always acts as an authenticated Taskavel user. It does not create a workspace-wide AI administrator or silently combine access from other accounts. The client can only work with projects that its connected user owns or belongs to, and the same role checks that protect the web application protect MCP tool calls.
This model matters when you share a workspace. Giving an assistant an MCP connection does not give it permission to read every project in the organization. Conversely, a project that does not appear in a tool response is usually a membership or account problem, not a missing MCP feature.
Roles continue to apply
Owners and admins can carry out administrative project actions such as inviting or removing members. Owners, admins, and members can create and update normal project work, including tasks and comments. Guests can read project content and watch tasks, but they cannot comment, upload attachments, or modify tasks.
Ask the client to surface a denial rather than repeatedly retrying a write tool. If an action is denied, confirm the connected account and role in Taskavel. Do not work around a role restriction by borrowing another person’s PAT or OAuth connection. The appropriate workspace owner should adjust membership when broader access is intended.
Resolve the target before mutation
Many Taskavel tools accept a project name or an exact project ID. A human-readable name is convenient but can be ambiguous. For any substantial change, have the client list projects or show the matching candidates first, then use the returned ID if needed. The same principle applies to columns, milestones, tags, and tasks.
An explicit request is safer and easier to audit: “In project Website, move task #42 to Review” states a project, task, and outcome. A vague request such as “clean up the backlog” forces the client to guess boundaries and should be narrowed before it acts.
Tool classifications and deletion
The generated MCP tool reference labels each action as read, write, or destructive. Use read tools to establish context before asking for a write. Treat destructive actions as a separate approval point. In particular, permanent deletion only applies after a task is already archived and the call includes explicit confirmation. Archiving first gives you an opportunity to review before any irreversible step.
Read safe approvals for operational guardrails and troubleshooting when a result is missing or denied.