DosePlot Agent API

recon_calc

Paid: $0.01 USDC per call via x402 (payment in _meta["x402/payment"]). Reconstitution math for one vial and one target dose: the concentration to reconstitute to, the bacteriostatic water to add, what one dose reads on a U-100 syringe, and how many doses the vial yields. Exactly one target-dose field must be present; unknown fields are rejected. Outputs are for relay to a human decision-maker; not for autonomous administration.

Input Schema

TableJSON Schema

Name	Required	Description
`draw_ml`	Yes	The volume you want to DRAW for one dose, in mL -- not the vial fill. Accepted range is one hundredth of a mL up to ten mL. The fill needed to make that true comes back as bac_water_ml.
`vial_mg`	Yes	Total mass in the vial, mg. Positive.
`cost_usd`	No	Vial cost, zero or more. Omitted, cost_per_dose_usd is null.
`frequency_days`	No	Days between doses, positive. Feeds days_per_vial only. Defaults to one.
`target_dose_mg`	No	Target dose, mg. Positive.
`target_dose_mcg`	No	Target dose, mcg. Positive.

Output Schema

TableJSON Schema

Name	Required	Description
`meta`	Yes
`disclaimer`	Yes	Fixed disclaimer. Relay it with any output.
`residual_mg`	Yes
`bac_water_ml`	Yes
`intended_use`	Yes	Fixed intended-use statement. Relay it too.
`days_per_vial`	Yes
`syringe_marks`	Yes
`doses_per_vial`	Yes
`units_per_dose`	Yes
`cost_per_dose_usd`	Yes
`concentration_mg_per_ml`	Yes

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden and discloses a $0.01 USDC per-call payment via x402, strict field validation behavior, and a usage limitation (not for autonomous administration). This goes well beyond what the schema provides. It does not explicitly state the tool is read-only, but as a pure calculation that is reasonably inferable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three dense sentences deliver payment info, purpose, outputs, validation constraints, and usage scope with zero redundancy. The most critical operational detail (payment) is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, parameters are fully documented, and the description adds payment, validation, and output-usage context. The only meaningful gap is explicit guidance for selecting this tool versus sibling tools; otherwise an agent has enough to invoke it correctly and interpret the results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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 well described. The description adds the important cross-parameter rule that exactly one target-dose field must be present and that unknown fields are rejected, which clarifies how target_dose_mg and target_dose_mcg relate and is not captured by the schema's required list.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool performs reconstitution math and enumerates the outputs (concentration, bacteriostatic water to add, U-100 syringe reading, doses yielded). It uses a specific verb and resource, though it does not explicitly distinguish itself from the sibling tools get_compound, list_compounds, or simulate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a hard usage constraint: 'Exactly one target-dose field must be present; unknown fields are rejected.' It also scopes outputs to relay to a human decision-maker, not autonomous administration. It does not, however, state when to prefer this tool over its siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All DosePlot Agent API tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0

Disambiguation5/5

Each tool targets a distinct operation: single-compound lookup, full compound listing, reconstitution math, and PK simulation. The paid tools recon_calc and simulate are clearly differentiated by inputs and outputs, and get_compound vs list_compounds is obviously singular vs. plural.

Naming Consistency3/5

get_compound and list_compounds follow a clean verb_noun pattern, but recon_calc mixes an abbreviated noun with 'calc' and simulate is a bare verb. The names are still readable and not chaotic, but the set is not stylistically uniform.

Tool Count5/5

Four tools is a well-scoped count for a focused reference and calculation API. Each tool earns its place and there is no redundant surface area.

Completeness4/5

The core domain is covered: compound lookup, full listing, reconstitution calculations, and PK simulation. Minor gaps exist, such as no filtering/searching on list_compounds and no direct multi-compound comparison, but an agent can work around these.

Resources

Need Help?