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., "@Reconstitution Calculator MCP Server I added 2 mL to 10 mg powder—what's the concentration and volume for 250 mcg?"
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 Model Context Protocol server with six lab math tools. Pure math, no network calls, no data stored. Same formulas as the Reconstitution Calculator browser extension.
Made by Peptara Labs (peptaralabs.io)
Tool | What it does | Inputs |
| Concentration after adding diluent to a powder, in mg/mL and mcg/mL, plus the volume in mL and µL that holds a wanted amount |
|
| Converts mass, volume or mass concentration units |
|
| Solves C1V1 = C2V2 for the one missing value and gives the diluent volume to add | any three of |
| Mass needed for a molarity, or molarity from a mass |
|
| Grams of solute for a percent w/v solution |
|
| Concentration in each tube, plus transfer and diluent volume per tube |
|
Supported units for convert_units:
Mass: kg, g, mg, mcg, ug, µg, ng
Volume: L, mL, uL, µL, nL
Mass concentration: g/L, mg/mL, mg/L, mcg/mL, ug/mL, µg/mL, mcg/L, ug/L, µg/L, ng/mL
Every tool checks its input. A bad value (a zero volume, a unit of the wrong kind, too many blanks) returns a clear error instead of a number.
Related MCP server: MSDS-Chain
Requires Node.js 18 or newer.
Run it with npx:
npx -y reconstitution-calculator-mcpOr run it from a local copy:
npm install
npm startAdd this to claude_desktop_config.json:
{
"mcpServers": {
"reconstitution-calculator": {
"command": "npx",
"args": ["-y", "reconstitution-calculator-mcp"]
}
}
}From a local copy, point command at Node instead:
{
"mcpServers": {
"reconstitution-calculator": {
"command": "node",
"args": ["/absolute/path/to/mcp/src/index.js"]
}
}
}The server speaks stdio by default. Add --http to serve Streamable HTTP at /mcp (stateless, JSON responses):
node src/index.js --http --port 8081 --host 127.0.0.1PORT, HOST and TRANSPORT=http work as environment variables too. GET /status returns a status line. The included Dockerfile and smithery.yaml run the HTTP mode in a container for remote hosting.
Input to reconstitution_concentration:
{ "powder_amount": 10, "powder_unit": "mg", "diluent_ml": 2, "wanted_amount": 250, "wanted_unit": "mcg" }Result: 5 mg/mL (5000 mcg/mL), and 250 mcg is in 0.05 mL (50 µL).
npm testThe test starts the server over stdio and over HTTP with the MCP SDK client, lists the tools, checks known answers for each tool, and runs one bad input per tool that must return an error.
MIT. For laboratory calculations only.
Convert a value between units of the same kind: mass, volume or mass concentration. Supported units: kg, g, mg, mcg, ug, µg, ng, L, mL, uL, µL, nL, g/L, mg/mL, mg/L, mcg/mL, ug/mL, µg/mL, mcg/L, ug/L, µg/L, ng/mL. For laboratory calculations only.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Unit to convert to, of the same kind as from. | |
| from | Yes | Unit to convert from, for example mg, mL or mg/mL. | |
| value | Yes | Value to convert. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is read-only, idempotent, non-destructive, and closed-world. The description adds useful behavioral context by restricting conversions to matching unit kinds and limiting use to laboratory calculations, though it does not describe error behavior for incompatible units.
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 conversion purpose is front-loaded, followed by the necessary supported-unit list and a brief scope restriction. The long unit enumeration is functional and earns its space.
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 three-parameter, read-only conversion tool with no output schema, the description supplies everything needed to invoke it correctly: supported unit kinds, exact unit tokens, and the laboratory-use restriction.
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. The description meaningfully extends the schema by enumerating all supported units—including equivalent spellings like ug/µg and uL/µL—which the schema itself does not list.
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 (Convert) and resource (a value between units), and scopes it to mass, volume, and mass concentration. The explicit supported-unit list makes it clearly distinguishable from sibling calculation tools like molarity or serial_dilution.
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?
Gives clear context: conversions must be between units of the same kind and are for laboratory calculations only. It does not explicitly compare to sibling tools, but those are different calculation types rather than alternatives for unit conversion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Solve C1 x V1 = C2 x V2 for the single missing value. Give exactly three of c1, v1, c2, v2 in consistent units. Also returns the diluent volume to add. For laboratory calculations only.
| Name | Required | Description | Default |
|---|---|---|---|
| c1 | No | Stock concentration. | |
| c2 | No | Final concentration. | |
| v1 | No | Stock volume. | |
| v2 | No | Final volume. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so safety is largely covered. The description adds value beyond that: it discloses the returned diluent volume and the consistent-units requirement, and scopes it to laboratory use. Return-format detail is limited but annotations carry most of the profile.
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?
Three short sentences, front-loaded with the core operation, then the input rule, then the side output and scope note. No filler, every sentence earns its place.
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 no output schema, the description partly compensates by noting the diluent-volume return, and it explains the input rule and units. It could say more about what the primary solved value looks like, but for a simple four-number utility it is essentially complete.
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 baseline is 3, but the description adds a constraint the schema does not express: required is 0 and all four params are optional in the schema, yet the description mandates exactly three be supplied. It also imposes a units-consistency rule, which is meaningful semantics beyond the field docs.
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 operation (solve C1 x V1 = C2 x V2 for the single missing value) and adds a secondary output (diluent volume). It clearly distinguishes itself from a multi-step tool like serial_dilution in spirit, but never names a sibling to route the agent explicitly.
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 rule 'give exactly three of c1, v1, c2, v2 in consistent units' is a real invocation constraint, so usage is more than implied. However, it gives no when-to-use vs alternatives — nothing tells the agent why to pick this over serial_dilution or reconstitution_concentration.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Relates mass, molarity, volume and molecular weight (mass g = M x L x g/mol). Give molarity to get the mass needed, or give mass to get the molarity. For laboratory calculations only.
| Name | Required | Description | Default |
|---|---|---|---|
| mw | Yes | Molecular weight in g/mol. Must be greater than 0. | |
| mass | No | Mass of solute. Give this or molarity, not both. | |
| volume | Yes | Solution volume. Must be greater than 0. | |
| molarity | No | Target molarity. Give this or mass, not both. | |
| mass_unit | No | Unit of mass. Default g. | |
| volume_unit | No | Unit of volume. Default mL. | |
| molarity_unit | No | Unit of molarity. Default M. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare this is a read-only, idempotent, non-destructive computation, so the safety profile needs no elaboration. The description adds a directionality constraint (input molarity vs. input mass) but says nothing about precision, rounding, or error conditions when inputs are inconsistent.
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?
Three short sentences: the relationship and formula lead, the two usage directions follow, and the scope caveat closes. 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 7 fully described parameters, no output schema, and annotations covering the safety profile, the description supplies enough for correct invocation. It could mention return units or precision, but nothing critical to calling the tool 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 schema already documents every parameter including units and the 'give this or that, not both' exclusivity for mass/molarity. The description reinforces the exclusivity but adds no syntax or format detail beyond structured fields.
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 names the exact quantity relationship and even supplies the formula (mass g = M x L x g/mol), so the agent knows precisely which computation this performs. It is clearly distinct from siblings like dilution_c1v1, serial_dilution, or convert_units, which handle different kinds of solution math.
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?
It explicitly states both invocation modes: supply molarity to obtain mass, or supply mass to obtain molarity. It also scopes usage to laboratory calculations. It stops short of naming sibling alternatives or saying when another tool is preferable, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Grams of solute for a percent weight per volume solution (g = percent x mL / 100). For laboratory calculations only.
| Name | Required | Description | Default |
|---|---|---|---|
| percent_wv | Yes | Percent w/v, greater than 0 and at most 100. | |
| final_volume_ml | Yes | Final volume in mL. Must be greater than 0. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds the useful caveat that results are for laboratory calculations only (i.e., not clinical/dosing use) and that this is a pure formula, but says nothing about output format or precision.
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 short sentences, zero filler: the formula—the single most useful piece of information—is front-loaded, followed by the scope caveat. Nothing is padded or redundant.
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 two-parameter pure calculator with no output schema, the description supplies the key missing piece—what the result is (grams of solute) and how it is derived. Only minor gaps remain, such as output rounding or unit conventions.
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 would be 3, but the description goes further by spelling out the computation g = percent x mL / 100, which clarifies the role each parameter plays. It does not restate the >0 / ≤100 bounds, but those are 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?
The description names the exact quantity produced ("grams of solute for a percent weight per volume solution") and even gives the formula, so the operation is unambiguous. It does not, however, distinguish itself from siblings such as molarity or reconstitution_concentration, which an agent must infer from the units alone.
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?
"For laboratory calculations only" is a scope disclaimer, not usage guidance; it never says when to pick this over molarity, dilution_c1v1, or reconstitution_concentration. The applicable scenario is only implied by the w/v formula.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Concentration of a lyophilized powder after adding a diluent volume, in mg/mL and mcg/mL. Optionally gives the volume in mL and µL that holds a wanted amount. For laboratory calculations only.
| Name | Required | Description | Default |
|---|---|---|---|
| diluent_ml | Yes | Volume of diluent added, in mL. Must be greater than 0. | |
| powder_unit | No | Unit of powder_amount. Default mg. | |
| wanted_unit | No | Unit of wanted_amount. Default mcg. | |
| powder_amount | Yes | Mass of powder in the vial. Must be greater than 0. | |
| wanted_amount | No | Optional mass you want to draw out. Must be greater than 0. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, covering the full safety profile. The description adds useful context about the dual output (concentration plus the volume holding a wanted amount) and the lab-only scope, but says nothing about invalid-input handling or edge cases.
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 tight sentences, front-loaded with the core computation and followed by the optional secondary output and a scope caveat. No filler or redundancy; each clause carries information.
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 no output schema, the description carries the return-value burden and does so reasonably well by naming the concentration units and the optional volume output. Annotations cover safety and the schema covers all parameters, so the only real gap is the absence of guidance relative to sibling calculation tools.
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 all five parameters are already documented. The description adds marginal meaning by linking the optional wanted_amount to the volume output ('the volume in mL and µL that holds a wanted amount'), which clarifies that parameter's role beyond the schema, but the rest of the parameter semantics are left to 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?
The description names a specific computation (concentration of a lyophilized powder after adding diluent) and states the output units (mg/mL and mcg/mL), so an agent knows exactly what it produces. It does not, however, explicitly differentiate itself from siblings like dilution_c1v1 or serial_dilution, which is the only thing keeping it from a 5.
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 only implied by the scenario ('reconstitution of a lyophilized powder') and the scope caveat 'For laboratory calculations only'. There is no explicit when-to-use statement, no exclusions, and no routing to sibling tools such as dilution_c1v1 or molarity, leaving the agent to infer the correct choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Concentration in each tube of a serial dilution, plus the transfer and diluent volume per tube. Output concentrations use the same unit as start_conc. For laboratory calculations only.
| Name | Required | Description | Default |
|---|---|---|---|
| steps | Yes | Number of tubes, a whole number from 1 to 20. | |
| factor | Yes | Dilution factor per step. Must be greater than 1. | |
| start_conc | Yes | Starting concentration. Must be greater than 0. | |
| volume_per_tube_ml | Yes | Final volume in each tube, in mL. Must be greater than 0. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations establish that this is a safe, read-only, idempotent, closed-world operation, so the safety profile is covered. The description adds genuinely useful behavior beyond that: it discloses what is computed (transfer and diluent volume per tube) and the unit convention for outputs. It stops short of stating anything about edge behavior (e.g. rounding, invalid inputs).
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, both front-loaded with the substantive output information first and the unit rule second. The trailing 'For laboratory calculations only' adds little but costs only a clause.
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 no output schema, the description correctly takes on the job of describing the return values (per-tube concentrations, transfer and diluent volumes). Combined with a fully covered parameter schema and read-only annotations, an agent has what it needs to call it correctly; only cross-tool routing guidance 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 schema already documents all four parameters with their constraints (factor > 1, steps 1-20, positive start_conc and volume). The description only adds the unit-mapping rule for start_conc, which is a small increment. 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 names the specific resource (a serial dilution) and its outputs — per-tube concentrations plus transfer and diluent volumes. It is clearly distinguishable from single-step siblings like dilution_c1v1, though it lacks an explicit verb and doesn't name that sibling.
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 only guidance is the scope note 'For laboratory calculations only', which is a disclaimer rather than usage direction. There is no statement of when to pick this over dilution_c1v1, reconstitution_concentration, or the other siblings, and no exclusions.
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.
v1.0.0convert_unitsdilution_c1v1molaritypercent_solutionreconstitution_concentrationserial_dilutionScored across 6 tools
Most tools target distinct calculations (unit conversion, molarity, percent solution, reconstitution). The two dilution tools (serial_dilution vs dilution_c1v1) are the only pair with potential overlap, but their descriptions clearly separate multi-tube serial workflows from single C1V1=C2V2 solving.
All names use snake_case, which is consistent. However, styles vary between verb_noun (convert_units, serial_dilution) and bare noun calculators (molarity, percent_solution), plus the formula-style dilution_c1v1, so it is not a single uniform pattern.
Six tools is well-scoped for a lab calculator server, with each tool covering a distinct calculation type and no filler. Nothing feels thin or bloated.
The surface covers the main lab math: dilution, reconstitution, unit conversion, molarity, and percent solutions, giving solid lifecycle coverage for the stated purpose. Minor gaps like molar mass lookup or a dedicated mcg/mg dose-per-volume helper are workarounds rather than dead ends.
Calculators accessible via MCP with real-time collaborative sessions and shareable URLs.
MCPCalc gives agents access to a comprehensive library of calculators spanning finance, math, health, construction, engineering, food, automotive, and more. It includes a full Computer Algebra System (CAS) and a grid-based Spreadsheet calculator.
Free calculators as MCP tools: finance, taxes, health, units, dates. Search, fetch & compute.
Deterministic peptide reconstitution and dosing math, so assistants compute it instead of guessing.