The get_file_contents tool does not return the SHA hash of the file, which is essential for updating files using create_or_update_file.

Description

When calling the github.get_file_contents tool, the response object does not include the sha field for the requested file. The official GitHub REST API documentation for the GET /repos/{owner}/{repo}/contents/{path} endpoint confirms that the sha is expected in the response.

This omission prevents the direct use of the github.create_or_update_file tool, as it requires the blob's SHA for any update operation.

Expected Behavior

The response from get_file_contents should include the file's SHA hash, consistent with the GitHub API.

{
  "type": "file",
  "encoding": "base64",
  "size": 5362,
  "name": "file.txt",
  "path": "path/to/file.txt",
  "content": "...",
  "sha": "b23e37d327d520337de2f7a1a4a4b49435b37699" 
}

Current Behavior

The sha field is missing from the tool's response.

Workaround

A functional workaround has been identified:

1. Delete the target file using github.delete_file (which does not require a SHA).
2. Recreate the file at the same path using github.create_or_update_file with the updated content. This is treated as a new file creation, thus not requiring a SHA.

While effective, this workaround is suboptimal.

Suspected Cause

The server-side implementation of the get_file_contents tool likely fails to parse or include the sha field from the GitHub API response before sending it to the client agent.