layajev-mcp

decide

Read-onlyIdempotent

Choose between multiple plausible actions by returning calibrated probabilities for each option plus an act or escalate gate, so agents can resolve ambiguity or defer to a human.

Instructions

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.

Input Schema

TableJSON Schema

Name	Required	Description
`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'.

Output Schema

TableJSON Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 26, 2026

TDQS

A4.3/5.0

Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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.

Deploy Server