The answer is "No", or at least "not directly". Certain objects are server-only (ex anything in ServerStorage). Attempting to send a reference to game.ServerStorage.SomeModel in a RemoteEvent will fail (it will be replaced by nil) since the client doesn't have access to it. Similarly, the Mouse and CurrentCamera are client-only, and the same thing happens when sending references to them to the server (as you found out). You can read about the limitations of RemoteEvent here.
As Goulstem says, you need to send the information you need to the server with RemoteEvents or RemoteFunctions. ex, say you want it so that the player's click places a model. Then you would have the client trigger a RemoteEvent on click, sending the relevant coordinates.
I am suspecting that you are trying to create Local Parts. Ideally, if you have the model required in ReplicatedStorage, you can simply have a LocalScript place the model in the workspace (or in the local player's camera). So long as FilteringEnabled is active, no one else will receive these parts.
If you want the model to start on the server and you want to transmit it to a specific client, you can try putting the model in the player's PlayerGui. (I tested this months ago, but not more recently.) If this still works, it will send the model to only the player whose PlayerGui you put it in. Relying on undocumented behaviour like this is risky, though - Roblox might change it later.
A safer alternative: "craftsmashbuild"'s first paragraph's idea is reasonable (with some modifications). Put the model in ReplicatedStorage and then transmit a reference to this model to the client. (It needn't have a unique name or anything since you'll be transferring a reference, not the name.)
A final note: you don't need to use "..." in your function definition. Just use:
game.ReplicatedStorage.RemoteEvents.Spawn.OnServerEvent:Connect(function(plr, request, camera, mouse)
"..." in documentation is just a way of saying "send as many arguments as you like". When you're making your own function, you can use "..." just like you did, but it is easier to just specify the arguments you want. As usual, if not enough arguments are sent, the last ones will receive nil. Only use "..." when you are expecting a variable number of arguments and want them in a list.
1
