Agiflow MCP server

other

Agiflow MCP server gives an agent structured access to Agiflow's hosted project board at the organization level, covering organizations, projects, work units, and tasks rather than a single project's kanban view alone. Where a lighter Agiflow connection might focus on moving individual tasks around, this server is built for scoped access across a team's broader structure, so requests respect who should see what within an organization before anything gets returned or changed. Neotask uses it to keep Agiflow as the actual system of record: nothing gets duplicated into a separate tracking document, and every change made through the agent lands back in Agiflow itself, visible to anyone who already has access to that project. That matters for teams managing more than one project under a shared organization, where access needs to stay scoped rather than open to everything at once regardless of who's asking or which project they normally work in. The result is an agent that can work across an organization's structure while respecting the same boundaries a person would have logging in directly, which keeps the integration safe to hand to more than one person on a team without worrying about who can see what. As an organization grows past a handful of projects, that scoping is what keeps the agent useful instead of becoming another place data quietly drifts out of sync.

What you can automate

list_organizationsReturns the organizations the connected account has access to. The starting point for any cross-project request.
list_projectsReturns projects within a given organization. Scoped to what the account is permitted to see.
manage_work_unitsCreates or updates work units within a project. Reflects the same structure as the hosted board itself.
manage_tasksCreates or updates tasks scoped to a specific project. Changes land back in Agiflow directly.
get_scoped_accessConfirms what an account can see or change within the organization structure. Useful before running a broader request.

Real workflows

coordinating work across several projects in one organization

A team lead manages three projects under the same Agiflow organization and wants a combined read on open work units before a planning session. She asks Neotask to pull work units across all three, and the agent queries the Agiflow MCP server using her scoped access. She gets one combined view instead of switching between three separate project boards and trying to hold the totals in her head. The planning session starts with an accurate picture instead of a rough guess pieced together from memory, and the team spends less time reconciling numbers before deciding what to prioritize.

keeping Agiflow as the single source of truth

A team that used to track some tasks in a spreadsheet decides to move everything back into Agiflow after losing track of what was current. Instead of re-entering old items by hand one at a time, they ask Neotask to create the missing tasks directly inside the relevant projects. Every item lands in Agiflow itself, so there's no separate document drifting out of sync with the board going forward. The spreadsheet gets archived once the migration is confirmed complete, and nobody has two places to check anymore, which quietly resolves an argument the team had been having for months.

Frequently asked questions

How is this different from a basic Agiflow connection?

This server works at the organization level, across projects and work units with scoped access, rather than being limited to a single project's board.

Does this create data outside of Agiflow?

No. Agiflow stays the system of record, and everything created or updated through the agent lands back in Agiflow itself.

Can access be limited to certain projects?

Yes, access is scoped, so requests respect what an account is actually permitted to see or change.

What counts as a work unit here?

Work units sit alongside tasks as a unit of work within a project, and both can be managed through this integration.

Is this suited to teams with more than one project?

Yes, the organization-level access is specifically built for coordinating across several projects at once rather than just one.

What happens if an account tries to reach a project it doesn't have access to?

The scoped access check limits results to what that account is actually permitted to see, so nothing outside its permissions comes back.

Does this integration handle comments and collaboration too?

Yes, since it works with the same hosted board, comments and other collaboration features remain part of how the team interacts with the work.

Does the scoped access ever need to be reconfigured as a team grows?

As new projects or organizations get added, access can be adjusted so the agent's reach keeps matching who's actually supposed to see each one.