Repository navigation
get_file_contents tool should have non-base64 option #372
Description
Activity
+1
I seriously thought I was going crazy when gpt-4o-mini was making up example code after knowingly reading the file contents and I explicitly instructed it to reference code from the repo. Turns out this was the problem. Made a fix locally and it works as expected now.
For reference, I changed the following:
github-mcp-server/pkg/github/repositories.go
Lines 472 to 477 in 5634add
to:
var result interface{} if fileContent != nil { result, err = fileContent.GetContent() if err != nil { return nil, fmt.Errorf("failed to get file content: %w", err) } } else { result = dirContent }Does having it in base64 also increase the token usage?
Does having it in base64 also increase the token usage?
yes. The model has to write code in which it reproduces the base64 file. This code will then produce the original file. This is 3x token usage.
Reacted by JC (Jonathan Chen)- added a commit that references this issue
on Jun 10, 2025 Binary content is meant to be base64 encoded, and text content should not be. I have fixed this by using the raw API properly. It's been a TODO for me for ages, finally got round to it: #505
Things should be faster, and less brittle too.
Reacted by Koichi Okuda and Ralf D. MüllerReacted by JC (Jonathan Chen) and Jon Apgar
Describe the feature or problem you’d like to solve
The
get_file_contentstool currently returns file contents in base64. This matches the backing API, but it'd be nice to have a non-base64 option for this. The correspondingcreate_or_update_filetool accept plaintext, even though the backing API only allows base64.Proposed solution
This would create interface consistency and probably lead to better model performance with the tool.
Additional context
I'm happy to send a PR for this if there's a recommended approach I should take!