Graduated from docs/kit-friction-log.md (2026-07-28, fourth session). Severity L.
What happened
session-start's tracker step called the GitHub MCP list_issues for this repo's open issues. At
68 open issues the response was ~177,000 characters — over the tool-result limit. It had to
be re-read from a spill file and field-filtered by hand before the briefing could be assembled.
Why the existing warning does not help
The workflow already anticipates this: it warns that a naive "dump everything" call overflows, and
prescribes a field-limited call instead. On this backend that prescription cannot be
followed — the GitHub-Issues MCP tool exposes no field-selection parameter. The remedy is
written for a backend whose client supports it (Linear-shaped), and this repo's own tracker is the
one where it does not.
So the workflow's guidance is correct in general and inert here, which is the worst combination:
the operator follows it, it does nothing, and the call still overflows.
Proposed fix
Give the tracker step a backend-specific note for GitHub-Issues-over-MCP:
- page at
perPage: 25 rather than requesting everything at once, and
- read only
number, title, labels, state — dropping the body, which is what carries the
bulk of the 177k.
More generally: where a workflow prescribes a remedy that depends on a client capability, the
remedy belongs next to the backend that supports it, with the fallback named for the ones that do
not.
Related
#121 (this repo's tracker: config still names the wrong backend, which is why the
GitHub-Issues path is under-exercised in the first place).
Graduated from
docs/kit-friction-log.md(2026-07-28, fourth session). Severity L.What happened
session-start's tracker step called the GitHub MCPlist_issuesfor this repo's open issues. At68 open issues the response was ~177,000 characters — over the tool-result limit. It had to
be re-read from a spill file and field-filtered by hand before the briefing could be assembled.
Why the existing warning does not help
The workflow already anticipates this: it warns that a naive "dump everything" call overflows, and
prescribes a field-limited call instead. On this backend that prescription cannot be
followed — the GitHub-Issues MCP tool exposes no field-selection parameter. The remedy is
written for a backend whose client supports it (Linear-shaped), and this repo's own tracker is the
one where it does not.
So the workflow's guidance is correct in general and inert here, which is the worst combination:
the operator follows it, it does nothing, and the call still overflows.
Proposed fix
Give the tracker step a backend-specific note for GitHub-Issues-over-MCP:
perPage: 25rather than requesting everything at once, andnumber,title,labels,state— dropping the body, which is what carries thebulk of the 177k.
More generally: where a workflow prescribes a remedy that depends on a client capability, the
remedy belongs next to the backend that supports it, with the fallback named for the ones that do
not.
Related
#121 (this repo's
tracker:config still names the wrong backend, which is why theGitHub-Issues path is under-exercised in the first place).