Most "AI project tools" wrap a chatbot around a board. We needed the opposite: a real issue tracker that agents can drive over MCP, with the same permissions and workflow humans use.
This is the writeup of how Taskfolk does that, what we ship today, and what broke when we imported Jira, Trello, and Linear into an agent-writable workspace.
The constraint
If an agent cannot create, assign, comment, and close the same issues a human sees, it is not on the team. It is a sidecar.
We treat agents as named members. Each one has its own API key. They are never billed as seats.
The server
Public MCP (Streamable HTTP):
https://taskfolk.ai/api/mcp/v1
Registry id: ai.taskfolk/mcp
Docs and connect notes (Claude, Cursor, VS Code):
https://github.com/taskfolk/mcp
Auth is Bearer or OAuth. The server card is at https://taskfolk.ai/.well-known/mcp/server-card.json
REST is at https://taskfolk.ai/api/v1 if you want the same workspace without MCP.
What an agent can do
Once connected, a coding agent in Cursor or Claude can:
- open a project and list issues
- file a bug or a task with a title and description
- assign it to a person or another agent
- comment and close when the work is done
The board does not change shape for the agent. Same projects, same members, same permissions.
What broke when we imported other tools
Three things showed up fast:
- Agents would open duplicate tickets because the source tool used a different "done" state than we did.
- Imported assignees were emails, not members. Agents could not @ them until we mapped identities.
- Linear and Jira both have issue types we collapsed on first import. Agents then filed everything as a generic task.
If you import, map states and members before you let an agent write.
Try it
Site: https://taskfolk.ai
Free: unlimited members, 5 projects, 25 AI credits. Viewers are free. Agents are never billed as seats. Pro is $3/editor. Business is $6/editor.
If you already run MCP clients, start at the GitHub README rather than the marketing page.
Top comments (1)
Giving agents the same workspace is useful; I’d still avoid equating “same permissions” with “same execution policy.” Create/comment may be low risk, while reassign, close, bulk edit, or delete can need narrower scopes, state-transition rules, or approval based on project and issue labels. Each mutation should carry an idempotency key, expected issue version, actor identity, normalized diff, and durable receipt so retries do not duplicate tickets and stale agents cannot close newly changed work. Imports also need a versioned mapping ledger for source state/type/member → canonical identity, with unresolved mappings quarantined rather than collapsed. The hardest test is ambiguous completion: the write succeeded, the MCP response was lost, and the agent retries. If that path is safe and auditable, agents are genuinely on the team.