feat(mcp): align remote settings and runtime filtering

[gitfromwildan]

Summary

Follow-up to the merged MCP settings implementation in #241, aligned with the remote-server and client-owned lifecycle requirements.

• Replace the user-facing Server ID with a unique Server Name, while reading legacy id config entries and keeping existing credential keys usable.
• Add a per-remote HTTP request timeout override: default 10 seconds, bounded to 1–120 seconds, persisted for web and desktop settings.
• Remove manual tool-name entry from Settings. The MCP client discovers tool schemas dynamically and filters new tools using readOnlyHint: true plus destructiveHint: false. Existing backend allow-lists are retained for compatibility; Settings does not expose or manage tool lists.
• Keep remote process lifecycle user-managed; coordinate protocol sessions per remote and use unique JSON-RPC request IDs. Discover configured remotes concurrently.
• Explain optional bearer-token authentication in Settings and document the remote configuration and filtering behavior.

MCP annotations are server-provided hints, not a security guarantee; configure only trusted remote endpoints.

Validation

• npm test: 790 passed
• cargo test: core 156, server 51, desktop 23 passed
• npm run build passed
• Clippy passed for core, server, and desktop with -D warnings
• Oxlint, Tauri ACL guard, Docker path guard, and git diff --check passed

Local E2E could not run: the available macOS 12 host is unsupported by the installed Playwright version. CI should run the browser E2E checks.

[pullfrog]

Important

The annotation filter can reject valid read-only MCP tools, so this needs correction before merging.

Reviewed changes The review covers the MCP settings migration, timeout persistence, dynamic discovery/filtering, session lifecycle coordination, and the corresponding web and desktop settings paths.

• Settings and migration — accepts legacy id entries while persisting unique names, bounded timeout overrides, and backend-held credentials.
• Dynamic tool filtering — discovers remote schemas and retains compatibility allow-lists while filtering newly configured tools by MCP annotations.
• Session/runtime behavior — adds per-remote coordination, unique JSON-RPC request IDs, concurrent discovery, and retired-session cleanup.

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using gpt-6-luna ｜ 𝕏}

[pullfrog]

This rejects valid read-only tools unless the server also sends destructiveHint: false. Under the MCP ToolAnnotations contract, readOnlyHint: true already declares that the tool does not modify its environment, while destructiveHint is only meaningful for non-read-only tools and may be omitted. As a result, servers that correctly return only { "readOnlyHint": true } have their tools marked unusable and disappear from the usable context-tool flow; accept the read-only hint without requiring destructiveHint: Some(false) (and keep destructive tools excluded).

Technical details

# Read-only annotation filter rejects valid MCP tools

## Affected sites
- `core/rust-ai/context.rs:229-231` — requires `destructiveHint == false` even when `readOnlyHint` is true.

## Required outcome
- A tool with `annotations.readOnlyHint: true` must pass the read-only filter whether `destructiveHint` is omitted or present, while tools without the read-only hint remain unavailable.

## Suggested approach
- Treat `readOnlyHint` as the controlling condition and do not require `destructiveHint` for a read-only tool.

## Open questions for the human
- None; this follows the MCP ToolAnnotations contract.

Source: https://modelcontextprotocol.io/specification/2025-06-18/server/tools

[pullfrog]

Pushed commit 069c1539aa27c4e7dc6ee84e530beb567af432dc to PR #242. The MCP filter now accepts tools with annotations.readOnlyHint: true when destructiveHint is omitted, while still rejecting tools without the read-only hint and preserving legacy allow-list behavior; regression coverage was added in core/rust-ai/context.rs:151-154 and core/rust-ai/context.rs:779-813.

Verified: cargo +stable test --manifest-path core/Cargo.toml passed (158 tests), cargo +stable clippy --manifest-path core/Cargo.toml -- -D warnings passed, cargo +stable test --manifest-path server/Cargo.toml passed (51 tests), npx oxlint frontend/ test/__fixtures__/ passed, npx tsc -b passed, npm test passed, node test/check-acl.mjs passed, node test/check-docker-paths.mjs passed, and git diff --check passed. cargo test/clippy --manifest-path src-tauri/Cargo.toml could not start project compilation because this Linux environment lacks system package glib-2.0 >= 2.70; the first pinned-toolchain Clippy attempt also failed while rustup was downloading 1.94.1, so stable was used for the successful Rust verification.

Task list (6/6 completed)

• Checkout PR branch and inspect failed check logs
• Verify failure is introduced by PR and reproduce exact CI command
• Implement minimal root-cause fix
• Run required verification and review diff
• Commit signed-off fix and push to PR
• Report diagnosis, changes, and verification

  ^{｜ View workflow run ｜ via Pullfrog ｜ Using gpt-6-luna ｜ 𝕏}