Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@layajev-mcp Should I fix the email bug, drop the field, or refuse the sale?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Calibrated probabilities for an agent's own options.
An agent reaches a decision it cannot resolve from the information it has: several courses of action are plausible, or none is clearly right. Asking a chat model is the slow, expensive way to settle that — and it returns prose, so the caller cannot tell a confident answer from a coin flip.
This is an MCP server that answers the question cheaply and returns numbers.
Give it a situation and a list of candidate actions; it comes back with a
probability for every option and a gate: act on the leader, or escalate
because the call is too close to make.
// decide(state="the test fails on a malformed email", options=["fix the email",
// "drop the field", "refuse the sale"])
{
"decision": "act", // or "escalate" — the useful half
"recommendation": "drop the field",
"confidence": 0.971,
"margin": 0.943,
"probabilities": {
"fix the email": 0.028,
"drop the field": 0.971,
"refuse the sale": 0.001
},
"backend": "laya"
}An agent that always takes the argmax will act on a 51/49 split and never notice
it guessed. escalate gives an ambiguous situation somewhere to go that is not a
coin flip, and the thresholds are the caller's to set.
Two numbers are checked, because they catch different failures:
catches | default | |
| the leader is not confident in absolute terms |
|
| the leader is barely ahead of the runner-up |
|
A 0.55 leader over a 0.45 second option passes a bare act_at test while being a
coin flip; margin is what refuses it.
Related MCP server: jev-mcp
Laya | Jev (TypeSafe) | |
runs | on this machine | remote HTTP |
costs | nothing | billed per call |
needs |
| an API key |
privacy | the state never leaves the box | the state is sent to a third party |
speed | one local forward pass | network round trip |
auto prefers Laya: it is free, private, and fast enough. Naming an engine that
cannot run is an error, never a silent substitution — quietly answering with a
different model than the caller asked for is how a wrong answer looks right.
Jev is reached through TYPESAFE_API_KEY, or through an OPENROUTER_API_KEY
with an openrouter.ai base URL, since OpenRouter mirrors the same product and
that is a way to use Jev with no new credential.
# local engine (pulls torch + the checkpoints)
pip install "layajev-mcp[laya]"
# remote engine only — no local weights, tiny install
pip install layajev-mcp
export TYPESAFE_API_KEY=...Wire it into any MCP client:
{ "mcpServers": { "layajev": { "command": "layajev-mcp" } } }tool | use it when |
| several actions are plausible, or none is clearly right |
| you have many questions about one state — one pass, all answers |
| you have more than ~20 candidates and need to narrow first |
| one yes/no with asymmetric costs — "is this irreversible?" |
| a decision call failed and you need to know why |
decide_many is the efficiency argument for using this at all. Question ids
stay on the caller's side and are never sent to the model, so N questions about
one state cost one forward pass, not N. That is the difference between this
and asking a chat model each question in turn.
Question types: choice (a label set), score (an ordered 2–10 scale), noul
(a yes/no returning P(true)).
// decide_many — three independent judgments, one call
{
"state": { "diff": "...", "test": "failing" },
"questions": {
"risk": { "type": "score", "instructions": "How risky is `diff` to ship?", "criteria": ["safe", "minor", "moderate", "dangerous"] },
"reversible": { "type": "noul", "instructions": "Is the change in `diff` reversible?" },
"owner": { "type": "choice", "instructions": "Which area does `diff` touch?", "criteria": { "api": "the HTTP surface", "db": "schema or queries", "ui": "the front end" } }
}
}The same decisions without an MCP client. The gate is also the exit code
(0 = act, 3 = escalate), so a shell script can drive it without parsing
anything.
layajev status
layajev decide --state "the test fails on a malformed email" \
--option "fix the email::resolve and pass the real address" \
--option "drop the field::Stripe does not require an email" \
--instruction "Which fix is correct for 'state'?"
layajev judge --state "<diff>" --question "is this change reversible?"Read this before trusting a number.
It is a decision model, not an oracle. The base checkpoint scores around
0.36 on typed decisions against 0.77 when fine-tuned per domain. Treat a
confident answer as a strong prior, not as ground truth — and escalate is the
branch for when it matters.
Confidence is not correctness. The confidence field describes how peaked
the distribution is. A peaked distribution over the wrong options is still
wrong, and it will look decisive.
Laya's shipped checkpoint warns on load that some of its temperatures are out of range, so treat confidence from the affected entries as uncalibrated. The warning is surfaced, not hidden — see it in stderr.
Non-Latin scripts collapse in the English checkpoint (measured: near-zero accuracy at high confidence). Use the multilingual checkpoint for those.
Past ~20 options a choice degrades, because options share a fixed token
budget. triage_options exists for exactly this — and it reports what it
discarded rather than cutting silently.
The threshold is always yours. No engine here returns a boolean, and none
should. act_at/margin/noul_act_at are how you say what a decision is
worth acting on.
laya-mcp-serverUpstream Laya ships its own MCP server exposing the raw primitives —
laya_predict, laya_route, laya_preset, laya_status. If those are what you
want, run that; it is installed by laya[mcp] and this package deliberately does
not re-implement it.
This is the layer above: what to ask, and what to do with the answer.
MCP 2025-06-18. Every tool declares an outputSchema and returns a matching
structuredContent, with the same JSON mirrored into a text block so clients
that predate structured output still receive something. Failures set isError
with the reason in the text, so a caller can tell a refusal from an empty result.
python -m pytest tests/ -qNo model, network, or API key is needed: both backends are faked at the
predict() boundary, so the suite covers the decision logic, the gate, the
validation, and the JSON-RPC surface without loading a checkpoint.
MIT.
Which decision engines can run here and why not, if one cannot. Call this first when a decision tool fails: it separates 'the model declined' from 'no engine is installed or configured', which need different fixes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| default | No | the backend used when none is named |
| version | Yes | |
| backends | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The read-only, idempotent, non-destructive annotations already cover safety. The description adds valuable behavioral context by stating that the tool explains why an engine cannot run and distinguishes 'model declined' from missing configuration, which is beyond what the annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. The first sentence states the tool's purpose, and the second provides the critical usage trigger and interpretation guidance. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter status tool with an output schema, the description is complete: it names the resource, the failure scenarios it disambiguates, and when to invoke it. Nothing needed for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully covers the input surface. The baseline of 4 applies; no additional parameter explanation is necessary or possible.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states exactly what the tool reports: which decision engines can run and why not. It distinguishes this status/diagnostic tool from the decision-execution siblings by framing it as the diagnostic step before decision tools are used.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells the agent when to call this tool: 'Call this first when a decision tool fails.' It also explains how the result guides the next action by separating two distinct failure causes, which is directly actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Choose between several courses of action and get a gated decision. Use when the task is ambiguous: more than one option is plausible, or none clearly is. Returns probabilities over every option plus 'act' or 'escalate' — escalate means it is too close to call and a human or a stronger model should decide. Cheap: a local call costs nothing and no state leaves this machine.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | The situation to decide on: a string, or an object of named facts. | |
| act_at | No | Probability the winner needs before acting. Default 0.65. Raise to make the agent ask more; lower to make it act more. | |
| margin | No | Lead over the runner-up needed before acting. Default 0.15. This is what stops a 55/45 split being treated as a decision. | |
| backend | No | Force an engine. Omit to use the default. An engine that cannot run is an error, never a silent substitute. | |
| options | Yes | The candidate actions. Give a description whenever the label alone could be read two ways. | |
| instruction | Yes | What is being decided, phrased as a question about the state. | |
| state_label | No | Key to file a plain-string state under, when the questions refer to it by name. Default 'state'. |
| Name | Required | Description |
|---|---|---|
| model | No | |
| margin | No | lead over the runner-up |
| reason | Yes | why the gate decided that way |
| backend | Yes | |
| decision | Yes | act when the winner cleared the gate; escalate when it did not |
| runner_up | No | |
| confidence | No | probability on the recommendation |
| probabilities | Yes | label -> probability, every option the caller offered |
| recommendation | No | the leading option |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavior beyond annotations: it returns probabilities plus 'act' or 'escalate', explains what escalation means, and notes the call is cheap, local, and sends no state off-machine. This is rich, non-obvious behavioral context that complements the read-only/idempotent annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each earning its place: what it does, when to use it, what it returns, and cost/privacy characteristics. The core purpose is front-loaded and there is no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for an agent selecting and invoking the tool: purpose, usage trigger, output semantics, and operational traits are all covered. The schema and output schema handle parameter details and return structure, so nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema carries full parameter documentation. The description adds no parameter-level meaning, which matches the baseline of 3 for fully covered schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource ('Choose between several courses of action and get a gated decision') and provides scope with the ambiguity condition. It does not explicitly distinguish itself from obvious siblings like decide_many or judge, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: use when the task is ambiguous and more than one option is plausible or none is clearly correct. It does not name alternatives or state when not to use this tool versus decide_many, so it lacks explicit exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask several independent questions about ONE state in a single pass. Question ids stay local, so N questions cost one model call, not N — this is the cheap way to get many judgments at once. Types: 'choice' (label + criteria map), 'score' (ordered list of 2-10 steps), 'noul' (a yes/no, returns P(true)).
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | The situation: a string, or an object of named facts. | |
| backend | No | ||
| questions | Yes | question name -> {type, instructions, criteria} | |
| state_label | No |
| Name | Required | Description |
|---|---|---|
| model | No | |
| usage | No | |
| answers | Yes | question name -> answer |
| backend | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value on top: question ids stay local to the call, 'noul' returns P(true), and 'score' expects an ordered list of 2-10 steps. These are behavioral facts beyond the structured fields and are consistent with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences, zero filler. The core purpose is front-loaded in sentence one, the cost justification in sentence two, and the type semantics in sentence three. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists (so return values needn't be described) and annotations cover the safety profile, the description covers the main usage pattern and the tricky question-type semantics. The only gaps are not naming the sibling decide for explicit routing and not explaining backend, but for a complex nested-parameter tool this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema coverage at 50%, the description must compensate, and it meaningfully does for the most complex parameter. It explains the three question types and their criteria shapes ('choice' label+criteria map, 'score' ordered 2-10 steps, 'noul' returns P(true)), which the schema only enumerates. It adds nothing about backend or state_label, but the questions parameter is the one that needed the semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states a specific verb+resource: 'Ask several independent questions about ONE state in a single pass.' It also distinguishes itself from the sibling decide by emphasizing the N-questions-one-call batching and 'cheap way' framing, so an agent can tell this is the multi-question counterpart without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use it: when you have several independent questions and want to save model calls ('N questions cost one model call, not N'). The 'independent' qualifier implicitly warns against batching dependent questions. However, it never names the alternative tool (decide) explicitly, nor states a when-not-to-use condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask one yes/no question and get P(true). Use for a risk check with asymmetric costs — 'might this destroy something?', 'is this irreversible?', 'does this violate the contract?' — where the rare yes matters more than the common no. Set the threshold yourself with noul_act_at; it defaults low (0.5).
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | The situation: a string, or an object of named facts. | |
| backend | No | ||
| question | Yes | The yes/no question about the state. | |
| noul_act_at | No | P(true) needed to answer yes. Default 0.5; lower is more cautious. | |
| state_label | No |
| Name | Required | Description |
|---|---|---|
| yes | Yes | |
| reason | No | |
| backend | Yes | |
| decision | Yes | |
| threshold | No | |
| probability | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior. The description adds valuable behavioral context beyond that: it returns P(true), and the threshold (noul_act_at) defaults to 0.5 with guidance to set it lower for caution. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, purpose first, with embedded examples and no filler. Every clause earns its place; it is tightly structured and immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter tool with an output schema, the description covers purpose, risk-check usage, and threshold behavior. However, backend and state_label are undocumented in both schema and description, which is a genuine gap for correct invocation. The described parts are complete, but the whole tool is not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 60% (state, question, noul_act_at are described). The description reinforces noul_act_at's meaning and clarifies question is yes/no, but it does not add any meaning for backend or state_label, leaving those parameters ambiguous. Partial compensation, not complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource pair ('Ask one yes/no question and get P(true)') and gives concrete risk-check examples that distinguish it from decide/triage tools. It does not explicitly name a sibling alternative, so it falls short of full differentiation, but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use context: risk checks with asymmetric costs where the rare yes matters more than the common no, illustrated with concrete questions. It does not mention when not to use the tool or name alternatives, so exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Narrow a LONG list of options and then decide over the survivors. Use when you have more than about twenty candidates: a choice question loses accuracy past that, so this scores them all, keeps the strongest few, and decides over those. The shortlist and what was discarded are both returned, so the cut is visible.
| Name | Required | Description | Default |
|---|---|---|---|
| keep | No | How many to carry into the decision. Default 5, max 20. | |
| state | Yes | The situation: a string, or an object of named facts. | |
| act_at | No | ||
| margin | No | ||
| backend | No | ||
| options | Yes | All candidates (labels or {label, description}). | |
| instruction | Yes |
| Name | Required | Description |
|---|---|---|
| model | No | |
| margin | No | lead over the runner-up |
| reason | Yes | why the gate decided that way |
| backend | Yes | |
| decision | Yes | act when the winner cleared the gate; escalate when it did not |
| runner_up | No | |
| confidence | No | probability on the recommendation |
| probabilities | Yes | label -> probability, every option the caller offered |
| recommendation | No | the leading option |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is known. The description adds meaningful process detail: it scores all options, retains the strongest few, and decides over those, with both kept and discarded returned. This goes beyond the annotations by describing internal behavior and output visibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. The primary purpose and usage trigger are front-loaded, and the second sentence adds a valuable transparency detail. Every phrase earns its place; no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists (so return format is not needed), the description is incomplete for correct invocation. Several parameters (act_at, margin, backend) are unexplained in both schema and description, and the description does not clarify how to construct the state or instruction fields beyond minimal schema hints. The high-level workflow is clear, but the tool's full input contract remains opaque.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 43% (3 of 7 parameters have descriptions). The description does not compensate: it never mentions act_at, margin, backend, or clarifies instruction beyond the schema. It implies the meaning of 'keep' and 'options' only indirectly, but the undocumented parameters remain a significant gap for an agent trying to invoke the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific two-step action (narrow then decide) on a resource (options), and gives a concrete trigger threshold (>20 candidates). It clearly distinguishes the tool's purpose from typical decision tools by focusing on large lists, which differentiates it from siblings like decide or decide_many without needing to name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides an explicit usage condition: use when there are more than about twenty candidates, because accuracy degrades beyond that. It does not explicitly name alternative tools or state when NOT to use it, but the threshold serves as a clear guideline. The note about returning the shortlist and discarded items also hints at transparency expectations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0backend_statusdecidedecide_manyjudgetriage_optionsScored across 5 tools
Each tool has a clearly distinct purpose: backend_status diagnoses engine availability, decide handles general ambiguous choices, decide_many batches independent questions, triage_options narrows large option sets, and judge handles yes/no risk checks. The descriptions emphasize when to use each, making misselection unlikely.
All tool names use snake_case and are concise, but they mix verbs (decide, judge) and nouns (backend_status, triage_options). The pattern is mostly verb-driven, with backend_status being the outlier as a status query, but the style is consistent and readable.
Five tools is well-scoped for a decision-support server. Each tool covers a distinct aspect of the decision lifecycle (status, single decision, batch, triage, binary risk), and none feels redundant or missing.
The surface covers the core decision-making workflow: checking engine availability, making single or batched decisions, handling large option sets, and binary risk assessment. Minor gaps like a history or explanation tool could be added, but the current set is functionally complete for its stated purpose.
Deterministic contextual decision arbitration and action routing for autonomous software. Takes current state, context, or intent plus caller-supplied candidate actions, state transitions, routes, refusals, escalations, tools, or models and returns a deterministic ordered candidate field. Also provides persistent machine representations for memory, retrieval, indexing, and downstream coherence measurement.
Human-in-the-loop for AI agents. Submit choices, get a human decision.
Calibrated probabilistic foresight for AI agents, powered by live prediction-market signal.
The decision layer for AI agents: act, escalate or refuse, and every decision comes back signed.
