Limit response size for github_list_releases tool to prevent context overruns
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 52/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- typescript
Research direction
Start in packages/github/src/tools.ts around line 928 at the github_list_releases definition. Reproduce the large response with include_body_and_assets enabled, then trace how per_page, release bodies, and assets are mapped. Done means responses stay within the agreed limits and clearly indicate when data was truncated.
Written by the indexing model from the issue text.
Description
Problem
The github_list_releases tool can return excessively large responses that cause the model to exceed context limits, resulting in "Input is too long for requested model" errors in brand new chats.
Root Cause Analysis
When fetching releases with include_body_and_assets: true, the tool returns massive amounts of data. Testing with coder/coder:
- 5 releases with bodies and assets = ~38KB of JSON
- Each release has ~24 assets (download URLs, sizes, counts, etc.)
- Release bodies can be ~1KB each (full changelogs)
- Requesting 100 releases with full data could exceed 500KB+
The tool implementation at packages/github/src/tools.ts (line ~928) passes data through without any size limits:
list_releases: toolWithOctokit(({ octokit }) =>
tool({
inputSchema: z.object({
owner: z.string(),
repo: z.string(),
page: z.number(),
per_page: z.number(), // No max limit!
include_body_and_assets: z.boolean(),
}),
execute: async (args, opts) => {
// ...
return {
releases: response.data.map((release) => ({
// Full body returned, no truncation
body: args.include_body_and_assets
? (release.body ?? undefined)
: undefined,
// ALL assets returned
assets: args.include_body_and_assets
? release.assets.map((asset) => ({ ... }))
: undefined,
})),
};
},
})
),
Proposed Solution
Modify the tool in packages/github/src/tools.ts:
- Cap
per_pageto a reasonable max (e.g., 10 releases) - Truncate release bodies to ~500-1000 chars with a
[truncated]indicator - Limit assets per release to 5-10 most relevant ones
- Add response size indicator so the model knows data was limited
list_releases: toolWithOctokit(({ octokit }) =>
tool({
inputSchema: z.object({
owner: z.string(),
repo: z.string(),
page: z.number(),
per_page: z.number().max(10), // Hard cap
include_body_and_assets: z.boolean(),
}),
execute: async (args, opts) => {
const MAX_BODY_LENGTH = 500;
const MAX_ASSETS = 5;
const response = await (await octokit()).request(...);
return {
releases: response.data.map((release) => ({
// ...
body: args.include_body_and_assets && release.body
? release.body.length > MAX_BODY_LENGTH
? release.body.slice(0, MAX_BODY_LENGTH) + '... [truncated]'
: release.body
: undefined,
assets: args.include_body_and_assets
? release.assets.slice(0, MAX_ASSETS).map((asset) => ({ ... }))
: undefined,
total_assets: release.assets.length, // Let model know if more exist
})),
_truncated: true, // Signal that limits were applied
};
},
})
),
Related Context
This affects the Blink agent (coder/agents) which uses github.tools directly. The fix should be in the SDK (coder/blink) since that's where the tool is defined.
- Dominant language
- TypeScript
- Stars
- 165
- Forks
- 20
- Avg merge
- 24m
- Merged PRs (30d)
- 1
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from coder/blink
-
Difficulty 5/5 Over a week Newbie friendliness 30/100
-
Difficulty 4/5 3-5 days Newbie friendliness 38/100
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
-
GitHub tools `list_user_installations` and `list_app_installations` fail with app installation authOpen
Difficulty 4/5 3-5 days Newbie friendliness 42/100
-
Difficulty 5/5 Over a week Newbie friendliness 30/100
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
CopilotKit/openmuse#215 ·
Maintainers usually reply within 3 days
-
b:minor bug
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
software-mansion/argent#1698 ·
Maintainers usually reply within 1 day
-
e2e-failure ready-to-code
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
redhat-developer/rhdh-plugin-export-overlays#4624 · 1 comment ·
Maintainers usually reply within 1 day