The question that actually matters
When an engineer asks to connect Claude Code or Cursor to the project board over MCP, the question a manager should ask isn't "can the AI see our data." It's narrower and more useful: what does it need permission for, and does someone still have to say yes to the things that matter?
WKFGo's MCP server exposes roughly 55 tools — tasks, git, wiki, finance, decisions, reports, and more — to any connected agent. That sounds broad. What keeps it safe isn't a smaller tool list; it's what each tool checks before it runs.
The access boundary is the same one humans already have
Every MCP call runs through the authenticated user's own feature_accesses — the identical permission system that gates the web app. An agent connected with a read-scoped API key can query tasks and reports but can't create or edit anything. An agent connected with a personal key inherits exactly that person's project roles, nothing more. There's no separate, more permissive "AI mode" — if a tool would be forbidden to the human in the browser, it's forbidden to their agent over MCP too, and the server says exactly which access is missing rather than failing silently.
The parts that require a human, structurally
Two gates exist specifically because completing work and committing code are decisions a person should make, not a side effect of an agent finishing fast:
An AI agent identity can never mark its own work done. mark_done called by an agent account routes automatically to submit_for_review instead — the task sits in a review queue until a human approves it. This isn't a setting; it's how the tool is built.
Nothing gets written or committed without being asked first. As of this release, the three tools that close out work — mark_done, submit_for_review, end_work — carry structured prompts back to the agent: ask whether to publish a wiki page, ask whether to commit and push, ask whether to link a commit to the task. The agent's instructions are explicit that these are questions, not actions — see the mechanism in detail.
What this means for a rollout
Start with read-scoped keys for anyone experimenting. They can orient, search, and pull context without being able to change anything — a safe way to let someone try MCP before deciding on write access.
Write access follows existing project roles, so there's nothing new to configure per-agent. If someone already has EDITOR on a project, their connected agent does too — and no more.
Merging is gated separately and explicitly. merge_pr requires its own GIT_COMMIT grant beyond general write access — org membership and a write-scope key alone aren't enough to push code through an agent.
What still deserves human attention
Access control answers "is this agent allowed to." It doesn't answer "should this specific change happen" — that's still code review, same as any other pull request, whether the diff came from a person or an agent. The review queue an agent's work lands in isn't a formality to route around; it's where the judgment call still belongs.
FAQ
Does connecting MCP give an AI agent more access than the person who set it up?
No — it inherits exactly that person's feature_accesses. It can't see or do anything they can't.
Can an agent complete a task without any human involved?
Not through mark_done as an agent identity — that path always routes to review. A human key calling mark_done directly is a different case, since that's a person acting through the tool, not an autonomous agent.
What if I only want the agent to read, never write? Issue a read-scoped API key. Every write tool checks scope before checking anything else and refuses outright.
Does the "ask before writing" behavior apply to every tool, or just docs and git?
It's specific to the wrap-up point of task work — mark_done, submit_for_review, end_work — where documentation and commits naturally come up. Other write tools (creating a task, updating status) are direct actions a connected agent takes when asked to, the same as any tool call.
Bottom line
The right way to evaluate MCP isn't "how much can it see" — it's "what happens at the boundary." WKFGo's answer: the same access rules as the browser, a mandatory human review gate on completion, and a structured ask — not an assumption — before anything gets documented or committed.