Skip to content

Project management MCP

Can a coding agent read one task without getting the whole project board?

A useful agent-readable task system should offer a narrow, read-only path for one handoff and a separate workspace path for ongoing authorized work. The choice changes what the agent can discover, how long access lasts, and whether it can act.

Two access paths

Choose the credential by scope, not convenience

Suppose task #482 asks for CSV export from an invoice screen. A runner who needs only that prepared task should not receive ongoing workspace authority. A staff engineer who maintains the board from an agent may need the broader connection.
Task Handoff and MCP Workspace are separate credentials with separate authority.
Access questionTask Handoff credentialNamed MCP Workspace connection
Credentialtkp_read_…tkp_mcp_…
Discovery scopeThe exact active claim. If it was linked to a Story when access was issued, the agent may also follow that Story and its currently published linked tasks. It cannot browse the whole board.The connection owner’s currently authorized tickets, Drafts, Stories, Notes, people, and other exposed views in one Team.
WritesNone. The credential is read-only and cannot deliver or change the task.Only named MCP tools allowed by the same person’s current permissions. There is no generic database or status write.
LifetimeAt most seven days, and it stops when the exact claim ends. A fresh copy revokes the earlier read credential for that claim and runner.No automatic expiry. It stops on connection revocation, Team disablement, or loss of membership, and can be rotated by its owner.
Checks on useThe active claim, runner, issue time, and any captured Story relationship are checked again on reads.Connection status, Team MCP setting, membership, roles, effective permissions, and resource visibility are loaded again for each request.

Access model

Current authority, explicit actions, visible conflicts

Wagglet is an AI task handoff for teams with two deliberately different agent access modes. MCP Workspace is the ongoing mode: a named connection acts as one person in one Team, never as a second identity above that person.
  1. 01

    Recheck the person behind the connection

    Wagglet rechecks Team membership and permissions whenever an agent requests current task context through MCP. Revocation, Team disablement, membership removal, and role changes therefore affect the next request.

  2. 02

    Read the current record and revision

    The agent reads the authorized task before changing it. Private Drafts are visible only when the connection owner is the creator or a collaborator; everyone else receives no identifier, count, relation, or existence signal.

  3. 03

    Use a lifecycle action, not a status patch

    The MCP server exposes task commands with product rules and permission checks. It does not expose arbitrary SQL or a generic status setter.

  4. 04

    Fail visibly when the record moved

    Mutations carry the current revision and a fresh operation id. If another edit won first, the server returns STALE_REVISION; the agent must read again and reconcile instead of overwriting newer work.

claim_ticket
Claim an eligible Open task as the connection owner.
release_ticket
Release an authorized active claim back to Open.
deliver_ticket
File a delivery report for the owner’s active claim.
accept_ticket
Accept an independently reviewed delivery with owner or admin authority.
reject_delivery
Send a delivery back with required feedback while keeping the runner claimed.
reopen_ticket
Reject the standing delivery and return the task to Open for another claim.

The security boundary explains credential storage, revocation, attachment access, and the difference between authorization and delivery.

Privacy and limits

Agent-readable does not mean board-wide

The connection can use only the product views and actions its named owner may use now. It is not a standing exception to Team membership, task visibility, or lifecycle rules.
  • Human-only instructions stay out of agent views. Human-only tasks may expose safe planning metadata, but MCP hides the dormant agent prompt and Human instructions and cannot perform their reserved agent lifecycle actions.
  • Private Drafts remain private. Only their creator and collaborators can discover them through MCP; other connections receive no existence signal.
  • The supported clients are protocol clients. Claude Code, Codex, and Cursor can connect to the remote HTTP MCP endpoint with bearer authorization. The server applies the same Wagglet scope regardless of which client calls it.
  • Provider access never moves. No account, key, subscription, credit, token allowance, or token balance moves between people through either access path.

Who should not use this

Not for autonomous whole-board control

A team that wants an agent to autonomously browse and update the whole board will find this model restrictive by design. That restriction is the same property that keeps each request inside a named person’s current authority.

Choose a different architecture if an agent must hold independent workspace authority, bypass human approval policy, or write arbitrary records. Wagglet's MCP server is designed for human-supervised AI execution through explicit product actions.

Where to go next

Choose the workflow, then follow the setup guide

This page explains the architecture decision. The documentation pages contain the operational setup and runner procedure.