Use GitHub-signed commits for repository file write tools

create_or_update_file と push_files の実装から始め、既存の delete_file パスおよびその GitHub API の使用方法と比較します。GraphQL createCommitOnBranch を調査し、既存のツール入力とレスポンスの形式を維持します。対応している場合に書き込みによって GitHub で検証済みのコミットが生成され、プルリクエストが署名済みコミットの要件を満たせば完了です。

Summary

Repository write tools such as create_or_update_file and push_files can create unsigned commits. In repositories that require verified commit signatures, the MCP-created pull request is then blocked with:

Commits must have verified signatures.

Reproduction

1. Use the MCP server against a repository with a ruleset/branch protection rule requiring signed commits.
2. Create a branch.
3. Use create_or_update_file or push_files to write a commit.
4. Open a pull request.

Actual behavior

The commit can be reported by GitHub as verification.verified=false with verification.reason=unsigned, and the pull request cannot be merged while the signed-commit rule is active.

Expected behavior

Repository write tools should use a GitHub API path that can produce GitHub-verified commits when supported by the authenticated actor, so MCP-generated pull requests can satisfy signed-commit requirements without clients managing GPG or SSH signing keys.

Notes

I verified in an internal test repository that switching the file write to GraphQL createCommitOnBranch produced a commit with:

• verification.verified=true
• verification.reason=valid

The existing delete_file implementation already avoids the simpler REST contents deletion path because of commit signing behavior. The same issue can affect create/update and multi-file writes.

Proposed fix

Use GraphQL createCommitOnBranch for create_or_update_file and push_files, keeping the existing tool inputs and response shape as much as possible.