Blog
Your app has an MCP server. Next, it could publish its decision space.
Reading time.
Wrtitten by
Kamil Bennani-Smires
Artificial Intelligence
A new kind of model
Over the last two years, many popular applications shipped an MCP server. Plug your CRM, your project tracker, or your smart home into an LLM, and the model can read your data and take actions. That makes sense: LLMs are the most general way to let AI drive software, so the protocol is built around them.
Decision models don’t write text at all. You give it some state and a set of typed questions, and it returns typed answers with calibrated probabilities in milliseconds, for a fraction of an LLM’s cost.
Several already exist. Open-weight models such as Cloudflare’s Clef, Perplexity’s pplx-decider and Laya can run on your own hardware, served by Ollama or llama.cpp. Hosted options include TypeSafe AI’s Jev, launched in September 2026. Most of them accept the same /v1/systemone request format, which is becoming a de facto standard.
These decision models are great at the small choices that make automation work: which option, which category, yes or no. But someone has to write the questions and list the options. Today that someone is you, the integrator. We think that is the missing piece, and that applications themselves are best placed to fill it.
For a chat assistant handling a few requests a minute, an LLM filling a tool call is often good enough. Decision models pay off in high-volume, latency-sensitive automation, where their speed and cost add up.
Where decision models really shine: labels that move
A decision model only picks from the options you give it. When those options never change, a decision model can certainly do the job, but it isn’t the only option. Routing tickets into five fixed categories is also a job for a small fine-tuned classifier: train or fine-tune once and forget.
The interesting case is when the options change all the time. Take a smart home platform. The valid answers depend on whose home it is and on the moment:
Which devices does this home have? Every home is different, and devices get added, renamed and moved between rooms.
Which scenes has this family created? “Movie night” or “Leaving home” mean something different in every house, and they evolve.
What state is each device in right now? Which lights are on and which blinds are open changes by the minute.
Retraining a classifier every time a user’s options change would be a constant overhead. A decision model needs no training: it reads the options at call time. In that sense, we see decision models as powerful zero-shot classifiers. That is the sweet spot.
There is one constraint. Decision models work on bounded option lists; Jev’s choice questions accept up to 255 options. A platform’s millions of connected devices won’t fit, but one home’s few dozen will. The application is the right place to narrow the list, because it already knows who is asking, what they may control (a child’s account may not unlock the front door), and what is relevant right now.
Part 1: the app hands you the questions
To start, imagine a smart home platform publishing one extra thing per action next to some of its MCP tools: a decision spec, already filled with live options.
Say someone tells the kitchen speaker: “Turn off the lights in the kids’ room and close the blinds downstairs.” You send that sentence to the authenticated platform’s spec endpoint for control_devices. It sends back a ready-to-send /v1/systemone request, built for this home at this moment:
Simplified for readability; in practice each device and option would carry a short plain-language description, such as which floor the room is on.
Two things happened here that you didn’t have to do. The questions are this home’s devices, under the names this family gave them, limited to what this account may control. And each device’s options follow its current state: the kids’ lights are on, so the only change offered is turning them off. Decision models don’t generate values, so turning a live situation into a closed set of choices is exactly the app’s job.
In some scenarios, the app could go one step further. Beyond the right questions and options, it could also enrich the state with context the caller doesn’t have, beyond the user’s message, whenever that context is needed or would help make the decision.
You forward the request to the decision model of your choice and get typed answers back, each with a confidence. From there you’re in charge: call the platform’s API or MCP tool yourself, ask the user to confirm when confidence is low, or feed the result into another system entirely.
Part 2: the app also executes
We could go further and let the app execute the action too. The first steps don’t change: you ask for the spec, then call your decision model. But instead of executing yourself, you send the answers back (sound familiar…right?). The platform switches off the two lights, closes the downstairs blinds and returns the new state of each device.
Using a decision model to call functions isn’t a new idea in itself: TypeSafe’s own function-calling cookbook already turns natural-language requests into typed function calls. But there, the integrator writes every question and wires every function, for each application. What we suggest is a standard, where the application provider exposes the spec and the execution once, and anyone can use them.
Going further: systems that run on decisions alone
And we could go even further. Routing a request to the right action with a decision model is already possible today; TypeSafe documents it as an intent routing pattern. What’s missing is, again, the standard. If application providers published their actions this way, routing would just be one more spec, whose options are the actions themselves.
“Turn off the lights in the kids’ room” would land on control_devices, and "start movie night" on run_scene, which in turn would offer this family's own scenes. Chained together, these could form whole subsystems, like a home assistant that picks the action, the devices and the scene, and only asks back when it's unsure, running on decision models alone. LLMs would stay where they shine, writing and open-ended reasoning, while decision models handle the thousands of small choices around them.
Where this could live
We don’t think this needs a brand-new protocol. Applications already ship MCP servers, and MCP already describes actions with typed inputs. Two paths seem natural:
Extend MCP. Each tool could advertise a decision spec next to its input schema, with a description for every option, a way to fetch live options and, optionally, extra context that could help make the decision.
Add a new kind of endpoint. Alongside the MCP server, a small decisions endpoint: give it an action and a request, get back a
/v1/systemone-ready question set, and optionally post the answers back to execute.
The idea goes well beyond smart homes. An HR platform could publish the leave types an employee’s contract allows. A CRM could publish a sales rep’s open deals as the options for “which deal is this email about?”. A semantic layer could publish the metrics and dimensions a user may query, so “revenue by region last quarter” becomes a typed query with no SQL written. Early community projects such as semantic-jev already do this for semantic layers, but by hand, one integration at a time.
A suggestion, and an invitation
Let’s be clear about the scope. For most scenarios, LLMs will keep shining, and Part 2, especially the decision-only systems of “Going further,” is admittedly a stretch today. Part 1, however, is valuable on its own: when all you need is a classification, getting the live labels and the right context straight from the application already saves real work.
None of this exists as a standard yet. Decision models have only recently become popular, and the ecosystem around them focuses on calling the model, not on applications describing their own decisions.
We think that will change. MCP made applications usable by LLMs. Publishing decisions space would make them usable by models that are faster, cheaper, and can’t answer outside the options they’re given. Applications are best placed to do it, because only they know their live options, per user and over time. If you build or own an application where you think this is relevant, consider this an invitation.
Sources
Awesome Decision Models, a community list of hosted and open-weight decision models and runtimes
Introducing System One Models & Jev, TypeSafe AI
Function calling cookbook, TypeSafe documentation
semantic-jev, GitHub
Written by
Kamil Bennani-Smires
Head of AI
Download
