You're asking for something different here. What conda does is package all binary dependencies (e.g., libpq, cuda) that normally should be dynamically linked and provided by your OS.

The pip ecosystem (including uv) doesn't encourage this. Although you could and many have, the build tools don't support it as first class.

For why? Ask what happens if you want an updated version or specific version of CUDA? The library author must add support for runtime linking or users would have rebuild the entire conda package.

It's determinism, flexibility, and language.

To the LLM, the a skill input is deterministic, inflexible, and outputs natural language.

A REST API (not the REST itself, but modern output being JSON primitives) outputs are deterministic, flexible, but doesn't output natural language.

An MCP as an input is deterministic, flexible, outputs natural language.

Then we ask the same question on whether the LLM gets back a response that is deterministic. Skills output are not deterministic, it requires LLM to generate tokens to take action. It may or may not take the specific actions instructed by the skill.

So, Skills + REST API = MCP only if you can deterministically call on the REST API.

In other words:

* /skill may or may not call on the instructed action

* /tool (or @tool) will guarantee the action is taken

This is overgeneralizing and we need to talk about harness-specific features like hooks (which adds a deterministic action to skill usage).

You've misunderstood the GIL and Python threads.

For I/O, you can add threads and share the same connection object. Like any other languages, you are responsible for making it thread-safe.

There's also async. Many Python web apps spawn a thread per worker in your web server, not processes. Look into ASGI vs WSGI.

It's more so horizontal vs vertical scaling rather than languages.

You aren't running large scale xact/s on a single node.