Projects
Projects is where you plan and track work. A project is a place to put the work that belongs together: the items to do and the people doing them, the stretches of time you do them in and the conversation around them. A project does not tell you how to work. It holds the work, and you decide how it is done.
You open Projects from your workspace, and you can see a project as a board, a list or a timeline.
Topics
- What a project is: a project with its owner and its people, plus the programs and templates around it.
- Work items: the pieces of work in a project and what each one carries.
- Statuses: the columns of a board, named by you.
- Iterations: time boxes, and what happens to unfinished work when one closes.
- Tasks and milestones: the older, flat task list.
- Comments, activity and status updates: the conversation and the record around a project.
- Saved views, artifacts and research projects: views you return to, files you attach and research you tie in.
What you do in Projects on the site, a program can do over the API: create projects, add and move work items, keep statuses and iterations, leave comments, read the activity stream, search across projects and pull the triage list.
Projects, work items, statuses and iterations are under the project tag in the REST reference. Each has calls to list, create, read, change and remove, and a project has calls for its stream, its rollover and its search. Triage is one call across every project you can see.
Tasks are plain resources, with the same list, create, read, update and delete as any other table.
Over MCP, the projects tool group gives an agent a small set of tools: list projects, iterations and work items, update a work item, and add a comment or list the comments already there. An agent can read a board, move an item and leave a comment. It can do nothing else.
The full list of routes, with each one's parameters, body and responses, is the REST reference on the help site. The tools an agent gets are listed in the MCP reference.
A project is a place, not a process. Statuses, iterations and fields are things a project defines, not a workflow the platform enforces. That is why a status has a category: the board needs to know what "done" means without the platform deciding what "done" is called.
Activity is written, never worked out later. Each change writes its own record at the time it happens, so the stream can be replayed and the feed comes from one place.
A move changes one item. Ordering within a column uses fractional positions, so moving an item between two neighbours writes one change and never renumbers the rest.
Written by hand, not generated. Projects has a stream, triage, search and rollover, none of which a plain table can say on its own, so its routes are written by hand rather than generated from the tables. Tasks are the exception.