Add `update_repository` to the repos toolset (repository metadata: description, topics, visibility)
維護者通常 2 天內回覆
還沒有人認領這個 Issue。
評估
研究方向
Start by reading the existing repository tools and their registration, then inspect repositories_test.go and the translation keys mentioned in the issue. Compare the repository update and topics endpoints in the linked GitHub REST API docs, since topics require a separate request. Done means a single-repository update_repository tool updates only supplied fields and has tests for the metadata behavior.
由索引模型根據 Issue 內容生成。
描述
Describe the feature or problem you'd like to solve
An agent can create a repository (create_repository) but cannot change its metadata afterwards — description, homepage, topics, visibility, default branch, archived state or feature flags. In practice that means an agent scaffolds a repo with a placeholder description and no topics, then has no way to fix it without leaving the MCP surface.
The REST API supports this via PATCH /repos/{owner}/{repo}, and topics additionally need PUT /repos/{owner}/{repo}/topics.
Current state (verified 2026-10-26 against the hosted server https://api.githubcopilot.com/mcp/):
| configuration | tools | has an update-metadata tool? |
|---|---|---|
| default toolsets | 46 | no |
| all 15 toolsets enabled | 73 | no |
The closest existing tools are create_repository, fork_repository, create_or_update_file, push_files and delete_file — all creation/content operations, none metadata.
This was raised before as #449, which was closed as completed, but the linked PR #453 was closed without merging (merged: false, labelled stale), so the gap is still open today.
Proposed solution
One update_repository tool in the repos toolset. Only the fields the caller supplies are patched, so an omitted field can never be cleared by accident:
| param | type | notes |
|---|---|---|
owner |
string (required) | |
repo |
string (required) | |
description |
string | empty string clears it |
homepage |
string | |
topics |
string[] | needs a second request — see below |
visibility |
"public" | "private" |
high impact |
default_branch |
string | |
archived |
boolean | high impact |
has_issues / has_wiki / has_projects |
boolean |
Why topics needs its own call: PATCH /repos/{owner}/{repo} silently ignores a topics field; topics can only be replaced through the dedicated endpoint, and that endpoint is replace-all (not append). PR #453 covered name / description / default_branch / archived / allow_forking but not topics, homepage, visibility or feature flags — the two-endpoint behaviour is probably worth calling out in the design, since it is the part that is easy to get wrong.
Safety
The concern raised in #449 by @SamMorrowDrums was about bulk updates. This proposal is deliberately single-repository: no repos[] / org parameter, one call per repository, so an accidental call has the blast radius of one repo's metadata.
For the two high-impact fields I would suggest either documenting them as such, or splitting them behind the existing read-only/write split, rather than adding a new flag. Tool annotation readOnlyHint: false is appropriate.
Alternatives considered
- A generic passthrough (
github_api(method, path, body)): one tool, ~200 tokens of schema, covers every REST endpoint including this one. But it pushes API-shape knowledge into the model, loses per-endpoint validation, and makes the blast radius of a wrong call unbounded. Probably worth a separate discussion rather than folding it in here. - Client-side workarounds: what I do today — a local script calling the two endpoints directly. It works, but every client has to reimplement it and rediscover the topics quirk.
I'm happy to submit a PR along these lines (with toolset registration, tests in repositories_test.go, and translation keys) if the shape looks acceptable to you. If you would rather this not live in the main server at all, that is also a useful answer — I will stop re-proposing it.
- 主要語言
- Go
- 星號
- 34.2k
- 分支
- 5.3k
- 平均合併
- 5 天 18 小時
- 30 天內合併 PR
- 13
環境準備
- 提供 Dockerfile 或 Docker Compose 檔案
- 有 Pull Request 範本
- 閱讀貢獻指南
從這裡開始
- 先讀完整個 Issue，再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫，在一個分支上完成修改。
- 送出 Pull Request，並在描述裡引用這個 Issue 編號。
github/github-mcp-server 的其他 Issue
-
難度 2/5 1-3 小時 新手友好度 69/100
github/github-mcp-server#3760 ·
維護者通常 2 天內回覆
-
難度 2/5 1-3 小時 新手友好度 82/100
github/github-mcp-server#3758 ·
維護者通常 2 天內回覆
-
難度 2/5 1-3 小時 新手友好度 69/100
github/github-mcp-server#3729 ·
維護者通常 2 天內回覆
-
難度 2/5 1-3 小時 新手友好度 65/100
github/github-mcp-server#3722 ·
維護者通常 2 天內回覆
-
Insiders Feedback: PR created UI doesn't link to the PR可能已有人在做 @genius-0963 於 5 天前認領。 未關閉bug insiders user-experience
難度 2/5 1-3 小時 新手友好度 65/100
github/github-mcp-server#3658 ·
維護者通常 2 天內回覆
查看 github/github-mcp-server 的全部 Issue
相似的 Issue
-
bug
難度 2/5 1-3 小時 新手友好度 68/100
維護者通常 1 天內回覆
-
難度 1/5 1 小時以內 新手友好度 72/100
open-feature/flagd-schemas#237 ·
-
enhancement
難度 2/5 1-3 小時 新手友好度 72/100
superplanehq/superplane#9234 ·
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 65/100
betterleaks/betterleaks#469 ·
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 82/100
prime-radiant-inc/evener#5901 ·
維護者通常 1 天內回覆