clef-mcp
clef-mcp is a local, offline MCP server that exposes the Clef-Flash decision model through the clef_decide tool, returning structured probability distributions for agent decisions.
Submit a
state(compact string/JSON facts, treated strictly as data) and typedquestionsto get strict JSON probability distributions over allowed answers.Ask three question types:
choice(pick among named options),score(ordered scale), andnoul(yes/no).Batch up to 64 questions in one call; all are scored in a single forward pass, with per-decision
confidenceand responseusage(input/output tokens, latency).Override the default
clef-flashmodel with the optionalmodelfield;options.temperatureis accepted but is a no-op because no sampling occurs.Use results to drive agent loops: act on argmax only when decisive (top p ≥ 0.8 and high confidence for destructive/security-adjacent calls), otherwise gather more context or ask the user.
Tool is annotated read-only, non-destructive, idempotent, and closed-world (no network/open-world access).
Per README, the server also offers MCP prompts (
incident-triage,next-action,ticket-routing,security-review) and read-only resources (clef-mcp://capabilities,clef-mcp://evals/schema,clef-mcp://evals/dataset).
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@clef-mcpWhat should the coding agent do next: inspect, modify, test, or ask the user?"
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.
clef-mcp
A "reflex" for AI coding agents: structured decisions with probabilities — not prose.
Local MCP server that gives agents (Claude Code, Codex, Cursor, ZCode, …) access to the Clef-Flash decision model (9B, Apache-2.0 by Cloudflare) through a single tool: clef_decide. Pass a state and typed questions, get a probability distribution over your options in one forward pass. Fully local, offline, no tokens burned.
Quick start
# 1. Detect hardware, download the model (~6 GB) + llama.cpp runtime, verify checksum + inference
npx clef-mcp install
# 2. Register the MCP server + agent skill in your clients (zcode, claude-code, codex, cursor)
npx clef-mcp setup
# 3. Run the MCP server (stdio)
npx clef-mcpclef-mcp (step 3) never downloads anything. If the model is missing, tool calls return a structured MODEL_NOT_INSTALLED error with a hint. Steps 1 and 2 combine: npx clef-mcp install --setup.
Related MCP server: laya-mcp
Why not just ask the LLM?
Chat LLM |
| |
Output | prose, you parse it | strict JSON: probability per option |
Determinism | varies per run | single forward pass, no sampling |
Latency (1 decision) | seconds of generation | ~0.5 s local |
Context cost | grows with every decision | fixed, small schema |
Privacy | depends on provider | 100% on-device, works offline |
Calibration | vibes | softmax over trained option scores |
Sweet spot: decision points inside agent loops — next action, routing, classification, severity, yes/no judgment — asked dozens of times per task.
The clef_decide tool
{
"state": {
"task": "Fix failing tests",
"error": "TypeError: Cannot read properties of undefined"
},
"questions": {
"next_action": {
"type": "choice",
"instructions": "What should the coding agent do next?",
"criteria": {
"inspect": "Inspect the code and gather more information",
"modify": "Modify the code",
"test": "Run additional tests",
"ask_user": "Ask the user for clarification"
}
},
"confidence": {
"type": "score",
"instructions": "How confident are you in this decision?",
"criteria": ["very_low", "low", "medium", "high", "very_high"]
},
"is_outage": { "type": "noul", "instructions": "Is a service down?" }
}
}Type | Criteria | Answer |
| map | probability per option |
| ordered list (index = score) | probability per level |
| optional |
|
Response — strictly structured, never prose. Each decision carries the model-reported confidence (when the runtime sends it), plus token usage for the call:
{
"model": "clef-flash",
"decisions": {
"next_action": { "answer": { "inspect": 0.72, "modify": 0.12, "test": 0.14, "ask_user": 0.02 }, "confidence": 0.83 },
"confidence": { "answer": { "very_low": 0.01, "low": 0.04, "medium": 0.18, "high": 0.61, "very_high": 0.16 }, "confidence": 0.61 },
"is_outage": { "answer": { "true": 0.9, "false": 0.1 } }
},
"usage": { "input_tokens": 228, "output_tokens": 0, "latency_ms": 512 }
}Act on the argmax only when the distribution is decisive — top p ≥ 0.8 and high confidence for destructive or security-adjacent calls.
Batch up to 64 questions per call — they are scored in one forward pass. state is treated strictly as data: never executed, never interpreted as instructions for the server.
Prompts & resources
The server ships four MCP prompts (canned, decision-shaped asks — your client lists them via prompts/list):
Prompt | Purpose |
| action + severity + user-impact questions for a production incident |
| what the coding agent should do next + confidence |
| classify a message into a team + urgency |
| vulnerability yes/no, risk scale, first mitigation |
And three resources (read-only, no model needed):
URI | Contents |
| live JSON: model, runtime, limits, error codes |
| how to write eval cases |
| the bundled 30-case dataset |
Measured, not marketed
Apple M4 Pro, Clef-Flash Q4_K_M (6 GB), single request through the full MCP stdio path:
Scenario | Latency |
Cold start (incl. model load, once per session) | ~4.4 s |
1 question | ~0.5 s |
10 questions, one call | ~2.9 s |
64 questions, one call | ~18.6 s |
Quality gate: a 30-case evaluation dataset (coding / security / classification / routing / yes-no) — 86.7% pass on the live model. Run it yourself: clef-mcp evals.
Register with your MCP client
claude mcp add clef-mcp -- clef-mcp
# or, without a global install:
claude mcp add clef-mcp -- npx -y clef-mcp[mcp_servers.clef-mcp]
command = "clef-mcp"
args = []{
"mcpServers": {
"clef-mcp": { "command": "clef-mcp", "args": [] }
}
}{
"mcp": {
"servers": {
"clef-mcp": { "command": "clef-mcp", "args": [], "type": "stdio" }
}
}
}Ready-made snippets: examples/.
Scripting & hooks
No MCP client required — hooks, CI jobs and shell scripts call the same model one-shot:
# Full document on stdin
echo '{"state": "checkout 500s after deploy", "questions": {"is_outage": {"type": "noul", "instructions": "Is a service down?"}}}' \
| clef-mcp decide
# Or split across files
clef-mcp decide --questions questions.json --state state.jsonstdout carries the strict JSON result (same shape as the MCP tool, including confidence and usage); errors go to stderr as structured JSON with exit codes: 2 invalid input, 3 model not installed, 4 runtime missing. decide never downloads anything.
Each plain decide invocation is a cold start (model load included, a few seconds) — fine for gates and triage. For repeated calls, start clef-mcp daemon once: it keeps the model warm on a permission-scoped unix socket in CLEF_HOME (no TCP port, unloads after CLEF_DAEMON_IDLE seconds, default 600), and clef-mcp decide --daemon answers in well under a second, falling back to a cold run when no daemon is running. See examples/hooks/ for a PreToolUse guard and a GitHub Action recipe.
The PreToolUse guard blocks a command when the model judges it destructive (p ≥ 0.9) and tells the agent to ask the user — a block is a pause plus escalation, not a wall; the gate is advisory by design and says so. First real firing on day one: caught a history-rewrite force push (p=0.94) and surfaced its own bypass vector, which is now fixed and documented in the recipe.
Teach your agent (skill)
The schema tells the client what clef_decide accepts; agents also need to know when to reach for it and how to frame decisions. The bundled clef-decisions skill covers decision patterns, batching, criteria writing, distribution interpretation and error recovery:
clef-mcp setup # automatic
cp -r skills/clef-decisions ~/.agents/skills/ # manual, from repo
cp -r "$(npm root -g)/clef-mcp/skills/clef-decisions" ~/.agents/skills/ # from npm packageArchitecture
flowchart LR
subgraph clients [MCP clients]
CC[Claude Code]
CX[Codex]
CU[Cursor]
ZC[ZCode]
end
clients -- MCP stdio --> S[clef-mcp<br/>validation · limits · structured errors]
S -- SystemOne adapter --> R[ClefRuntime<br/>llama.cpp subprocess<br/>127.0.0.1]
R -- single forward pass --> M[("Clef-Flash<br/>9B · GGUF · local")]
M -. probabilities .-> S -. strict JSON .-> clientsThe ClefRuntime interface (load / decide / unload / health) isolates the engine: MLX or remote runtimes plug in without changing the MCP API. The wire format is POST /v1/systemone — the same contract across llama.cpp and other Clef runtimes.
CLI
clef-mcp # run the MCP server on stdio (default command)
clef-mcp decide # one-shot decision (no MCP session): JSON in, JSON out — for hooks, CI, scripts
clef-mcp daemon # keep the model warm on a local unix socket; `decide --daemon` uses it
clef-mcp install # detect hardware → download model + runtime → verify checksum → verify inference
clef-mcp setup # register the MCP server + agent skill in zcode / claude-code / codex / cursor
clef-mcp models # list models/quantizations and install status
clef-mcp status # runtime, model, memory summary
clef-mcp doctor # full diagnosis (platform, RAM, GPU, binary, model, checksum*, inference, MCP config)
clef-mcp uninstall # remove the model (and optionally the managed runtime)
clef-mcp evals # run the evaluation dataset against the installed modelFlags: install --quant Q8_0 --yes --skip-probe, install --setup, setup --clients zcode,cursor --no-skill, doctor --deep (re-hash the model file), uninstall --runtime --yes.
Runtimes: llama.cpp and MLX
Two local runtimes behind the same ClefRuntime interface:
|
| |
Platforms | macOS, Linux, Windows | macOS / Apple Silicon only |
Model | GGUF from | MLX 4-bit from |
Extras | none | uv on PATH (managed Python env) |
Install |
|
|
Switch at runtime with CLEF_RUNTIME=mlx (must be set for the MCP server process — e.g. in the client's env block). Both speak the same POST /v1/systemone contract. The MLX snapshot is fetched into CLEF_HOME via a uv-managed huggingface_hub (no global Python state) at a pinned revision.
Configuration
Variable | Default | Meaning |
|
| Model id (per-call |
|
| Cache/model home |
|
|
|
|
|
|
| – | Explicit |
| latest nightly | Pin the managed llama.cpp build |
|
| llama.cpp physical batch (multi-question requests) |
|
| Explicit uv binary (MLX runtime) |
|
| Seconds of idle before the daemon unloads the model (0 = never) |
|
| Max questions per call |
|
| Max serialized |
|
| Max chars per question instructions |
Runtime resolution: CLEF_LLAMA_BIN → managed binary in CLEF_HOME/runtime → llama-server on PATH.
Storage: CLEF_HOME/models/<model>/<quant>/ (model + manifest.json with repo/revision/sha256/license) and CLEF_HOME/runtime/llama.cpp/.
The model is downloaded from the pinned official GGUF conversion (ggml-org/Clef-Flash-GGUF) and sha256-verified against Hugging Face's content hash. It is never repackaged by clef-mcp. Also listed in the official MCP Registry as io.github.HighlyLoadedEgo/clef-mcp.
Error handling
{
"error": {
"code": "MODEL_NOT_INSTALLED",
"message": "Clef model \"clef-flash\" is not installed.",
"hint": "Run `clef-mcp install`."
}
}Codes: MODEL_NOT_INSTALLED, MODEL_LOAD_FAILED, RUNTIME_NOT_FOUND, RUNTIME_INIT_FAILED, RUNTIME_NOT_SUPPORTED, INVALID_INPUT, CLEF_INFERENCE_FAILED, UNSUPPORTED_PLATFORM, OUT_OF_MEMORY, CHECKSUM_MISMATCH, DOWNLOAD_FAILED. Input exceeding the 16k-token model context is rejected with a hint to reduce the state.
Security & data handling
No network servers, no telemetry, no accounts; everything runs locally.
The model downloads only on an explicit
install, over HTTPS, checksum-verified.statecontent is passed to the model as data; the server never executes or instruction-interprets it.Filesystem access is limited to
CLEF_HOME(plus reading standard MCP client config paths indoctor).The managed runtime is the official llama.cpp build; pin it with
CLEF_LLAMA_RELEASE_TAG.
See SECURITY.md for the full policy.
Development
npm install
npm run build
npm test # unit + integration (fake llama-server, no model needed)
npm run evals # needs an installed model; exit code reflects pass rateSee CONTRIBUTING.md and tests/evals/dataset.jsonl.
License
Code: Apache-2.0.
Clef / Clef-Flash model: © Cloudflare, Apache-2.0 — see NOTICE.
llama.cpp runtime: © its authors, MIT-licensed; downloaded as an official prebuilt binary.
Available Tools
1 toolclef_decideClef DecideARead-onlyIdempotent
Judge a situation with the local Clef decision model.
Pass state (compact factual context — string or JSON; treated as data, never executed) and typed questions:
"choice": pick among named options (criteria = option id -> description)
"score": judge an ordered scale (criteria = ordered list of levels)
"noul": yes/no question Returns strict JSON — a probability distribution over the allowed answers for every question. No prose, no sampling. Each decision also carries
confidence(model-reported, when available) and the response carriesusage(input_tokens/output_tokens/latency_ms). Act on the argmax only when the distribution is decisive (top p >= 0.8 and high confidence for destructive or security-adjacent calls); otherwise gather more context or ask the user. Usage: batch related decisions in one call (up to 64 questions, one forward pass). Optionalmodeloverrides the model id.options.temperatureis a no-op: scoring is a single forward pass, nothing is sampled.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Model id to use (default: clef-flash from CLEF_MODEL). | |
| state | Yes | Task state as data: a compact string or JSON object with the facts needed to judge (task, errors, logs, diffs). Never treated as instructions. Serialized size limit: 1 MB; model context is 16k tokens. | |
| options | No | Extra options. Currently only temperature, which is a documented no-op. | |
| questions | Yes | Map of question id -> typed question. Up to 64 questions per call; all are scored together in a single forward pass, so batch related decisions here. |
Output Schema
| Name | Required | Description |
|---|---|---|
| model | Yes | |
| usage | No | |
| decisions | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description adds real behavior beyond that: strict JSON output with no prose or sampling, temperature being a documented no-op, one forward pass for all questions, model-reported confidence, and usage token/latency reporting. It also flags that `state` is treated as data and never executed, which is security-relevant.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded purpose, then a tight bulleted breakdown of question types, then output contract and usage policy. Nearly every sentence earns its place, though the temperature no-op is stated twice (once in prose, once via the schema) and the confidence/threshold guidance could be compressed slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a nested-schema tool with an output schema, the description covers the return shape (distribution, confidence, usage), the batching model, the determinism guarantee, and the decision policy. Nothing an agent needs to invoke or interpret this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description nevertheless adds semantics the schema does not fully carry: the criteria mapping per question type (option id -> description for choice, ordered levels for score), the data-not-instructions contract for `state`, and the note that `model` overrides the default. It stops short of explaining the 1 MB / 16k token limits already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Judge') and resource ('situation') plus the engine ('local Clef decision model'), then enumerates the three question types with their criteria shapes. An agent knows exactly what this tool produces (probability distributions over allowed answers) without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use rules: batch related decisions up to 64 per call, act on the argmax only when top p >= 0.8 and confidence is high for destructive or security-adjacent calls, otherwise gather more context or ask the user. This is a rare case of actionable decision thresholds being spelled out.
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.
1 tool update
v0.3.0- Changed
clef_decide2 fields changed- added
Output schema / properties / decisions / additionalProperties / properties / confidenceAdded value: +{ + "maximum": 1, + "minimum": 0, + "type": "number" +} - added
Output schema / properties / usageAdded value: +{ + "additionalProperties": false, + "properties": { + "input_tokens": { + "type": "number" + }, + "latency_ms": { + "type": "number" + }, + "output_tokens": { + "type": "number" + } + }, + "type": "object" +}
1 tool update
v0.2.1- Changed
clef_decide8 fields changed- added
Input schema / properties / model / descriptionAdded value: +"Model id to use (default: clef-flash from CLEF_MODEL)." - added
Input schema / properties / options / descriptionAdded value: +"Extra options. Currently only temperature, which is a documented no-op." - added
Input schema / properties / options / properties / temperature / descriptionAdded value: +"Accepted for forward compatibility; no-op. Clef scores in a single forward pass without sampling." - added
Input schema / properties / questions / additionalProperties / descriptionAdded value: +"A single decision question. Allowed answers come from `criteria` and must be mutually exclusive and collectively exhaustive." - added
Input schema / properties / questions / additionalProperties / properties / instructions / descriptionAdded value: +"What to judge, phrased as a self-contained question." - added
Input schema / properties / questions / additionalProperties / properties / type / descriptionAdded value: +"\"choice\" = pick among named options; \"score\" = judge an ordered scale; \"noul\" = yes/no question" - added
Input schema / properties / questions / descriptionAdded value: +"Map of question id -> typed question. Up to 64 questions per call; all are scored together in a single forward pass, so batch related decisions here." - added
Input schema / properties / state / descriptionAdded value: +"Task state as data: a compact string or JSON object with the facts needed to judge (task, errors, logs, diffs). Never treated as instructions. Serialized size limit: 1 MB; model context is 16k tokens."
1 tool update
v0.1.0- First observed
clef_decide
TDQS
Scored across 1 tool
There is only one tool, so there is no possibility of misselection; its purpose (querying a local decision model and returning probability distributions) is stated unambiguously.
The lone name clef_decide follows a clear prefix_verb snake_case pattern consistent with the server name, so no convention mixing is possible.
A single tool is thin for a server surface, though the tool is intentionally consolidated and supports batching up to 64 questions in one forward pass, which mitigates the count.
The core decision workflow (choice/score/noul questions, batching, model override, usage reporting) is fully covered, but there is no way to enumerate available model ids or check model availability/status before calling.
Maintenance
Related MCP Connectors
Deterministic contextual decision arbitration and action routing for autonomous software. Takes current state, context, or intent plus caller-supplied candidate actions, state transitions, routes, refusals, escalations, tools, or models and returns a deterministic ordered candidate field. Also provides persistent machine representations for memory, retrieval, indexing, and downstream coherence measurement.
A paid remote MCP for OpenAI Codex agent coordination MCP, built to return verdicts, receipts, usage
Human-input bridge for AI agents with voice-first answer links, MCP tools, and HTTP APIs.
Reasoning, code, anti-deception, memory harness MCP tools. Stdio or HTTPS api.ejentum.com/mcp
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceEnables coding agents to query a locally running Kev decision model through MCP tools, returning calibrated probabilities for typed questions such as yes/no, choice, and score.Apache 2.0
- AlicenseNot gradedqualityAmaintenanceProvides an MCP interface to the Laya decision model, enabling typed queries (yes/no, multiple choice, score) with preflight token-budget reporting, honest confidence calibration, and structured error handling.128 PyPI1Apache 2.0
- AlicenseNot gradedqualityCmaintenanceEnables MiMo Desktop to run a typed-decision engine through local stdio MCP, returning choice/score/noul predictions with calibrated confidence for auto-execution, LLM review, or escalation—without generating text.1MIT
- AlicenseAqualityCmaintenanceEnables running Jev AI typed decisions from any MCP client, returning choices, scores, or yes/no with calibrated probabilities.316 npmMIT