Sends validated decision requests to a local Ollama server using the dedicated Nimble decision endpoint (POST /v1/systemone), then validates and returns typed choice, noul, and score results.
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., "@Decision Bridge Classify this support request as routine, investigate, or unknown, and return probabilities."
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.
A small MCP server and CLI that lets any stdio MCP client ask a local Nimble model, running through Ollama, for typed decisions.
Status: pre-release (0.1.0). Not published to any package registry.
You supply the evidence and the allowed answers. Decision Bridge validates the request, sends it to Ollama's dedicated Nimble decision endpoint (POST /v1/systemone), validates the response against your questions, and returns typed results. Your calling application decides what, if anything, to do next.
flowchart LR
agent["MCP client<br/>(Claude Code, Codex, ...)"] -->|"stdio: MCP messages"| server
term["Terminal or script"] -->|"decision-bridge decide"| cli
subgraph bridge["decision-bridge (one local process)"]
server["MCP server<br/>decide, bridge_status"]
cli["CLI<br/>doctor, decide"]
service["Decision service<br/>validates the request and the response"]
server --> service
cli --> service
end
service -->|"HTTP: POST /v1/systemone"| ollama["Ollama<br/>127.0.0.1:11434 by default"]
ollama --> nimble["Nimble model<br/>installed locally"]The MCP client starts decision-bridge serve; Ollama's API address is not an MCP server URL.
Two MCP tools are exposed: decide and bridge_status. The same decision logic is available from the command line (decision-bridge decide). Three question types are supported: choice (pick one labelled alternative), noul (returns a probability, not a boolean), and score (rate against an ordered rubric). Details: docs/tool-contract.md.
Decision Bridge is not an agent, a chat interface, or a classifier for one specific workflow. It does not download models, manage Ollama, or execute the decisions it returns.
Related MCP server: system-one-mcp
Ollama 0.35 or newer, running: https://ollama.com/download. Nimble decisions need that version. See the model page for the current contract.
The Nimble model, installed explicitly by you. The download is roughly 9.5 GB (see the model page); disk size is not a RAM requirement or a speed guarantee, and this project makes no universal minimum-memory claim. Whether your machine runs it comfortably depends on your hardware: see the hardware guide for tiers and how to check yours.
Python 3.11 or newer and uv (recommended). A pip alternative is in docs/installation.md.
An MCP client that can launch a stdio server (only needed for MCP use; the CLI works without one).
The bridge itself needs no GPU libraries, model weights, Node.js, database, or Docker.
Works today, before any registry release.
Install Ollama and make sure its server is running (the desktop app usually runs it; use ollama serve only if nothing is listening on port 11434).
Download the model yourself:
ollama pull nimble:latestGet this repository: download the ZIP and extract it (no Git needed), or clone it:
git clone https://github.com/poacosta/decision-bridge-nimble-mcp.git
cd decision-bridge-nimble-mcpIn the project directory:
uv tool install .
decision-bridge doctor
decision-bridge doctor --smoke-test
decision-bridge decide --input examples/task-routing.jsondoctor checks configuration, Ollama, and the installed model without running inference. doctor --smoke-test sends one tiny synthetic request and may load the model, so a cold start can take a while.
Connect your MCP client: docs/clients.md.
Ask your agent to try it:
Use Decision Bridge to classify the supplied request into one of the provided categories. Return the selected category and probabilities. Do not execute the selected action.
Other install routes (development checkout, local wheel, pip, Windows notes): docs/installation.md. A step-by-step guide to installing, connecting, and using it from an agent or the command line: docs/usage.md.
Input, examples/mixed-questions.json:
{
"state": {
"request": "Investigate a payment failure reported by a customer."
},
"questions": {
"route": {
"type": "choice",
"instructions": "Select the most appropriate handling category.",
"criteria": {
"routine": "A known mechanical task with no behavior change.",
"investigate": "A problem requiring investigation.",
"unknown": "The evidence is insufficient to choose."
}
},
"mentions_payment": {
"type": "noul",
"instructions": "Does the request explicitly mention a payment problem?"
},
"evidence_detail": {
"type": "score",
"instructions": "Rate the amount of diagnostic detail provided.",
"criteria": [
"A general report without reproduction details.",
"Some concrete diagnostic details.",
"Clear reproduction steps and supporting evidence."
]
}
}
}Output from a real run of decision-bridge decide --input examples/mixed-questions.json on 2026-09-30 (macOS, Ollama 0.35.0, nimble:latest digest 24e550a16a70). Values come from the model and vary between runs and machines:
{
"schema_version": "1",
"model": "nimble:latest",
"answers": {
"route": {
"type": "choice",
"choice": "investigate",
"probabilities": {
"routine": 0.01159717142726515,
"investigate": 0.97105294791667,
"unknown": 0.017349880656064874
},
"confidence": 0.862961784371299
},
"mentions_payment": {
"type": "noul",
"noul": 0.9977317919335601
},
"evidence_detail": {
"type": "score",
"score": 0.43353631198311937,
"legend": {
"0": "A general report without reproduction details.",
"1": "Some concrete diagnostic details.",
"2": "Clear reproduction steps and supporting evidence."
},
"probabilities": {
"0": 0.6485568883849057,
"1": 0.26934991124706914,
"2": 0.08209320036802512
},
"confidence": 0.2359709949194575
}
},
"usage": {
"input_tokens": 915,
"output_tokens": 4
},
"metadata": {
"duration_ms": 9252,
"request_id": "101d233b96ee"
}
}Probabilities, scores, and confidence are passed through exactly as Ollama returns them. confidence describes how concentrated the model's probabilities are; it is not a calibrated chance of being correct. A high probability is not proof: decide your own acceptance threshold in the consumer, after evaluating it on your data (docs/evaluation.md).
docs/clients.md has a generic stdio configuration plus setup notes for Claude Code, Codex, Claude Desktop, Cursor, and Antigravity, with an honest tested/untested table. Installing this package never edits any client's configuration.
Configured by DECISION_BRIDGE_* environment variables, with CLI options taking precedence. Defaults: Ollama at http://127.0.0.1:11434, model nimble:latest, one model call at a time. Full table and policies: docs/configuration.md.
decision-bridge doctor # config, endpoint, version, installed model; no inference
decision-bridge doctor --json # same, machine-readable
decision-bridge doctor --smoke-test # also sends one tiny real decision requestExit codes: 0 success, 2 input or configuration error, 1 unavailable service or execution failure. A doctor run without --smoke-test states explicitly that inference readiness is unverified.
The model can be wrong. Results are advisory and must not be used to bypass approvals, tests, or checks.
Requests are limited to 1-64 questions, 2-26 alternatives per choice/score question, and a 64 KiB request body. The model also has an approximately 8K-token prompt budget; the byte limit does not prove your request fits it, and nothing is truncated for you.
Inference can be slow, especially on a cold start or modest hardware (hardware guide). There is no automatic retry, because a timeout does not prove the original computation stopped.
Only stdio MCP is supported. No hosted inference, cloud fallback, caching, or batch tooling.
Only Ollama with a Nimble model that reports decision support is supported.
Inference stays on the machine running Ollama (by default, yours). The bridge sends nothing anywhere else, has no telemetry, and does not log evidence, questions, answers, or raw upstream error bodies. But the calling agent may already have sent your input to a hosted model, and may send the returned decisions there too. Running this one step locally does not make the whole agent workflow private. If you configure a remote Ollama endpoint, that server controls what happens to your data; the bridge cannot verify its environment.
uv sync --locked
uv run decision-bridge doctor
uv run pytestContributor guide: CONTRIBUTING.md. Please follow the Code of Conduct. Security: SECURITY.md. Changes: CHANGELOG.md.
Released under the MIT License. The bridge does not redistribute model weights. Ollama, the Nimble model, and this project's Python dependencies each have their own licenses and upstream owners.
This project is independent. Names such as Ollama, Nimble, Bespoke Labs, and MCP identify interoperability only and imply no endorsement or ownership.
Nimble on Ollama (decision API contract)
Report bridge version, configured model, Ollama reachability and version, and installed-model status. Performs only cheap checks: it never loads the model or runs inference.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| model | Yes | |
| ollama | Yes | |
| endpoint | Yes | |
| inference | Yes | |
| model_status | Yes | |
| bridge_version | Yes | |
| schema_version | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true, destructiveHint=false, and openWorldHint=false, but the description adds valuable behavioral context: it performs cheap checks and never loads the model or runs inference. This tells the agent the call is lightweight and side-effect-free beyond what the annotations alone convey.
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?
Two sentences, front-loaded with the reported checks and followed by the key operational constraint. Every sentence earns its place with no redundancy.
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?
With an output schema present, zero parameters, and rich annotations, the description is complete enough for an agent to call the tool correctly. It explains what is reported and notes the cheap, no-inference behavior, leaving return structure to the output schema.
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?
The tool takes zero parameters, so there are no parameter semantics to explain. The baseline score for a zero-parameter tool is 4, and the description does not need to compensate for any schema gaps.
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?
The description states a specific verb and resource: it reports bridge version, configured model, Ollama reachability/version, and installed-model status. It clearly distinguishes this as a status/diagnostic tool, though it does not explicitly contrast it with the only sibling tool, decide.
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?
The description implies usage for cheap health/status checks by stating it 'performs only cheap checks' and 'never loads the model or runs inference.' However, it never explicitly says when to use this tool instead of the sibling 'decide' or any other alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evaluate caller-supplied evidence against caller-supplied fixed questions using the configured local decision model. The result is advisory and does not authorize or execute actions. Question types: 'choice' (pick one labelled alternative; returns probabilities), 'noul' (returns a probability between 0 and 1, not a boolean verdict), and 'score' (rate against an ordered rubric, lowest level first; returns a numeric score). Limits: 1-64 questions, 2-26 alternatives per choice/score question, a 64 KiB request body, and roughly an 8K-token prompt budget; nothing is truncated for you. Failures are returned as tool errors with a compact {"error": {"code", "message", "retryable", "request_id"}} body. Upstream contract: https://ollama.com/library/nimble:latest
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | The evidence to judge. | |
| questions | Yes | Insertion-ordered map of unique question ID to question. |
| Name | Required | Description |
|---|---|---|
| model | Yes | |
| usage | No | |
| answers | Yes | |
| metadata | Yes | |
| schema_version | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description adds meaningful behavior: results are advisory and do not authorize or execute actions, input limits are stated, overflow is not silently truncated, and failures use a compact error body with code, message, retryable, and request_id. This is strong disclosure for a read-only local decision tool.
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?
The description is front-loaded with the core operation, then proceeds through semantics, limits, failure behavior, and the upstream contract. Each sentence adds actionable information, and there is no filler or repetition of structured annotations.
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?
Given the nested schema and the presence of an output schema, the description supplies the remaining operational context an agent needs: question-type semantics, cardinality and size limits, non-truncation behavior, error shape, advisory-only status, and the upstream contract link. Nothing important for correct invocation appears 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 coverage is 100%, so the baseline is 3, but the description adds real semantic meaning about question types that the schema does not carry. In particular it explains that 'noul' returns a probability rather than a boolean verdict, that 'choice' returns probabilities over labelled alternatives, and that 'score' follows an ordered rubric starting at the lowest level.
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?
The description states a specific verb and resource: evaluate caller-supplied evidence against caller-supplied fixed questions using a configured local decision model. It also immediately clarifies that results are advisory and do not authorize or execute actions, which makes the tool's role unambiguous.
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?
Usage is implied by the evaluation framing and by the advisory/no-action boundary, but there is no explicit when-to-use/when-not-to-use guidance and no named alternative. The only sibling, bridge_status, is unrelated, so the lack of routing guidance is less harmful but still leaves selection context implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0bridge_statusdecideScored across 2 tools
The two tools have clearly distinct roles: bridge_status performs only diagnostic checks, while decide runs inference on caller-supplied questions. Their descriptions explicitly separate health/status reporting from decision evaluation.
Both names use lowercase snake_case and are readable, but the convention is slightly mixed: bridge_status is a noun-like status tool while decide is a bare action verb. The deviation is minor and does not impair understanding.
Two tools is slightly under the typical 3-15 range, but the server has a narrow purpose: report bridge health and evaluate supplied questions. Each tool has a clear, essential role rather than feeling arbitrarily thin.
The core surface is covered: status/diagnostics and the primary decision operation are both present, with detailed limits and error semantics. Minor gaps exist around model/configuration management and explicit model-loading operations, but these are workaroundable through status and the upstream contract.
Illumora Craft — evidence-augmented prompt compile for agents via remote MCP (OAuth) or local stdio.
MCP server providing access to the Scorecard API to evaluate and optimize LLM systems.
Remote MCP server for supportsheep: run AI interviews and manage support content for your blog.
Focused MCP server for OpenAI image/audio generation (v2.0.0). Wraps endpoints via HAPI CLI.
