Skip to content

Enrich issue_read get with hierarchy relationship signals#2764

Draft
zwick wants to merge 1 commit into
mainfrom
zwick-enrich-issue-read-hierarchy
Draft

Enrich issue_read get with hierarchy relationship signals#2764
zwick wants to merge 1 commit into
mainfrom
zwick-enrich-issue-read-hierarchy

Conversation

@zwick

@zwick zwick commented Jun 24, 2026

Copy link
Copy Markdown
Contributor

Summary

Enrich the issue_read get payload with layered hierarchy relationship signals, derived from a single combined GraphQL round-trip (no added round-trips on get).

Why

The default get payload surfaced no relationship data, so an agent calling the most obvious tool got zero hierarchy signal and had to drop to raw REST (parent_issue_url) or scan sibling sub-issues. This also addresses the #2726 review note asking for cheap has_parent / has_children routing booleans as a follow-up.

Refs github/planning-tracking#3306

What changed

  • issue_read get now returns has_parent / has_children (always emitted), plus parent (compact ref: number/title/state/url/repository, mirroring get_parent) and sub_issues_summary (total/completed/percent_completed) when those relationships exist.
  • Replaced the single-issue field-values GraphQL call with one combined query (fetchIssueReadEnrichment) returning field values + parent + subIssuesSummary.
  • Best-effort enrichment: a query failure still returns the base issue and never fails get.
  • Parent title is sanitized (may be cross-repo) and redacted under lockdown mode unless the parent content is verified safe; counts/booleans are always emitted.
  • get_parent / sub_issue_write behavior unchanged; tool descriptions clarify hierarchy is read here but written via sub_issue_write.

MCP impact

  • Tool schema or behavior changed — issue_read get response gains hierarchy fields; issue_read and sub_issue_write method descriptions updated.

Prompts tested (tool changes only)

  • "Read issue #2990 in github/github-mcp-server" — expect has_parent: true and parent (#2820) without raw REST / sibling scanning. Covered by unit tests; live MCP verification noted as a manual follow-up.

Security / limits

  • Data exposure, filtering, or token/size limits considered — parent titles are sanitized and redacted under lockdown mode when the (possibly cross-repo) parent content cannot be verified as safe; numeric/structural fields stay intact.

Tool renaming

  • I am not renaming tools as part of this PR

Lint & tests

  • Linted locally with ./script/lint
  • Tested locally with ./script/test

Docs

  • Updated (README / docs / examples)

The default issue_read `get` payload surfaced no hierarchy data, forcing
agents to drop to raw REST (parent_issue_url) or scan sibling sub_issues
to discover relationships. Enrich `get` with a layered, zero-extra-round-trip
relationship signal derived from a single combined GraphQL query:

- has_parent / has_children: cheap, always-emitted routing booleans
  (addresses Sam Morrow's #2726 review note).
- parent: compact ref (number/title/state/url/repository) mirroring the
  existing get_parent payload keys; omitted when there is no parent.
- sub_issues_summary: native subIssuesSummary counts (total/completed/
  percent_completed); omitted when there are no sub-issues.

The single-issue field-values GraphQL call in GetIssue is replaced by one
combined query (fetchIssueReadEnrichment) returning field values + parent +
subIssuesSummary, so `get` adds no round-trips. Enrichment is best-effort:
a query failure still returns the base issue and never fails `get`. Parent
titles are sanitized (parent may be cross-repo) and redacted under lockdown
mode unless the parent content can be verified as safe; numeric/structural
fields and counts stay intact. get_parent / sub_issue_write behavior is
unchanged; tool descriptions clarify hierarchy is read here but written via
sub_issue_write (no writable parent field).

Refs github/planning-tracking#3306

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant