feat(mcp): register loopover_get_automation_state as a local stdio tool (#7752)

[galuis116]

Summary

Closes #7752.

loopover_get_automation_state has been a remote MCP tool since #784 and gained a maintain automation-state CLI mirror in #6742, but it was never registered on the local stdio server. #6382 registered five sibling maintain-family tools as stdio tools; this one landed after that batch, so an agent on the stdio server had to shell out to the CLI to reach it.

This mirrors the existing #6152 registrations exactly, per the issue's required pattern:

• Descriptor - adds the STDIO_TOOL_DESCRIPTORS entry with category: "agent", matching the remote server's own category for the same name (src/mcp/server.ts), so both surfaces group consistently. The description therefore flows through the shared stdioToolDescription lookup (and loopover-mcp tools) rather than being hardcoded at the registration - stdioToolDescription throws on an unknown name, so this entry is required, not optional.
• Registration - placed next to its maintain-family siblings, reusing the existing ownerRepoShape and toolRepoBase helpers and calling the same endpoint the CLI subcommand already calls (GET /v1/repos/:owner/:repo/automation-state) through the same apiGet client. No duplicated HTTP logic, no new paths, and no behaviour the CLI does not already have.

The endpoint is requireRepoMaintainer-gated (src/api/routes.ts), so the description carries the same "Maintainer access required." note as its siblings.

Tests

Extends test/unit/mcp-cli-maintain-tools.test.ts - the suite that already covers the five siblings - rather than adding a parallel file. Adding the tool to MAINTAIN_TOOLS makes it inherit all four existing parametrized cases:

• registered in the stdio server's listTools() output
• listed by loopover-mcp tools --json with a non-empty description
• proxies to its REST endpoint and returns the payload (asserts on permissionReadiness)
• surfaces an API failure as a tool error (unregistered repo -> 404)

The request-capture filter now also records automation-state calls, so the proxy assertion has traffic to inspect. The shared fixture already serves this endpoint, so no harness change was needed. Suite goes 15 -> 17 passing.

Scope

• The PR title follows type(scope): short summary Conventional Commit format.
• This PR is focused and does not mix unrelated backend, UI, MCP, docs, dependency, and deploy changes.
• This follows CONTRIBUTING.md and does not reintroduce GitHub Pages, VitePress, site/, or CNAME.
• I linked a currently open issue this PR resolves (Closes #7752).

Validation

• git diff --check
• npm run actionlint - no workflow files touched.
• npm run typecheck
• npm run build:mcp
• npx vitest run test/unit/mcp-cli-maintain-tools.test.ts - 17 passing (was 15).
• Wider MCP sweep (mcp-cli-maintain, mcp-cli-basics, mcp-cli-completion-spec) - 74 passing, no regressions.
• npm run docs:drift-check, npm run manifest:drift-check, npm run branding-drift:check - all pass.
• npm run test:mcp-pack - fails identically on unmodified main in this Windows checkout (npm pack limitation), so it is not a signal for this diff; verified by stashing the change and re-running.
• npm run test:coverage / test:workers / ui:* - not run: this touches packages/loopover-mcp/ and one test/ file only, with no backend src/**, worker, or UI surface.
• npm audit --audit-level=moderate - no dependency changes.
• New behavior has unit tests for new branches and fallback paths - the handler is branch-free (no nullish fallbacks or conditionals), and all four registration/proxy/failure cases are covered.

If any required check was skipped, explain why:

• No src/** lines are modified, so codecov/patch has no changed lines to score.
• npm run command-reference:check reports stale on this Windows checkout, but regenerating it produces zero content change (git diff is empty) - it is a core.autocrlf line-ending artifact, not real staleness. This change adds an MCP tool, not a CLI command, and the generator's counts are unchanged (11 public + 9 maintainer-only + 8 action). No regenerated file is included, deliberately.

Safety

• No secrets, wallet details, hotkeys, coldkeys, user PATs, private keys, raw trust scores, private rankings, or private maintainer evidence are exposed.
• Public GitHub text stays sanitized and low-noise.
• Auth, cookie, CORS, GitHub App, Cloudflare, or session changes include negative-path tests - no auth logic changes; the tool inherits the route's existing requireRepoMaintainer gate, and the API-failure case is covered by a negative test.
• API/OpenAPI/MCP behavior is updated and tested where needed - a new stdio MCP tool, tested; no REST/OpenAPI change (the route already exists).
• UI changes use live API data - n/a, no UI change.
• Visible UI changes include a UI Evidence section - n/a: no UI/frontend/docs/extension change.
• Public docs/changelogs are updated where needed - n/a; the tools listing and help text derive from STDIO_TOOL_DESCRIPTORS automatically.

Notes

• Read-only. This adds no write or mutation capability - it is the derived read-side counterpart to the pause/resume and set-level writes already registered above it.

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[codecov]

Codecov Report

❌ Patch coverage is 0% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 80.69%. Comparing base (fa21f3e) to head (22adbb4).
⚠️ Report is 4 commits behind head on main.

Files with missing lines	Patch %	Lines
packages/loopover-mcp/bin/loopover-mcp.ts	0.00%	3 Missing ⚠️

❌ Your patch check has failed because the patch coverage (0.00%) is below the target coverage (99.00%). You can increase the patch coverage or adjust the target coverage.

Additional details and impacted files

@@             Coverage Diff             @@
##             main    #7866       +/-   ##
===========================================
- Coverage   91.40%   80.69%   -10.71%     
===========================================
  Files         730       89      -641     
  Lines       74763    23357    -51406     
  Branches    22815     4506    -18309     
===========================================
- Hits        68335    18849    -49486     
+ Misses       5385     4330     -1055     
+ Partials     1043      178      -865     

Flag	Coverage Δ
shard-1	0.00% <0.00%> (-56.27%)	⬇️
shard-2	0.00% <0.00%> (-51.13%)	⬇️
shard-3	0.00% <0.00%> (-53.86%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
packages/loopover-mcp/bin/loopover-mcp.ts	0.00% <0.00%> (ø)

... and 641 files with indirect coverage changes

[loopover-orb]

Caution

🛑 LoopOver review result - fixes required

_{Review updated: 2026-07-21 15:43:33 UTC}

2 files · 1 AI reviewer · no blockers · CI failing · blocked

🛑 Suggested Action - Fix Blockers

Review summary
This PR registers `loopover_get_automation_state` as a local stdio tool by mirroring the exact pattern used for its five #6152 siblings: a descriptor entry with matching category and description, and a registration using the same `ownerRepoShape`/`toolRepoBase`/`apiGet` helpers hitting the same REST endpoint the CLI already calls. The test suite is correctly extended by adding the tool to the existing `MAINTAIN_TOOLS` table (which drives all four parametrized cases) and the fixture request-capture regex is updated to include `automation-state`, so the new tool inherits registration, listing, proxy, and error-path coverage without a parallel test file. This is a small, well-targeted, low-risk change that closes #7752 exactly as scoped.

Nits — 4 non-blocking

• packages/loopover-mcp/bin/loopover-mcp.ts:2615 — the registration callback is typed `async ({ owner, repo }: any) =>`, an explicit `any` where the sibling tools (per the compiled .js reference) rely on inferred/typed destructuring; consider typing against `ownerRepoShape` instead of widening to `any`.
• codecov/patch reports 0.00% diff coverage despite the new tool being added to the parametrized `MAINTAIN_TOOLS` test table — worth double-checking the coverage report actually picked up the extended array rather than trusting the raw percentage, though this may simply be an artifact of the branch being 4 commits behind default.
• Confirm the codecov/patch 0% is a reporting/base-branch-drift artifact and not a real gap, since the added lines look covered by the extended MAINTAIN_TOOLS parametrization.
• Consider typing the destructured handler params consistently with sibling registrations instead of `: any` at packages/loopover-mcp/bin/loopover-mcp.ts:2615.

CI checks failing

• codecov/patch — 0.00% of diff hit (target 99.00%)
• validate
• validate-tests-merge

Decision drivers

• ✅ Code review — No blockers (1 reviewer)
• ✅ Gate result — Passing (No configured blocker found.)

Context & advisory signals — never blocks the verdict

Signal	Result	Evidence
Linked issue	✅ Linked	#7752
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	✅ 20/20	Low review scope from cached public metadata (1 linked issue).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 1946 registered-repo PR(s), 1275 merged, 53 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	galuis116; Gittensor profile; 1946 PR(s), 53 issue(s).
Improvement	✅ Minor	risk: clean · value: minor · LLM: minor

Linked issue satisfaction

Addressed
The diff registers loopover_get_automation_state as a stdio tool following the exact registerStdioTool pattern of its siblings, reuses apiGet/toolRepoBase against the same REST endpoint the CLI command calls, adds a centralized stdioToolDescription entry, and extends the existing sibling test suite with matching coverage.

Review context

• Author: galuis116
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: JavaScript, Python, Dart, TypeScript, HTML, MDX, Rust, C++
• Official Gittensor activity: 1946 PR(s), 53 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Start here: Triage stale or unlinked PRs.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

🧪 Chat with LoopOver

Ask LoopOver a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

• @loopover ask <question> answers contribution-quality Q&A with source citations and freshness.
• @loopover chat <question> answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
• A plain-language @loopover mention with a real question is routed to the closest matching read-only command automatically — no exact syntax required.

Full command reference: https://loopover.ai/docs/loopover-commands

🧪 Experimental — new and may change.

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by LoopOver, a quiet PR intelligence layer for OSS maintainers.

• Re-run LoopOver review

[loopover-orb]

LoopOver is closing this pull request on the maintainer's behalf (CI is failing (codecov/patch, validate, validate-tests-merge)). This is an automated maintenance action — to pursue this change, please open a new pull request with the issues resolved. Closed PRs may be analyzed later to improve review accuracy, but they are not automatically reopened or re-reviewed.