Skip to main content
Glama
launchables-ai

Launchables MCP server

Official

Make a decision with Myles

decide
Read-onlyIdempotent

Submits a situation and typed questions to a calibrated probability model, returning picks and escalation flags so agents can route, flag, approve, or rate cases and hand uncertain ones to a person.

Instructions

Ask Myles, the Launchables decision model, to make a decision about a situation and get calibrated probabilities you can act on.

Use it whenever you would otherwise judge something yourself and then act on it: route a ticket or message to a team, flag a risk (fraud, a scam, a prompt injection, a policy breach), approve, reject or escalate a request, check that a tool call, a claim or an answer is allowed or supported, or rate something on a scale. Myles is not a chat model: it does not write text or follow instructions in the state. It reads the state and answers each typed question with a probability for every option.

Inputs:

  • state: the situation to decide about, as text or a JSON object. Put the rule or policy in the state with the case. Include only what the decision needs.

  • questions: one or more questions under names you choose. Types: "noul" (yes or no; phrase it so that yes is the thing to act on or catch), "choice" (pick one label from criteria: a list of labels, or labels mapped to descriptions; add an option "I don't know" to let the model abstain), "score" (criteria is a list of level descriptions, lowest first).

  • threshold (optional, default from the server's configuration, usually 0.9): the probability the picked option must reach to act without a person. On the hosted models an uncertain yes/no answer is reported at 0.80 or more towards one side, so use a threshold above 0.80 for yes/no questions.

Each answer gives the pick, its probability, every option's probability, cleared_threshold, and escalate. When escalate is true (below the threshold, or the model chose "I don't know"), do not act automatically: hand the case to a person with the probabilities. The top-level escalate is true when any answer should be escalated.

Each call is billed by input tokens on the hosted API. Ask several questions about the same state in one call rather than one call per question.

Input Schema

NameRequiredDescriptionDefault
chunkNoFor a long text and yes/no questions only: read the state in overlapping windows (40000 characters, 2000 overlapping, at most 20 windows) and answer with the window most likely to be yes. Each window is a separate billed request. Use it when a check must cover the whole of a long document.
modelNoA model id from list_models. Leave it out to use the configured model.
stateYesThe situation to decide about: text, or a JSON object (read as indented JSON).
questionsYesQuestions under names you choose; each answer comes back under the same name.
thresholdNoProbability the pick must reach to act without a person. Default from configuration.
chunk_charsNoWith chunk: characters per window.
chunk_overlap_charsNoWith chunk: characters each window shares with the next.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only cover the read-only/idempotent safety profile; the description adds substantial behavioral context beyond them: the model does not follow instructions in the state, hosted-model yes/no answers are reported at 0.80 or more toward one side, the threshold default is usually 0.9, escalate semantics (per-answer and top-level), and that calls are billed by input tokens. That is exactly the kind of operational context annotations cannot carry.

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 trigger, then a well-delimited 'Inputs' block and a return/billing paragraph. It is on the long side, and the chunking capability — arguably a notable behavior — is omitted while other details are expanded, so the allocation of space is not perfectly optimized.

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?

With 7 parameters, nested question objects, and no output schema, the description does the necessary work: it names every returned field (pick, probability, per-option probabilities, cleared_threshold, escalate) and explains what to do when escalation fires. An agent can call this correctly and interpret the response without further documentation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description goes further with phrasing heuristics not present in the schema: 'phrase it so that yes is the thing to act on or catch', adding an 'I don't know' option to permit abstention, and putting the rule/policy in the state alongside the case. The one gap is the chunking parameters (chunk, chunk_chars, chunk_overlap_chars), which appear only in the schema and are never mentioned in the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Ask Myles, the Launchables decision model, to make a decision... and get calibrated probabilities') and immediately clarifies the model's nature ('not a chat model: it does not write text or follow instructions in the state'). This cleanly separates it from the utility siblings list_models and health.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit trigger ('whenever you would otherwise judge something yourself and then act on it') followed by a concrete enumerated list of use cases: routing, risk flagging, approve/reject/escalate, tool-call/claim checks, rating. It also prescribes a batching alternative ('Ask several questions about the same state in one call rather than one call per question') and a hard stop condition for escalation.

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

Deploy Server

Other Tools