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

[jaytbarimbao-collab]

Closes #7752

loopover_get_automation_state is registered as a remote MCP tool (src/mcp/server.ts) and has a CLI mirror (maintain automation-state), but there was no local stdio MCP tool registration for it in packages/loopover-mcp/bin/loopover-mcp.ts — so a self-host operator using the local stdio MCP server (not the CLI or remote MCP) couldn't call it. #6742 added the REST route + CLI subcommand but not the matching stdio registration, so it fell outside the #6382 batch.

Change — following the exact pattern of its five #6382 siblings:

• A STDIO_TOOL_DESCRIPTORS entry (category agent, mirroring the remote tool's category in src/mcp/server.ts).
• A registerStdioTool("loopover_get_automation_state", …) block placed with its maintain-family siblings, using ownerRepoShape and reusing the same GET ${toolRepoBase(owner, repo)}/automation-state call the maintain automation-state CLI already makes — no duplicated HTTP logic.

Tests:

• Added to the maintain stdio-proxy suite (mcp-cli-maintain-tools.test.ts): the existing MAINTAIN_TOOLS loop now covers it for both the proxy-contract case (asserts it hits /v1/repos/owner/repo/automation-state) and the API-failure case. The fixture server already serves /automation-state.
• Bumped the discovery tool-count invariant in mcp-tool-rename-aliases.test.ts from 87 → 88 (both the listTools and tools --json assertions) and appended the count-history comment, matching the convention the sibling registrations (loopover_get_gate_config_effective has a REST route but no remote MCP tool or local stdio MCP tool #7800/loopover_get_pr_maintainer_packet has a REST route but no remote MCP tool or local stdio MCP tool #7802/loopover_get_upstream_ruleset has a REST route but no remote MCP tool or local stdio MCP tool #7807) established.

Verified locally: tsc -p packages/loopover-mcp clean, mcp-cli-maintain-tools (19) + mcp-tool-rename-aliases (10) + mcp-automation-state/mcp-output-schemas all pass, root tsc --noEmit clean for the changed files.

[superagent-security]

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

[loopover-orb]

Warning

⏸️ LoopOver review result - manual review recommended

_{Review updated: 2026-07-21 20:05:01 UTC}

3 files · 1 AI reviewer · no blockers · CI pending · dirty

⏸️ Suggested Action - Manual Review

Review summary
This PR adds the missing local stdio MCP registration for `loopover_get_automation_state`, following the exact established pattern of its five #6382/#6152 siblings: a STDIO_TOOL_DESCRIPTORS entry, a registerStdioTool block reusing the existing `apiGet` proxy call, and a stdioToolDescription lookup for the description text. Tests are extended in-place (MAINTAIN_TOOLS loop, tool-count pins bumped 87→88 in both assertions, count-history comment appended), and the PR closes #7752 as required. The change is narrow, well-targeted, and matches prior precedent closely enough that correctness is straightforward to verify from the diff alone.

Nits — 3 non-blocking

• packages/loopover-mcp/bin/loopover-mcp.ts:2790 — the handler param is typed `async ({ owner, repo }: any) =>`, consistent with the rest of the file's registerStdioTool blocks but still an explicit `any`; not worth introducing a one-off stricter type here given the file-wide convention.
• The PR relies on `stdioToolDescription("loopover_get_automation_state")` (packages/loopover-mcp/bin/loopover-mcp.ts:2784) resolving correctly from the remote tool's description table — worth confirming that lookup key matches exactly what src/mcp/server.ts registers, since a mismatch would silently yield an empty description rather than a hard failure.
• Consider a one-line comment noting where `stdioToolDescription` sources its text from, since this file hand-syncs several enums/lists from sibling files elsewhere and that context helps future maintainers verify parity.

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: 136 registered-repo PR(s), 66 merged, 16 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	jaytbarimbao-collab; Gittensor profile; 136 PR(s), 16 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/STDIO_TOOL_DESCRIPTORS pattern of its siblings, reuses the same GET automation-state endpoint without duplicating HTTP logic, and updates the corresponding test suites and tool-count invariants.

Review context

• Author: jaytbarimbao-collab
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: Rust
• Official Gittensor activity: 136 PR(s), 16 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Keep the PR focused and include validation evidence before maintainer review.

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 (conflicts with the base branch — resolve and open a fresh PR). 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.