mathiasandClaude Opus 4.8
184d5a95dd
Per-repo MCP tools 404'd while owner-level tools worked (#36). Root cause was a parameter-name contract mismatch, not a routing fault: every per-repo tool declares the repo identifier as 'name' (and issue/PR index as 'number'), but every caller — the claude.ai connector, LLMs primed on gitea's own API — sends 'repo' and 'index'. The unmatched fields zero-valued the upstream path segment, producing '/api/v1/repos/{owner}//...', which gitea answers with its generic api-404 whose body points at /api/swagger. That swagger pointer is gitea boiler- plate, not a misroute — the MCP dispatch was correct all along. Two layers of defence: - parseArgs aliases repo->name and index->number (explicit canonical wins; alias key left intact so pr_merge's real 'index' field is unaffected). Kills the recurrence by accepting the idiomatic argument names. - the gitea client rejects any path with an empty segment before the HTTP call, returning ErrValidation instead of forwarding a malformed path and surfacing gitea's opaque swagger-404. Kills the silent-misleading-error class. Closes #36 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
gitea-mcp
Streamable HTTP MCP service exposing Gitea repo operations to Claude apps.
See ~/dev/AI/infra/docs/superpowers/specs/2026-05-04-gitea-mcp-gitops-workflow-design.md.
Quickstart
task setup:hooks # installs .githooks/pre-push — runs task check before every push
task check # context sync + lint + test + vet
task build # produces bin/gitea-mcp
This repo uses Trunk-Based Development. Commit directly to main. The pre-push
hook enforces the quality gate locally; CI re-runs task check on every push.