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.