Files
holocron/plugins/gitea/.apm/skills/gitea-labels-milestones/references/labels.md
Defame1297 37382cb72a refactor(gitea-labels-milestones): retrofit to the ADR-0020 context contract
Description 835 -> 214 chars, body 669 -> 426 words, Gotchas 8 entries/63% of
body -> 3/20.4%. Clears the description FAIL, all three Vale CompositionNote
errors and both Gotchas suggestions. 63% was the worst Gotchas ratio in the
corpus.

Cut the composition sentence to README -- it changes no routing decision and an
agent picks this skill because the user asked about labels, not because two
other skills call it. Cut the capability enumeration; 'list, create, edit,
delete' decompose 'reading or writing' and add no trigger.

Boundary clauses are now one arrow per target. The resolver extracts only the
first name per arrow clause, so the previous '-> gitea-issues / gitea-prs' left
gitea-prs neither dangling nor checked while validate.sh reported 1 of 1. Now
2 of 2.

Makes org-scoped label resolution executable. The org label pool was reachable
in principle -- four *_org_label* methods, and a claim to own name-to-ID
resolution -- but list_org_labels takes org, and Step 1 derived only owner and
repo, so both resolution procedures stalled at the fallback. Fixed once at the
identity step rather than per-procedure. get_user_orgs is outside allowed-tools,
so the failing call is the discriminator: a failure means the owner is a user
account with no org pool, which is an answer, not an error.

Corrects a Gotcha that was false for create_repo_label/create_org_label and
collided with the literal tool name label_write. Same false claim removed from
README.

Refs #99
2026-08-30 12:29:18 +00:00

3.6 KiB

topic, source_keys
topic source_keys
labels
gitea-mcp-repo
gitea-mcp-slim-go

Label operations

Execution detail for label_read and label_write. Both tools operate on either repo-scoped or org-scoped labels — never both in one call. Pick the method family (*_repo_label* vs. *_org_label*) that matches the target, and pass owner+repo or org accordingly.

Verified live schemas

label_read — required: method.

Param Type Notes
method string (enum) "list_repo_labels" | "get_repo_label" | "list_org_labels"
owner string for repo methods
repo string for repo methods
org string for org methods
id number label ID, required for "get_repo_label"
page number default 1
per_page number default 30

label_write — required: method.

Param Type Notes
method string (enum) "create_repo_label" | "edit_repo_label" | "delete_repo_label" | "create_org_label" | "edit_org_label" | "delete_org_label"
owner string for repo methods
repo string for repo methods
org string for org methods
id number for edit/delete
name string required for create
color string hex #RRGGBB, required for create
description string optional
exclusive boolean org labels only
is_archived boolean repo labels only

Note: unlike milestone_read/milestone_write, owner/repo/org are not schema-required on either label tool — only method is. Passing none for a repo/org method still fails, just as a runtime error from Gitea rather than a client-side validation error.

List repo labels

label_read  method: "list_repo_labels"  owner: <owner>  repo: <repo>  per_page: 50

Paginate (page: 1, 2, ...) until the returned count is less than per_page. This is the only way to build a complete name → ID map — there is no lookup-by-name endpoint.

Get one label

label_read  method: "get_repo_label"  owner: <owner>  repo: <repo>  id: <id>

Resolve a name to an ID

There is no direct name lookup. List all repo labels (paginating if needed), scan for a case-insensitive name match, and extract id. Both pools can apply to one issue: if the name is not in list_repo_labels, also check list_org_labels before reporting it unresolved. That method takes org, not owner/repo — pass the repo's owner as org, which is what it means when the owner is an organisation. If that call fails, the owner is a user account, there is no org pool, and the miss is a real miss.

Resolution is the required first step before any label application on an issue or PR — the actual add_labels/replace_labels/remove_label call lives in gitea-issues/gitea-prs via issue_write/pull_request_write, which take numeric IDs only.

Create a label

label_write  method: "create_repo_label"
  owner: <owner>  repo: <repo>
  name: "Kind/Bug"
  color: "#d73a4a"
  description: "Confirmed bug"

For an org label, use method: "create_org_label" with org: instead of owner/repo, and exclusive: true if the label belongs to a mutually-exclusive scope group.

Edit a label

label_write  method: "edit_repo_label"  owner: <owner>  repo: <repo>  id: <id>  color: "#ff0000"

Only pass the fields being changed — id plus any of name/color/description/is_archived.

Delete a label

label_write  method: "delete_repo_label"  owner: <owner>  repo: <repo>  id: <id>

Deleting a label does not remove it from historical issue/PR timeline events — it disappears only from current label lists.