Stage: alpha
v0.1| Python ≥ 3.9Reference SDK that showcases the MCS driver contract plus two first‑party drivers. Every driver ships as its own wheel. Install only what you need.
Large Language Models (LLMs) are powerful, but connecting them to external data sources (APIs, databases, bus systems) is often an ad-hoc process. The result: brittle prompts, hardcoded logic, and poor reusability.
The Model Context Standard (MCS) introduces a clean contract: the MCSDriver interface.
Your application no longer needs to know the API specifics. Instead:
- The driver contains the optimized prompts and execution logic.
- Your application talks to the driver interface only.
This makes the driver swappable and reusable. Prompt tuning and structured execution are handled in one place, not scattered across codebases.
Unlike MCP, no new protocol is required. At the end of the day, function calling connects a LLM with its environment. That makes this primarily a driver challenge, not a protocol stack challenge.
If you really need features provided by MCP (Model Context Protocol), MCS complements that by providing possible drivers or MCP using MCS compatible drivers.
But for most tool integrations, implementing a robust MCS driver is the pragmatic and efficient path.
Each part of the SDK is packaged independently. Install exactly what you need.
| Sub-directory / Project | PyPI Distribution | Purpose |
|---|---|---|
mcs-drivers-core/ |
mcs-drivers-core |
Defines the language-agnostic MCSDriver interface and metadata. |
mcs-driver-rest-http/ |
mcs-driver-rest-http |
A reference driver for connecting to REST APIs (OpenAPI). |
mcs-examples/ |
(not on PyPI) | A minimal client and FastAPI demo for local development. |
Why split packages?
The core contract is ~5 kB and has no runtime dependencies.
Only add the drivers your app truly needs.
python -m venv .venv && source .venv/bin/activate # Windows: .venv\Scripts\activate
pip install mcs-drivers-core mcs-driver-rest-httpThe interaction always follows this pattern:
- Get system prompt: Provided by the driver, tailored for your LLM.
- Run LLM: Send prompt + input to the LLM.
- Process response: The driver parses the LLM response and executes commands.
from mcs.drivers.rest_http import RestHttpDriver
driver = RestHttpDriver(urls=["https://example.com/openapi.json"])
# 1) Get the system prompt for the LLM
system_prompt = driver.get_driver_system_message()
# 2) Let the LLM use that system message (pseudo code)
llm_out = get_llm_response(system_prompt, "Find the email for Danny")
# 3) The driver executes any structured command in the LLM output
final_answer = driver.process_llm_response(llm_out)Once perfect prompts exist for a protocol and transport, they are encapsulated inside the driver. This avoids the burden to come up with prompts across apps again and again, this makes the logic reusable.
First time in history of function call it makes sense to get the perfect prompt for a use case, because once developed everyone can use it directly, without even knowing how it looks like.
With this interface using projects like DSPy to optimize prompts for different LLMs will make the effort pay off really quickly.
git clone https://github.com/modelcontextstandard/python-sdk.git python -m venv .venv && source .venv/bin/activate # Windows: .venv\Scripts\activate pip install -r requirements-dev.txt
Create a project with the name mcs-driver--
Like this: mcs-driver-filesystem-localfs - For LLM to access the local filesystem mcs-tool-filesystem-localfs - For a driver that must be used with an orchestrator mcs-tool-driver-filesystem-localfs - For a driver that is dual use
Execute python -m venv .venv && source .venv/bin/activate # Windows: .venv\Scripts\activate pip install mcs-drivers-core # Or create a requirements.txt file with the dependencies or a pyproject.toml file with the dependencies Create a README.md file with the information about the driver Create a LICENSE file with the license of the driver
Create the folder structure: src/mcs/drivers//init.py src/mcs/drivers//protocol>__driver.py
Because of Dank PEP 420 (Namespace Packages) we can't put an init.py file in src or src/mcs or src/mcs/drivers.
- Reliable, tested prompts: Drivers include system prompts that clearly describe the available tools and expected responses.
- Plug-and-play logic: Add or swap drivers without rewriting your app logic.
- Lean configuration: All setup is done via the driver constructor. Making it easy to use by an orchestrator with dependency injection.
- Shared ecosystem: Standard naming makes drivers easily discoverable via PyPI.
The SDK follows a consistent naming convention using PEP 420 namespace packages. This enables modular packaging and seamless discovery of drivers, tool drivers, and orchestrators.
| Component Type | PyPI Package Name Format | Python Namespace | Example |
|---|---|---|---|
| MCS Driver | mcs-driver-<protocol>-<transport>[-<variant>] |
mcs.drivers.<protocol>_<transport> |
mcs-driver-rest-http |
| MCS Tool Driver | mcs-tool-<protocol>-<transport>[-<variant>] |
mcs.tooldrivers.<protocol>_<transport> |
mcs-tool-rest-http |
| Hybrid Driver | mcs-tool-driver-<protocol>-<transport>[-<variant>] |
mcs.tooldrivers.<protocol>_<transport> |
mcs-tool-driver-rest-http |
| Orchestrator | mcs-orchestrator-<target> |
mcs.orchestrators.<target> |
mcs-orchestrator-openai-chatml |
If a name is already taken or the implementation is organization-specific, a custom prefix can be added, for example: mcs-driver-rest-http-<variant>.
This structure makes it easy to discover relevant packages using standard tools, like https://pypi.org/search.
There you can search for available drivers and orchestrators with the prefix
mcs-driver-
mcs-tool-
mcs-tool-driver- (if you need a dedicated hybrid driver)
mcs-orchestrator-
This naming scheme avoids the need for a central registry while maintaining clarity, searchability, and future extensibility. Tool drivers are expected to become the default in more complex setups due to their structured interface and better separation of concerns. The hybrid variant ensures backward compatibility and gradual transition.
Later it might be an interesting option to have a central registry for drivers and orchestrators, also to have a better control over the delopyment, security and versioning.
We welcome new drivers and improvements:
- pip install mcs-driver-core
- Implement the MCSDriver Interace and follow the naming conventions above
- Implement your driver under
mcs/drivers/<protocol>_<transport>_driver.py. - Publish to PyPI (using the naming scheme) or open a PR in this repo.
Distributed under Apache 2.0. See LICENSE for more information