get_file_contents tool should have non-base64 option

[ashwin-ant]

Describe the feature or problem you’d like to solve

The get_file_contents tool 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 corresponding create_or_update_file tool 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!

[bratorange]

+1

[Coffee-Boyy]

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

	var result interface{}
	if fileContent != nil {
	result = fileContent
	} else {
	result = dirContent
	}

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
}

[dijonkitchen]

Does having it in base64 also increase the token usage?

[rdmueller]

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.

[SamMorrowDrums]

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.