The question every MCP setup eventually raises
Once an IDE or CLI agent is connected over MCP — Claude Code, Cursor, Windsurf, Codex — the next question is always "what can it actually do?" Not in the abstract ("project management stuff") but as a concrete list someone can audit before trusting an agent with write access to real tasks. /api-docs is that list, grouped by what a session actually needs at each stage, not dumped as one alphabetical wall of names.
Orientation first — an agent has to know where it is
Before an agent can act, it needs the shape of the workspace: list_projects, list_columns, list_sprints, list_epics, list_users, list_teams, plus smart_search and search_people for finding things by name instead of ID. This group answers "what exists here" — the questions a new human hire would also ask on day one, just answerable in one tool call instead of a tour.
Reading tasks vs. writing to them — a real boundary, not a formality
The catalog splits task tools into two groups on purpose. Reads — list_tasks, my_queue, get_task, search_tasks, get_context_pack, get_comments, list_attachments — are safe to let an agent call freely; they can't damage anything. Writes — create_task, update_status, update_progress, add_todo, create_comment, assign_task, add_dependency, set_labels — each carry their own FeatureAccess requirement (taskAddEdit, taskMove, taskViewManage, and so on), the exact same permission checks a human clicking the same button in the web UI would hit. An agent's wk_ key inherits its holder's actual project role; it doesn't get a shortcut around access control just because a model is the one calling the tool.
Session and context tools — what makes the agent loop actually work
get_context_pack deserves its own mention beyond "it's a read tool" — it's the one call that bundles acceptance criteria, related wiki pages, and dependencies into a single response, which is what lets an agent start a task with real constraints instead of a bare title. Paired with session tools like start_work, end_work, and log_time, this is the backbone of the loop described in the Cursor MCP guide: orient, get context, do the work, log time, submit for review.
The groups that only some keys can reach
Finance, reports, calendar, and admin tools exist in the same catalog but behind their own FeatureAccess gates — a key without finance permission gets forbidden on finance tools exactly as a contractor's web login would, not a partial or fuzzy response. Planning tools (sprint and epic operations) and docs/support tools (wiki search, form and knowledge-base access) round out the catalog for agents doing more than task-level work — sprint planning assistance, or answering a question by searching the team's own wiki instead of guessing.
Prompts and code examples, not just a tool list
The docs page also ships ready-to-use prompts per workflow stage and copy-pasteable code examples for calling tools directly, not just through a chat panel — useful for anyone building a custom integration or a scripted agent rather than using an off-the-shelf IDE client.
Common mistakes
Assuming the tool list is the same as the tool's actual access. The catalog shows every tool that exists; what a given key can call depends entirely on that key holder's FeatureAccess. Two developers with different project roles see the same catalog but get different results from the same tool call.
Granting a broad admin key to an agent "to avoid permission errors." This defeats the purpose of FeatureAccess entirely — a forbidden response is useful signal ("this needs a permission fix"), not a bug to route around with a wider key.
Treating write tools as equally safe to call speculatively. A read tool called with a wrong ID returns nothing useful. A write tool called with a wrong ID updates the wrong task. Confirm IDs from a read call before writing, every time.
FAQ
Is the tool catalog the same regardless of which MCP client connects?
Yes — the same /api/mcp endpoint and tool set serves Claude Code, Cursor, Windsurf, Gemini CLI, and Codex; only each client's config file format differs.
Does a new tool require a new API version or a client update? No — tools are discovered by the MCP client at connection time, so the catalog page and the live tool list stay in sync without a separate client release.
Where do I find the exact request shape for a specific tool? /api-docs lists each tool's arguments and required access level per group, plus runnable code examples.