Skip to main content
Glama
TanNhatCMS

github-binary-mcp

by TanNhatCMS
README.md
# github-binary-mcp

MCP server riêng (stdio, Node zero-dependency) để push file nhị phân lên
GitHub — vá đúng chỗ tool GitHub chính thức thiếu: tool gốc chỉ nhận text
và tự base64, nên ảnh gửi qua đó thành chuỗi base64 chứ không phải ảnh.
Server này nhận `content_base64` và chuyển nguyên văn cho GitHub API.

## Tools

- `push_binary_file` — 1 file nhị phân (Contents API).
- `push_binary_files` — tối đa 20 file trong 1 commit (Git Data API).
- `get_binary_file` — đọc file về dạng base64.
- `delete_file` — xoá file trong phạm vi cho phép.

## Cơ chế bảo mật (fail-closed)

- Token GitHub chỉ lấy từ env `GITHUB_TOKEN`. Không log, không trả về
  trong kết quả tool, không xuất hiện trong thông báo lỗi.
- Allowlist repo `GITHUB_BINARY_ALLOWED_REPOS` (dạng `owner/repo`, cách nhau
  bằng dấu phẩy). Không đặt biến này = từ chối mọi push.
- Allowlist đường dẫn `GITHUB_BINARY_ALLOWED_PATHS` (mặc định:
  `assets/,public/,docs/,static/,images/`). File ngoài các tiền tố này bị từ chối.
- Denylist luôn thắng: `.github/workflows/`, `.git/`, `*.env*`, `*.pem`,
  `*.key`, tên chứa `credentials` hoặc `secret`. Chặn leo thư mục `..`.
- Chặn file thực thi: exe, dll, so, dylib, bat, com, scr, msi, appimage, deb, rpm.
- Base64 phải hợp lệ và round-trip đúng, nếu không từ chối trước khi gọi API.
- Audit log: 1 dòng JSON mỗi lần gọi (tool, repo, path, size, sha, ok/error),
  ra stderr. Không ghi content, không ghi token.

## Giới hạn

- 10 MB mỗi file (sau giải mã), 50 MB mỗi commit nhiều file, tối đa 20 file/commit.
- 30 lần ghi/xoá mỗi giờ (rolling window, theo process). Đọc không giới hạn.
- Không bypass branch protection: nếu nhánh bị bảo vệ, GitHub API tự từ chối.

## Chạy và kiểm thử

```sh
GITHUB_BINARY_MOCK=1 node test.mjs   # 14/14 pass, không chạm mạng
GITHUB_TOKEN=... GITHUB_BINARY_ALLOWED_REPOS=TanNhatCMS/dia-nguc-live node server.mjs
```

Mock mode (`GITHUB_BINARY_MOCK=1`) luôn thắng và mọi kết quả đều gắn
`mock:true`, không bao giờ nhầm thành push thật.

## Triển khai lên gateway (chưa làm — cần chốt)

1. Tạo token GitHub cho server này (fine-grained, chỉ các repo trong allowlist,
   quyền Contents: Read and write).
2. Đặt server lên flex (STDIO) hoặc đóng gói chạy HTTP, đăng ký vào MetaMCP
   gateway, gắn vào namespace Public với tool policy allowlist.
3. Kiểm thử push thật lên 1 repo thử trước khi mở allowlist cho repo chính.

Trạng thái hiện tại: code + test mock xong, đã push lên GitHub tại
https://github.com/TanNhatCMS/github-binary-mcp. Chưa triển khai lên flex,
chưa có token thật, chưa kiểm thử push thật.

TDQS

B3.3/5.0

Scored across 4 tools

Disambiguation4/5

Each tool targets a distinct action (push single, push batch, read, delete) and the descriptions clearly separate the single-file path (verbatim base64) from the multi-file commit path. The only mild overlap is push_binary_file vs push_binary_files, since a single file could plausibly go through either, but the cardinality and API mechanism differences are stated explicitly.

Naming Consistency4/5

All four names are snake_case verb_noun and follow the same shape (push_binary_file(s), get_binary_file, delete_file). The only deviation is that delete_file and get_binary_file drop the 'push_' prefix while delete_file also omits 'binary', but the pattern remains predictable and readable.

Tool Count4/5

Four tools is a tight, purposeful surface for a narrowly scoped binary-file server, and each one maps to a real operation. The single vs batch push pair is arguably a slight over-split of one capability, keeping it just under a perfect score.

Completeness3/5

Create/overwrite, read, and delete are covered, but there is no listing or path-discovery tool, so an agent must already know exact repo paths. GitHub's content API also requires a blob SHA to delete or update an existing file, and nothing states that get_binary_file returns one, leaving a likely dead end for delete/overwrite workflows.

Maintenance

ActivityMaintained
ResponsivenessNo issues