Summary

• max_tools == 0 now means no cap on LLM-selected candidates — previously 0 >= 0 fired on the first iteration, returning zero candidates (fix(mcp): prune_tools max_tools == 0 should mean no cap, not zero candidates #2294)
• Sanitize tool names and descriptions before interpolating into the pruning prompt: strip control characters (char::is_control()), cap names at 64 chars and descriptions at 200 chars — prevents prompt injection from attacker-controlled MCP servers (fix(security): sanitize MCP tool descriptions before interpolating into pruning prompt #2297)
• Document and enforce that always_include tools bypass the max_tools cap; max_tools applies only to LLM-selected candidates (fix(mcp): clarify always_include semantics vs max_tools cap in prune_tools #2296)

All three fixes are prerequisites before prune_tools is wired into the agent loop.

Changes

• crates/zeph-mcp/src/pruning.rs: three fixes + three new unit tests
• CHANGELOG.md: entries for fix(mcp): prune_tools max_tools == 0 should mean no cap, not zero candidates #2294, fix(mcp): clarify always_include semantics vs max_tools cap in prune_tools #2296, fix(security): sanitize MCP tool descriptions before interpolating into pruning prompt #2297

Test plan

• cargo +nightly fmt --check — clean
• cargo clippy --features full --workspace -- -D warnings — no new warnings
• cargo nextest run --config-file .github/nextest.toml --workspace --features full --lib --bins — 6913/6913 passed
• New unit tests: max_tools_zero_means_no_cap, description_sanitization_strips_control_chars_and_caps, always_include_bypasses_max_tools_cap
• Security audit: char::is_control() covers all C0/C1 controls including \n, \r, \t, null byte; whitelist on LLM-returned names remains intact

Closes #2294, Closes #2297, Closes #2296