Verbex Lab Tools

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds genuinely new context: it returns Markdown and HTML, and timestamps and voice prompts are opt-in. It does not explain the default behavior when only a preset or only sections are supplied, which keeps it short of a 5.

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, front-loaded with the purpose, then the return formats. Almost no waste; the section list is long but each item conveys real output structure.

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 an output schema present and annotations covering safety, the description supplies what the structured fields do not: the generated document shape and output formats. A note on default behavior with zero required parameters, or on preset-vs-section precedence, would make it 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 coverage is 86%, so the baseline is 3, but the description adds value the schema does not: it frames `preset` and `sections` as alternative construction paths ('from a preset or custom list') and clarifies that timestamps and voice-capture prompts are optional outputs. It does not resolve the preset/presetId and sections/sectionItems alias ambiguity, which is the main remaining gap.

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?

Specific verb ('Build') plus a well-defined resource ('electronic lab notebook entry template') and an enumeration of the sections it produces. It also states the output formats. It does not, however, distinguish itself from the sibling `protocol_template`, which an agent could plausibly confuse for the same job.

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 an experiment' implies the use case, and 'from a preset or custom list' hints at two construction modes, but there is no explicit when-to-use, no exclusion against `protocol_template`, and no statement of what happens if called with no arguments.

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 readOnly, idempotent, non-destructive and closed-world behavior, so the safety profile is covered. The description adds real value beyond that by explaining how output varies by content type: guides give a summary, templates include a blank template plus worked example and editable file link, and calculators return method, input fields and a computed example.

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 lead with the core action and return format, then spend the remaining space on genuinely useful type-specific expectations. No sentence is redundant.

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 an output schema present and rich annotations, the description only needs to cover what structured fields cannot. It does that by explaining the shape of results for each content type and the search-result id dependency, leaving little an agent would need to infer.

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 already documents the single id parameter with examples like 'template:experiment-plan'. The description reinforces that the id comes from a search result but adds no syntax or format details beyond what the schema provides, so the 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 specific action ('Get the full text of a search result by id, as Markdown') and distinguishes itself from the sibling search tool by making clear it operates on results already found. It also names the three content families (guides, templates, calculators) it can return, so an agent can tell exactly what resource it retrieves.

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 'a search result by id' clearly implies this is a follow-up call to search, giving solid context for when to use it. It stops short of explicitly stating when not to use it or naming alternatives, but the search-first dependency is unambiguous.

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 read-only, idempotent, non-destructive, closed-world, so safety needs no restating. The description adds real behavioral context beyond that: the calculation is deterministic given inputs, defaults are named (3:1 mixing ratio), and it warns that molecular weights must come from the user or certificates of analysis, which is a genuine input-quality prerequisite not encoded in annotations.

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 dense sentence front-loads the verb and input basis, then lists outputs in a computable order, with a short caveat sentence at the end. Every clause carries information; 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 an output schema present, the description need not describe return values, and it correctly omits them while still naming the computed quantities. Combined with annotations covering safety and the MW provenance caveat, an agent has enough to call it correctly; only the less-obvious numeric parameters are left entirely to the schema.

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 64%, so the schema already documents most parameters including defaults and enums. The description reinforces the domain-critical ones (RNA mass, N/P ratio, lipid mol% with an example 50/10/38.5/1.5 breakdown, mixing ratio default) but says nothing about nucleotideMolecularWeight, aminesPerMolecule, or the stock unit enums, so it does not fully compensate for the gap.

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?

Names a specific verb ('Plan') and resource ('lipid nanoparticle (LNP) formulation for RNA') and enumerates exactly what is computed: moles, mass, stock volumes, ethanol/aqueous phase volumes, final RNA concentration, ethanol fraction, lipid:RNA ratio. Nothing among the siblings (solution_prep, serial_dilution, pcr_master_mix) could be confused with it.

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 input framing (from RNA mass, N/P ratio and lipid mol%) but there is no explicit statement of when to call this versus solution_prep or serial_dilution, nor any exclusion or prerequisite trigger. An agent can infer it is the formulation-planning step, but only by reasoning about the name.

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, idempotentHint, openWorldHint=false and non-destructive, so the safety profile is covered. The description adds genuinely useful context beyond that: this is a pure text-in/text-out transform with no image processing, which is the main behavioral surprise an agent could hit.

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 load-bearing: the first defines the transform and its output shape, the second kills the image-input misconception. Nothing is redundant or buried.

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 field details needn't be restated, and annotations cover safety. The definition is essentially complete for calling it, though it does not hint at whether ocrConfidence or sourceImageName affect results, a minor gap for a 3-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 100%, so ocrText, ocrConfidence and sourceImageName are already documented in the schema. The description only reinforces which parameter to send ("send the label text") and says nothing about how confidence or source image name are used. 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 (turn/parse) and a specific resource (reagent bottle or kit label text) and names the concrete output fields (product name, catalog number, lot, expiry, concentration, storage). An agent can immediately tell this is a text-to-structured-fields parser rather than an OCR or file-fetch tool.

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?

Explicitly bounds the input: "Parses the provided text only; send the label text, not an image." That exclusion prevents the most likely misuse. It stops short of naming a sibling (e.g., fetch) as the source for obtaining OCR text, so routing to an alternative is left implicit.

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 cover safety (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds real behavioral context beyond that: the calculator fills leftover volume with water, applies an excess factor, and excludes template from the mix — all of which determine what the result actually contains.

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 triggering condition, then the calculation rule, then input modes, then the two exclusions. Dense but every sentence carries information; the 'Give each component...' sentence is long but earns its length via examples.

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?

Output schema exists, so return values needn't be explained, and an output schema means the description only has to cover inputs and behavior — which it does for the component modes and water rule. Minor gaps: no mention of how excessPercent interacts with fixed-volume components, or what happens when per-reaction volumes exceed reactionVolume.

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 already 88%, so baseline is 3, but the description goes further by explaining the three mutually exclusive ways to specify a component (stock + final concentration, amount per reaction such as '1.25 U from 5 U/µL', or a fixed volume) and the accepted unit families. That is the key disambiguation the flat enum lists cannot convey.

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 (calculates volume of each component) and resource (PCR/qPCR reaction master mix) and scopes it to 'several wells', which separates it from single-solution siblings such as solution_prep and serial_dilution. The water-fills-remainder rule makes the output shape 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?

'Use when someone sets up a PCR or qPCR reaction mix for several wells' gives a clear triggering condition, and 'Do not list water; it is calculated' plus 'Template can be added per well separately' give concrete usage rules. No alternative tool is named for the single-reaction or non-PCR case, so it stops short of explicit routing.

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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context beyond that: the supported plate formats, composition with standards/samples/controls/blanks, row- or column-filling, edge-well avoidance, replicate grouping, and the shape of the returned grid.

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?

The description is two sentences, front-loaded with the usage condition and followed by the operation and return shape. Every clause earns its place and there is no preamble 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?

For an 11-parameter tool with a nested standards object and an output schema, the description covers the purpose, the layout rules and the return format succinctly. It does not discuss limits such as maximum replicate counts or what happens when the plate is too small, but those are largely schema-enforced or output-schema-covered.

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 high at 82%, so the schema already documents the key parameters such as fillDirection, avoidEdges and keepReplicatesTogether. The description reinforces the meaning of these options in prose but does not add much syntax or constraint detail beyond what the schema already 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?

The description states a specific verb and resource: laying out standards, samples, controls and blanks with replicates on 6- to 384-well plates. It is clear enough to distinguish the tool from general liquid-handling or dilution tools, though it never explicitly contrasts with siblings such as serial_dilution or eln_template.

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 opening 'Use when someone lays out a multiwell plate (ELISA, qPCR, cell or compound assays)' gives a concrete usage context. It does not state when not to use it or name an alternative tool for adjacent tasks, so the guidance is strong but not complete.

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 this as read-only, idempotent, non-destructive, and closed-world, so the description has a lower disclosure burden. It adds useful behavioral context by saying the result is a structured protocol returned as Markdown and HTML ready to fill in or print, without contradicting the annotations.

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?

The description is two tight sentences with the core action and output front-loaded. Every phrase contributes to understanding what the tool produces and how it is configured.

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 an output schema present, the description does not need to explain return values in depth, and it still usefully names Markdown and HTML output. It is nearly complete for ordinary selection, though it could explicitly clarify preset versus custom sections and sibling differentiation.

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 high at 86%, so the schema already documents presets, custom sections, title, and inclusion flags. The description reinforces the preset/custom-section choice but does not add meaningful detail about aliases such as preset/presetId or includeExecutionNotes and includeVersionHistory.

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: it builds a structured lab protocol from a title using a preset or custom sections, and it names the returned formats. It does not distinguish this tool from the sibling eln_template or explain when this protocol scaffold should be chosen over that alternative.

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 'using a preset or custom sections' implies the main usage path, but there is no explicit when-to-use guidance, no exclusions, and no comparison with eln_template or other siblings. An agent must infer the selection context from the name and schema.

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 readOnly, idempotent, non-destructive and closed-world, so the safety profile needs no restating and the description correctly avoids it. It adds real context beyond annotations: the return shape (ids, titles, urls to cite) and the note that type='tool' lists calculators you can call without searching. It doesn't mention ranking, empty-result behavior or pagination past limit, so not a 5.

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 front-loaded sentences: scope, return contract, then exclusion. The parenthetical topic list is long but functional, serving as searchable subject matter. Slightly dense but nearly every clause 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?

With a rich annotation set and an output schema, the description doesn't need to explain return values or safety, and it correctly focuses on routing. Scope, exclusions and the id-to-fetch handoff cover what an agent needs; only ranking/result-volume behavior is left implicit, which is minor.

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 67% with strong enum and query descriptions, so the schema carries most parameter meaning. The description's only parameter-adjacent contribution is the note that calculators can be called without searching, which the enum description already states; limit and query semantics get nothing extra. 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 (search) plus the exact resource set (guides, templates) and enumerates the guide topics so an agent can match intent. It also distinguishes itself from the fetch sibling by saying it returns ids to pass to fetch, which no schema field conveys.

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?

Explicitly names what the tool is NOT for (mass, volume, dilution, master mix, LNP formulation, plate map) and routes to the correct alternative ('call that calculator directly'). The sibling list (serial_dilution, pcr_master_mix, plate_map, lnp_formulation, solution_prep) maps cleanly onto those excluded cases, leaving little inference.

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 this safe, read-only, idempotent, and closed-world, so the description doesn't need to repeat that. It does add that the tool computes per-tube transfer volume, diluent volume, and resulting concentration at each step, but leaves open computational details such as whether transfer volume is included in final volume.

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, front-loaded with the usage trigger, followed by the output the tool plans. Nothing in it is redundant with the schema or annotations.

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 an output schema covering return values and full annotation coverage, the description only needs to convey scope and computed outputs, which it does. Slight gap: it doesn't mention the 12-tube cap that the schema enforces, which would matter for large dose series.

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 baseline is 3. The description restates four of the seven parameters (stock concentration, constant dilution factor, number of tubes, final volume per tube) and clarifies that the factor is applied uniformly at each step, but adds no syntax or unit-coupling detail 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 and resource (plans a serial dilution) and enumerates concrete applications (standard curves, titrations, dose series), which implicitly separates it from siblings like solution_prep or lnp_formulation. No explicit sibling comparison, so it stops short of 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?

"Use for any serial dilution" plus the parenthetical use cases gives clear triggering context for an agent deciding among sibling tools. It doesn't state when not to use it or name an alternative for one-off single dilutions.

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 readOnly/idempotent/non-destructive/openWorld=false, so the safety bar is low; the description still adds value by disclosing the response envelope (primary result, step summary, warnings, safety notes). It also discloses mode-conditional input expectations, which matters more than the annotation set here. It omits computational caveats (rounding, unit-conversion assumptions).

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 'Use when', then mode semantics, then return contents — a clean trigger-to-behavior progression. Every clause carries information: the parenthetical examples are user-language triggers, and the mode breakdowns are not restated elsewhere in prose.

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, yet the description still summarizes them. For a 13-parameter conditional allOf/oneOf schema, the mode + solveFor narrative gives enough scaffolding to construct a valid call. The one gap is that it does not state that solid mode requires molecularWeight and the unit parameters, leaving that inference to the schema.

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 69% across 13 parameters, so baseline would be 3. The description compensates by explaining what each mode consumes (solid: molecular weight, target concentration, final volume; stock: the four solvable C1V1 variables), which maps the conditional schema onto a mental model. It does not clarify unit parameters or the optional solvent/solutionName fields.

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 two concrete computations — solid mass from molecular weight/target concentration/final volume, and C1V1 dilution — with the C1V1 formula spelled out. It is specific enough that an agent knows exactly what class of answer comes back. It does not, however, name any sibling (serial_dilution, lnp_formulation) to disambiguate similar wet-lab math.

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 opening clause is a trigger phrase tied to real user phrasing ('how many grams for X mM in Y mL, making up a buffer or salt solution'), which is genuinely useful routing. It gives clear positive conditions but never states when NOT to use it or which sibling to pick instead for stepwise dilution series.

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