As others have mentioned, this isn't a use case well supported by Rust. It's possible, but I don't think any good interfaces exist.
There are two hard parts here: first, compiling it, and second, linking it with the existing server.
For the first part, I think your best bets are either to just run rustc manually, using the CLI interface, or to have your clients compile the rust code before sending it to the server. Depending on what your clients are, one of these could be easier than the other.
For the second part, the most direct choice would be to compile to a dynamic library, and use libloading. You get direct calls to dynamically loaded dylibs, but the downside is that all of those calls need to be through a C interface, and you have the other constraints of FFI like needing to keep track of which side allocated things, and only free them on that side. abi_stable is a great rust crate for this, but even with that, it can still be clunky.
Another alternative would be to run your compiled rust code as a subprocess, and use an RPC interface to it. Kind of like how text editors use an RPC to talk to the language server - the language server runs as an independent binary, and the text editor uses it as a plugin by running that binary and talking to it via stdin/stdout. This does induce overhead. However, if there's any chance your code will crash, then this is definitely safer - crashing compiled code won't crash your whole service.
From your description, it seems like there might be more concerns, though. Do you trust your clients - in other words, are you willing to give them full user privileges on your machine? If so, then it's all good. If not, you probably want to look into sandboxing both the rustc execution, and the process you run the code in.