mcp/mod.rs re-exports 13 of 21 public param structs with no visible rule

[bug-ops]

Description

crates/mcpls-core/src/mcp/mod.rs re-exports 13 of the 21 pub param structs defined in mcp/tools.rs via pub use, with no apparent rule governing which ones are included. None of the re-exported names are actually used in-tree (handlers.rs/server.rs import directly from super::tools, never through mod.rs's re-export path).

This surfaced during the #301/#302 refactor (PR #319): removing HoverParams, DefinitionParams, and CallHierarchyPrepareParams forced touching this re-export list (three of the six deleted wrapper structs happened to be re-exported, three were not), which raised the question of what the intended public API surface of mcpls_core::mcp actually is.

Reproduction Steps

1. grep -n "pub use" crates/mcpls-core/src/mcp/mod.rs
2. Compare against all pub struct *Params definitions in crates/mcpls-core/src/mcp/tools.rs
3. Observe: 13 of 21 are re-exported, with no discernible pattern (not alphabetical, not by tool category, not "only structs with extra fields beyond the flattened base")
4. rg "mcpls_core::mcp::(Hover|Definition|References)Params" --type rust outside mcp/ itself returns no in-tree callers

Expected Behavior

The public param-struct surface of mcpls_core::mcp should follow a stated, deliberate rule (e.g., "re-export only param types library embedders are expected to construct directly," or "re-export none, since Parameters<T> extraction is the only supported entry point") rather than an accumulated, unexplained partial list.

Actual Behavior

13 of 21 param structs are re-exported from mcp/mod.rs with no visible selection criterion; the other 8 are only reachable via mcpls_core::mcp::tools::*.

Environment

• Version: main, surfaced during PR refactor(mcp): consolidate position params and centralize tool annotations #319 (issues 20 MCP tool handlers in mcp/server.rs repeat the same destructure/call/wrap boilerplate #301/mcp/tools.rs has six byte-identical position-only param wrapper structs #302)

Notes

Filed as a separate, deliberately out-of-scope follow-up from PR #319 per that PR's review -- deciding the whole public param surface is a distinct API design call, not something to bundle into a boilerplate-dedup refactor.