Why not use workspace/symbol in find_symbol (or a new LSP-only tool)?

[Daniel599]

Hi,

In #44 the proposal to use workspace/symbol was closed with:

“Won’t do, we use the symbol tree to construct the name_path.”

That makes sense for correctness, but a big advantage of LSP servers is the ability to find symbols outside the current project folder, including external libraries.
I did a small patch to test it in a large cpp project with libraries as "add_subdirectory" and called "request_workspace_symbol" and it found the symbol in the external library and did it really fast, using clangd

Would you consider:
introducing a new tool/flag (e.g. find_symbol_lsp or find_symbol --lsp-only) for cases where external coverage is more valuable than strict name_path reconstruction?

Or

a hybrid approach (use workspace/symbol for candidate discovery, then validate with the symbol tree),

Or

Use just lsp without symbol tree but add support for the name_path format class/method

This way both workflows are supported without changing the existing contract.

Thanks!

[MischaPanch]

Thanks for the proposal and info, we'll think about it.

This month our time is very limited, and we're generally prioritizing the release of the jetbrains extension (where external libraries are fully indexed automatically at no time cost), so it may be some time till we answer, since it's a rather serious extension from a conceptual point of view

[Daniel599]

@MischaPanch
Can you provide more information regarding jetbrains? Does it means this mcp will require Jetbrains IDE?

I am willing to create a PR for this feature, what do you think about adding a new tool "find_workspace_symbol"?