Bioassay & ecotoxicology calculators: ELISA 4PL/5PL curves, dietary risk, pollution indices.
Scored across 3 tools
The three tools serve clearly distinct computational purposes: dietary risk assessment, ELISA standard curve fitting, and pollution index calculation. There is no overlap in their inputs or outputs, so an agent can easily select the right tool.
All names use snake_case, but the patterns differ: 'fit_standard_curve' uses a verb_noun structure, while 'dietary_risk' and 'pollution_indices' are noun phrases. The mix is readable but not consistent.
With only three tools, each covering a substantial and distinct scientific computation, the set is well-scoped. Every tool earns its place and there is no redundancy.
The tools cover three core analysis workflows (dietary risk, curve fitting, pollution indices) completely for their stated methods. Minor gaps exist, such as general data preprocessing or additional lab calculations, but agents can work around them.
Compute Estimated Daily Intake, Target Hazard Quotient per element, Hazard Index and optional cancer risk for contaminants in food. The result echoes the inputs received, lists plausibility warnings and includes the required Labreador citation.
| Name | Required | Description | Default |
|---|---|---|---|
| elements | Yes | ||
| bodyWeightKg | Yes | Body weight in kg. | |
| ingestionRateKgPerDay | Yes | Food ingestion rate in kg/day (wet weight basis). Convert kg/year by dividing by 365. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, closed-world behavior, so the safety profile is covered. The description adds genuinely useful output behavior: the result echoes inputs back, emits plausibility warnings, and includes a required Labreador citation.
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 that lead with the core computation and then the returned artifacts. No filler, though the acronym-laden first sentence is dense enough to slow comprehension slightly.
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 usefully covers return contents (echoed inputs, plausibility warnings, citation) and the optional-vs-required logic for cancer risk. What is missing is guidance on input validity limits or how the sibling pollution_indices differs, but the essentials for calling the tool are present.
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 67%, with the element fields (csf, name, rfdMgPerKgDay, concentrationMgPerKg) individually documented in the schema. The description only adds that cancer risk is optional, which corresponds to the non-required csf field; otherwise it adds nothing beyond 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?
States a specific verb (compute) and names the exact metrics produced (EDI, THQ per element, HI, optional cancer risk) for contaminants in food. This clearly separates it from fit_standard_curve, though it does not explicitly distinguish itself from the more topically similar pollution_indices 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?
No when-to-use or when-not-to-use guidance is given, and neither alternative (pollution_indices, fit_standard_curve) is mentioned. The reader must infer applicability purely from the metrics named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fit a 4PL or 5PL logistic curve to ELISA standards and optionally interpolate sample concentrations from their signals (OD). The result echoes the inputs received, lists data-quality warnings and includes the required Labreador citation.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Logistic model to fit. | 4PL |
| signals | Yes | Measured signal (OD) for each standard, same order. | |
| sampleSignals | No | Sample signals to convert to concentrations. | |
| concentrations | Yes | Nonzero standard concentrations. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, closed-world, so the safety profile is covered. The description adds genuinely useful output context: the result echoes inputs, emits data-quality warnings, and carries a required Labreador citation — all beyond what annotations provide.
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 core action is front-loaded, the optional behavior follows immediately, and the return-value remark is packed efficiently. No filler.
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 shoulders the burden by describing the response (echoed inputs, warnings, citation). Combined with 100% schema coverage on inputs, an agent has what it needs; only the model-choice rationale is 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 description coverage is 100%, so every parameter (model, signals, sampleSignals, concentrations) is already documented in the schema. The description reinforces that signals are OD and that sampleSignals drive interpolation, but adds no format or constraint detail beyond the schema. 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?
States a specific verb and resource: fitting a 4PL/5PL logistic curve to ELISA standards, plus the optional interpolation of sample concentrations from OD signals. The domain is fully unambiguous and trivially separable from the unrelated siblings (dietary_risk, pollution_indices).
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: fit a curve to standards and optionally interpolate samples. It says interpolation is optional but gives no guidance on when to prefer 4PL vs 5PL, nor any prerequisites for the input data. Adequate but leaves the model-selection decision to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute contamination factor and geoaccumulation index per element and the Pollution Load Index for one sample. The result echoes the inputs received, lists plausibility warnings and includes the required Labreador citation.
| Name | Required | Description | Default |
|---|---|---|---|
| elements | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and closed-world behavior, so the safety profile is covered. The description goes beyond them by disclosing the response contents: inputs are echoed, plausibility warnings are listed, and a Labreador citation is required — useful output-shape context not available in any structured field.
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 earning their place: the first gives the computation and its scope, the second discloses the response contents. Front-loaded with the core verb and no filler.
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 read-only deterministic calculator with no output schema, the description covers inputs (per element, one sample) and return contents (echoed inputs, warnings, citation). It stops short of describing the index scales or units of the returned CF/Igeo/PLI values, but nothing critical for calling it 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?
With one top-level parameter and reported schema description coverage of 0%, the description must carry meaning. It clarifies that input is per element and limited to a single sample, which is helpful, but it does not explain the baseline/reference role or unit expectations for the elements array beyond what the nested schema notes.
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 (compute) plus three named outputs (CF, Igeo, PLI) and their scope: per element, for one sample. This is far more specific than the sibling tools dietary_risk and fit_standard_curve, so routing is unambiguous.
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 phrase 'for one sample' implicitly scopes usage and warns against passing multiple samples, but there is no explicit when-to-use, when-not-to-use, or mention of alternatives such as dietary_risk. Usage must be inferred from the scope constraint.
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.
dietary_riskfit_standard_curvepollution_indicesEFSA OpenFoodTox — the reference values EFSA has derived for chemical substances in food and feed…
90+ pure finance calculators: loans, investing, bonds, options, tax. Stateless, stores nothing.
140+ calculators and data tools — finance, health, science, global comparisons and more.
Exact statistics & probability: distributions, hypothesis tests, CIs, Bayesian updates, regression.
Add one secure layer between your agents and this server.
