get_project_topology

List a project's issue tree (epics → stories → tasks), level by level or a whole subtree. Without parent you get the top level: the epics and the stories / tasks without a parent, each with its status and child count (the first page also gives the project's totals per type and per status). Drill down: parent (an epic or story key such as ITR-3, or id) lists that item's children, one level, 50 a page (200 at most). To read a whole epic or story in one walk, pass parent with depth="all" (or subtree=true): every descendant, stories followed by their tasks, flattened in tree order, indented by depth, each with `parent KEY`; 200 nodes a page (500 at most). Filters (the filter arguments of search_issues, e.g. status, assignee, label, cycle, blocked; not the text search) show only what matches: an item is listed when it matches (`match`) or has a matching descendant (`context`, kept so that a match stays under its epic or story; its count says how many matching items sit below it); its child count is the number of children that match or lead to a match. The answer has the nodes (key, title, type, status key, blocked, children and done, parent in a subtree, match / inside with filters), `statuses` ({key: {name, category}}), the paging, the level, the parent, the links, and on the first top-level page the counts per type and status. Answers are compact JSON; pass format="text" for a readable Markdown answer. Results are paged: if the answer has a cursor, call again with it (a missing cursor means the last page) — never assume the first page is everything.

• 2026-10-05 — The week and committer filters of search_issues apply.
• 2026-10-05 — The cycle filter of search_issues applies.
• 2026-10-04 — The reviewer and review_state filters of search_issues apply.
• 2026-10-03 — Issue links touching the items of the page are listed (`Links touching these items`: A blocks B, A relates to B; the other end may be on another page or level) and in the json block's links array ({from, to, kind} by key; linksTruncated: true when more than 2000); a blocked issue's line says `· blocked`.
• 2026-10-02 — New optional query: free text or an issue key, matched as in search_issues (key / number, title, description); the items that match it and the way to them (their ancestors) are listed, marked `· match` / `· context`, with the totals of the filtered level.
• 2026-10-02 — Optional filters, the same as search_issues (status, type, priority, category, open, assignee, reporter, label, epic, story, subtasks, blocked, due, subscribed): a node is listed when it matches or has a matching descendant. Matching items are marked `· match`, the ones kept only as the way to a match `· context (N matching inside)`; the child count and the totals are those of the filtered level, and the json block has filtered, matching and context (keys of the page).
• 2026-10-02 — No longer returns the whole tree at once: it returns one level of it, page by page (new optional limit and cursor). Without parent: the epics and the stories / tasks without a parent, each with its child count; with parent (an epic or story key or id): that item's children. parent with depth="all" (or subtree=true) returns the whole subtree of that item, stories and tasks, flattened in tree order with indentation and parent references (200 per page, 500 at most). Totals per type and per status come with the first page of the top level. The result opens with a page header and ends with the next cursor or Last page.; the json block has the paging, the level (top, children or subtree) and the parent, not the nodes.
• 2026-10-02 — Progress counts the whole subtree: the text line of an epic or story says `N/M in the subtree` (done of ALL its descendants, every depth, unaffected by a filter) and each json node has desc_total, desc_done and desc_in_progress (started: in progress or review), left out when the item has no descendants; children / done still count the direct (filtered) children.
• 2026-10-02 — Answers are compact JSON by default (one document, no Markdown, nothing said twice); format="text" gives the readable Markdown without the json block. The nodes are in the document (they were in the text before): {key, title, type, status (key), blocked (only when true), children and done (counts), parent (a subtree only), match: true or inside: N for a context item (filters)}, with `statuses` ({key: {name, category}}), the project, the level, the parent, the counts per type and per status of the first page, and the links.
• 2026-10-03 — New optional ac_incomplete / dod_incomplete filters (true: only issues with unchecked acceptance criteria / definition of done items, in projects that have the list on).
• 2026-10-03 — Also answers structuredContent (see outputSchema); a failed call adds structuredContent.error. Text unchanged. Details: /docs/mcp, "Structured results and errors".
• 2026-10-04 — Claude Code 2.1.288+ (clientInfo claude-code): the text of a successful answer is itself up to 512 bytes, else "Result in structuredContent (N bytes)."; structuredContent and errors are unchanged. See /docs/mcp.
• 2026-10-04 — format="text" now also answers structuredContent {"text": the Markdown} (it was the JSON document), so a client that reads only structuredContent gets the Markdown it asked for.