Add `update_repository` to the repos toolset (repository metadata: description, topics, visibility)

未关闭
  • 哪里不对？
#3,588 1 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 2 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
48/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
活跃
技术栈
github, go
领域
api

调研方向

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

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

github/github-mcp-server 的其他 Issue

查看 github/github-mcp-server 的全部 Issue

相似的 Issue

更多 Go Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。