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., "@STEM Calc MCP Balance C3H8 + O2 -> CO2 + H2O and give the molar mass of O2"
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.
When an AI guesses chemistry and physics homework, the numbers are often wrong. STEM Calc MCP fixes that: it is a free, open source MCP server that does the arithmetic with tested code, so you get the same answer every time. It works out molar mass, balances chemical equations, converts between grams, moles and particles, converts units and rounds to the right number of significant figures.
Install with one line:
npx -y stem-calc-student-mcpTry these prompts:
"What is the molar mass of copper sulfate pentahydrate, CuSO4.5H2O?"
"Balance this equation: C3H8 + O2 -> CO2 + H2O"
"How many moles are in 36 grams of water?"
Use it with Claude Desktop, Claude Code, Cursor, VS Code, Windsurf and any other app that runs a local MCP server. It runs on your computer and needs no internet, no account and no API key.
Add this to claude_desktop_config.json, then restart the app:
{
"mcpServers": {
"stem-calc": {
"command": "npx",
"args": ["-y", "stem-calc-student-mcp"]
}
}
}claude mcp add stem-calc -- npx -y stem-calc-student-mcpAdd the same block as for Claude Desktop to .cursor/mcp.json.
VS Code uses a servers key, not mcpServers. Add this to .vscode/mcp.json:
{
"servers": {
"stem-calc": {
"type": "stdio",
"command": "npx",
"args": ["-y", "stem-calc-student-mcp"]
}
}
}All five tools are read only. They calculate an answer and never change anything on your computer.
Tool | What it does | Inputs | Example prompt |
| Molar mass of a formula in g/mol, with the mass each element adds |
| "What is the molar mass of Ca(OH)2?" |
| Balances a chemical equation |
| "Balance C3H8 + O2 -> CO2 + H2O." |
| Converts between grams, moles and particles |
| "How many moles are in 36 grams of water?" |
| Converts a value from one unit to another |
| "Convert 2.5 km to feet." |
| Rounds a number to a number of significant figures |
| "Round 123456 to 3 significant figures." |
Every tool also returns its answer as fields next to the text, so an app that reads JSON gets the numbers without picking them out of a sentence.
Related MCP server: mcp-mathjs
Formulas. Write each element with a capital first letter. Round brackets and square brackets work, so Fe2(SO4)3 and K3[Fe(CN)6] are fine, and so are hydrates written with a dot, like CuSO4.5H2O. It knows 56 common elements, from hydrogen to uranium. A symbol it does not know gets a clear error, never a guess.
Units. Length: m, km, cm, mm, in, ft. Mass: g, kg, mg, lb. Time: s, min, h. Volume: L, mL, m^3. Energy: J, kJ, cal, kcal. Temperature: K, C, F. It refuses to convert one kind into another, so metres to seconds is an error.
What it does not do. It does not find a limiting reagent, work with charges or isotopes, or balance reactions that have no solution. When it cannot answer, it says so.
Some MCP servers connect an assistant to a learning management system, so it can read your courses, grades and due dates. Those need an account, a login and a network connection. This one does none of that. It only does homework math, and it runs on your own computer with no sign in, no network calls and no files read or written. The same input gives the same answer every time.
Use an LMS server to find out what is due. Use this one to check the chemistry and unit conversions once you sit down to do it. They work fine side by side.
There are two floors here, and they are not the same number.
What you are doing | Node.js |
Running the published server | 20 or newer |
Building and testing a clone | 22.12 or newer, on the 22 and 24 release lines or 26 and later |
The server itself is happy on Node.js 20, and that is what engines in package.json says. The test runner wants a newer Node.js, so the development floor lives in devEngines in the same file. npm checks devEngines before install, run and test, so a clone on Node.js 20 stops with a clear message instead of a strange failure part way through the test suite. The 23 and 25 release lines are left out on purpose, because the test runner does not run on them.
Both numbers live in package.json, and a test in tests/node-version.test.ts keeps them in step with the README and with the range the test runner asks for.
npm install
npm run build
npm testThe tests call the same functions the tools use, and they check the README, llms.txt, glama.json and the package files against the tools in src/tools.ts.
MIT
Balance a chemical equation written with -> and +.
| Name | Required | Description | Default |
|---|---|---|---|
| equation | Yes | Equation like H2 + O2 -> H2O |
| Name | Required | Description |
|---|---|---|
| balanced | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the input notation constraint, but says nothing about failure behavior on unbalanced/invalid input or what the coefficients look like on return (the output schema handles the latter).
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?
One front-loaded sentence with zero filler; the format constraint sits immediately after the verb. It is arguably terse to the point of omitting routing guidance, but nothing is wasted.
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?
A single-parameter tool with 100% schema coverage and an output schema needs little prose; the description covers the one thing an agent must get right (the arrow/plus notation). Only the relationship to sibling tools is left unaddressed.
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% and the single parameter's description already gives the example 'H2 + O2 -> H2O', so the description's '-> and +' note largely restates structured data. Baseline 3 applies.
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 ('Balance') and resource ('chemical equation'), and adds the exact notation the input must use ('->' and '+'). This makes it distinguishable from molar_mass and stoichiometry by resource, though no sibling is named 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?
There is no statement of when to use this tool versus the alternatives; notably, stoichiometry typically requires an already-balanced equation, which is exactly the kind of routing hint that is missing. The usage context is only implied by the tool's purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert a value between units of length, mass, time, volume, energy or temperature. It refuses to convert one kind of unit into another.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | The unit to convert it to. | |
| from | Yes | The unit it is in, like km, kg, mL, J or C. | |
| value | Yes | The number to convert. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds one genuine behavioral trait — that cross-category conversions are rejected — but says nothing about case sensitivity, accepted unit spellings, or how temperature offsets are handled, which are the real failure modes here.
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 with zero waste; the capability and its category scope are front-loaded, and the constraint follows immediately.
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?
An output schema exists, so return values need not be explained, and all three parameters are documented. What remains thin is the accepted unit vocabulary and its normalization rules — the description names categories but not the strings an agent may pass.
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% and the schema already gives unit examples ('km, kg, mL, J or C'), so the baseline is 3. The description adds no syntax or format detail (e.g., whether unit strings are case-sensitive or what aliases exist) beyond what the schema provides.
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 enumerates the supported measurement families (length, mass, time, volume, energy, temperature), which lets an agent judge scope immediately. It does not explicitly differentiate itself from the sibling tools, though that difference is obvious from the domain (they are chemistry 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?
Usage is only implied — an agent infers 'use this when you need a unit conversion.' The sentence about refusing cross-category conversions acts as a negative condition but is phrased as an error behavior, not as guidance, and no alternatives or prerequisites are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse a chemical formula and return the molar mass in g/mol with the mass each element adds. Handles brackets and hydrates like CuSO4.5H2O.
| Name | Required | Description | Default |
|---|---|---|---|
| formula | Yes | Chemical formula like H2O, Ca(OH)2 or CuSO4.5H2O. Write each element with a capital first letter. |
| Name | Required | Description |
|---|---|---|
| mass | Yes | |
| breakdown | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered; the description adds useful behavioral context by disclosing what the response contains (total g/mol plus per-element contributions) and which formula syntaxes are supported. It does not say what happens with an unparseable formula, which is the main remaining 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?
Two sentences, zero filler, with the core action and output stated first and the syntax support second. Nothing here could be cut without losing 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?
For a one-parameter read-only computation with an output schema already defined, the description covers purpose, output shape, and input syntax adequately. The absence of error/edge-case guidance (invalid formula, unknown element) is the only meaningful omission.
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% and the single `formula` parameter is fully documented with examples and the capital-first-letter rule. The description's mention of brackets and hydrates largely duplicates the schema's own examples, so it adds little beyond the structured field. 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 states a concrete verb+resource pair ("Parse a chemical formula and return the molar mass in g/mol") and even names the secondary output (per-element mass contributions). That is far more specific than the title restatement. It stops short of naming a sibling to differentiate from, so an agent must infer on its own that balance_equation or stoichiometry is the right tool for reactions.
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?
"Handles brackets and hydrates like CuSO4.5H2O" implies the input scope this tool accepts, but there is no statement of when to choose this over stoichiometry or balance_equation. Usage is only implied by the tool's domain, not explained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Round a number to a given number of significant figures.
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | The number to round. | |
| sigFigs | Yes | How many significant figures to keep. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds no further behavioral context about rounding mode (half-up, banker's, etc.) or handling of edge inputs, which is the one piece of behavior an agent might care about here; with annotations covering the basics, a 3 fits.
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 efficient sentence with no waste, and the key concept (significant figures) is front-loaded. Nothing needs trimming.
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 pure-function tool with an output schema, fully documented params, and read-only annotations, the description is nearly sufficient. The only minor gap is not stating the rounding convention, which could matter to callers.
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%: 'value' and 'sigFigs' are both documented in the schema, including the exclusiveMinimum constraint. The description repeats the parameter intent without adding syntax or semantic detail beyond the schema, so baseline 3 applies.
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 verb (Round) and resource (a number to significant figures), making the operation unambiguous. It doesn't explicitly distinguish itself from siblings like convert_units, but those perform clearly different transformations, so misselection risk is low.
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?
There is no guidance on when to use this tool versus alternatives, no mention of edge cases (e.g., negative sigFigs, very large/small values), and no exclusions. The agent must infer applicability entirely from the one-line purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert between grams, moles and particles. The formula is required whenever grams are the from or to unit. Converting between moles and particles needs no formula.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | What to convert it to. | |
| from | Yes | What the value is in. | |
| value | Yes | The amount to convert. | |
| formula | No | The chemical formula, like H2O. Required when from or to is grams. Not used otherwise. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered by structured data. The description adds the formula-requirement condition, but that same condition is also stated in the schema, and it doesn't say what happens if formula is omitted for a gram conversion (error vs default) or what precision the result carries.
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, no filler, with the core capability stated first and the conditional rule second. 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?
An output schema exists, so return values need not be explained, and the input rules are fully covered by schema plus description. The only omissions are sibling routing and error behavior when a gram conversion is requested without a formula.
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% with enums on from/to, so the schema already documents every parameter. The description's formula rule merely repeats the formula parameter's schema description, adding no new syntax, format, or constraint information.
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 an explicit domain resource set (grams, moles, particles), which distinguishes it from the generic convert_units sibling. It does not name a sibling or clarify its boundary against molar_mass, which also deals with grams/moles, so it stops short of full differentiation.
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 second sentence gives a clear conditional rule for when the formula argument is needed vs not needed, which is genuine usage guidance for a required parameter. However, there is no guidance on when to pick this tool over molar_mass or convert_units, and no statement of preconditions or failure modes.
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.1balance_equationconvert_unitsmolar_massround_sig_figsstoichiometryScored across 5 tools
Each tool targets a clearly distinct operation: balancing equations, computing molar mass, stoichiometric conversion, unit conversion, and sig-fig rounding. Although molar_mass is a sub-step of stoichiometry, their descriptions make the boundary explicit, so an agent can select correctly.
Three tools use the verb_noun pattern (balance_equation, convert_units, round_sig_figs) while two are bare nouns (molar_mass, stoichiometry). The mix is minor and still readable, so it only slightly deviates from a predictable pattern.
Five tools is a tight, well-scoped set for a chemistry/math calculator; each tool covers a distinct computation with no filler. This fits comfortably in the ideal 3-15 range.
The surface covers the core calculation lifecycle: equation balancing, molar mass, mole/gram/particle conversion, unit conversion, and rounding. Common STEM add-ons like empirical-formula derivation, dilution, or percentage yield are absent, but these are minor gaps workable around with the existing tools.
Free deterministic tools for math, data transforms, dates, text, statistics, finance, and units.
More than a hundred everyday tools: PDFs, images, text, data, calculators, dice and currency.
Exact arithmetic, algebra, calculus, physics, chemistry and finance with a checkable formula.
Everyday calculators and converters for AI assistants: units, dates, percentages, text, JSON.
