Problem
The projects_list and projects_get tools return extremely large payloads when fetching project items, making them impractical for LLM-based workflows that need to operate within context window limits.
Each project item response includes the full content object with:
- Complete issue/PR body text
- Full repository object (~2KB of URL templates)
- Full user objects for author, assignee, milestone creator (~500B each)
- Reaction URLs, label URLs, and other metadata
Measured impact: A single project item response is easily ~8KB+. A list_project_items call returning 50 items (max per_page) produces ~400KB / ~100K tokens — roughly half of a typical LLM context window. At 100 items across two pages, the response consumes the entire context window.
The fields parameter controls which project fields (Status, Cycle, etc.) are included, but there is no way to suppress or reduce the content object that dominates the response size.
Usecase
I want to be able to take programatic action across my project board (e.g., get me all items that have been updated in the last week). I want to be manipulating them with the same level of information at the project board UI layer, not with a bunch of extra content (e.g.,, issue/PR body). I'll fetch those explicitly if I need them.
What the useful data looks like
For project board operations, what's actually needed per item is:
| Field |
Example |
Size |
item_id |
146039219 |
tiny |
content.number |
111 |
tiny |
content.title |
"Robust wallet management" |
small |
content.state |
"closed" |
tiny |
content.html_url |
"https://github.com/FilOzone/dealbot/issues/111" |
small |
content.assignees[].login |
["rvagg", "SgtPooki"] |
small |
content.milestone.title |
"M4.1: mainnet ready" |
small |
content.repository.full_name |
"FilOzone/dealbot" |
small |
| Project fields |
Status, Cycle, etc. |
small |
This is ~200-300 bytes per item. The other ~7.5KB per item (issue body, full repo object, full user objects with all URL templates) is rarely needed for project board workflows.
Suggested approach
Apply the same "minimal type" pattern used in #2023, #2025, and #2028 to the projects tools:
- Default to a minimal
content representation (title, number, state, html_url, assignee logins, milestone title, repo full_name, labels)
- Omit the issue/PR
body, full repository object, and expanded user objects by default
- Optionally, add a
minimal_output parameter (like search_repositories already has) to let callers choose
Context
This is the same class of problem reported in #142 for list_commits (5-6KB per commit) and discussed in #181 (response trimming). The recent fixes for issue_read (#2023), issue comments (#2025), and create_or_update_file (#2028) show the pattern works well — applying it to the projects tools would make them viable for LLM workflows that query project boards with dozens or hundreds of items.
Problem
The
projects_listandprojects_gettools return extremely large payloads when fetching project items, making them impractical for LLM-based workflows that need to operate within context window limits.Each project item response includes the full
contentobject with:Measured impact: A single project item response is easily ~8KB+. A
list_project_itemscall returning 50 items (maxper_page) produces ~400KB / ~100K tokens — roughly half of a typical LLM context window. At 100 items across two pages, the response consumes the entire context window.The
fieldsparameter controls which project fields (Status, Cycle, etc.) are included, but there is no way to suppress or reduce thecontentobject that dominates the response size.Usecase
I want to be able to take programatic action across my project board (e.g., get me all items that have been updated in the last week). I want to be manipulating them with the same level of information at the project board UI layer, not with a bunch of extra content (e.g.,, issue/PR body). I'll fetch those explicitly if I need them.
What the useful data looks like
For project board operations, what's actually needed per item is:
item_id146039219content.number111content.title"Robust wallet management"content.state"closed"content.html_url"https://github.com/FilOzone/dealbot/issues/111"content.assignees[].login["rvagg", "SgtPooki"]content.milestone.title"M4.1: mainnet ready"content.repository.full_name"FilOzone/dealbot"This is ~200-300 bytes per item. The other ~7.5KB per item (issue body, full repo object, full user objects with all URL templates) is rarely needed for project board workflows.
Suggested approach
Apply the same "minimal type" pattern used in #2023, #2025, and #2028 to the projects tools:
contentrepresentation (title, number, state, html_url, assignee logins, milestone title, repo full_name, labels)body, fullrepositoryobject, and expandeduserobjects by defaultminimal_outputparameter (likesearch_repositoriesalready has) to let callers chooseContext
This is the same class of problem reported in #142 for
list_commits(5-6KB per commit) and discussed in #181 (response trimming). The recent fixes forissue_read(#2023), issue comments (#2025), andcreate_or_update_file(#2028) show the pattern works well — applying it to the projects tools would make them viable for LLM workflows that query project boards with dozens or hundreds of items.