refactor(tools): drop 29 unused tool registrations (102→73) #2
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "slim/tool-surface-2026-05-21"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Removes 29 unused tool registrations to reduce the MCP server's tool-schema footprint in the agent's context window (~7k tokens saved per session).
Removed:
tracking/module (10): time-tracking + stopwatch APIscreate_org,edit_org,delete_orglist/create_org_team+add/remove team_member/team_repoedit+delete× {issue, comment}dismiss_pull_review,delete_pull_review,get_pull_review(single —list_pull_reviewscovers it)Preserved:
create_repo+fork_repo(explicit keep)Context: anthropics/claude-code#38044 — subagents inherit full MCP tool schemas without deferred loading. Less tool surface = more usable subagents.
Three new MCP tools for debugging workflow-run failures without leaving the agent loop: - list_run_jobs: GET /repos/{o}/{r}/actions/runs/{id}/jobs - get_run_logs: GET /repos/{o}/{r}/actions/runs/{id}/logs - get_job_logs: GET /repos/{o}/{r}/actions/jobs/{id}/logs The SDK's existing ListRepoActionJobs targets a different endpoint (/actions/runners/jobs), so all three tools use pkg/forgejo's raw HTTP helpers. Logs are capped at MaxInlineDownloadBytes (1 MiB); ErrPayloadTooLarge maps to a clear hint to use get_job_logs.Forgejo's REST v1 API does not expose action-run logs or artifacts; the web UI fetches both from same-origin routes (no /api/v1 prefix) that still accept "Authorization: token X" via Forgejo's auth middleware. Reshape the toolset: - Drop list_run_jobs entirely — Forgejo has no equivalent JSON endpoint; job lists are rendered into HTML, not exposed. - get_run_logs + get_job_logs both hit GET /{owner}/{repo}/actions/runs/{run}/jobs/{job}/attempt/{attempt}/logs which returns text/plain. job_index defaults to 0 (single-job common case); attempt defaults to 1. run_id in these tools is the URL-style run index (the N in /actions/runs/N), matching the existing get_workflow_run convention, NOT the run_number shown in the UI as "#962".Set ReturnRunInfo=true on the SDK call so Forgejo 14+ responds with {id, run_number, jobs[]} instead of a bare 204. The tool now surfaces the run id, run_number (= #N in the UI), and job names in its text output, so callers can hand the id straight to get_workflow_run or wait_for_run instead of racing list_workflow_runs by head_sha. Older Forgejo (pre-return_run_info) still answers 204 — the SDK errors on the empty JSON decode in that case; we catch that specific error and fall back to the legacy success summary so the tool stays backward-compatible. Verified against forgejo.philflow.me v14.0.3: POST /api/v1/repos/Phil/flow.raven/actions/workflows/e2e-staging.yml/dispatches body {"ref":"dev","return_run_info":true} -> HTTP 201 {"id":1642,"run_number":1463,"jobs":["e2e"]} Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>Forgejo v14.0.3 has no /api/v1/repos/{owner}/{repo}/actions/runs/{id}/jobs endpoint (verified: 404), so discovering the jobs of a run required brute-forcing get_run_logs(job_index=0,1,2…) until 404 — burning tool calls and giving no metadata back. list_run_jobs scans /api/v1/repos/{owner}/{repo}/actions/tasks (which returns ALL recent repo tasks; per-run filter params are silently ignored on v14) and matches client-side on the task URL suffix /actions/runs/<run_number>. Default scan window: 500 tasks (10 pages of 50) — covers ~24 h on raven-scale CI. max_scan_pages caller-tunable. Accepts either run_number (preferred, UI-visible #N) or run_id (database PK; resolved to a run_number first via GetRepoActionRun). Output exposes task_id, name, status, event, workflow, started time, duration, and the canonical run URL — enough to drive get_run_logs and to triage failures without a follow-up tool call. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>The web log route returns a generic "Not found." for three distinct failure modes — wrong run number, job index out of range, log expired or unreachable. The previous error couldn't differentiate, costing tool calls during triage. On 404 the tool now: 1. Probes GetRepoActionRun(runID) — if it hits, the caller passed a database id where a run_number was needed; we surface the actual run_number so they can retry. 2. Enumerates /actions/tasks and matches on the URL suffix to count jobs in the run. If job_index >= count, returns "out of range, valid 0..N-1, names=[...]". 3. Otherwise explains the Forgejo v14 bearer-token-vs-session-cookie limitation on web routes and points at the working artifact workaround (workflow uploads -> issue attachment -> triage agent pulls via download_issue_attachment). Also documents the dead-end status of /actions/runs/{N}/jobs/.../logs under bearer auth on v14, with the v16 + forgejo#12140 reference. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>Removes registration of tools that are never used in Phils workflows to reduce the MCP server's tool-schema footprint in the agent's context window. Tool surface: 102 -> 73 (-29 tools, ~7k tokens saved per session). Removed: - tracking module (10): time-tracking + stopwatch APIs - org admin (3): create_org, edit_org, delete_org - org teams (6): list/create_org_team + add/remove team_member/team_repo - attachment cold (4): edit + delete x {issue, comment} - pull review cold (3): dismiss_pull_review, delete_pull_review, get_pull_review (single — list_pull_reviews covers it) - search_org_teams (1) — not in registry, was already inert Behaviour preserved: - All issue / PR / repo / branch / file CRUD - Workflow runs, logs, dispatch, wait - Notifications + read state - Attachment hot path (list/get/download/create) — including Phils PR #109 attachment feature + auto-spill - Org read-only (get, list members, check membership, remove member) - create_repo + fork_repo explicitly kept (Phil-decision) Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>