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

Open
  • Is something wrong?
#3,588 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 2 days

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
github, go
Domain
api

Research direction

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.

Written by the indexing model from the issue text.

Description

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.

Dominant language
Go
Stars
34.2k
Forks
5.3k
Avg merge
5d 18h
Merged PRs (30d)
13

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from github/github-mcp-server

All issues in github/github-mcp-server

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.