Mellix MCP server
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MELLIX_MODEL | No | The model a decide call uses when it names none. | myles-g-12b |
| MELLIX_API_KEY | No | Your Mellix API key. Required; alternatively, MELLIX_API_TOKEN works. | |
| MELLIX_BASE_URL | No | Set to your own address for a self-hosted deployment. Plain http:// is accepted only for a server on the same machine unless MELLIX_ALLOW_HTTP=1 is also set. | https://api.mellix.ai |
| MELLIX_API_TOKEN | No | The API token name used by the Mellix SDKs; works as an alternative to MELLIX_API_KEY. | |
| MELLIX_THRESHOLD | No | The probability a pick must reach to act without a person, from 0.5 to 1. | 0.9 |
| MELLIX_ALLOW_HTTP | No | Set to 1 to allow plain http:// for a remote Mellix server; otherwise http:// is accepted only for a server on the same machine. | |
| MELLIX_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.
Mellix gives agents calibrated decisions from Myles. Call decide when you need to route, flag, approve, reject, escalate or check something, and act on its answer only when escalate is false; otherwise hand the case to a person.
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 Mellix 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. A call that runs longer than 25 seconds in all, retries included, is stopped with a timeout error. |
| 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
The three tools serve clearly separate roles: a liveness probe, the core inference call, and model enumeration. There is no plausible way an agent confuses `decide` with either `health` or `list_models`, and the descriptions reinforce the boundaries.
All names are lowercase snake_case, which is consistent. `list_models` follows verb_noun while `health` is a bare noun and `decide` a bare verb, a minor deviation but still readable and idiomatic for a small API surface.
Three tools is on the thin side but each earns its place: the domain is a single inference endpoint plus two supporting utilities. Nothing feels padded, though the surface is minimal enough that any addition would be noticeable.
The core decision lifecycle (check availability, discover models, submit typed questions with thresholds and escalation) is covered, and batching is handled via multiple questions per call. Minor gaps remain: no async/job handling for the 25-second timeout, no way to retrieve past decisions or inspect billing/usage.