oh-my-laya

Overview Schema Source Related Servers Discussions Admin

laya_tell_me

Run local typed decisions for bounded classification, ordered scoring, yes/no probability, and model advice via Laya-MLX; treat results as advisory, not authorization.

Instructions

Run a local typed decision with Laya-MLX.

Use for bounded classification, ordered scoring, and yes/no probability. Question types are choice, score, and noul. Treat results as advisory; never use them as authorization for destructive or consequential actions.

Unless advisor is provided, questions is required: an object keyed by question id. Each question requires type and instructions (use a string). choice requires criteria: a nonempty list of unique string labels or an object mapping labels to descriptions. score requires a nonempty criteria list ordered from lowest to highest. noul optionally accepts a criteria object with false/true descriptions. Use criteria, not options. Example: {"risk": {"type": "choice", "instructions": "Classify risk", "criteria": {"low": "Reversible documentation edit", "high": "Data loss"}}}.

For model advice, omit questions and pass advisor with models and current_model. Each host-verified model has id, reasoning_efforts (least to most), and an optional user-approved tier: fast, balanced, strong. No model is switched. For Alpha Squad, also pass role and verified current_reasoning_effort. Non-auto execution roles also require the confirmed session execution_choice pair; omit it for auto and reviewer routing. Returned delegation parameters are recommendations for the host's spawn call, never execution authorization. The current session is not changed.

Input Schema

Name	Required	Description	Default
`state`	Yes
`advisor`	No
`questions`	No
`orchestration`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv2.0.2Oct 19, 2026

addedInput schema / properties / advisor

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Advisor"
+}

addedInput schema / properties / orchestration

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Orchestration"
+}

removedInput schema / properties / questions / additionalProperties

Removed value: -{
-  "additionalProperties": true,
-  "type": "object"
-}

addedInput schema / properties / questions / anyOf

Added value: +[
+  {
+    "additionalProperties": {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    "type": "object"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / questions / default
```
Added value: +null
```
removedInput schema / properties / questions / type
```
Removed value: -"object"
```

changedInput schema / required

Previous value: -[
-  "state",
-  "questions"
-]New value: +[
+  "state"
+]

First observedv0.1.0Sep 23, 2026

TDQS

A3.8/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and discloses meaningful behavior: results are advisory, no model is switched, the current session is not changed, and returned delegation parameters are only recommendations, not authorization. It omits operational traits like latency, rate limits, or error behavior, but the side-effect profile is well covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and question-type usage before diving into field rules and the example. It is dense and uses sentence fragments, but nearly every sentence conveys a rule the agent needs, and the example is high-value for a schema-less parameter set.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is complex (dual-mode: questions vs advisor, 4 params at 0% schema coverage), and an output schema exists so return values need not be explained. The description covers the two primary modes well but silently omits the required 'state' param and the 'orchestration' param, so an agent cannot fully reconstruct a valid call from the documentation alone.

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 coverage is 0%, so the description must compensate, and it does richly for two params: it defines question types (choice/score/noul), required fields (type, instructions), criteria formats, the 'use criteria not options' rule, and an example, plus advisor fields (models, current_model, reasoning_efforts, tier, role, execution_choice). However, the required 'state' param and the 'orchestration' param are never explained at all, leaving major gaps at zero coverage.

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?

States a specific verb and resource ('Run a local typed decision with Laya-MLX') and enumerates the use cases (bounded classification, ordered scoring, yes/no probability). It is clear what the tool does, but it never names or contrasts the sibling laya_advisor_preferences, which handles the closely related preferences concern.

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?

Gives explicit when-to-use cases and a strong when-not-to-use caveat ('never use them as authorization for destructive or consequential actions'). It does not, however, route the agent to the sibling tool for preference-related needs, so the alternative-selection guidance is incomplete.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server