Launchables MCP server
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LAUNCHABLES_MODEL | No | 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. | myles-g-12b |
| LAUNCHABLES_API_KEY | No | Your Launchables API key from the console (e.g. launchables_...). | |
| LAUNCHABLES_BASE_URL | No | The API base URL. Set it to your own address for a self-hosted deployment. | https://api.launchables.ai |
| LAUNCHABLES_API_TOKEN | No | An alternative name for the API key, as used by the Launchables SDKs. Works in place of LAUNCHABLES_API_KEY. | |
| LAUNCHABLES_THRESHOLD | No | 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. | 0.9 |
| LAUNCHABLES_ALLOW_HTTP | No | Set to 1 to allow a plain http:// base URL for a server not on the same machine. Without it, plain http is accepted only for a server on the same machine, because the key would otherwise cross the network unencrypted. | |
| LAUNCHABLES_TIMEOUT_MS | No | How long one attempt may take, in milliseconds. | 60000 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| decideA | 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:
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. |
| list_modelsA | 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. |
| healthA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
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.
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.
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.
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.