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

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/):

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:

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.