Add sandbox MCP server with secure Python code execution

[florenzi002]

Adds sandbox for code execution in a python secure container via mcp (#166)
The main contribution is in mcp/servers/sandbox.

Downgrades required python version to >=3.12 for pydantic compatibility

Conceptually what is proposed in this PR is largely the same as what the mcp-sandbox utility provides. It exposes a couple of tools to run python code, either passed as string or file, in a dedicated lightweight and secure container.

this PR would work by registering the sandbox tools as top level mcp servers and could be reached by all the other tools, servers or agent, including the planner executor if needed.

[DhavalRepo18]

@florenzi002, in my understanding, if there is an existing MCP Server, do I need to write the code again, or is there an economic way of just registering it into the current ecosystem?

I was originally under the impression that - existing MCP server stays where they are, MCP client gets registered. And we do not need to write code.

[florenzi002]

@florenzi002, in my understanding, if there is an existing MCP Server, do I need to write the code again, or is there an economic way of just registering it into the current ecosystem?

I was originally under the impression that - existing MCP server stays where they are, MCP client gets registered. And we do not need to write code.

My understanding is that #166 was about registering a new MCP server to run code. This PR addresses the following in #166

Given that we are rebasing AssetOpsBench in the MCP-compliant environment, we would like to provide a Sandbox as part of the AssetOpsBench MCP echo system.

All the other servers stay the same, this is just an additional one registered alongside all the others e.g., utility server

[DhavalRepo18]

@florenzi002 I discussed this with @ShuxinLin, and I will be primarily reviewing this PR.

[DhavalRepo18]

@florenzi002 - Any further comments on what makes the existing MCP-Sandbox tough will be highly valuable.

#166 (comment)

[florenzi002]

@florenzi002 - Any further comments on what makes the existing MCP-Sandbox tough will be highly valuable.

#166 (comment)

@DhavalRepo18

I've found that sandbox-mcp is primarily a GO utility. This means a need to install a whole GO compiler for a single dependency. Then it doesn't provide a way to install a subset of the sandboxes, so it always install about 6GB of sandboxes some of which we would probably never use, i think for starter a python only sandbox is all we need. Furthermore the current AssetOpsBench can be used with both docker or podman backends while the proposed library works with docker only due to some hardcoded paths in the source code of the project, we would lose that flexibility; it is relevant because while docker offers a free tier, it is a commercial product and a part of the open source community is moving away (or required by institutions) to use open source alternatives like podman. Finally sandbox MCP seems to be stuck with development to May 2025 so I think this small in-house alternative might prove to be more stable.

Conceptually what is proposed in this PR is largely the same as what the library provides. Ultimately it expose a couple of tools to run python code, either passed as string or file, in a dedicated lightweight and secure container.

this PR would work by registering the sandbox tools as top level mcp servers and could be reached by all the other tools, servers or agent, including the planner executor if needed.

[DhavalRepo18]

• This PR needs test cases at the tool level testing.
• This PR also needs some example scenarios to be tested: where we typically download data from IoT and then perform the same data aggregation (obtain first-order statistics) using Python code sandbox. Some example query - ``Give me the mean and max value of temperature for Chiller 6.''
• The Docker should also expose the library available as a part of the MCP-doc string, and this will enable efficient coding at the LLM side
• version (typically we fix library version to avoid a mismatch in APIs, etc)