app.ganty/mcp-server

list_workspaces

Get all workspaces the authenticated user is a member of.

No parameters.

list_projects

List all projects in a workspace (excluding archived).

create_project

Create a new project in a workspace. Returns the created project. Subject to plan-based project count limits.

delete_project

Permanently delete a project. All tasks, milestones, and dependencies inside the project are also removed. This cannot be undone.

list_tasks

List tasks in a project. Supports optional filtering by name (search), status, and assignee.

get_task

Get detailed information about a single task, including assignees and dependencies.

list_milestones

List milestones in a project (key dates such as launch or review gates).

create_milestone

Add a milestone (key date) to a project.

create_task

Create a new task in a project. Dates must be in YYYY-MM-DD format. End date is exclusive (a 1-day task has end = start + 1 day).

update_task

Update fields of an existing task. Only provided fields will be modified.

set_task_progress

Update the progress percentage of a task (0-100). Status is auto-derived: 0=not_started, 1-99=in_progress, 100=done.

add_dependency

Add a finish-to-start dependency between two tasks in the same project.

delete_task

Delete a task. Child tasks and dependencies are removed as well.

get_critical_path

Calculate the critical path of a project on the Ganty side and return it as data (don't ask the model to reason over raw task lists). Uses forward/backward CPM with progress-aware remaining duration. Returns critical_path tasks in order, per-task earliest/latest start/finish + slack, project_end_date, and total_duration_days. v1 limitations: Finish-to-Start dependencies only (Ganty has no other types), calendar days by default (business_days=true skips Sat/Sun but no holiday table), ignores multi-period segments, no resource calendars. Returns { error: 'cyclic_dependency', cycle } if a cycle is detected.

reschedule_and_propagate

Compute the downstream impact of shifting a single task. Default is dry_run (no DB writes); set mode='commit' to actually persist the changes. Cascades forward only (no pull): successors are pushed only if their predecessor's new end + lag would violate their current start. Tasks with progress=100 are treated as pinned; pass pinned_task_ids for additional pins. When a pin would be violated, the change is recorded in 'conflicts' and not propagated further. In mode='commit', if any conflicts exist nothing is written (all-or-nothing transaction). Same v1 limitations as get_critical_path: FS only, calendar days by default, no holiday table, ignores multi-period segments.