[Bug]: search_traces gives no truncation signal and silently clamps search_depth

[Lagmator22]

What happened?

search_traces bounds its result by search_depth and reports neither the depth it used nor whether the result hit it.

Two things are invisible to the caller:

1. A result that fills the depth looks identical to an exhaustive one. Ask for 10, get 10, and there is no way to tell whether the trace you needed was the eleventh.
2. The requested depth is clamped to the server's MaxSearchResults with no notice. buildQuery does if searchDepth > h.maxResults { searchDepth = h.maxResults }. Ask for 500 on a default server and the search runs at 100.

The schema says the max is "controlled by server config", but the response never says what that turned out to be.

Expected behavior

The same signal the sibling tools already give:

• get_services returns total_count and truncated ([Bug]: [mcp] get_services and get_span_names truncate silently #8901)
• get_trace_errors returns total_error_count, and its description tells the agent to compare it with the returned list ([Bug]: get_trace_errors does not signal when error-span results are truncated #9235)
• get_critical_path is getting total_segment_count in [Bug]: get_critical_path returns unbounded output while every other trace tool is capped #9175

search_traces is the entry point for most investigations and has nothing.

Storage applies the depth, so an exact match total is not available without a second query. What the handler can report honestly is the depth it actually used and whether the result filled it.

Additional context

This matters more than a normal missing field because it interacts with context budgeting. An agent that cannot tell a full page from a complete one either re-queries blindly or stops early on a partial view, and neither shows up as a tool error.

PR follows.

Jaeger backend version

main (26c5612)

SDK

Not applicable, this is in the MCP handler layer.

Pipeline

Not applicable.

Stogage backend

Any, the behavior is in the handler.