bounded-calcs-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| units | No | Path to a YAML file specifying site units, passed via --units (e.g., 'urea: bun_mg/dL'). | |
| normal_ranges | No | Path to a YAML or JSON file specifying site normal ranges, passed via --normal-ranges. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Clinical calculators that never assume an unmentioned finding is normal.
Workflow:
list_calculators, then get_schema for the calculator you need.
Read the note and send to
evaluateonly what it actually documents: present, absent, a level, or a number. Leave out (or send "unknown") anything the note does not mention. Never fill an unmentioned item as absent or normal. If the note says only that a numeric item is normal ("vital signs normal"), send "normal" when the schema gives that item a normal range, and leave it unknown otherwise. If it gives only bounds ("heart rate over 100", "SBP in the 90s"), send {"min": x, "max": y}, leaving out the bound it does not give. Never invent a number. Send a plain number only in the unit the schema states for that item. If the note gives another unit that the schema lists for the item (other_units), send {"value": x, "unit": "the note's unit"} and the tool converts it. An item the schema marks unit_required always goes that way, with the unit exactly as the note gives it (unit_labels says what each listed unit means). Only if the note gives the number with no unit at all, send "unit": "not stated" when the schema shows a site_unit for the item, and otherwise ask for the unit. Never guess a unit, and convert one yourself only when the schema does not list it.If the result is settled, report its category (for a score-only calculator, one whose schema has no categories, its score). If not, ask the clinician about the decisive unknowns (in the order given), add the answers, and call evaluate again.
Items of kind "judgment" (for example HEART history, Wells "alternative diagnosis less likely") must come from the clinician, never from your reading of the note.
Research and reference use only. Not a medical device; not for unsupervised clinical decisions.
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 |
|---|---|
| list_calculatorsA | List the available calculators (id, name, purpose). |
| get_schemaB | Describe a calculator: its items and allowed values, how points are assigned, the decision categories, the source citation, and open review notes. |
| evaluateA | Evaluate a calculator on what is actually known.
Returns whether the decision category is settled, every category still possible, the worst case, the score range, and the decisive unknowns: the only items worth asking the clinician about, each with what the category would be for each possible answer. |
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
Three tools with clearly distinct purposes: enumerate calculators, retrieve one calculator's schema, and run an evaluation against it. There is no overlap between listing, describing, and computing.
All snake_case, but the verbs are mixed: list_calculators and get_schema follow verb_noun, while evaluate is a bare verb with no object noun. Still predictable and readable.
Only 3 tools, but the purpose is narrow and self-contained; list → get_schema → evaluate is a minimal complete lifecycle. Slightly thin, though each tool clearly earns its place.
Listing, schema retrieval, and evaluation cover the core read-only workflow, and the domain appears not to require mutation. Minor gaps: no batch evaluation or saved-result retrieval, but agents can compose calls.