Decision Bridge
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| decideA | 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 |
| bridge_statusA | 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. |
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 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.