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., "@clinical-calc-mcp Calculate Parkland formula for 70 kg patient with 30% TBSA"
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 local-only FastMCP server providing validated, deterministic clinical calculation tools for nursing and emergency-care education and authorized clinical software workflows.
Clinical safety: This project is a calculation utility, not a diagnostic or treatment-decision system. It does not determine what is appropriate for any particular patient. Clinical decisions must follow current institutional protocols, clinician judgment, and applicable guidance. Verify every input, unit, and result independently.
Three focused MCP tools with typed inputs, explicit units, validation, and structured results.
Deterministic arithmetic; no external API, database, patient file access, or network access is needed to calculate.
Clear input errors for non-finite, zero, negative, out-of-range, and inappropriate drop-factor values.
FastMCP-generated tool schemas; usable with MCP-compatible clients.
Python 3.11+ package, installable with pip or uv, with a clinical-calc-mcp command.
No patient data is retained or logged by this application.
Related MCP server: Medical Calculator MCP Server
Tool | Inputs | Outputs | Formula and limitations |
|
| Estimated 24-hour volume, first 8-hour and remaining 16-hour volumes and average rates | Classic formula: |
|
|
| Mosteller: |
|
|
|
|
Inputs must be finite numbers greater than zero. TBSA must be at most 100%. Drop factor must be a positive whole number. Invalid inputs produce understandable tool errors; no calculation tool silently substitutes a value.
Results are rounded to two decimal places where applicable. Calculated values outside finite floating-point range fail with a clear error. This package does not add arbitrary demographic or body-size limits.
python -m pip install "git+https://github.com/Umarjaum/clinical-calc-mcp.git"
clinical-calc-mcpTo install a specific release tag, replace main with a tag, for example:
python -m pip install "clinical-calc-mcp @ git+https://github.com/Umarjaum/clinical-calc-mcp.git@v0.1.0"git clone https://github.com/Umarjaum/clinical-calc-mcp.git
cd clinical-calc-mcp
python -m venv .venvActivate the environment:
# macOS / Linux
source .venv/bin/activate
# Windows PowerShell
.venv\Scripts\Activate.ps1
# Windows Command Prompt
.venv\Scripts\activate.batThen install and launch:
python -m pip install .
clinical-calc-mcpFor local development, install test and lint tools too:
python -m pip install -e '.[dev]'git clone https://github.com/Umarjaum/clinical-calc-mcp.git
cd clinical-calc-mcp
uv sync
uv run clinical-calc-mcpuv sync installs the locked project dependencies from uv.lock. For development extras, use uv sync --extra dev.
PyPI availability: The repository is pip-installable from GitHub. A plain
pip install clinical-calc-mcpis available only after a release has been published to PyPI; GitHub publication does not publish a PyPI distribution automatically.
The installed command starts FastMCP using its default stdio transport:
clinical-calc-mcpYou can also run it as a Python module:
python -m clinical_calc_mcpFor development from the checkout:
uv run clinical-calc-mcp
# or, after activating the venv and installing editable:
python -m clinical_calc_mcpKeep the process attached to the MCP client; stdio is a protocol transport, not an interactive terminal interface. Do not add arbitrary shell commands or network-exposed transports to a clinical deployment without a separate security review.
Add the following server entry to Claude Desktop's MCP configuration file. The command name works when the package is installed in an environment visible to Claude Desktop:
{
"mcpServers": {
"clinical-calc-mcp": {
"command": "clinical-calc-mcp"
}
}
}If Claude Desktop cannot find the command, use the full path to the executable inside the environment where you installed the package. To find it, run which clinical-calc-mcp on macOS/Linux or where clinical-calc-mcp on Windows. Alternatively, configure the environment's Python executable with arguments -m clinical_calc_mcp and set the corresponding working directory if your client supports it.
Configuration-file locations can vary by OS and app version. Use the current MCP / developer settings in Claude Desktop to locate or edit its configuration rather than relying on a hard-coded path. Restart or reload the client after changing configuration, then confirm the three tool names appear.
The same stdio command pattern applies to other MCP clients. Example configuration shape:
{
"mcpServers": {
"clinical-calc-mcp": {
"command": "clinical-calc-mcp",
"args": []
}
}
}If installed only inside an isolated virtual environment, point command at that environment's clinical-calc-mcp executable. The server is local and does not require credentials or a remote endpoint.
Requirements: Python 3.11 or newer and Git. Clone the repository, then install its development dependencies:
git clone https://github.com/Umarjaum/clinical-calc-mcp.git
cd clinical-calc-mcp
uv sync --extra devThe runtime is deliberately small: FastMCP and Pydantic. Tests use pytest; Ruff supplies optional lint checks. No external service credentials are needed.
Run the full suite (including an in-memory MCP client handshake/tool call):
uv run pytestOr use pip in an activated virtual environment:
python -m pip install -e '.[dev]'
python -m pytest
ruff check .Tests cover known calculation examples, validation boundaries, NaN/infinity, invalid drop factors, half-up drop rounding, numeric overflow behavior, and exposure of all three MCP tools.
clinical-calc-mcp/
├── .gitignore
├── .python-version
├── .github/workflows/test.yml
├── docs/clinical-safety.md
├── src/clinical_calc_mcp/
│ ├── __init__.py
│ ├── __main__.py
│ ├── py.typed
│ └── server.py
├── tests/test_server.py
├── CHANGELOG.md
├── CONTRIBUTING.md
├── LICENSE
├── pyproject.toml
├── SECURITY.md
├── uv.lock
└── README.mdThe calculator functions are deterministic local arithmetic. This application makes no outbound HTTP requests, has no API keys, database, telemetry, or patient-file access, and does not persist or log tool inputs. It does not evaluate user-provided code, execute shell commands, dynamically import modules based on user input, or make external decisions. MCP clients may maintain their own logs or conversation history; review the privacy and retention behavior of the client and deployment environment separately. Do not send identifiable patient data to an AI client unless permitted by your organization's policies.
This software is provided for calculation support and educational or authorized software workflows only. It is not medical advice, does not diagnose, prescribe, or recommend treatment, and has not been validated for a specific clinical workflow. Mathematical correctness does not establish clinical suitability. Confirm inputs, units, rounding, equipment, current guidance, and institutional protocols with a qualified clinician. The developers and contributors do not assume responsibility for clinical decisions made using this software. See docs/clinical-safety.md.
Released under the MIT License. See CONTRIBUTING.md for contribution expectations and CHANGELOG.md for release notes.
Calculate body surface area by Mosteller and body mass index.
| Name | Required | Description | Default |
|---|---|---|---|
| height_cm | Yes | Height in centimeters; must be greater than zero. | |
| weight_kg | Yes | Body weight in kilograms; must be greater than zero. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It correctly states that this is a calculation tool producing BSA and BMI, which conveys the pure-computation nature. It does not detail the formula, rounding, or return format, but the presence of an output schema compensates for some of this gap.
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?
A single sentence that is front-loaded with the action and outputs, containing no filler or redundancy. Every word contributes to the tool's purpose.
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 simple two-parameter calculator with a detailed input schema and an output schema, this description is complete enough for an agent to select and invoke the tool correctly. No critical behavioral or parameter information 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?
The input schema has 100% description coverage for both required parameters, clearly defining height_cm and weight_kg with positivity constraints. The description adds no new parameter-level meaning beyond what the schema already provides, so baseline 3 is appropriate.
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 uses a specific verb ('Calculate') and names the exact outputs: body surface area by Mosteller and body mass index. This clearly distinguishes the tool from siblings like parkland_formula and drip_rate_calculator, which address different clinical calculations.
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 clearly implies when to use the tool: whenever BSA or BMI values are needed from weight and height. While it does not explicitly state exclusions or name alternatives, the sibling tools are sufficiently different that an agent can infer the correct choice from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate a volume/time rate and gravity drip rate.
| Name | Required | Description | Default |
|---|---|---|---|
| volume_ml | Yes | Fluid volume in milliliters; must be greater than zero. | |
| time_hours | Yes | Infusion duration in hours; must be greater than zero. | |
| drop_factor | No | Giving-set calibration in drops per milliliter (gtt/mL), positive whole number. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It does indicate a side-effect-free calculation and the two outputs, but it does not describe the formula relationship, units of the returned rates, or how the optional drop_factor default is applied.
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?
A single 10-word sentence with no filler, front-loading the core action and outputs. Every word earns its place for a simple calculator tool.
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 three-parameter calculator with 100% schema coverage and an output schema, the description plus schema is largely sufficient to invoke the tool correctly. It loses a point only because the lack of usage guidance and behavioral annotations leaves selection and safety to inference.
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 input schema already documents all parameters with units, defaults, and constraints. The description adds only a mild conceptual link between volume_ml/time_hours and the volume/time rate, and between drop_factor and the gravity drip rate, which is not enough to raise it above the high-coverage baseline.
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 uses a specific verb ('Calculate') and names the exact resources computed: a volume/time rate and a gravity drip rate. This clearly identifies the tool as an IV infusion calculator and distinguishes it from the sibling Parkland formula and BSA calculators.
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?
No guidance is given about when to choose this tool over the available alternatives, and no exclusions or prerequisites are stated. The agent must infer from the tool name alone that it applies to drip-rate calculations rather than Parkland resuscitation or BSA.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate the classic Parkland-formula 24-hour crystalloid estimate.
| Name | Required | Description | Default |
|---|---|---|---|
| weight_kg | Yes | Body weight in kilograms; must be greater than zero. | |
| tbsa_percentage | Yes | Total body surface area affected, as a percentage from >0 to 100. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It clarifies that this is a 24-hour crystalloid estimate, which is meaningful context beyond the tool name. It does not spell out the 4 mL/kg/%TBSA coefficient or explicitly state the output is a total volume, but 'classic Parkland-formula' and 'estimate' encode the essential behavior.
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?
A single, front-loaded sentence with no filler. Every word adds value: 'classic', 'Parkland-formula', '24-hour', and 'crystalloid estimate' all clarify scope and behavior.
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 simple two-parameter formula with full schema coverage and an output schema, the description is sufficient. It conveys the domain, the timeframe, and the estimate nature. The only notable gap is explicit guidance about when to choose a sibling tool, but this is minor for this calculator.
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 input schema already describes both parameters (weight_kg and tbsa_percentage) with meaningful constraints, covering 100% of parameters. The description adds no parameter-specific detail, so the baseline score of 3 is appropriate.
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 uses a specific verb ('calculate') and a specific resource ('classic Parkland-formula 24-hour crystalloid estimate'). This distinguishes it clearly from siblings like bsa_mosteller and drip_rate_calculator without needing to open their schemas.
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 intended use is implied by the formula name: burn resuscitation fluid estimation. However, the description gives no explicit when-to-use or when-not-to-use guidance, and does not mention that drip_rate_calculator may be relevant for rate conversion or that bsa_mosteller handles surface area instead.
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.0bsa_mostellerdrip_rate_calculatorparkland_formulaScored across 3 tools
Each tool targets a distinct clinical calculation: Parkland burn fluids, BSA/BMI, and drip rate. There is no meaningful overlap between them, so an agent can confidently select the correct tool.
All names are lowercase snake_case and descriptive, but the suffixes are inconsistent: one tool ends in _formula, one has no suffix, and one ends in _calculator. This is readable but does not follow a uniform naming pattern.
Three tools is a well-scoped size for a focused clinical calculator server. Each tool provides a distinct, useful calculation without redundancy.
The tools cover burn resuscitation, BSA/BMI, and drip administration, but the broad 'clinical-calc' name suggests many common clinical calculators are missing. It is reasonable as a small emergency/fluid calculator set, but not comprehensive.
AI-callable calculators and engineering models with real formulas. No hallucinated math.
Deterministic fitness calculators — TDEE, adaptive TDEE, body fat, 1RM, macros — with consensus.
90+ pure finance calculators: loans, investing, bonds, options, tax. Stateless, stores nothing.
Consent-gated tools that turn user health notes into non-diagnostic appointment-prep materials.
