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

Đang mở
  • Có gì không ổn?
#3,588 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 2 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
48/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
github, go
Lĩnh vực
api

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Go
Star
34.2k
Fork
5.3k
Merge trung bình
5 ngày 18 giờ
Pull request đã merge (30 ngày)
13

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của github/github-mcp-server

Tất cả issue của github/github-mcp-server

Issue tương tự

Thêm issue về Go

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.