Install configured MCP tools in LocalHarness

Merged
VA
3d ago
+322-175

Problem

LocalHarness opens a stock agent without reading configured MCP servers. User tools therefore never enter its registry or retained task grants, even though the shared settings loader and bounded stdio/HTTP installer already exist.

Design

Load native settings and install configured servers before compaction selection and durable owner creation. Keep default and custom tools additive; the registry retains each installed connection. Carry the installer's server capabilities into task admission, filtering registry-derived tool-call grants before copying them. Expose optional startup diagnostics; a required failure rejects opening. LocalHarnessConfig accepts the existing SettingsConfig (including explicit project trust) and McpClientLimits.

Decisions

  • Fresh branch from origin/main at 4774d27a82, after #495. #618 is already merged; no pushed history is rewritten.
  • Configuration remains ordinary user/project files, read by the existing NativeSettings loader. User configuration loads by default; project MCP stays disabled unless SettingsConfig::trust_project_mcp(true) is explicit. No new configuration schema, store, protocol, polling or transport.
  • Volume mode uses its configured provider directory as the default settings workspace and process root. Callers may select configuration locations with SettingsConfig. Transport availability follows the existing mcp-stdio/mcp-http features.
  • Run installation before calculating compaction budgets so MCP schemas count toward the provider's fixed tool overhead. Required startup errors precede owner creation; optional errors remain available as the existing McpServerFailure data.
  • No synchronization or parser implementation changes: reuse the existing modeled cancellation, bounded installer and fuzzed settings parser. Lifecycle hook invocation and pinned instruction/skill assembly remain separate follow-ups.

Deletions

Move the existing HTTP integration fixture out of the manual installer test into the LocalHarness suite. Replace its manual settings/discovery/catalog wiring with LocalHarness::open and a scripted stock tool turn. No duplicate fixture or startup implementation. Net +147 lines (+322/-175); 175 lines are migrated fixture coverage.

Tests run

Signed head f0772e32dc6d826cb9f05ed8aac125a0909fbd8a.

  • Local Windows: cargo check -p acyclic-harness --lib --tests --features filesystem-local,native-execution,terminal,mcp-http,test-support passed in 2m53s (includes hooks, mcp-stdio, mcp-http and defaults). Existing unrelated warnings remain.

  • Added/compiled scenarios: configured HTTP initialization and pagination, session reuse, filtering, additive defaults/custom tools, retained admission authority and real MCP call through ScriptedModelProvider; optional versus required missing executable; project trust off/on.

  • Caller search confirms the moved fixture has one definition. rustfmt --check, git diff --check, LF/NUL and file-size checks passed.

  • Runtime execution pending CI/bb1 recovery: bb1 is down. Per the user's current direction, the pre-push gate is the local Windows compile check. No runtime timing claim is made for the new integration scenarios.

  • Final pre-push check after removing duplicate tool-grant copies: the identical local Windows cargo check command passed in 19.82 s.

  • Merge-only refresh: merged origin/main at 13590b5c79a5, preserving both MCP and #615 goal/admission fields in the two conflict hunks. No follow-up fixes included. Local Windows cargo check with the identical full native feature set passed in 3m25s. Net diff unchanged (+322/-175).