fix(gitea): make gitea-releases executable and correct misleading domain claims
gitea-releases was the weakest skill in the plugin: no allowed-tools, no owner/repo resolution, and a checkbox list where a dispatch table belongs, so an agent reaching it had to guess both its permissions and its inputs. The id-vs-tag_name trap — deleting by tag name where the API wants the numeric id — is restored as an explicit Gotcha because it destroys the wrong release silently. Elsewhere the `exclusive` flag was documented on the wrong side of the read/write split, and label data from one instance was presented as though it were universal, which invites an agent to assume a taxonomy that does not exist on the target repo. rename_branch was missing from the branch surface. Reference prose and fences are cleaned up in passing.
This commit is contained in:
@@ -7,10 +7,11 @@ source_keys:
|
||||
|
||||
# Branch operations
|
||||
|
||||
Call signatures below were verified live against the deployed `gitea-mcp` server via `ToolSearch`
|
||||
at authoring time, not copied from research docs — this is deliberate: research docs are generated
|
||||
from source code at a point in time and can drift from the server actually deployed. Re-verify
|
||||
against the live schema if these tools appear to behave differently than documented here.
|
||||
Call signatures below were verified live against the deployed `gitea-mcp` server via `ToolSearch`,
|
||||
not copied from research docs — this is deliberate: research docs are generated from source code at
|
||||
a point in time and can drift from the server actually deployed. **Last verified against gitea-mcp
|
||||
v1.7.0**, as reported by `get_gitea_mcp_server_version`. Re-verify against the live schema if the
|
||||
deployed version differs or these tools behave differently than documented here.
|
||||
|
||||
## `list_branches`
|
||||
|
||||
@@ -21,7 +22,7 @@ against the live schema if these tools appear to behave differently than documen
|
||||
- `per_page` (number, optional, default: `30`)
|
||||
|
||||
**Call:**
|
||||
```
|
||||
```text
|
||||
list_branches owner: <owner> repo: <repo>
|
||||
```
|
||||
|
||||
@@ -41,7 +42,7 @@ count is less than `per_page`.
|
||||
branch server-side (not necessarily your current local checkout)
|
||||
|
||||
**Call:**
|
||||
```
|
||||
```text
|
||||
create_branch owner: <owner> repo: <repo> branch: <new-name> old_branch: <source-branch>
|
||||
```
|
||||
|
||||
@@ -53,6 +54,29 @@ top-level request with no working branch context), omit `old_branch` and let it
|
||||
|
||||
A branch name collision returns `409 Conflict`.
|
||||
|
||||
## `rename_branch`
|
||||
|
||||
**Parameters:**
|
||||
- `owner` (string, required)
|
||||
- `repo` (string, required)
|
||||
- `branch` (string, required) — the branch's current name
|
||||
- `new_name` (string, required) — the name to move it to
|
||||
|
||||
**Call:**
|
||||
```text
|
||||
rename_branch owner: <owner> repo: <repo> branch: <current-name> new_name: <new-name>
|
||||
```
|
||||
|
||||
A rename moves the ref server-side; it is not a delete-plus-create, and no commit history is
|
||||
rewritten. What it does to things *pointing at* the old name — open pull requests using it as head or
|
||||
base, a branch protection rule matching it, CI config, and tracking branches on every other clone —
|
||||
is **not confirmed** by this skill's sources: the deployed tool describes itself only as "Rename an
|
||||
existing branch in a repository". Treat a rename of a branch with open PRs or a protection rule as a
|
||||
change needing verification afterward (`list_branches`, plus `gitea-prs` for the PR side), and
|
||||
confirm with the user first, exactly as for `delete_branch` below. A collision with an existing
|
||||
branch name is expected to return `409 Conflict` by analogy with `create_branch`, not separately
|
||||
confirmed.
|
||||
|
||||
## `delete_branch`
|
||||
|
||||
**Parameters:**
|
||||
@@ -61,7 +85,7 @@ A branch name collision returns `409 Conflict`.
|
||||
- `branch` (string, required)
|
||||
|
||||
**Call:**
|
||||
```
|
||||
```text
|
||||
delete_branch owner: <owner> repo: <repo> branch: <name>
|
||||
```
|
||||
|
||||
@@ -73,9 +97,12 @@ protected, every time, regardless of how the request is phrased.
|
||||
|
||||
## Token scope
|
||||
|
||||
All three — `list_branches`, `create_branch`, `delete_branch` — require `write:repository`. Gitea
|
||||
`list_branches`, `create_branch` and `delete_branch` all require `write:repository`. Gitea
|
||||
gates reads behind write scope for repo-scoped operations, so `list_branches` needs the same scope
|
||||
as the write operations, not `write:issue` alone. An earlier version of this doc claimed
|
||||
`write:issue` alone was sufficient for `list_branches`, based on empirical testing under a token
|
||||
that held both `write:issue` and `write:repository` simultaneously — that test didn't isolate the
|
||||
variable, so it couldn't actually establish `write:issue` alone as sufficient.
|
||||
|
||||
`rename_branch` is a write on the same repo-scoped surface and is inferred to need `write:repository`
|
||||
too — inferred by analogy, not separately confirmed.
|
||||
|
||||
@@ -8,8 +8,9 @@ source_keys:
|
||||
# Commit operations
|
||||
|
||||
Read-only commit history, scoped to a repo (optionally to one branch or one path). Call signatures
|
||||
below were verified live against the deployed `gitea-mcp` server via `ToolSearch` at authoring time,
|
||||
not copied from research docs, for the same drift-avoidance reason noted in `references/branches.md`.
|
||||
below were verified live against the deployed `gitea-mcp` server via `ToolSearch`, not copied from
|
||||
research docs, for the same drift-avoidance reason noted in `references/branches.md`. **Last verified
|
||||
against gitea-mcp v1.7.0**, as reported by `get_gitea_mcp_server_version`.
|
||||
|
||||
This domain has no prior skill precedent — it's new coverage added alongside branches because commit
|
||||
history is naturally scoped to a branch (a "what happened on this branch" question), not because it
|
||||
@@ -27,7 +28,7 @@ shares any tool family with branch create/delete.
|
||||
- `per_page` (number, optional, default: `30`, minimum: `1`)
|
||||
|
||||
**Call:**
|
||||
```
|
||||
```text
|
||||
list_commits owner: <owner> repo: <repo> sha: <branch-or-sha> path: <optional-path>
|
||||
```
|
||||
|
||||
@@ -52,7 +53,7 @@ Paginate per the pagination Gotcha in SKILL.md if you need more than one page of
|
||||
- `sha` (string, required)
|
||||
|
||||
**Call:**
|
||||
```
|
||||
```text
|
||||
get_commit owner: <owner> repo: <repo> sha: <commit-sha>
|
||||
```
|
||||
|
||||
|
||||
@@ -2,8 +2,8 @@
|
||||
|
||||
**Note on call signatures:** per `docs/adr/0011-gitea-skill-deep-modules.md`, the tool parameter
|
||||
signatures in `references/branches.md` and `references/commits.md` were re-verified live via
|
||||
`ToolSearch` against the deployed `gitea-mcp` server at authoring time — they are not copied
|
||||
verbatim from `api-reference.md` below. This resolves issue #6 comment #849's root-cause finding
|
||||
`ToolSearch` against the deployed `gitea-mcp` server — **last verified against v1.7.0**, as reported
|
||||
by `get_gitea_mcp_server_version` — rather than copied verbatim from `api-reference.md` below. This resolves issue #6 comment #849's root-cause finding
|
||||
that a prior skill was authored from API docs that had drifted from the actual MCP tool schema.
|
||||
The research docs cited here informed gotchas, response shapes, and workflow context, not the
|
||||
parameter lists themselves.
|
||||
@@ -11,7 +11,7 @@ parameter lists themselves.
|
||||
## gitea-mcp-repo
|
||||
|
||||
- **URL:** https://gitea.com/gitea/gitea-mcp
|
||||
- **Description:** Official gitea-mcp repository (v1.3.0); operation/*.go source files documenting all 55 MCP tools, their parameters, and CLI flags. Informed the dispatch table and pagination / 404-may-mean-403 gotchas in SKILL.md, and the list/create/delete branch and list/get commit mechanics (including 409 conflict and default-branch fallback behavior) in references/branches.md and references/commits.md.
|
||||
- **Description:** Official gitea-mcp repository; operation/*.go source files documenting the MCP tools, their parameters, and CLI flags. Extracted at v1.3.0; the parameter lists carried into this skill are re-verified live against the deployed server, last at v1.7.0. Informed the dispatch table and pagination / 404-may-mean-403 gotchas in SKILL.md, and the list/create/delete branch and list/get commit mechanics (including 409 conflict and default-branch fallback behavior) in references/branches.md and references/commits.md.
|
||||
- **Research doc:** plugins/gitea/docs/research/docs/gitea/sources.md
|
||||
- **Contributing files:** SKILL.md, references/branches.md, references/commits.md
|
||||
- **Status:** `extracted`
|
||||
@@ -19,7 +19,7 @@ parameter lists themselves.
|
||||
## gitea-mcp-slim-go
|
||||
|
||||
- **URL:** https://gitea.com/gitea/gitea-mcp/raw/branch/main/operation/repo/slim.go
|
||||
- **Description:** Slim response shape structs from gitea-mcp source; defines exactly which fields the MCP server returns for branches (name, protected, commit_sha) and commits (sha, html_url, created, message, author), and informed get_commit's always-populated guarantee vs. list_commits' conditional fields.
|
||||
- **Description:** Slim response shape structs from gitea-mcp source, extracted at v1.3.0; defines exactly which fields the MCP server returns for branches (name, protected, commit_sha) and commits (sha, html_url, created, message, author), and informed get_commit's always-populated guarantee vs. list_commits' conditional fields.
|
||||
- **Research doc:** plugins/gitea/docs/research/docs/gitea/sources.md
|
||||
- **Contributing files:** references/branches.md, references/commits.md
|
||||
- **Status:** `extracted`
|
||||
|
||||
Reference in New Issue
Block a user