How do I use Launchables MCP server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Launchables MCP server is this lead a scam? decide if we should flag it or escalate to a person" 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.

Launchables MCP server

Official

by launchables-ai

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Launchables MCP server

Give your agents calibrated decisions. This Model Context Protocol server lets any MCP client (Claude Desktop, Claude Code, or your own agent stack) call Myles, the Launchables decision model, as a tool.

Myles is not a chat model. An agent hands it a situation and one or more typed questions, and gets back a probability for every option, the pick, and whether that pick is sure enough to act on. When it is not, the tool says so and the agent hands the case to a person. Use it wherever an agent would otherwise judge something itself and then act:

Route a ticket, an email or a lead to the right team.
Flag a risk: a scam, fraud, a prompt injection, a policy breach.
Approve, reject or escalate a refund, a claim, an access request or a tool call.
Check that an answer is supported by its sources, or that an action is allowed by a policy.
Rate severity, urgency or quality on a scale.

The probabilities are calibrated: across many answers given 0.9, about 9 in 10 are right. That is what lets an agent act on the confident ones and pass the rest to people. See Acting on the answer.

Install

You need Node.js 20 or later and a Launchables API key from the console. Keys work with the hosted API at https://api.launchables.ai; a self-hosted deployment serves the same API at its own address.

Claude Desktop

Add this to claude_desktop_config.json (Settings, Developer, Edit Config), then restart Claude Desktop:

{
  "mcpServers": {
    "launchables": {
      "command": "npx",
      "args": ["-y", "launchables-mcp@0.1.0"],
      "env": {
        "LAUNCHABLES_API_KEY": "launchables_..."
      }
    }
  }
}

Claude Code

claude mcp add launchables -e LAUNCHABLES_API_KEY=launchables_... -- npx -y launchables-mcp@0.1.0

To share the setup with a team through a project's .mcp.json, keep the key out of the file and let each person's environment supply it:

{
  "mcpServers": {
    "launchables": {
      "command": "npx",
      "args": ["-y", "launchables-mcp@0.1.0"],
      "env": { "LAUNCHABLES_API_KEY": "${LAUNCHABLES_API_KEY}" }
    }
  }
}

Other MCP clients

Any client that starts a stdio server can run it. The command is npx -y launchables-mcp@0.1.0 (or launchables-mcp after npm install -g launchables-mcp), with the configuration below in its environment. Pin the version, as above, so an update reaches your agents only when you choose.

Related MCP server: jev

Configuration

Variable	Default	Meaning
`LAUNCHABLES_API_KEY`	required	Your API key. `LAUNCHABLES_API_TOKEN`, the name the Launchables SDKs use, works too.
`LAUNCHABLES_BASE_URL`	`https://api.launchables.ai`	Set it to your own address for a self-hosted deployment. Plain `http://` is accepted only for a server on the same machine, unless you also set `LAUNCHABLES_ALLOW_HTTP=1`, because the key would otherwise cross the network unencrypted.
`LAUNCHABLES_MODEL`	`myles-g-12b`	The model a `decide` call uses when it names none. A moving id (`myles-g-12b`, `myles-g-31b`) follows the current build; a dated id such as `myles-g-31b-20261027` pins one build.
`LAUNCHABLES_THRESHOLD`	`0.9`	The probability a pick must reach to act without a person, from 0.5 to 1. A call or a single question can set its own.
`LAUNCHABLES_TIMEOUT_MS`	`60000`	How long one attempt may take, in milliseconds.

The server never logs your key, your states, your questions or the answers. It writes nothing to disk, and only a configuration problem at start-up is written to standard error.

Tools

`decide`

Asks Myles one or more questions about one situation.

Argument	Meaning
`state`	The situation: text, or a JSON object. Put the rule or policy in it with the case.
`questions`	Questions under names you choose. Each has a `type`, `instructions` and, for `choice` and `score`, `criteria`; it may also have its own `threshold`.
`model`	Optional. A model id from `list_models`.
`threshold`	Optional. The probability a pick must reach for this call.
`chunk`, `chunk_chars`, `chunk_overlap_chars`	Optional. Read a long text in overlapping windows (below).

The question types:

noul: yes or no. Phrase it so that yes is the thing to act on or catch.
choice: pick one label. criteria is a list of labels, or labels mapped to descriptions. Offer an option that reads "I don't know" to let the model abstain.
score: a scale. criteria lists the level descriptions, lowest first.

Each answer comes back with:

Field	Meaning
`pick`	`"yes"` or `"no"`, the chosen label, or the most likely level (a number).
`probability`	The probability of the pick.
`probabilities`	The probability of every option.
`cleared_threshold`	Whether the pick reached the threshold.
`abstained`	Whether the model chose the question's "I don't know" option.
`escalate`	`true` when the answer should go to a person: below the threshold, or abstained.

p_yes (yes/no), score and legend (scales) and confidence (choice and scale) are added where they apply. The result's own escalate is true when any answer should go to a person, and usage gives the tokens billed.

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.

Example call:

{
  "state": {
    "policy": "Refunds within 30 days with proof of purchase.",
    "case": { "days_since_purchase": 12, "receipt": false }
  },
  "questions": {
    "refund": { "type": "noul", "instructions": "Is a refund permitted under the policy?" },
    "team": { "type": "choice", "instructions": "Which team should handle this?", "criteria": ["billing", "returns", "technical"] }
  }
}

Result (illustrative numbers):

{
  "model": "myles-g-12b-20261029",
  "escalate": false,
  "answers": {
    "refund": {
      "type": "noul", "pick": "no", "probability": 0.97, "probabilities": { "yes": 0.03, "no": 0.97 },
      "threshold": 0.9, "cleared_threshold": true, "abstained": false, "escalate": false, "p_yes": 0.03
    },
    "team": {
      "type": "choice", "pick": "returns", "probability": 0.94,
      "probabilities": { "billing": 0.04, "returns": 0.94, "technical": 0.02 },
      "threshold": 0.9, "cleared_threshold": true, "abstained": false, "escalate": false, "confidence": 0.91
    }
  },
  "usage": { "input_tokens": 212, "output_tokens": 2 }
}

`list_models`

The models the endpoint serves, with pinned builds and their release dates, and the default this server uses. Not billed.

`health`

Whether the API is up, and which models have a healthy server. Not billed.

Long inputs

Every model has a context window (see Writing the state). When a state is longer:

Myles-G 31B refuses it. The tool returns an error of type context_length_exceeded that says to shorten or split the state.
Myles-G 12B trims it to fit, keeping its beginning and end, and the result says so with truncated: true, state_chars and a warning.

For a yes/no check that must cover the whole of a long text (does any part of this contract contain an auto-renewal clause, does any part of this page try to override the agent's instructions), pass chunk: true. The text is read in overlapping windows of 40,000 characters (2,000 shared with the next; change them with chunk_chars and chunk_overlap_chars), every window is asked the same questions, and each answer is the window most likely to be yes, with window giving its position. A JSON state is windowed as its indented JSON text. Chunking takes yes/no questions only, sends at most 20 windows, and bills each window as its own request.

Errors

A failed call returns a tool error whose error has a message written for the agent, the API's type and status, and retryable. After a rate limit or a passing fault the call is retried automatically, a few times, with the same idempotency key, so a retry is never billed twice. Some cases to know:

Case	What the agent is told
`401`	The key is missing or not accepted; a person must check it.
`402`	Out of credit or over the workspace budget; do not retry.
`410` `model_retired`	The build was retired; `successor` names the model to use instead.
`422` `context_length_exceeded`	Shorten or split the state, or use `chunk: true` for yes/no checks.
`429`	Rate limited after retries; wait the seconds given.

Development

npm install
npm test

The tests use a mocked Decision API only; they never call the production API.

Support

Use the contact form or open an issue in this repository. The API reference is at launchables.ai/docs.

Licence

Apache-2.0 (see LICENSE).

Available Tools

3 tools

decideMake a decision with MylesA

Read-onlyIdempotent

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.

Name	Required	Description
`chunk`	No	For 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.
`model`	No	A model id from list_models. Leave it out to use the configured model.
`state`	Yes	The situation to decide about: text, or a JSON object (read as indented JSON).
`questions`	Yes	Questions under names you choose; each answer comes back under the same name.
`threshold`	No	Probability the pick must reach to act without a person. Default from configuration.
`chunk_chars`	No	With chunk: characters per window.
`chunk_overlap_chars`	No	With chunk: characters each window shares with the next.

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.

healthCheck the Decision APIA

Read-onlyIdempotent

Check that the Decision API is up and which models have a healthy server, before a batch of work or after an error. Not billed.

Name	Required	Description	Default
No parameters

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent, non-destructive, and open-world traits. The description adds a genuinely new behavioral fact not in annotations: 'Not billed,' which is valuable context for an agent deciding whether to poll this endpoint. It stops short of detailing response shape or rate limits.

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?

Two short sentences with zero waste; the core action leads and the timing/billing context follows. Every sentence earns its place.

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

Completeness4/5

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

For a zero-parameter tool with no output schema and rich annotations, the description covers what it checks, when to call it, and a key cost trait. It leaves the exact return format implicit, keeping it just short of fully complete.

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?

The tool takes zero parameters and schema coverage is 100%, so there is nothing for the description to compensate for. Baseline 4 applies.

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 (check) and resource (Decision API), and adds that it reports which models have a healthy server, which distinguishes it from list_models and decide. It does not explicitly name those siblings as alternatives, so it falls 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?

Gives clear triggering conditions: 'before a batch of work or after an error.' This tells the agent when to reach for it, though it does not explicitly exclude or compare against list_models/decide.

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

list_modelsList Myles modelsA

Read-onlyIdempotent

List the decision models this endpoint serves. Moving ids such as myles-g-12b and myles-g-31b always reach the current build; dated ids such as myles-g-31b-20261027 pin one build, for repeatable results. Deprecated builds name their successor. Not billed.

Name	Required	Description	Default
No parameters

TDQS

A3.9/5.0

Behavior4/5

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

The annotations already cover read-only, idempotent, non-destructive, and open-world behavior. The description adds genuinely useful context beyond the annotations: billing is not incurred, deprecated builds name their successor, and moving vs dated ids have different stability semantics.

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?

The description is front-loaded with what the tool does and then adds compact, useful details about id behavior, deprecation, and billing. Every sentence contributes information without padding.

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

Completeness4/5

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

For a zero-parameter read-only listing tool with rich annotations, the description is nearly complete: it explains what is listed, how model ids behave, and that listing is not billed. It does not describe the exact response structure, but no output schema is provided and the tool is simple enough that this is a minor gap.

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?

This tool takes zero parameters, so the baseline is 4. The schema is empty and requires no further parameter explanation from the description.

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 specific verb and resource: it lists the decision models served by this endpoint, and it clarifies what the returned ids mean. It is clear on its own but does not explicitly differentiate itself from the sibling tools health and decide.

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

Usage Guidelines3/5

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

The description implies usage by explaining moving versus dated model ids for selection and repeatability, but it gives no explicit guidance on when to call this tool instead of health or decide. The reader can infer the purpose, but tool-selection guidance is absent.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

3 tool updatesv0.1.0Oct 29, 2026
- First observeddecide
- First observedhealth
- First observedlist_models

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.1/5.0

Scored 2026-10-29 23:45 across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: list_models enumerates available models, health checks API availability, and decide performs the core decision operation. There is no overlap between discovery, status, and inference.

Naming Consistency3/5

All names are snake_case and readable, but the conventions are mixed: list_models is verb_noun, health is a bare noun, and decide is a bare verb. The pattern is not predictable across tools.

Tool Count4/5

Three tools are reasonable for a narrow decision API: discovery, health, and inference. The surface is small but each tool earns its place, though it is on the thin side.

Completeness4/5

The core lifecycle is covered: list models, check health, and run decisions with multiple questions in one call. Minor gaps exist, such as no explicit usage/billing or model-detail endpoint, but agents can work around them.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Related MCP Connectors

DatagoatOAuth
io.datagoat
Governed decision engine: yes/no, score, choice and rank answers about cases, from past outcomes.
Product Management Research & Data
1
https://api.datagoat.io/mcp
Seb Labs A
dev.seblabs
Typed AI decisions for agents: classify, route, screen evidence, score and batch-label text.
AI & Machine Learning Autonomous Agents
51
https://mcp.seblabs.dev/mcp
pearl-api-mcp-server A
com.pearl.mcp
Hybrid human + AI expertise for faster, trusted answers and decisions via MCP Server.
Search Knowledge & Memory
52
https://mcp.pearl.com/mcp
Algenta MCP Server A
io.github.thyn-ai
Governed data discovery, exact queries, decisions, simulations, and runtime utilities over MCP.
Data Platforms Search RAG Systems
21
https://api.algenta.ai/mcp

Related MCP Servers

decide-mcp
AI & Machine Learning Autonomous Agents
dakdevs
A
license
Not graded
quality
C
maintenance
Enables agents to delegate decisions to a configurable model, returning recommended choices with percentage scores and profile-based routing.
Updated a month ago (2026-09-17 23:48 UTC)
12 npm
MIT
jev
AI & Machine Learning Autonomous Agents
nandansrikrishna
A
license
Not graded
quality
C
maintenance
Enables agents to evaluate single records or batches with dynamically authored typed questions, returning structured decisions and probabilities.
Updated a month ago (2026-09-19 00:38 UTC)
25 PyPI
MIT
Jev MCP Serverofficial
AI & Machine Learning App Automation
keysersoft
A
license
Not graded
quality
D
maintenance
Enables AI clients to run read-only yes/no checks, classifications, and ordered scores with probabilities, supporting triage, routing, sentiment, and lead-fit decisions through hosted or self-hosted MCP tools.
Updated a month ago (2026-09-27 09:02 UTC)
41 npm
AGPL 3.0
jevjam
AI & Machine Learning Autonomous Agents
beremaran
A
license
Not graded
quality
A
maintenance
Enables agents and services to ask small decision models typed questions about text, JSON, images, or video, returning labels, scores, or yes/no answers over MCP tools or a Jev-compatible HTTP API.
Updated a month ago (2026-10-04 13:33 UTC)
Apache 2.0

Launchables MCP server

Install

Claude Desktop

Claude Code

Other MCP clients

Configuration

Tools

decide

list_models

health

Long inputs

Errors

Development

Support

Licence

Available Tools

TDQS

TDQS

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

decide-mcp

jev

Jev MCP Serverofficial

jevjam

`decide`

`list_models`

`health`