PeptideLab Calculator

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds genuine behavioral context beyond that: it discloses returned precision/parallax warnings, syringe overflow checks and concentration advisories, plus the 'Research use only' domain caveat. It does not describe error behavior, but the added disclosure is substantive.

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?

Front-loaded with the core purpose, then modes, then return characteristics, then the disclaimer — every sentence carries information. It is slightly dense with four clauses but no wasted wording.

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 compensates by naming what is computed and what warnings come back, which is what an agent needs to interpret results. A calculator with all parameters documented needs little more, though error/edge-case behavior (e.g. invalid dose/water combos) is 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 coverage is 100% and the schema itself already labels dose_mcg as forward mode and dose_units as reverse mode, so the description's mode explanation largely restates structured data. Baseline 3 is appropriate since the schema carries the parameter burden.

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 (calculate) and resource (peptide reconstitution) and enumerates the exact outputs — concentration, draw volume, syringe units, doses per vial. It also splits the tool into forward and reverse modes, making it unmistakably distinct from planning-oriented siblings like plan_schedule and compare_syringes.

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 explicit mode-selection guidance — pass dose_mcg for forward mode, pass dose_units to back-solve the dose — which tells the agent when to supply each parameter. It does not name an alternative sibling tool or state exclusions, so it stops short of the 5 bar.

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

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

Annotations already declare readOnlyHint=true, so the safe-read profile is covered. The description adds genuine behavioral context beyond that: the ranked best-first ordering, the parallax/reading-error risk dimension, and the 'Research use only' scope limitation. It does not contradict the annotation.

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 the comparison scope, the output dimensions and the sorting rule front-loaded, plus the safety disclaimer at the end. No filler or repetition.

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 enumerates what comes back (units, fit, relative error, ranked order) and flags research-only use. But for a 5-parameter tool at 0% schema coverage, the inputs most needed to call it correctly (peptide, vial_mg, water_ml, lang) remain undocumented.

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 0% across 5 parameters, so the description carries the full burden and largely fails: only 'target dose' loosely maps to dose_mcg, while vial_mg, water_ml, peptide and the lang enum are unexplained. An agent must infer the reconstitution inputs entirely from parameter names.

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 (compare U-100 vs U-40 syringes for one target dose) and even enumerates the comparison outputs (units required, fit, relative reading error). This clearly separates it from siblings like calc_reconstitution or plan_schedule without opening their schemas.

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 one target dose' implies the context (a single dose you want to read accurately), and 'Sorted best-first' implies the decision it supports. However, there is no explicit when-to-use/when-not statement and no alternative tool named for related tasks such as reconstitution volume calculation.

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

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

readOnlyHint=true already tells the agent this is a safe read, so the description's main addition is the payload inventory (what fields come back) plus the research-only disclaimer. It says nothing about behavior on an unknown peptide id, localization behavior of the lang parameter, or retrieval limits.

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 dense sentences with no filler; the payload inventory is front-loaded and the disclaimer is correctly relegated to the end.

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 field enumeration is genuinely useful and covers the return contract. However, the undocumented lang parameter and the absence of any error/not-found behavior leave gaps for a lookup tool with a required identifier.

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 only 50%: 'peptide' is documented by the schema, but 'lang' (enum en/zh, default en) is undocumented in both the schema and the description. The phrase 'for one peptide' faintly reinforces the singular identifier input but adds no syntax or format detail beyond the schema example.

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 ('Get') and resource ('research protocol record for one peptide') and enumerates the returned content (dosing window, frequency, cycle, titration ladder, notes, confidence grade). It implicitly distinguishes itself from list_peptides by scoping to a single peptide, but it never names a 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 guidance, no exclusions, no routing among siblings such as list_peptides, plan_schedule, or plan_stack. 'Research use only' is a legal disclaimer, not usage guidance.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful scope—curated dataset, returned fields, and a research-only restriction—but does not describe pagination, result limits, or search behavior beyond the schema.

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, front-loaded with the action and returned fields. The "Research use only" caveat is brief and 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?

For a simple read-only list/search tool with no output schema, the description adequately names the dataset and returned fields. However, it omits the language parameter and does not clarify search matching behavior, leaving gaps for a two-parameter tool.

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 50%: query is documented in the schema, but lang has no description and is not mentioned in the tool description. The description does not compensate for this gap, so an agent must infer what lang controls.

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: "List or search the curated research peptide dataset," and enumerates the fields returned (ids, names, aliases, categories, confidence grades, dosing windows). It does not explicitly differentiate from siblings like get_protocol or plan_stack, though the list/search framing is distinct.

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 description implies usage through "List or search" and adds a "Research use only" restriction, but it gives no explicit when-to-use guidance, no exclusions, and no routing to alternatives such as get_protocol or compare_syringes.

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

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

readOnlyHint=true already covers the safety profile, and the description adds genuinely non-obvious behavior: on-demand compounds yield an advisory rather than a calendar, and the output is a research-use-only schedule. It still does not say what the advisory looks like or how the schedule is structured, but that gap is minor against the annotation coverage.

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 tightly packed sentences with no filler, and the core capability (week-by-week schedule) is front-loaded. The trailing 'Research use only' clause is short and carries real constraint information rather than padding.

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 7-parameter read-only generator with no output schema, the description covers what is produced (presets, titration ladders, optional syringe units) and the one output divergence (advisory vs calendar). It stops short of describing schedule granularity or what the advisory contains, but nothing essential to invoking the tool correctly is absent.

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 86%, so the schema already documents days, weeks, start_date, and the vial_mg/water_ml pairing. The description's 'frequency presets (daily / 1-3x weekly)' and 'per-event syringe units' loosely reinforce those parameters but add no syntax or semantics beyond what the schema states, so the 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 (generate) and a well-defined artifact (week-by-week research schedule with frequency presets, titration ladders, and syringe-unit readouts), which clearly separates it from data-lookup siblings like list_peptides or get_protocol. However, it never explicitly contrasts itself with plan_stack, the closest sibling, so the agent must infer the boundary between scheduling one peptide and planning a stack.

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 artifact it produces; there is no explicit 'use this when…' statement or naming of alternatives such as plan_stack or calc_reconstitution. The one conditional note ('On-demand compounds return an advisory instead of a calendar') hints at an edge case but is behavioral rather than routing guidance.

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

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

Annotations declare readOnlyHint=true, so the safety profile is already covered; the description still adds real value by disclosing what the computation produces — per-compound draws, a combined draw with split-injection advisories, and frequency-conflict detection. With no output schema, this output disclosure matters. It omits any error/permission behavior, but none is critical for a pure calculation.

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 with a colon-delimited list of three outputs, plus a short research-use trailer. Every clause earns its place and nothing is padded.

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 carries the return-value burden by naming the three result categories. It does not mention guidance on defaults or how the stack relates to scheduling tools like plan_schedule/get_protocol, but for a bounded calculation tool this is close to 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 description coverage is 100%, so peptide, vial_mg, water_ml, dose_mcg, syringe_type and syringe_capacity_ml are all documented in the schema. The description adds no additional parameter meaning (e.g., how dose_mcg interacts with the draw-unit conversion), 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?

States a specific verb ('Plan') and resource ('multi-compound stack') and enumerates the concrete outputs (per-compound draw volumes/units, combined draw volume with split-injection advisories, frequency-conflict detection). The 'multi-compound' framing implicitly separates it from single-compound calc_reconstitution, but it never names a sibling outright.

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 2–4 compound scope and 'multi-compound' wording suggest this is the stack-planning tool rather than calc_reconstitution or plan_schedule, but no explicit when-to-use, when-not, or alternative is named.

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