René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Reduce context usage for `projects_list` / `projects_get` project item responses","articleBody":"## Problem\n\nThe `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.\n\nEach project item response includes the full `content` object with:\n- Complete issue/PR body text\n- Full repository object (~2KB of URL templates)\n- Full user objects for author, assignee, milestone creator (~500B each)\n- Reaction URLs, label URLs, and other metadata\n\n**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.\n\nThe `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.\n\n## Usecase\n\nI 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. \n\n## What the useful data looks like\n\nFor project board operations, what's actually needed per item is:\n\n| Field | Example | Size |\n|-------|---------|------|\n| `item_id` | `146039219` | tiny |\n| `content.number` | `111` | tiny |\n| `content.title` | `\"Robust wallet management\"` | small |\n| `content.state` | `\"closed\"` | tiny |\n| `content.html_url` | `\"https://github.com/FilOzone/dealbot/issues/111\"` | small |\n| `content.assignees[].login` | `[\"rvagg\", \"SgtPooki\"]` | small |\n| `content.milestone.title` | `\"M4.1: mainnet ready\"` | small |\n| `content.repository.full_name` | `\"FilOzone/dealbot\"` | small |\n| Project fields | Status, Cycle, etc. | small |\n\nThis 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.\n\n## Suggested approach\n\nApply the same \"minimal type\" pattern used in #2023, #2025, and #2028 to the projects tools:\n\n1. Default to a minimal `content` representation (title, number, state, html_url, assignee logins, milestone title, repo full_name, labels)\n2. Omit the issue/PR `body`, full `repository` object, and expanded `user` objects by default\n3. Optionally, add a `minimal_output` parameter (like `search_repositories` already has) to let callers choose\n\n## Context\n\nThis 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.\n","author":{"url":"https://github.com/BigLep","@type":"Person","name":"BigLep"},"datePublished":"2026-04-24T16:42:22.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":1},"url":"https://github.com/2383/github-mcp-server/issues/2383"}