Linked Issue Or Context

Closes #357. Increment 3/3 of the agent web-fetch capability (after #358 added the unwired @frontagent/mcp-web-fetch adapter). Learned from CLAUDE-FABLE-5.md's web_fetch tool.

Summary

Wires the previously-unwired @frontagent/mcp-web-fetch adapter so the agent can actually call the web_fetch tool, and surfaces it to the two-phase planner.

• runtime-node (mcp-clients.ts): register web_fetch in WebMCPClient.callTool + listTools, delegating to handleWebFetchTool. No browser launch — playwright is lazy, so web_fetch stays decoupled from the browser tools that share the client.
• core/agent (agent.ts): add web_fetch to registerWebTools() so the executor routes it to the 'web' client (mirrors how filesense_* is routed via the 'file' client in registerFileTools()).
• core/schemas (schemas.ts): add web_fetch to ACTION_ENUM so planner-emitted steps with action web_fetch pass StepSchema validation (url param already exists in STEP_PARAMS_SCHEMA). Treated like browser_navigate.
• core/plan-generation (plan-generation.ts): mention web_fetch in both # 可用工具 prompt regions + a param hint, so the planner knows it can fetch external docs / API references.
• add @frontagent/mcp-web-fetch workspace dep to runtime-node.

Why web_fetch is added to ACTION_ENUM (unlike filesense_*)

This increment's directive is to give the planner a prompt mention of web_fetch. Planner steps are zod-validated against ACTION_ENUM (StepSchema.action = z.enum(ACTION_ENUM)), so mentioning the tool in the prompt without the enum entry would invite the planner to emit a step that fails validation. Prompt-mention and enum-inclusion are therefore coupled. filesense_* is deliberately NOT planner-surfaced, so it stays registry-only; web_fetch is, so it is treated like browser_navigate.

On the cli MCP registry (issue acceptance criterion)

#357's acceptance criteria list "registered in runtime-node + cli MCP client registries". Investigation shows apps/cli/src/mcp-client.ts is dead code: it is imported nowhere in apps/cli/src (the CLI commands delegate to runFrontAgentTask from @frontagent/runtime-node, which uses runtime-node/src/mcp-clients.ts), the package main is dist/index.js, and no test references its classes. The @frontagent/mcp-filesense precedent was likewise never wired into this dead CLI copy. Wiring it would add a dependency for a never-instantiated class (low-value churn). The live registry — runtime-node — is wired here. Deleting the dead CLI copy is noted as a possible follow-up cleanup, out of scope for this focused PR.

Impact Scope

MVP scope only: no web_search, no planner when-to-search heuristics (deferred to follow-up issues). SSRF guards live in the adapter (#358) with their own security tests.

GitNexus Impact Summary

• Risk level: LOW
• Critical skeleton changes: packages/core/src/agent/agent.ts (agent-core, covered by new test in agent.test.ts) and packages/runtime-node/src/mcp-clients.ts (mcp-boundary, covered by new mcp-clients.test.ts). Additive only — new switch case, listTools entry, ACTION_ENUM member, planner prompt lines, and one registerWebTools entry; no signature changes, nothing removed, no caller broken.
• GitNexus impact: detect_changes reports exactly the expected touched symbols — registerWebTools, WebMCPClient.callTool, generatePlanInTwoPhases/generatePlanSinglePhase (planner prompt builders) — and only the expected processes (CallTool tool dispatch + adapter SSRF chains, GeneratePlan). impact ACTION_ENUM = LOW (0 upstream); impact WebMCPClient = structurally HIGH but the edit is additive. No unexpected scope.
• Verification: pnpm contract:local passes (both critical boundaries have matching tests); pnpm quality:precommit passes (lint, typecheck, all unit tests, 32 workflow tests).

Verification

• contract:local: passed.
• Touched-package tests: core 696 pass (incl. new registerWebTools routing contract), runtime-node 93 pass (incl. new hermetic mcp-clients.test.ts).
• biome clean on all touched files.
• Full quality:precommit green via pre-commit hook; pushed through the quality:local pre-push gate.

Checklist

• I have linked an issue or explained why this PR stands alone.
• I have kept the diff focused on the stated change.
• I have run pnpm quality:precommit, or explained why it could not run.
• I have run pnpm quality:local for critical skeleton changes, or explained why it could not run.
• I have updated docs or tests when behavior, public APIs, or Harness contracts changed.
• For critical skeleton changes, I have filled the GitNexus impact summary with concrete results.

🤖 Generated with Claude Code