jlowin
create FastMCP Client from command string
I'm not crazy about blindly treating strings a shell commands, I think that could get into trouble pretty quickly. All the other inferences are fairly type bound: things that looks like paths are treated as paths; things that look like urls are treated as urls, things that look like servers are treated as in-memory servers. This would make a FastMCP client always effectively execute an arbitrary command which feels like a can of worms, especially because not all commands are stdio compatible -- let's think if there are ways to confine this. Otherwise I have no issue asking folks to import the correct transport for their use case.
@jlowin Yes, I agree you. there are some complex servers, not simple single server file, maybe need this...although there are another way to call, but this one is fast and simple. if you think strings is not good. Just think input is shell command. and check if command exist?
No, I don't see an advantage here - it is too magic. Inference works well if there is one clear option (e.g. a FastMCP instance must be in memory; a python path must be STDIO). Providing support for arbitrary commands and then running them as stdio creates a ton of really negative user experiences who provide commands that aren't starting stdio servers and end up with trapped error messages.
Without the clear hinting, and needing intense documentation to cover all the potential bad outcomes, it's difficult to argue that this is a better user experience than instantiating a StdioTransport itself.