### Check for existing issues

- [x] I have searched the existing issues and checked that my issue is not a duplicate.

### What happened?

`mcp_semantic_tool_filter` consistently filters every tool to zero when the client appends a unique identifier suffix to MCP tool names before sending them in `tools[]`. This is the normal behavior of MCP clients such as LibreChat, which registers every tool as `<canonical>_<unique_id>` to avoid naming collisions across multiple connected MCP servers.

The failure is related to but distinct from [#26078](https://github.com/BerriAI/litellm/issues/26078) (fixed in [#26117](https://github.com/BerriAI/litellm/pull/26117)): that fix introduced anchored suffix matching so that a client-side prefix (`litellm_<canonical>`) is resolved back to the canonical. The symmetric case — a client-side suffix (`<canonical>_<uid>`) — is not handled and falls through all existing checks.

Concrete example, one tool:

| form | value | |---|---| | MCP registry canonical (proxy side) | `fc_web_search-firecrawl_scrape` | | Incoming `tools[].name` from LibreChat | `fc_web_search-firecrawl_scrape_a1b2c3d4` | | Router top-k match returns | `fc_web_search-firecrawl_scrape`…