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

Abierto
  • ¿Algo no está bien?
#3,588 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
github, go
Área
api

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Go
Estrellas
34.2k
Forks
5.3k
Merge medio
5 d 18 h
PR fusionados (30 d)
13

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de github/github-mcp-server

Todos los issues de github/github-mcp-server

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.