push_files takes ~70s per call (both success and fast-fail cases)

まず、エントリポイント push_files と、それが行う GitHub Git Trees および commit 操作を追跡します。7 ファイルの payload を認可失敗パスと成功パスの両方で再現し、約 70 秒の遅延がどこで発生するかを比較します。完了の条件は、遅延の原因が特定されて対処されているか、明確に診断されており、影響を受けるパスがカバレッジで網羅されていることです。

Describe the bug

push_files calls are consistently slow (~1m12s–1m13s) in our MCP flow, even when one call fails with authorization error and the next call succeeds with the same payload.

This suggests significant latency before/around final Git operations, not only at final commit update step.

Affected version

Using hosted/remote GitHub MCP server, version: github-mcp-server/remote-57ddf9ca0de2f61fc022ca3cff21efc81a65fc99 (observed on 2026-03-08 via initialize -> serverInfo.version)

Steps to reproduce the behavior

1. Call github.push_files with a payload of 7 files (Twig templates + one larger classes/Email.php) to:
   • repo: https://github.com/Sogl/grav-plugin-login
   • branch: https://github.com/Sogl/grav-plugin-login/tree/feature/multipart-emails
2. First call result:
   • Error: failed to create tree: POST https://api.github.com/repos/Sogl/grav-plugin-login/git/trees: 403 Resource not accessible by personal access token []
   • Client timing: Worked for 1m 12s
3. Fix PAT permissions and call github.push_files again with the same payload.
4. Second call result:
   • Success, ref updated to commit: https://github.com/Sogl/grav-plugin-login/commit/8be0cd10415515109476025379545999f52b87b0
   • Client timing: Worked for 1m 13s

Expected vs actual behavior

Expected:

• Latency in seconds for this payload size, or at least clear diagnostics if server-side queueing/throttling is involved.

Actual:

• Both failed and successful calls take ~70+ seconds with almost identical duration.

Logs

First call (failed, ~1m12s):

• failed to create tree: POST https://api.github.com/repos/Sogl/grav-plugin-login/git/trees: 403 Resource not accessible by personal access token []

Second call (success, ~1m13s):

• {"ref":"refs/heads/feature/multipart-emails", ... "sha":"8be0cd10415515109476025379545999f52b87b0"}

Request payload was the same large push_files body in both calls (7 files, full file contents).