Physics, chemistry and biology formulas: velocity, electric field, resistance, growth, cell density
Scored across 7 tools
Most tools target clearly distinct quantities (bacterial growth, cell density, electric field, velocity, potential energy, wire resistance, population projection). The only mild overlap is between calculate_bacterial_growth and project_population, which are both exponential-growth models, but the descriptions (doubling time vs. annual percentage rate, bacteria vs. demography) make the boundary reasonably clear.
Four tools use a calculate_<quantity> verb_noun pattern while potential_energy, wire_resistance, and project_population drop the verb or use a different style. It is still readable, but the convention is inconsistent across the set.
Seven tools is a well-scoped size for a formula calculator server; each tool covers a separate formula and none feels redundant. The small mismatch is that the selection looks arbitrary rather than curated, but the count itself is appropriate.
The stated domain, 'science formulas,' is broad, and the surface covers only a few biology and physics/electrostatics formulas. Common staples such as radioactive half-life, dilution/molarity, kinetic energy, Ohm's law, or a listing/search tool for available formulas are absent, leaving notable gaps an agent must work around.
Calculates bacterial population after a given time using exponential growth formula: N(t) = N₀ × e^(rt) or N(t) = N₀ × 2^(t/doubling_time). (cost: 1 credit)
| Name | Required | Description | Default |
|---|---|---|---|
| time | No | number, required, time elapsed, hours, no default | |
| growth_rate | No | number, optional, exponential growth rate, per hour, no default | |
| doubling_time | No | number, optional, population doubling time, hours, no default | |
| initial_population | No | number, required, starting population size, cells, no default |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive, open-world behavior. The description adds useful context with the calculation formulas and a one-credit cost, but it does not clarify that effectively one of growth_rate or doubling_time must be supplied or how conflicting inputs are handled.
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 states the purpose and formulas without filler. The credit cost is compactly appended and does not distract from the core definition.
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 four-parameter calculation tool with no output schema, the description is nearly complete: it names the formulas and inputs. It could more explicitly state that one of growth_rate or doubling_time is required in practice, but the formulas make the intended usage clear.
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 schema already documents each parameter. The description adds meaning by showing how time, growth_rate, doubling_time, and initial_population fit into the exponential growth formulas, clarifying the relationship between the two optional rate parameters.
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 and resource: calculates bacterial population after elapsed time. The inclusion of both exponential formulas distinguishes it from generic calculators and siblings like project_population or calculate_cell_density, though it does not name an alternative 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?
Usage is implied by the tool name and formula, but there is no explicit when-to-use guidance, no mention of when to choose doubling_time versus growth_rate, and no named alternatives among the many calculate_* siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculates cell density (cells per mL) from optical density (OD) measurement and dilution factor. Formula: OD × dilution × factor (default 1e9 cells/mL per OD unit, organism-dependent). (cost: 1 credit)
| Name | Required | Description | Default |
|---|---|---|---|
| od | No | number, required, optical density measurement, absorbance units, no default | |
| factor | No | number, optional, cells/mL per OD unit, default 1e9 | |
| dilution | No | number, required, dilution factor, fold dilution, no default |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds genuinely new behavioral context: the exact formula applied, the default conversion constant's organism dependence, and a cost of 1 credit — none of which appear in structured fields.
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 compact sentences plus a short cost tag; the output unit and formula are front-loaded before the caveat. No filler, though the formula restates the multiplicative relationship in a slightly redundant way alongside the parameter list.
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 pure read-only calculation with fully documented parameters and no output schema, the description supplies everything needed to invoke it correctly, including the default constant and its caveat. It only omits minor practical notes such as the valid linear range for OD readings.
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 showing how the three parameters combine multiplicatively and flagging that factor is the organism-specific tuning knob. That relational meaning is not derivable from the per-field schema text alone.
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 and resource ("calculates cell density (cells per mL)") plus the exact inputs it consumes, so the agent knows precisely what it produces. It does not mention the closely related sibling calculate_bacterial_growth, so differentiation is left to inference.
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 implied by the named inputs (OD reading plus dilution factor), and the note that the factor is "organism-dependent" hints at when to override the default. There is no explicit guidance on when to prefer this over calculate_bacterial_growth or what conditions make the formula invalid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculates the electric field strength produced by a point charge at a given distance using Coulomb's law: E = kQ/r². Uses permittivity parameter or defaults to vacuum permittivity. (cost: 1 credit)
| Name | Required | Description | Default |
|---|---|---|---|
| charge | No | number, required, electric charge in coulombs (C) | |
| distance | No | number, required, distance from the charge in meters (m) | |
| permitivity | No | number, optional, permittivity of the medium in F/m, default 8.854e-12 (vacuum) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. Beyond that the description usefully adds the exact formula and the default permittivity fallback, and it discloses a cost of 1 credit — a genuinely behavioral detail not present in annotations. It stops short of noting edge cases such as r = 0 or invalid negative distances.
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 compact sentences with the core computation and formula front-loaded, followed by the medium/default note. The credit-cost parenthetical is short and earns its place, though it slightly interrupts the technical flow.
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 calculator with no output schema, the definition covers inputs, formula and default medium adequately. The main remaining gap is that the output unit (V/m or N/C) and behavior at zero distance are not stated, which matters for interpreting results.
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 charge, distance and permittivity are already fully documented with units and the vacuum default. The description echoes the permittivity default rather than adding new meaning, so the baseline of 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 states a specific verb and resource ('Calculates the electric field strength produced by a point charge') and pins down the underlying formula (E = kQ/r²), so the agent knows exactly which physical computation this is. It is clearly distinguishable from adjacent calculator siblings such as potential_energy or wire_resistance.
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: the agent can infer this is the tool for point-charge field calculations, but there is no explicit 'use this when…' statement, no note about when a different tool (e.g. potential_energy) is more appropriate, and no preconditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculates final velocity using the kinematic equation: v = v₀ + at, where v₀ is initial velocity, a is acceleration, and t is time. (cost: 1 credit)
| Name | Required | Description | Default |
|---|---|---|---|
| time | No | number, required, time elapsed, seconds, no default | |
| acceleration | No | number, required, acceleration, meters per second squared, no default | |
| initial_velocity | No | number, required, starting velocity, meters per second, no default |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, so safety is covered. The description adds genuinely useful context the annotation lacks: the 1-credit cost. It does not state the output unit (m/s) or how string-typed inputs are coerced.
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 compact clauses: the operation and formula first, the cost parenthetical last. Nothing is padded or repeated from the name.
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 deterministic calculation with full schema coverage and annotations, the definition is nearly sufficient. The only real gap is that with no output schema, the return value's identity and units are only implied by the 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% and already documents each parameter's unit and requirement, so the baseline is 3. The formula does add meaning beyond the schema by showing how the three inputs combine (a multiplied by t, then added to v₀), but no extra format or range detail is supplied.
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 and resource ("Calculates final velocity") and disambiguates from the large calculate_* sibling family by naming the exact equation v = v₀ + at. The reader knows precisely what quantity is produced without opening the schema.
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 pick this over related physics/kinematics siblings such as potential_energy, or on prerequisites like consistent unit systems. The description is a pure definition with no decision context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculates electrostatic potential energy using the formula U = qV, where U is energy, q is charge, and V is voltage. (cost: 1 credit)
| Name | Required | Description | Default |
|---|---|---|---|
| charge | No | number, required, electric charge, coulombs (C), no default | |
| voltage | No | number, required, electric potential difference, volts (V), no default |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds one genuinely new behavioral fact — the 1-credit cost — but says nothing about input validation (string inputs allowed) or output format.
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, front-loaded with the operation and formula, with the cost note trailing. Nothing superfluous, though the parenthetical cost could be more clearly separated.
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 pure calculation with full schema coverage and clear read-only annotations, the description covers what is needed. Only a brief note on output units or acceptance of string inputs 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% and already documents charge in coulombs and voltage in volts. The description only maps the symbols q and V to the parameters, which adds marginal meaning beyond the schema; 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 and resource ("Calculates electrostatic potential energy") and gives the exact formula U = qV, which distinguishes it from physics siblings like calculate_electric_field or calculate_final_velocity. No explicit sibling routing, so not 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?
There is no guidance on when to prefer this over related tools (e.g., calculate_electric_field) and no prerequisites stated. Usage is only implied by the formula itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Projects future population size using exponential growth formula with a constant annual growth rate (percentage). (cost: 1 credit)
| Name | Required | Description | Default |
|---|---|---|---|
| num_years | No | number, required, number of years to project forward | |
| current_pop | No | number, required, the current population size | |
| annual_growth | No | number, required, annual growth rate as a percentage (e.g., 2.5 for 2.5%) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered structurally. The description adds two pieces of real value beyond that: the growth model used and a 'cost: 1 credit' billing note. It does not mention that the projection assumes a fixed rate and ignores migration/fertility dynamics, which is the main behavioral caveat.
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 that names the computation and its model, with the credit cost appended. No wasted wording, though it is terse enough that the assumptions of the model go unstated.
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 deterministic math function with full schema coverage, rich safety annotations and no output schema, nothing an agent needs in order to call it correctly is missing. The model name and credit cost make it self-sufficient.
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 num_years, current_pop and annual_growth are fully documented in the schema, including the percentage convention. The description only echoes the percentage convention and adds no unit, range, or input-format detail beyond it; 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 and resource ('Projects future population size') and names the underlying model ('exponential growth formula with a constant annual growth rate'), which separates it from generic calculators like compound_interest or average. It does not explicitly name a sibling to avoid, so it stops short of the top score.
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 explicit when-to-use or when-not-to-use guidance and no named alternative among the many math siblings (project_investment_growth, calculate_bacterial_growth). The 'constant annual growth rate' phrasing implicitly signals the model's assumption, which is the only usage hint provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculates electrical resistance of a wire using the formula R = ρL/A, where R is resistance, ρ is material resistivity, L is length, and A is cross-sectional area. (cost: 1 credit)
| Name | Required | Description | Default |
|---|---|---|---|
| length_m | No | number, required, length of the wire, meters (m), no default | |
| material | No | string, required, material type (e.g., copper, aluminum, silver, gold), no units, no default | |
| area_sq_m | No | number, required, cross-sectional area of the wire, square meters (m²), no default |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds useful cost information ('1 credit') and the exact computation performed, but never says how resistivity is resolved from the 'material' string (internal lookup table? case sensitivity?) nor the units of the returned resistance.
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: the operation and governing formula come first, followed by a short cost tag. Nothing is redundant and the most decision-relevant information is front-loaded.
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?
There is no output schema, so the description ideally should state that the result is a resistance value in ohms; since R is defined in the formula this is mostly inferable. For a simple three-parameter deterministic calculator, the definition is nearly complete, with only output units and material handling left implicit.
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 each parameter is already fully documented. The description restates ρ, L and A and shows their relationship in the formula, which reinforces but does not materially extend the schema's meaning; the 3 baseline 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 states a specific verb ('Calculates') and an unambiguous resource ('electrical resistance of a wire'), backed by the exact formula R = ρL/A. It does not explicitly differentiate itself from the many sibling calculators (e.g., calculate_electric_field, potential_energy), but the formula makes its scope unmistakable.
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, when not to, or which sibling to prefer for related electrical/geometry calculations. The formula implicitly scopes it to uniform-wire DC resistance, but no explicit guidance, prerequisites, or alternatives are given.
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.
calculate_bacterial_growthcalculate_cell_densitycalculate_electric_fieldcalculate_final_velocitypotential_energyproject_populationwire_resistanceCompound and simple interest, investment growth, future value, CAGR, dividends and tax at a rate
Averages, spread, chi-square, regression, primes, factorials, probability, areas and distances
Exact arithmetic, algebra, calculus, physics, chemistry and finance with a checkable formula.
Physics calculators that show their work, plus the CODATA 2022 constants. Educational use.
Add one secure layer between your agents and this server.
