SDK and Building on MCS

Everything MCS does from the app, your own programs can do too.
The MCS SDK lets your software run a deliberation the same way a person would from the app: convene a panel, let the models work the problem under a moderator, and read back a result you can act on. Where the app gives a person a deliberation, the SDK gives your code one.
What the SDK Is
A small library, with a C API and a Python wrapper, that runs MCS sessions directly from your program. It is not a reimplementation of MCS. It drives the same engine as the app and the command line, so a panel behaves identically no matter how you start it. Your own models, your own keys, the same moderator-directed discussion. The library talks to the engine through a stable C interface, so the Python wrapper is simply one binding over it, and other language bindings can follow the same path.
Not an Orchestration Library
Developers who have built multi-model workflows know the usual shape: your application makes the model calls, holds the state, and coordinates the back-and-forth itself. The MCS SDK works the other way around. It does not ask your code to orchestrate anything. Your program starts a session and receives the result; the engine runs the deliberation, manages the discussion, and applies the moderator. You delegate the hard part instead of building it.
A Few Lines to a Result
In Python, a full session is short:
import mcs
mcs.init() # load your license
with mcs.start("mcs.conf", "session.conf") as session:
session.wait() # the panel deliberates to a conclusion
for path in session.output_files(): # read what the panel produced
print(path)
You describe the panel and the question in configuration, start the session, wait, and read the result. The deliberation runs as its own process; your program stays in control.
What You Can Build
Once a deliberation is a function call, it fits anywhere a single model's API would:
- Embed a panel inside your own product or internal tool.
- Add a deliberation step to a data pipeline that needs a checked answer, not a guess.
- Put a multi-model gate in your CI, so a risky change gets challenged before it merges.
- Run reviews in batch across many items, unattended.
Anywhere your code would call one model and hope, it can convene a panel instead.
Built for Automation
The SDK is made to run without a person watching. Start a session, wait for it to finish, read the outcome, and act on it in code. That turns MCS from a destination into a building block: a deliberation you can drop into the systems you already run.
Availability
SDK access is included with the Pro Max and Enterprise tiers, and can be added to the others. You install a single library and point it at an installed MCS engine; from there your C or Python program does the rest.
The Bottom Line
MCS is not only an app you open. It is a capability you can build on.
When your software reaches a decision where one model is not enough, it does not have to settle for one opinion. It can convene a panel, hear the deliberation, and act on a conclusion that has been challenged and defended.
Want to learn more about MCS?
