feature: add configuration option for shell of stdio client

[fredericbarthelet]

This PR adds to StdioClientTransport a shell configuration option whose type match the spawn function parameter with the same name. The current value for this parameter is not configurable and always false. This default behavior is preserved.

Making this option configurable enables spawning MCP clients with shell execution capabilities. This is particularly useful for command chaining without having to rely on workarounds like /bin/sh -c 'cd myDirectory && npm run start'.

Motivation and Context

This change provides a clean, cross-platform way to enable shell execution by adding a shell parameter that accepts either a boolean (to use the default system shell) or a string (to specify a custom shell path).

For exemple, this current configuration:

const transport = new StdioClientTransport({
  command: "/bin/sh",
  args: ["-c", "npm i && npm run start"],
});

can be replaced with:

const transport = new StdioClientTransport({
  command: "npm i && npm run start",
  shell: true
});

which is cross-platform compatible

How Has This Been Tested?

No additional tests, the default behavior is preserved

Breaking Changes

No breaking changes. The shell parameter is optional and defaults to false, maintaining backward compatibility with existing implementations.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

[fredericbarthelet]

Hey @ihrpr, sorry for pinging. Any chance this option on STDIO transport could be added to the constructor interface :)? Thanks a lot!

[felixweinberger]

Hi @fredericbarthelet thank you for this contribution!

I think allowing arbitrary shell commands with chaining like this could make it easier to accidentally misuse and paste in a malicious CLI command from somewhere that can now be executed, though I guess on stdio this might be slightly less of a worry.

The syntax benefit seems minimal though while losing explicitness - e.g. if you wanted to run a different command on windows you could do something like this:

  {
    command: process.platform === 'win32' ? 'cmd.exe' : '/bin/sh',
    args: [process.platform === 'win32' ? '/c' : '-c', 'cd myDirectory && npm run start']
  }

We also explicitly set shell: false in the past specifically because it was causing lots of terminals to spawn on windows apparently (see #55)

Are there any specific features or needs you're unable to meet for your usecase without this?