Hey thanks for contribution. I want to highlight that this removes the resource response and regresses lots of improvements in the file handling (you don't get a proper mime type from the API for example). The file API is jst not the same.

We can look at adding more than one bit of response content adding an API call too (possibly with a param), and returning the SHA part of the response., I agree it is useful (the reasons you specify are real), but while you have been very focused on what you wanted to add, you have removed things that make the tool faster and more flexible for other use cases.

I will need to think about this a bit more, but it will not be able to merged in the current state.

Closing this PR in favor of a more comprehensive solution.

I've developed an improved approach that addresses the same issue (#595) but with better flexibility and performance:

New Approach:include_sha Parameter

Instead of always including metadata in the response, the new solution adds an optionalinclude_sha boolean parameter that allows users to explicitly choose between:

• Raw content (default): Fast retrieval via GitHub's Raw API
• File metadata: Complete file information including SHA, size, type via Contents API

Benefits over this PR

✅Better Performance: Only uses slower Contents API when metadata is explicitly requested
✅More Flexible: Users can choose exactly what they need
✅Backward Compatible: Default behavior remains unchanged
✅Complete Solution: Works for both files and directories

Usage Example

// Get file content (existing behavior)get_file_contents({owner:"user",repo:"repo",path:"file.md"})// Get file metadata including SHAget_file_contents({owner:"user",repo:"repo",path:"file.md",include_sha:true})

I'll be creating a new PR shortly with this enhanced solution. Thanks for the review and feedback on this approach!