UMCPHandler_SearchWithinMaterials - Refactoring Notes

Changes Made

Plain-text output: Switched from Handle(Json, FJsonObject*) to Handle(Json, FStringBuilderBase&). Output is now one line per match instead of a JSON array of objects.
FormatName: Material names now come from MCPUtils::FormatName(MaterialObj) (returns path name) and expression names from MCPUtils::FormatName(Expr) (returns sanitized object name). Previously used Asset.AssetName.ToString() and Asset.PackageName.ToString() ad-hoc.
Concise output: Removed echoing of query and resultCount back to the caller. Each result is a single line: either material <path> or expression <name> in <material> (<class>) param=<name>.
Trimmed includes: Removed ~20 unused includes (MaterialGraph, BlueprintEditorUtils, AssetRegistry, various expression types that were never referenced, etc.). Kept only the parameter expression headers actually used for Cast.
Load instead of Info: Switched from Info() + manual GetAsset() casts to Load() + Objects(), which is the cleaner MCPAssets pattern for when you need the loaded objects.

The handler already used MCPAssets for asset discovery, which is correct.
The parameter name extraction logic (casting to specific parameter expression types) is reasonable and necessary since there's no common base for parameter names.
The MaxResults clamping is sensible.

Expression matching uses class names and descriptions, not FormatName/Identifies: The search matching still does raw Contains checks against Expr->GetClass()->GetName() and Expr->GetDescription(). These are search queries rather than identity checks, so Identifies doesn't directly apply here. But if MCPUtils gains a material-expression search helper in the future, this should use it.
UrlDecode on Query: The handler calls MCPUtils::UrlDecode(Query). It's unclear whether the MCP parameter population layer already handles URL decoding. If it does, this is redundant. I left it in to be conservative.
No AllContent(): The handler only searches /Game/ materials (the MCPAssets default). If engine or plugin materials should be searchable, AllContent() would need to be added. Left as-is since the original didn't search all content either.
Loading all materials is expensive: This handler loads every material asset to inspect expressions. For large projects this could be slow. A future optimization might use asset registry tags to pre-filter, or cache results. Left as-is since the original had the same behavior.