Chemistry, pharma and biotech tools for AI assistants: NMR, MS, IR and UV analysis, ADMET and ICH M7, stability (ICH Q1), HPLC methods, DoE, docking, retrosynthesis, biologics. Deterministic results you can check. Built in Leipzig, Germany.
Scored across 134 tools
With 134 tools spanning many chemistry and biopharma domains, several boundaries blur: covabasic_analyze and covachem_profile both compute broad descriptor sets from SMILES, covabasic_druglikeness and covachem_druglikeness duplicate drug-likeness screening, and the MS/NMR families contain several identification and verification tools with subtle distinctions. The detailed descriptions help in places, but overlapping capabilities remain easy to misselect.
Names use a consistent domain-prefix plus snake_case convention (covabasic_, covabio_, covadoe_, covnmr_, etc.), and most are verb-object pairs. A few are noun-only or proper-noun names like covasyn_credits, covasyn_jobs, and covabasic_reynolds, but these are minor deviations.
134 tools is far beyond a coherent selectable surface; even a broad chemistry suite would benefit from consolidation or splitting by domain. The count creates planning and selection overhead, and several tools duplicate or nearly duplicate others.
The suite covers core descriptor, bio-sequence, DoE, IR/MS/NMR/UV, solubility, and job-management workflows, so it is broad. However, it references absent tools such as covachem_pka and covachem_adme, lacks acute toxicity coverage in covatox, and omits some common chemistry operations such as reaction prediction/retrosynthesis or docking, leaving notable dead ends.
Compute molecular descriptors from SMILES.
scope options:
"basic" — 40+ RDKit descriptors (atoms, bonds, rings, scaffolds, HBD/HBA, MW, complexity)
"extended" — basic + Chi indices, Kier-Hall, Gasteiger charges, flexibility ratio
"lipophilicity" — LogP, MR, TPSA, LabuteASA surface descriptors
"mordred" — 100 Mordred 2D descriptors (autocorrelation, topology, information content)
"all" — everything combined
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | basic | |
| smiles | Yes | ||
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does disclose what each scope computes (descriptor families and rough counts), but says nothing about authentication requirements despite an api_key parameter, compute cost, rate limits, or failure behavior on invalid SMILES.
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 purpose sentence is front-loaded and the scope enumeration is compact and scannable. Slightly list-heavy, but every line carries distinct information.
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 no explanation, and the main input dimension (scope) is well covered. What is missing is any mention of authentication/API-key handling, which matters for a 3-parameter tool with zero schema descriptions.
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%, so the description must compensate. It richly documents the scope parameter (all five options with their contents), which is the one that matters most, but adds nothing about smiles format expectations or the api_key parameter.
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+resource (compute molecular descriptors) and a specific input (SMILES), which separates it from siblings like covabasic_druglikeness or covabasic_describe_structure. However, it never explicitly names the nearest alternatives or the boundary between them, leaving that inference to the agent.
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 choose this tool over sibling descriptor/profile tools such as covabasic_druglikeness or covabasic_describe_structure. The scope list tells you the options but not the conditions under which any option is preferable, so selection is left entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return atom indices for a named structural query — replaces hand-written SMARTS.
Use this when you need atom positions for a structural feature
(e.g. "which atoms are in the aromatic ring?", "where are the stereocenters?",
"which carbon has the highest oxidation state?").
Returns: `{indices: [...], groups: [[...]], smarts_used: "..."}`. Plus:
- `named_groups: [{name, atoms, smarts}]` for `functional_group_atoms`
- `oxidation_states: [{atom, state}]` for `oxidation_state`
Supported query names (22):
ring/topology : aromatic_ring, aliphatic_ring, saturated_ring,
heterocycle, fused_ring, bridgehead
atom-class : halogen_atom, carbon_atom, heavy_atom, csp3_carbon
stereo : stereocenter, r_s_stereocenter, unspecified_stereocenter
bonds & chains : rotatable_bond, branch_point, chain_termini,
longest_carbon_chain
derived : murcko_scaffold_atoms, brics_break_atoms,
functional_group_atoms
H-bonding / oxidation:
hba (Lipinski-style hydrogen-bond acceptors),
oxidation_state (per-carbon Pauling-EN ox-state,
with parallel `oxidation_states` field)
Examples:
query="aromatic_ring" + smiles="c1ccccc1" → indices [0..5], one group
query="r_s_stereocenter" + smiles="C[C@H](O)C(=O)O" → stereo carbon indices
query="hba" + smiles="CC(=O)O" → carbonyl + hydroxyl O indices
query="oxidation_state" + smiles="CC(=O)O" → carbon indices PLUS
oxidation_states=[{atom:0, state:-3}, {atom:1, state:+3}]
query="functional_group_atoms" + any SMILES → also returns named_groups list
Cost: 2 credits, available on Free tier.| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| smiles | Yes | ||
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses return shape, extra fields for specific queries, cost (2 credits), and Free-tier availability, but does not cover error behavior or authentication requirements beyond the api_key parameter.
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?
Despite its length, the description is tightly structured with clear sections (purpose, return shape, supported queries, examples, cost). It is front-loaded and every sentence adds useful information for selecting or invoking the tool.
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, yet the description still helpfully documents return fields and query-specific extras. Combined with the full query-name list, examples, and cost note, it gives an agent everything needed to select and correctly invoke this 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 coverage is 0%, so the description must compensate. It thoroughly explains the 'query' parameter with all 22 supported values and binds query+smiles in worked examples. The 'api_key' parameter is left unexplained and the SMILES syntax is only implied.
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: 'Return atom indices for a named structural query.' The phrase 'replaces hand-written SMARTS' and the list of 22 supported query names make it clearly distinct from siblings like covabasic_substructure or covabasic_functional_groups.
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 states when to use it: 'Use this when you need atom positions for a structural feature,' with concrete examples. It does not name when NOT to use it or point to specific alternative tools, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
BRICS retrosynthetic fragmentation into purchasable building blocks. Returns fragment SMILES and bond-break locations.
| Name | Required | Description | Default |
|---|---|---|---|
| smiles | Yes | ||
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses the return contents, but omits anything about cost, rate limits, auth for the api_key parameter, or limitations of the BRICS fragmentation (e.g., applicability scope).
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: purpose first, then return content. No filler, no redundancy, front-loaded with the essential operation.
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?
The output schema means return values need not be explained, and the description's mention of fragment SMILES/bond-break locations is a helpful summary. However, with zero annotation coverage and 0% parameter documentation, the definition leaves the api_key parameter and input format 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 0% for two parameters. The description never mentions the required 'smiles' input's expected format or the optional 'api_key', so it fails to compensate for the completely undocumented 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 algorithm (BRICS), a specific operation (retrosynthetic fragmentation), and a specific output target (purchasable building blocks). This clearly distinguishes it from siblings like covabasic_scaffold_analysis or covabasic_functional_groups, which are different analyses of the same input.
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 says what the tool does but gives no when-to-use guidance, no prerequisites, and names no alternatives among the many covabasic_* fragmentation/analysis siblings. The agent must infer eligibility from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the RDKit canonical SMILES. Useful to normalize SMILES before comparison or database lookup.
| Name | Required | Description | Default |
|---|---|---|---|
| smiles | Yes | ||
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It says 'Return,' which weakly implies a read-only computation, but it never states that the operation is non-destructive, deterministic, or free of side effects, nor does it mention authentication needs such as the api_key parameter. With zero annotation coverage, this is a significant disclosure gap.
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 zero waste. The core purpose is front-loaded, followed immediately by the usage context. Every sentence 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?
An output schema exists, so return values need not be described. The tool is simple and the purpose/usage are clear, making the description minimally viable. However, the complete absence of parameter explanation (especially api_key) and behavioral disclosure leaves meaningful gaps for an agent invoking the tool correctly.
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%, so the description must compensate for undocumented parameters. It implies the input is a SMILES string, but never explicitly says so, and it says nothing about the api_key parameter, leaving its purpose and usage completely unexplained. This adds minimal meaning beyond the bare parameter names and types.
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: 'Return the RDKit canonical SMILES.' It is clearly not a tautology and is distinguishable from most siblings by naming the exact chemistry operation. However, it does not explicitly differentiate itself from related siblings like covabasic_standardize or covabasic_convert, leaving that inference to the agent.
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 second sentence provides a clear intended context: 'Useful to normalize SMILES before comparison or database lookup.' This tells the agent when the tool is valuable. It does not name alternatives or exclusions, so it falls short of a full when/when-not/alternative routing guide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unit conversion for chemistry (30+ conversions). Examples: "mol_to_g", "g_to_mol", "ug_to_mg", "celsius_to_kelvin", "ppm_to_molarity", "atm_to_pa". Pass mw for mass-mole conversions.
| Name | Required | Description | Default |
|---|---|---|---|
| mw | No | ||
| value | Yes | ||
| api_key | No | ||
| conversion | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose the identifier vocabulary and the conditional mw requirement, but says nothing about invalid/unknown conversion names, case sensitivity, precision or rounding of results, or how failures are reported. Useful behavioral context, but material gaps remain for a 30+-mode dispatch tool.
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 tight sentences: purpose, concrete examples, then the conditional parameter rule. Zero filler and the most important 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?
An output schema exists so return values need not be explained. For a tool whose main parameter accepts an unenumerated set of 30+ conversion strings, though, a partial example list leaves the agent unable to know whether its chosen string is valid; error and casing behavior are also 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 0%, so the description must compensate. It explains mw (for mass-mole conversions) and gives six example values for the free-form 'conversion' string, which is the highest-risk parameter since it has no enum. It does not document api_key or the value parameter's units, and 6 of 30+ accepted conversion strings left the agent guessing.
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 ('Unit conversion for chemistry') and enumerates representative conversion identifiers, so an agent knows exactly what class of operation this is. It is clear without opening the schema, though it never explicitly distinguishes itself from the sibling covabasic_convert_format, whose name invites confusion.
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 sentence 'Pass mw for mass-mole conversions' is a genuine conditional instruction, telling the agent when one argument becomes necessary. However, there is no when-to-use-vs-alternatives guidance and no mention of the sibling convert_format, so usage is only partially implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert between chemical structure formats. Auto-detects input format.
Supported input: SMILES, InChI, MOL block, SDF block
to_format options: "smiles", "inchi", "inchikey", "molblock", "sdf"
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| to_format | No | smiles | |
| input_string | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It adds genuine value by disclosing the auto-detection trait and the supported input formats, but says nothing about the api_key parameter, authentication requirements, error behavior on unparseable input, or 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?
The text is short and front-loaded: purpose first, then capability, then supported values. Every line is relevant, though the format list could be structured more cleanly as a parameter-to-value mapping.
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 needn't be explained. For a simple 3-parameter transform tool this covers the essentials, with only the undocumented api_key and the convert-vs-convert_format distinction left open.
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% and no enums are declared, so the description is doing meaningful work by listing valid to_format values and supported input formats. However, the third parameter (api_key) is completely undocumented and the input format syntax is only named, not exemplified.
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 ('Convert between chemical structure formats') and enumerates concrete input and output formats, so the agent knows exactly what the tool does. It does not, however, distinguish itself from the sibling covabasic_convert, leaving an obvious ambiguity unresolved.
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?
'Auto-detects input format' is useful context but is not usage guidance. There is no statement of when to use this tool versus the clearly overlapping sibling covabasic_convert, and no prerequisites or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate 2D molecule depiction(s). Returns SVG string or base64-encoded PNG.
Single molecule: provide smiles. Add highlight_smarts to highlight a substructure.
Grid of molecules: provide smiles_list (list of SMILES) + optional legends.
img_format: "svg" (default, scalable) or "png" (base64-encoded).
| Name | Required | Description | Default |
|---|---|---|---|
| width | No | ||
| height | No | ||
| smiles | No | ||
| api_key | No | ||
| legends | No | ||
| img_format | No | svg | |
| smiles_list | No | ||
| mols_per_row | No | ||
| highlight_smarts | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses the return format (SVG string vs base64-encoded PNG) and the two operating modes, which is useful. But it omits behavioral traits such as the api_key requirement, error/rate-limit behavior, or what happens with empty/invalid SMILES.
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 purpose is front-loaded, then mode-specific guidance, then the format option. Sentences are short and each carries information with little waste; only the redundant restatement of the return type in the first and last lines is slightly duplicative.
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-value explanation is not strictly required, yet the tool has 9 params at 0% schema coverage with no annotations. The description covers the mode-selecting parameters well but leaves width, height, api_key (suggesting an undisclosed auth requirement), and mols_per_row unexplained, which is a meaningful gap for a 9-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 0%, so the description must carry parameter meaning. It explains smiles, smiles_list, legends, highlight_smarts, and img_format, but leaves width, height, api_key, and mols_per_row undocumented. It compensates for roughly half the parameters, so it adds real but incomplete value.
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 opens with a specific verb+resource: 'Generate 2D molecule depiction(s)', which is distinct from sibling tools like covabasic_image_to_smiles (the reverse operation). It clearly defines the tool's core function. It stops short of naming a sibling alternative explicitly, keeping it at a strong 4 rather than 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?
It distinguishes two modes and maps them to inputs ('Single molecule: provide smiles', 'Grid of molecules: provide smiles_list'), which is implied when-to-use guidance for the parameters. However, it gives no exclusions or comparison against sibling depiction-adjacent tools, so guidance is present but not explicit about alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain what a structure IS, in prose — parent framework, ring system, functional groups, substituents.
Turns a SMILES into a readable chemical description rather than a table of
numbers. Useful for reports, for captioning a drawn structure, and for
checking that a structure is what you meant to draw.
style="human" — compact, chemistry-facing narrative: the parent skeleton,
heteroatom positions, unsaturation, the principal
characteristic group, then substituents with their locants.
style="technical" — the full naming walkthrough, including how the name was
assembled token by token.
Returns: `{name, paragraphs: [...], text, rules_hit, smiles, style, engine}`,
or `{error, smiles}`. `text` is the paragraphs joined for direct display.| Name | Required | Description | Default |
|---|---|---|---|
| style | No | human | |
| smiles | Yes | ||
| verify | No | ||
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the response shape and the error case ("{error, smiles}") and the semantics of each style, which is genuine behavioral content. However it never explains what `verify` actually does, whether an api_key is required, or any determinism/rate limits, leaving meaningful behavioral gaps for a no-annotation tool.
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 in the first sentence, then use cases, then a clean style breakdown and return shape. It is slightly long with the repeated return-field enumeration, but every section is scannable and earns most of its space.
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 return-value enumeration is optional padding, and the core call information (required smiles, style selection, use cases) is complete. The only real shortfall is the undocumented `verify` flag, which an agent might set or avoid without understanding its effect.
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%, so the description must compensate. It does add real meaning for `style` by spelling out the human vs technical narratives (the schema offers no enum), and `smiles` is self-evident, but `verify` and `api_key` are entirely unexplained, leaving two of four parameters opaque.
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+resource ("Explain what a structure IS, in prose") and names the outputs it produces (parent framework, ring system, functional groups, substituents). It implicitly contrasts with table-based siblings via "rather than a table of numbers," but never names a specific alternative such as covabasic_iupac_name or covabasic_analyze, so an agent gains clarity without explicit sibling differentiation.
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 concrete scenarios (reports, captioning a drawn structure, sanity-checking a drawn structure) and explicitly tells the agent how to choose between the two style values. It stops short of naming when NOT to use it or pointing to a sibling for the naming-only or numeric case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evaluate drug-likeness: Lipinski Ro5, Veber, Ghose, Egan, Muegge, Ro3 (fragments), QED score, synthetic accessibility (SA) score.
| Name | Required | Description | Default |
|---|---|---|---|
| smiles | Yes | ||
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose the behavioral scope by listing every check performed, which is useful, but says nothing about error handling for invalid SMILES, the role/requirement of the api_key, or whether the evaluation is a pure static computation versus a remote call. Output schema existence reduces the need to describe return values.
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 dense sentence front-loads the verb and then enumerates the returned analyses. Nothing is redundant and there is no filler, though the parenthetical abbreviations are terse enough to require domain familiarity.
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?
Because an output schema exists, return values need not be explained, and the description does fully enumerate what is evaluated. However, for a tool with two parameters at 0% schema coverage and no annotations, it leaves the input format and api_key semantics unexplained and does not distinguish itself from the covachem_druglikeness sibling.
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% and both parameters (smiles, api_key) are undocumented in the schema. The description does not compensate: it never states that input is a SMILES string, nor what api_key is for or whether it is needed. Only an inference from the domain hints at the input format.
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+resource ('Evaluate drug-likeness') and enumerates exactly which rulesets and scores are computed (Lipinski Ro5, Veber, Ghose, Egan, Muegge, Ro3, QED, SA), so the agent knows precisely what analysis is performed. It does not differentiate itself from the near-identical sibling covachem_druglikeness, leaving ambiguity about which to call.
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 no alternative tool is named. The presence of covachem_druglikeness and covabasic_filter_check as plausible substitutes makes the absence of routing guidance a real gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Solve a physicochemical equation. Pass equation name + parameter dict.
Equations and their params:
"arrhenius" — {k1, t1_k, k2?, t2_k?, ea_kj?} compute Ea or predict k at new T
"vant_hoff" — {k1, t1_k, k2, t2_k} compute reaction enthalpy delta-H
"henderson_hasselbalch" — {pka, ph, acid (bool)} compute ionization fractions
"ideal_gas" — {n?, p_atm?, v_l?, t_k?} PV=nRT, solve for missing variable
"beer_lambert" — {absorbance?, epsilon?, concentration?, path_length?} A=ecl
"dilution" — {c1, v1, c2?, v2?} C1V1=C2V2, solve for missing variable
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes | ||
| api_key | No | ||
| equation | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses what each equation computes but says nothing about behavior for an unknown equation name, error handling, the role of api_key, or side-effect/reversibility expectations. For a solver this is a moderate gap, not a severe one, since the operation is a pure computation.
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-loads the imperative sentence, then presents a clean, scannable table of equations. The enumeration is necessary given the schema lacks an enum, so the length is justified rather than 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?
An output schema exists, so return values need not be explained. The description adequately covers the equation dispatch and its parameter shapes, leaving only api_key and error-path behavior unaddressed, which are minor for a compute-only 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 coverage is 0% and both the equation string and the free-form params object are undocumented in the schema. The description compensates strongly by listing every valid equation value and the exact parameter keys each expects, including optionality via "?". It only omits api_key.
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+resource ("Solve a physicochemical equation") and then enumerates the six supported equations, each with the parameters it consumes and what it computes. This is far beyond its siblings (stoichiometry, convert) and lets an agent pick the tool 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?
Each equation line implies its use case (e.g., "compute Ea or predict k at new T", "solve for missing variable"), which is useful context. However, there is no explicit when-to-use vs sibling guidance and no statement of prerequisites or exclusions, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Screen for problematic substructures: PAINS (pan-assay interference), BRENK (unwanted groups), NIH MLPCN filters, ZINC druglike filters. Returns alert count + details per filter set.
| Name | Required | Description | Default |
|---|---|---|---|
| smiles | Yes | ||
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does disclose the filter taxonomy being applied and that results come back as a per-filter-set alert count plus details, but says nothing about authentication needs (the api_key parameter), input format expectations, or failure behavior for unparseable input.
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 core purpose front-loaded and the filter list supporting it. The second sentence ('Returns alert count + details per filter set') largely restates what the output schema already specifies, so it is slightly redundant rather than wasteful.
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, and the tool itself is a simple one-input screener. However, with no annotations and zero parameter documentation, the definition leaves the agent without guidance on input format or the api_key parameter — a minor but real gap.
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% for both parameters. The 'smiles' parameter is only weakly inferable from the chemistry context, and 'api_key' is completely unexplained in both the schema and the description — an agent gets no signal on whether it is required, how to obtain it, or when it matters.
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 ('Screen for problematic substructures') and enumerates the four concrete filter sets it applies, with parenthetical expansions of the PAINS/BRENK acronyms. This lets an agent separate it from neighbors like covabasic_druglikeness, covabasic_validate, or covabasic_functional_groups without opening any 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?
The screening context implies when the tool is useful (flagging assay-interference or unwanted-group liabilities), but there is no explicit when-to-use versus covabasic_druglikeness / covabasic_reynolds / covabasic_validate, and no statement of prerequisites or exclusions. Usage is inferable but not guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate molecular fingerprints: Morgan (ECFP4), MACCS keys, RDKit topological. Returns bit vectors as hex strings.
| Name | Required | Description | Default |
|---|---|---|---|
| smiles | Yes | ||
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not say whether all three fingerprint types are returned or whether the caller selects one - and the schema has no selection parameter, leaving the core behavior ambiguous. It also omits cost, auth, and rate-limit context, though the 'hex strings' note does hint at output shape.
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 operation front-loaded and the output form trailing; nothing is wasted. It could have used the second sentence to resolve the fingerprint-selection ambiguity instead of stating return format already covered by the output schema.
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 compute tool with zero annotation coverage, 0% parameter documentation, and no selection parameter for the three listed fingerprint types, the description leaves the key calling question unanswered: which fingerprint do I get? The presence of an output schema excuses it from explaining return values, but not from this gap.
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%, so both parameters are undocumented in structured data. The description never clarifies that 'smiles' expects a SMILES string or what 'api_key' is for, leaving the description unable to compensate for the coverage 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?
States a specific verb ('Generate') and resource ('molecular fingerprints') and enumerates the three fingerprint flavors (Morgan/ECFP4, MACCS, RDKit topological). This distinguishes it from siblings like covabasic_similarity or covams_predict_fingerprint, though it does not name those siblings 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?
No when-to-use or when-not-to-use guidance, no mention of prerequisites, and no routing to alternatives such as covabasic_similarity (which consumes fingerprints) or covams_predict_fingerprint. The agent must infer usage purely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Count ~65 functional groups: alcohols, phenols, amines, amides, esters, ethers, ketones, aldehydes, carboxylic acids, sulfonamides, nitro, halogens, heterocycles, etc.
| Name | Required | Description | Default |
|---|---|---|---|
| smiles | Yes | ||
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses the counting scope (which categories are detected) but says nothing about input requirements, error behavior on malformed structures, or any auth/rate-limit constraints on the api_key path, leaving significant gaps for a chemistry-analysis tool.
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 leads with the action and count, then supports it with examples. The trailing 'etc.' is slightly loose but the overall size is well matched to the tool's simplicity.
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, and the description adequately frames what is counted. However, it omits the input format expectation and any usage context, which is thin even for a simple one-required-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 0% and neither parameter is described. The chemistry context implies a molecule input, but the required 'smiles' parameter and the 'api_key' parameter are undocumented in both schema and description, so the description fails to compensate for the coverage 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?
States a clear verb ('Count') and a specific resource ('functional groups'), and the enumerated categories (~65: alcohols, phenols, amines, etc.) make the scope concrete. It is distinguishable from generic siblings like covabasic_analyze or covabasic_describe_structure, though it never explicitly contrasts itself with them.
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 prerequisites, and no named alternatives among the many covabasic siblings. The agent must infer that this is the tool for counting functional groups rather than, say, covabasic_substructure, from the name and category list alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate green chemistry metrics: E-factor (kg waste / kg product) and/or PMI (Process Mass Intensity = total input / product).
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| mass_waste_kg | No | ||
| mass_product_kg | Yes | ||
| mass_all_inputs_kg | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses that either metric can be computed ('and/or') and defines the formulas, which signals the optional-parameter model, but it omits authentication expectations (the api_key param), error behavior, and whether both metrics return together.
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 the metric names and formulas; no filler. Every clause earns its place by defining the two computable quantities.
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, and the description covers which inputs feed which metric. It is nearly complete for a 4-param calculation tool, with the only real gap being api_key and units handling.
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%, so the description must compensate. It maps mass_waste_kg to E-factor and mass_all_inputs_kg to PMI over mass_product_kg, adding real meaning beyond the bare schema. It leaves api_key completely undocumented, keeping it from a 5.
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 ('green chemistry metrics') and defines both outputs (E-factor, PMI) with their formulas. The tool is unique among its siblings, so no sibling differentiation is strictly needed, but it stops short of a 5 by not clarifying the relationship to metrics-adjacent siblings like covabasic_stoichiometry.
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 'and/or' phrasing implies either metric is obtainable, but there is no guidance on when to use this tool, what prerequisites exist, or which sibling to pick instead. Usage is only weakly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert a chemical structure image to SMILES via Mathpix OCR. Input: base64-encoded PNG/JPG of a drawn molecule. Returns SMILES, confidence, and all detected structures. Requires Mathpix API credentials on server.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| image_base64 | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose two useful traits: an external dependency ('Requires Mathpix API credentials on server') and the return payload (SMILES, confidence, detected structures). It omits error behavior, image size/format limits, and rate/cost considerations of the OCR call, so gaps remain for an unannotated tool.
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 short sentences that front-load the purpose, then input, then output/dependency. Very little waste, though the 'Returns ...' sentence partially duplicates information the output schema already provides.
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?
Given an output schema exists, the description need not explain return values, and it still covers the essential input and auth prerequisites. Only failure modes and input constraints are missing, which is a modest gap for a single required-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 0%, so the description must compensate; it explains image_base64 well (base64 PNG/JPG of a drawn molecule) but says nothing about the optional api_key parameter, leaving the relationship between that parameter and the 'credentials on server' statement ambiguous.
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 precise verb and resource ('Convert a chemical structure image to SMILES') and names the mechanism ('via Mathpix OCR'), which clearly separates it from the many text/structure-based siblings that take SMILES or spectra rather than an image.
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?
It implies when to use it by specifying the input format ('base64-encoded PNG/JPG of a drawn molecule'), which is enough for an agent to route image inputs here, but it names no alternatives and gives no explicit exclusion criteria versus other conversion tools like covabasic_convert_format or covabasic_iupac_name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the IUPAC name of a structure — generating one when it is unknown to any database.
Two sources, tried in order, and the response always says which one answered:
- `source="pubchem"` — the curated, human-checked IUPAC name. Authoritative,
but only exists for compounds PubChem indexes.
- `source="openclatura"` — a name constructed from the molecular graph by a
deterministic IUPAC Blue Book (2013) rule engine. Works on any valid
structure, including novel compounds, intermediates and analogues.
Parameters:
prefer_pubchem — check PubChem first (default true). Set false to force
generation, or to keep the call purely offline and ~100x faster: the
rule engine takes ~5 ms, the PubChem round-trip 0.6-1 s.
explain — also return `rules_hit`, the Blue Book rules that fired
(e.g. P-44, P-61). Costs ~5x the naming time; off by default.
verify — round-trip the generated name through OPSIN and report whether it
parses back to the same structure. Needs a Java runtime; without one the
result reports `verification="skipped_no_java"` instead of failing.
Returns: `{name, smiles, source, generated, engine}` (+ `rules_hit`,
`verification` when requested), or `{error, smiles}`.
A generated name is a systematic construction, not a database record —
treat `generated=true` accordingly.| Name | Required | Description | Default |
|---|---|---|---|
| smiles | Yes | ||
| verify | No | ||
| api_key | No | ||
| explain | No | ||
| prefer_pubchem | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does so well: it discloses source order, speed difference (~5 ms vs 0.6–1 s), explain cost (~5x), verify's Java dependency and graceful fallback, and the meaning of generated=true. It also states the error return shape.
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 definition is front-loaded and organized with source bullets, parameter bullets, and a short returns note. It is appropriately sized for a tool with five parameters and no schema descriptions, though including return fields is somewhat redundant given the output schema.
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 tool with no annotations, zero schema descriptions, and complex behavior, the description is largely complete: it covers source precedence, performance, dependencies, and generated-name caveats. It stops short of full completeness because api_key and the exact smiles input expectation are unexplained.
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%, so the description must define all five parameters. It explains prefer_pubchem, explain, and verify in useful detail, but never explains the required smiles input format or the api_key parameter, leaving real gaps.
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+resource: 'Get the IUPAC name of a structure,' and immediately extends it to generation when no database entry exists. This is clear enough to distinguish it from sibling tools like covabasic_pubchem or covabasic_analyze by output, even though it does not explicitly name an alternative 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?
It explains the two source modes and gives concrete conditions for setting prefer_pubchem=false: force generation, keep the call offline, or gain ~100x speed. It does not explicitly route the agent away from sibling tools or state when not to use this tool, so it falls short of full alternative-routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn systematic chemical names into structures (OPSIN) — the inverse of covabasic_iupac_name.
Parses up to 50 English IUPAC / systematic names per call into canonical
SMILES and InChIKey with OPSIN, a deterministic grammar-based parser. It
does not look anything up: trade names, abbreviations, typos and
non-English names come back with `smiles=null` rather than a guess.
Translate a German or Chinese name to English first.
Returns: `{results: [{name, smiles, inchikey}], engine}`, or
`{error, reason}` (reason "no_java" when the server has no Java runtime).| Name | Required | Description | Default |
|---|---|---|---|
| names | Yes | ||
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does most of it well: it discloses the deterministic grammar-based parsing model, the no-lookup failure behavior (null instead of a guess), the 50-name-per-call cap, the response shape, and the `{error, reason}` case including the specific `no_java` server-dependency failure. The one uncovered behavioral trait is the `api_key` parameter — nothing says whether it is required, optional, or what it authenticates.
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 one-line purpose and inverse relationship, then constraints, then return shape — a sensible order. Every sentence carries information, though the 'Returns:' block partly restates the output schema that already exists.
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 two-parameter batch conversion tool with no annotations, the description supplies the parsing model, input constraints, failure semantics, and error reasons an agent needs to call it correctly. The remaining gap is the authentication parameter, which is the only thing an agent could get wrong here.
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%, so the description must compensate. It adds real meaning for `names` — English-only, systematic/IUPAC, an array processed up to 50 per call — but says nothing at all about `api_key`, leaving one of two parameters completely undocumented. Partial compensation warrants a mid score.
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 concrete verb and resource — converting systematic names into structures via OPSIN — and positions itself explicitly as 'the inverse of covabasic_iupac_name', which lets an agent separate it from that sibling without opening either schema. The named engine and output artifacts (SMILES, InChIKey) further sharpen the purpose.
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 clear when-to-use (English IUPAC/systematic names) and concrete when-not cases: trade names, abbreviations, typos, and non-English names return `smiles=null` rather than a guess, and it advises translating German/Chinese names first. What is missing is a pointer to the actual alternative (e.g. a lookup tool such as covabasic_pubchem) for the inputs it declines to handle — 'it does not look anything up' implies one exists but never names it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query PubChem database. NETWORK REQUIRED.
action options:
"lookup" — find compound by name, CAS, SMILES, or InChIKey. Returns CID, IUPAC name, InChI, MW, XLogP, TPSA.
"smiles" — resolve a compound name or CAS to canonical SMILES.
"properties" — fetch computed properties for a PubChem CID (pass CID as query).
"similarity" — find similar compounds by Tanimoto (pass SMILES as query, set threshold 0-1).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| action | No | lookup | |
| api_key | No | ||
| threshold | No | ||
| query_type | No | name | |
| max_results | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It usefully discloses "NETWORK REQUIRED", which flags latency/connectivity behavior, and describes per-action return contents. But it omits auth requirements (an api_key parameter exists), rate limits, and error behavior for a networked external-API tool.
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-loads the purpose and network caveat, then presents the actions as a scannable aligned list — efficient and easy to parse. Minor slack in that the output contents are listed redundantly for actions whose returns are covered by the output schema.
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-value explanation is legitimately offloaded and the action-to-return mapping is a bonus. Still, for a 6-parameter networked tool with zero annotation coverage, the missing api_key/query_type/max_results semantics leave the definition short of fully callable.
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%, so the description must compensate. It adds meaning for query ("pass CID as query", "pass SMILES as query") and threshold (0-1), but api_key, query_type, and max_results are entirely undocumented in both schema and description — roughly half the parameters carry no semantics.
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 ("Query PubChem database") and enumerates four concrete actions with their distinct outputs. However, it does not distinguish itself from the sibling covabasic_similarity, which overlaps with its own "similarity" action, so the boundary from that alternative is left unaddressed.
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 action list effectively routes the agent: lookup for name/CAS/SMILES/InChIKey, smiles for name→SMILES resolution, properties for CID-based property fetch, similarity for Tanimoto search. It gives clear when-to-use context per action, but never states when to prefer a sibling tool or any exclusions/prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reynolds number calculation with flow regime classification (laminar / transitional / turbulent). For pipe flow and mixing design.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| diameter_m | Yes | ||
| velocity_m_s | Yes | ||
| density_kg_m3 | Yes | ||
| viscosity_pa_s | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses that the result includes regime classification into three named bands, but it is silent on the api_key credential requirement visible in the schema, on units handling, and on any cost/rate behavior — meaningful gaps for a calculator tool.
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 with zero filler, and the core computation is front-loaded ahead of the application context. Slightly terse for a 5-parameter tool, but nothing is wasted.
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-format detail is not needed, and the domain framing (pipe flow, mixing design) is present. However, with zero annotation coverage and 0% parameter descriptions, the definition leaves the api_key requirement and input-unit assumptions unexplained — barely adequate for a 5-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 0% across 5 parameters, so the description is expected to compensate and does not. It explains none of density, velocity, diameter, or viscosity, nor what api_key is for; the only help comes from the unit-suffixed parameter titles themselves.
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 ('Reynolds number calculation') plus the output scope ('flow regime classification (laminar / transitional / turbulent)'). It clearly distinguishes itself from the surrounding chemistry/bio siblings, though it does not name a sibling for fluid-dynamics overlap (e.g. viscosity).
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 pipe flow and mixing design' gives implied context for when the tool applies, but there is no when-not guidance, no prerequisite statement, and no alternative tool named. Usage is inferable but not directed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Murcko scaffold decomposition: core ring framework, side chains, generic scaffold, ring systems, linkers. Useful for series analysis and SAR.
| Name | Required | Description | Default |
|---|---|---|---|
| smiles | Yes | ||
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, yet it discloses nothing about determinism, permissions, input failure behavior, or output shape. It enumerates decomposition components but not how the tool behaves or when it might fail.
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, front-loaded with the technique and its decomposition outputs, with no filler. Efficient and well-structured, though the trailing benefit clause is fairly generic.
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, and the decomposition list is helpful context. However, with 0% parameter coverage and no annotations, the description is a feature list that leaves input meaning and behavioral expectations 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 0% and the description says nothing about either parameter. The required 'smiles' input is only inferable from domain convention, and 'api_key' is entirely undocumented, so the description fails to compensate for the coverage 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?
The description states a specific technique (Murcko scaffold decomposition) and enumerates the concrete outputs it produces (core ring framework, side chains, generic scaffold, ring systems, linkers). An agent can clearly tell what the tool does, though it does not explicitly contrast itself with siblings like covabasic_brics or covabasic_substructure.
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?
It offers a usage context ('Useful for series analysis and SAR') but gives no when-not guidance or named alternatives among the many similar covabasic_* decomposition tools. Usage is implied rather than specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare two molecules by structural similarity.
method="all" — Tanimoto, Dice, Cosine, MCS (Maximum Common Substructure) method="tversky" — asymmetric Tversky index (alpha/beta control substructure vs superstructure bias)
| Name | Required | Description | Default |
|---|---|---|---|
| beta | No | ||
| alpha | No | ||
| method | No | all | |
| api_key | No | ||
| smiles_a | Yes | ||
| smiles_b | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses method-specific behavior (Tversky is asymmetric and alpha/beta tuned), which is useful, but says nothing about auth requirements (an api_key param exists), rate limits, cost, or failure modes.
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 purpose followed by a compact method breakdown. No filler, though the method block is telegraphic and could note defaults or when each applies.
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. Still, for a 6-param tool with no annotations, the description omits api_key handling, SMILES format expectations, and defaults for alpha/beta/method.
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 6 parameters, so the description must compensate. It adds real meaning for method, alpha, and beta (asymmetric bias control), but leaves smiles_a, smiles_b, and api_key entirely unaddressed.
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: 'Compare two molecules by structural similarity.' This is clearly distinguishable from siblings like covabasic_substructure or covabasic_fingerprint, though it never explicitly names an alternative to route against.
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?
It explains what each method value does, which implicitly guides method selection (Tversky for asymmetric substructure/superstructure bias). However, it gives no explicit guidance on when to use this tool versus related siblings, nor any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Standardize a SMILES string.
mode="basic" — salt stripping, neutralization, canonical tautomer mode="enhanced" — + charge-parent extraction, metal disconnection, stereo normalization
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | basic | |
| smiles | Yes | ||
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does disclose the exact operations performed per mode, which is real value, but it says nothing about the api_key auth requirement, whether the original input is preserved, error behavior, or cost/rate 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 lines of tightly front-loaded text with no filler; the mode breakdown is laid out so an agent can scan it immediately.
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 described, and the transformation semantics are well covered. The remaining gaps are the undocumented api_key credential parameter and the absence of any routing hint relative to sibling standardization tools.
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%, and the schema does not even declare the allowed values for mode, so the description is the only source defining basic vs enhanced — that is genuinely additive. It leaves api_key and smiles entirely unexplained, though smiles is self-evident.
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 (standardize) and resource (SMILES string), and the mode breakdown enumerates the concrete transformations applied, which meaningfully distinguishes it from generic siblings like covabasic_convert or covabasic_depict. It never names the closer sibling covabasic_canonicalize or covabasic_tautomers, so the differentiation is partial rather than complete.
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?
Listing what each mode does implies when to pick basic (light cleanup) versus enhanced (aggressive normalization), which is useful mode-selection guidance. However there is no explicit statement of when to use this tool instead of the many sibling normalization tools, and no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate reactant masses needed for a target product mass. Input: MW of product, list of reactant MWs, stoichiometric equivalents, and target mass in grams.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| mw_product | Yes | ||
| equivalents | Yes | ||
| mw_reactants | Yes | ||
| target_mass_g | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It only states the calculation and lists inputs; it does not disclose whether the operation is pure, deterministic, requires authentication, or has any side effects, rate limits, or error behavior.
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 with zero filler. The purpose is front-loaded and the input summary is compact and directly useful, making the definition easy to scan.
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 described. However, with no annotations, 0% schema coverage, and an unexplained api_key parameter, the definition is only minimally complete for correct invocation; array alignment and authentication expectations remain ambiguous.
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%, so the description must compensate fully. It names four required inputs in natural language but omits the api_key parameter and gives no detail on array structure, ordering correspondence between mw_reactants and equivalents, units for MW values, or equivalent definitions.
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: 'Calculate reactant masses needed for a target product mass.' This clearly identifies a stoichiometry calculation, though it does not distinguish itself from other covabasic tools such as covabasic_equation.
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?
Provides no when-to-use guidance, prerequisites, or alternatives. The description implies a calculation context but does not tell the agent when this tool is preferable to closely named siblings or what conditions are required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for a SMARTS substructure pattern in a molecule. Returns match count, atom indices of each hit, and highlighted atoms.
| Name | Required | Description | Default |
|---|---|---|---|
| smiles | Yes | ||
| api_key | No | ||
| pattern_smarts | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says the tool returns match count, atom indices, and highlighted atoms; it does not state that this is a read-only operation, whether it requires authentication (though api_key exists), or any side effects or rate 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 sentences, front-loaded with the core action, and no wasted words. The return value sentence is brief and directly follows the purpose.
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 the return-value description is somewhat redundant. However, the description lacks any parameter documentation beyond loose implied mapping, provides no usage guidelines, and does not address the behavioral aspects expected since annotations are absent. For a 3-parameter tool at 0% schema coverage, this is incomplete.
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%, so the description must explain the three parameters. It loosely maps 'molecule' to the smiles parameter and 'SMARTS substructure pattern' to pattern_smarts, but gives no format details and completely omits the api_key parameter. It does not sufficiently compensate for the missing schema documentation.
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?
Clearly states a specific verb and resource: 'Search for a SMARTS substructure pattern in a molecule.' An agent can understand the core action without opening the schema. However, it does not differentiate this tool from siblings like covabasic_functional_groups or covabasic_similarity, so it falls 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?
The description provides no when-to-use guidance, no alternatives, and no prerequisites. It merely states what the tool does, leaving the agent to infer that this is the substructure-search option among many covabasic tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enumerate tautomers of a molecule (keto-enol, amide-imidol, etc.). Returns canonical tautomer + all alternatives.
| Name | Required | Description | Default |
|---|---|---|---|
| smiles | Yes | ||
| api_key | No | ||
| max_tautomers | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose the return composition (canonical tautomer plus all alternatives). However it omits behavioral traits such as whether the returned set is ranked, auth/key requirements, or how max_tautomers affects results.
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, front-loaded with the core action followed by the return summary. No filler or redundancy.
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 no further explanation, and the tool is conceptually simple. But with zero annotation and zero schema-description coverage, the undocumented parameters leave the definition only partially 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 0%, so the description should compensate, but it mentions none of the three parameters. The key input (smiles) and the max_tautomers control are undocumented in both schema and description, leaving their meaning and effect to inference.
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 (enumerate) and resource (tautomers of a molecule), reinforced with concrete examples (keto-enol, amide-imidol). No sibling tool performs tautomerization, so the agent can route to it unambiguously.
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 says what the tool does but never when to use it, when not to, or what alternative to prefer. It offers no prerequisites (e.g., input must be a valid SMILES) or context for choosing it over covabasic_canonicalize/standardize.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate SMILES with 15+ checks: parsability, valence, stereo, aromaticity, charge, size limits, isotopes, radicals.
| Name | Required | Description | Default |
|---|---|---|---|
| smiles | Yes | ||
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses what is checked (parsability, valence, stereo, etc.), but says nothing about what happens on failure, whether invalid input errors or returns findings, or whether the operation is read-only. Partial disclosure only.
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 puts the verb and resource first, then the enumerated checks. Zero filler and no redundancy.
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-value detail is not required. However, for a validation tool with no annotations and 0% parameter coverage, the description should say more about usage context and parameter meaning to be 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 0%, so the description should compensate. It implies the input is a SMILES string but never states the parameter explicitly, that it is required, or what api_key is for. Half the parameters are entirely undocumented in both schema and description.
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 (Validate) and resource (SMILES) and enumerates the check categories performed. It is clear what the tool does, but it does not differentiate itself from close siblings such as covabasic_filter_check or covabasic_standardize, which also assess molecule quality.
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 guidance is given on when to use this tool versus alternatives, nor on preconditions. With siblings like covabasic_filter_check and covabasic_standardize overlapping in intent, the absence of routing guidance is a real gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Design an antibody-drug conjugate (ADC): estimate DAR (drug-to-antibody ratio), total molecular weight, conjugatable cysteine/lysine sites, aggregation risk, and payload hydrophobicity impact.
Parameters:
antibody_sequence: Antibody amino acid sequence.
payload_smiles: Drug payload SMILES (e.g. MMAE, DM1).
target_dar: Target drug-to-antibody ratio (default 4.0).
Returns: {total_mw, dar, conjugation_sites, aggregation_risk, payload_properties}| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| target_dar | No | ||
| payload_smiles | Yes | ||
| antibody_sequence | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses the computed outputs (DAR, aggregation risk, payload properties), which lets an agent predict behavior, but it omits the fact that an api_key is required, whether the computation is deterministic, and any limitations or cost considerations for a multi-property estimation.
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 purpose, then a clean parameter list and return summary; every line earns its place. Slightly redundant since the 'Returns' block restates outputs already implied by the opening sentence, but it remains compact and scannable.
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?
Given an output schema exists, return-value explanation is not strictly required, yet the description helpfully summarizes them. Purpose, inputs, and outputs are all covered; the only gaps are the missing usage guidance and the undocumented api_key, which keep it short of 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 0%, so the description must compensate, and it documents 3 of 4 parameters with real meaning: antibody amino acid sequence, payload SMILES including concrete examples (MMAE, DM1), and target DAR. Only the api_key parameter is left unexplained, and sequence/SMILES format constraints are not specified.
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 ('Design an antibody-drug conjugate') and enumerates exactly what is estimated: DAR, total molecular weight, conjugatable cysteine/lysine sites, aggregation risk, and payload hydrophobicity. It is clearly distinguishable from generic siblings like covabio_antibody or covabio_developability, though it never explicitly names a sibling to route against.
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 versus alternatives (e.g. covabio_antibody for plain sequence analysis, or covabio_developability for general developability). The ADC-specific framing implies its niche, but no exclusions, prerequisites, or alternative-selection guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pairwise sequence alignment using BioPython. Supports BLOSUM62, BLOSUM45, BLOSUM80 substitution matrices. Returns alignment score, identity percentage, aligned sequences, and gap statistics.
Parameters:
seq1: First amino acid sequence.
seq2: Second amino acid sequence.
matrix: Scoring matrix — "BLOSUM62" (default), "BLOSUM45", "BLOSUM80".
Returns: {score, identity_pct, aligned_seq1, aligned_seq2, n_gaps}| Name | Required | Description | Default |
|---|---|---|---|
| seq1 | Yes | ||
| seq2 | Yes | ||
| matrix | No | BLOSUM62 | |
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose useful behavior: the matrix options, the BLOSUM62 default, and the shape of the return payload. However, it omits the auth requirement implied by the api_key parameter, expected input format (raw residues vs FASTA), and error behavior.
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 and well organized: purpose first, then a compact parameter list, then the return shape. The returns line is somewhat redundant given an output schema exists, but the whole description is short and every remaining sentence is doing work.
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?
Because an output schema exists, the return fields need not be spelled out, yet the description restates them anyway. More importantly it never explains the api_key parameter, authentication expectations, or acceptable sequence formats, and gives no sibling differentiation for a crowded covabio namespace.
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%, so the description must compensate. It does document seq1, seq2 and the matrix parameter, and notably supplies the valid matrix values ('BLOSUM62', 'BLOSUM45', 'BLOSUM80') that the schema's free-string type lacks. The fourth parameter, api_key, is documented nowhere, leaving a real 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?
States a specific verb and resource ('Pairwise sequence alignment using BioPython') and names the supported substitution matrices, so the operation is unambiguous. It does not, however, differentiate itself from the many sibling covabio_* tools such as covabio_sequence_utils or covabio_parse_fasta, leaving overlap unresolved.
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 explicit when-to-use, when-not-to-use, or alternative-tool guidance. The reader can infer that it aligns two sequences, but nothing tells them why to pick this over other covabio sequence tools or what prerequisites (e.g. API key/auth) must be satisfied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Identify CDR regions (complementarity-determining regions) and framework regions in an antibody sequence. Supports Kabat, Chothia, and IMGT numbering schemes. Returns CDR boundaries, chain type (heavy/light), framework sequences, and CDR developability flags.
Parameters:
sequence: Antibody heavy or light chain amino acid sequence.
scheme: Numbering scheme — "kabat" (default), "chothia", or "imgt".
Returns: {chain_type, CDR1/2/3 sequences and positions, framework_regions, cdr_developability}| Name | Required | Description | Default |
|---|---|---|---|
| scheme | No | kabat | |
| api_key | No | ||
| sequence | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the disclosure burden. It usefully states the return fields (chain type, CDR boundaries, frameworks, developability flags) and numbering schemes, but does not address permissions, API-key requirements, error behavior, or explicitly confirm that the operation is read-only.
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 parameters and returns. The parameter/return recap is somewhat redundant with the schema and output schema, but it is controlled and useful given 0% schema description coverage.
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 details are optional; the description still summarizes them. It covers the main input semantics and behavior sufficiently for an agent to invoke the tool, though the unexplained api_key parameter and lack of usage alternatives leave a small gap.
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%, so the description must compensate. It defines sequence as an antibody heavy/light amino acid sequence and enumerates scheme values (kabat default, chothia, imgt), which is valuable; however, it omits the api_key parameter entirely.
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 and resource: identifies CDR and framework regions in an antibody sequence, and names supported numbering schemes. This distinguishes it from siblings such as covabio_developability, covabio_sequence_utils, and covabio_protein_profile, which do not perform antibody numbering.
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 purpose (use on an antibody heavy/light chain sequence when CDR/framework annotation is needed) and by the scheme parameter options. However, it gives no explicit when-to-use guidance, no exclusions, and does not name a sibling alternative for related tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Profile up to 100 protein sequences in one call — the same 30+ biophysical properties as covabio_protein_profile, per sequence. Charged once per call, not per sequence. Use for candidate panels, variant series, or a whole FASTA out of covabio_parse_fasta.
A sequence that fails does not abort the batch: its slot carries {error: true, message, sequence} and the rest still return. Over 100 sequences the call is rejected rather than truncated, so a silently short result is not possible — split the batch.
Parameters:
sequences: List of amino acid sequences (max 100).
Returns: {results: [profile | {error, message, sequence}]} in input order| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| sequences | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the entire burden and does so well: it discloses the pricing model (charged once per call, not per sequence), partial-failure behavior (failed slots carry {error: true, message, sequence} without aborting the batch), the hard cap rejecting rather than truncating, and guaranteed no silent short results. These are exactly the behavioral traits an agent needs and cannot get from 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?
Front-loaded with the core promise, then failure/limit behavior, then a compact parameters block and return shape. Every sentence earns its place and the structure is easy to scan.
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 batch tool with an output schema (which carries return shape) and no annotations, the description supplies the missing behavioral context: cost model, batch size limit, error containment, and ordering. Nothing an agent needs to call this correctly is absent beyond the peripheral api_key.
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%, so the description must compensate. It documents the critical 'sequences' parameter (amino acid sequences, max 100) which adds real meaning, but the second parameter api_key is never mentioned. Covers the important parameter but leaves one undocumented.
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 (profile), resource (protein sequences), scope (up to 100 per call), and explicitly ties itself to the sibling covabio_protein_profile ('same 30+ biophysical properties ... per sequence'). An agent can distinguish this batch tool from the single-sequence sibling 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?
Names concrete use cases ('candidate panels, variant series, or a whole FASTA out of covabio_parse_fasta') and the cap condition (over 100 rejected, so split the batch). It differentiates against covabio_protein_profile by implication ('per sequence') but never explicitly says to use the single tool for one sequence, so it stops short of full when/when-not framing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute net charge versus pH over a chosen window, plus the isoelectric point. Use for buffer and formulation-pH selection, for predicting IEX binding and elution behaviour, and for reading a pI shift between a reference and a comparability lot.
Parameters:
sequence: Protein amino acid sequence.
ph_start: Lower bound of the pH window (default 2.0).
ph_end: Upper bound of the pH window (default 12.0).
Returns: {charge_profile: [{ph, charge}], isoelectric_point}| Name | Required | Description | Default |
|---|---|---|---|
| ph_end | No | ||
| api_key | No | ||
| ph_start | No | ||
| sequence | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the output shape (charge_profile array plus isoelectric_point) and the pH-window defaults, but says nothing about the underlying pKa/charge model, its treatment of modifications or denaturation, or any accuracy limits — meaningful omissions for a predictive 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?
Purpose is front-loaded in the first sentence, followed by a tidy parameter block and a returns block; no filler sentences. The explicit Returns line is partly redundant given an output schema exists, which is the only small waste.
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 computation with an output schema already present, the description covers purpose, usage, parameter meaning and return shape adequately. The gaps are the undocumented api_key parameter and any statement of model assumptions or limitations.
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%, so the description must compensate. It documents three of four parameters (sequence, ph_start as lower bound, ph_end as upper bound) with clearer wording than the bare schema titles, but the api_key parameter is never mentioned in the description or the schema, leaving one parameter undocumented.
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 computation ('net charge versus pH over a chosen window, plus the isoelectric point') with an unambiguous resource, which is enough to separate it from general profiling siblings like covabio_protein_profile or covabio_developability. An agent knows exactly what comes out 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?
Gives three concrete application contexts (buffer/formulation pH selection, IEX binding and elution prediction, pI shift between reference and comparability lot), which is clear situational guidance. It never states when not to use it or names a sibling alternative, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Map protease cleavage sites and score proteolytic stability. Covers trypsin (after K/R, not before P), chymotrypsin (after F/W/Y, not before P), pepsin (after F/L) and elastase (after A/G/S/V). Returns per-protease position lists, a total site count, a 0-100 stability score and a classification (highly_stable / moderate / proteolytically_labile).
Two uses: predicting in-vivo half-life and serum stability for a peptide therapeutic, and planning the digest for a peptide-mapping or MAM method — the trypsin list is the peptide map you will get.
Returns the same protease analysis that covabio_peptide embeds, on its own and for any protein length.
Parameters:
sequence: Amino acid sequence.
Returns: {sites: {trypsin, chymotrypsin, pepsin, elastase}, total_cleavage_sites, stability_score, classification}| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| sequence | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does well: it discloses the exact cleavage rules per protease (e.g. trypsin after K/R but not before P) and the shape of the output (per-protease position lists, total count, 0-100 score, three-way classification). It omits error/edge behavior and any auth or rate-limit context.
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 purpose and rules, then use cases, then output shape. Dense but every sentence carries information; the protease rule list is compact rather than 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?
For a no-annotation, single-input analysis tool the description is largely self-sufficient: rules, scoring scale, classifications, and return fields are all stated (and the output schema independently documents the return shape). Minor gaps are input format expectations and failure conditions.
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 0%, so the description must compensate. It labels 'sequence' as an amino acid sequence and 'for any protein length' implies no length cap, which is useful, but it adds no format detail (one-letter code, allowed characters) and never mentions the second parameter, api_key.
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+resource ('Map protease cleavage sites and score proteolytic stability') and enumerates the exact proteases and their rules. It also differentiates from the sibling covabio_peptide by noting it returns the same analysis standalone and for any protein length.
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 two use cases (in-vivo half-life/serum stability prediction and peptide-mapping/MAM digest planning) and clarifies the relationship to covabio_peptide. It gives clear routing context but does not state when the embedding tool would be preferable instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute the Codon Adaptation Index (CAI) of a DNA coding sequence against host codon usage. Returns the score, how many codons were scored, how many hit the host's optimal codon, and a classification (highly_optimized >0.8 / well_optimized >0.6 / moderately_optimized >0.4 / poorly_optimized). Use to judge an expression construct before ordering synthesis, or to compare two vendor optimizations.
Scored against the optimal codon per amino acid, so it measures optimal-codon fraction rather than the geometric-mean CAI of Sharp & Li 1987. Stop codons are excluded. For mRNA therapeutics use covabio_mrna, which adds GC, CpG and uridine content.
Parameters:
dna_sequence: Coding DNA sequence (ATG...stop).
organism: Host codon table — "ecoli" (default) or "human".
Returns: {cai_score, total_codons, optimal_codons, scored_codons, organism, classification}| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| organism | No | ecoli | |
| dna_sequence | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full burden and mostly discharges it: it discloses the scoring method (optimal-codon fraction, explicitly NOT the geometric-mean CAI of Sharp & Li 1987), stop-codon exclusion, and the four classification thresholds. It does not mention the api_key requirement or any rate/permission behavior, so it stops 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?
Front-loaded with purpose and caveats, then cleanly sectioned into Parameters and Returns; every substantive sentence earns its place. The 'Returns:' block is largely redundant because an output schema already exists, which keeps it out of 5 territory.
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 single-sequence scoring tool with an output schema available, the description supplies the methodological caveat, the classification banding, the intended use cases, and the sibling alternative — everything an agent needs to call and interpret it correctly. Only the api_key parameter is unaddressed, a minor gap.
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%, so the description must compensate; it documents the two functional parameters well, giving the sequence format ('ATG...stop') and the accepted organism values ('ecoli' default or 'human') that the schema's bare string types omit. The third parameter, api_key, is left entirely undocumented.
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 — 'Compute the Codon Adaptation Index (CAI) of a DNA coding sequence against host codon usage' — and names the sibling it is not (covabio_mrna). An agent can distinguish it from the many other covabio sequence tools without opening a 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?
Gives explicit use cases ('judge an expression construct before ordering synthesis, or compare two vendor optimizations') and an explicit exclusion with alternative routing: 'For mRNA therapeutics use covabio_mrna, which adds GC, CpG and uridine content.' Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Locate asparagine deamidation hotspots in a protein sequence — the single most cited chemical-degradation CQA for antibodies and fusion proteins. Scans for the six Asn-Xaa motifs ordered by known lability: NG (critical), NS (high), NH and ND (medium), NA and NT (low). Use to justify a deamidation-monitoring strategy, to compare candidate sequences before lead selection, or to explain a charge-variant shift observed on IEX/icIEF.
This is a sequence-motif rule set, not a structural or kinetic prediction: solvent exposure, local flexibility, pH and temperature all modulate the real rate, and a buried NG can be stable while an exposed ND is not. Treat the output as a site list to test, not a rate.
Parameters:
sequence: Protein amino acid sequence (1-letter code).
Returns: {deamidation_sites: [{position, motif, risk, context}]} sorted by position| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| sequence | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so: it declares the method is a sequence-motif rule set, explains that solvent exposure/flexibility/pH/temperature modulate real rates, warns that a buried NG can be stable while an exposed ND is not, and instructs the agent to treat output as a site list to test rather than a rate. This is exactly the epistemic-boundary disclosure an agent needs to avoid misusing the output.
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 purpose, then motifs, then usage, then the limitation caveat — a logical order with no wasted sentences. Slightly verbose in the framing clause ('the single most cited chemical-degradation CQA') and the caveat paragraph is long, though it earns its place given the absence of 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?
An output schema exists, so return-value explanation is not required, yet the description still summarizes the return shape and sort order. Combined with the motif list, usage contexts, and methodological caveats, an agent has everything needed to call and correctly interpret this single-param 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 0%, so the description must compensate: it documents 'sequence' as a protein amino acid sequence in 1-letter code, which adds real meaning. The second parameter (api_key) is left unexplained, which is the only gap; for a self-evident credential parameter this is minor.
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+resource ('Locate asparagine deamidation hotspots in a protein sequence') and enumerates the exact rule set applied (NG/NS/NH/ND/NA/NT motifs with lability ordering), which distinguishes it from nearby siblings like covabio_cleavage_sites or covabio_protein_profile. An agent knows precisely what analysis is performed 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?
Gives three concrete use cases (justify a deamidation-monitoring strategy, compare candidate sequences before lead selection, explain a charge-variant shift on IEX/icIEF) and a scope exclusion ('not a structural or kinetic prediction'). It does not name specific alternative sibling tools for adjacent needs, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Assess biopharmaceutical developability across 8 risk dimensions: aggregation propensity, deamidation hotspots, oxidation sites, glycosylation risk, charge heterogeneity, hydrophobic patches, sequence liabilities, and post-translational modification risk. Returns composite score (0-100) with per-dimension breakdown and flagged positions.
Parameters:
sequence: Protein/antibody amino acid sequence.
metal_binding_context: Set True for chelators/metal-binding constructs so functional
Cys/His/carboxylate residues aren't penalized as liabilities (default False).
Returns: {composite_score, risk_dimensions: {aggregation, deamidation, ...}, flagged_positions}| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| sequence | Yes | ||
| metal_binding_context | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does substantial work: it discloses the output shape (composite 0-100 score, per-dimension breakdown, flagged positions) and explains that metal_binding_context suppresses penalization of functional Cys/His/carboxylate residues. It omits any auth/rate-limit or performance context, but for a compute-style assessment tool the disclosure is strong.
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 purpose followed by parameters and returns, with every enumerated dimension earning its place. The explicit 'Returns:' line partially duplicates the existing output schema, so it is slightly redundant but not wasteful.
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 moderate-complexity analysis tool with an output schema present, the description covers the purpose, the key input semantics, and the return contract adequately. It is slightly over-complete on returns (already in the output schema) while leaving the api_key parameter 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 0%, so the description must compensate; it does so well for 'sequence' (amino acid sequence) and exceptionally for 'metal_binding_context' (explains the exact residues affected and the default). Only 'api_key' is left undocumented, which is a minor gap given it is an injected credential.
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 ('Assess') and resource ('biopharmaceutical developability') and enumerates all 8 risk dimensions plus the composite scoring model, which precisely scopes the tool as a multi-dimension aggregate. This enumeration effectively distinguishes it from single-dimension siblings like covabio_deamidation, covabio_charge_profile, and covabio_viscosity.
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 purpose (run this for a developability read), but there is no explicit when-to-use, when-not-to-use, or routing to the single-dimension sibling tools that overlap with its dimensions. Only the metal_binding_context parameter carries any decision guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Screen protein sequence for potential T-cell epitopes (MHC-II binding). Scans 9-mer windows against 8 common HLA-DRB1 alleles using positional scoring matrices. A window counts as an epitope when it clears an absolute, background-calibrated score threshold (each allele flags at most 5% of random 9-mers of natural composition), so epitope_density is comparable between sequences: a sequence of random natural composition scores ~0.09 against this panel. Deimmunization suggestions target the P1/P4/P6/P9 anchor positions that drive binding. This is an in-silico binding prediction from hand-curated matrices, NOT an ADA rate and not calibrated against measured affinities.
Parameters:
sequence: Protein amino acid sequence.
alleles: Optional HLA allele list (default: 8 common DRB1 alleles).
Returns: {n_epitopes, epitopes: [{position, peptide, allele, score, binding_alleles}], epitope_density, risk_classification (low <0.18, moderate <0.27, high), hotspots, per_allele_scores, deimmunization_suggestions: [{position, original_aa, suggested_aa, position_class, predicted_reduction}], binder_thresholds, threshold_basis}| Name | Required | Description | Default |
|---|---|---|---|
| alleles | No | ||
| api_key | No | ||
| sequence | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so richly: it discloses the scoring method, the background-calibrated 5%-of-random-9-mers flag rate, the ~0.09 random-composition density baseline, the anchor positions targeted for deimmunization, and clearly scopes the prediction as in-silico from hand-curated matrices.
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 layers calibration and limitation detail. Dense but nearly every sentence adds interpretation value; the returns enumeration is somewhat lengthy but useful given the output schema.
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 and the description reinforces key return fields (epitope_density, risk_classification thresholds, deimmunization_suggestions, binder_thresholds), so return semantics are well covered. The only meaningful gap is the undocumented api_key parameter and absent usage routing.
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 0%, so the description must compensate. It does for sequence and for alleles (default 8 common DRB1 alleles), adding real meaning over the bare schema. But api_key is present in the schema and never mentioned in the description, leaving one of three parameters undocumented.
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+resource ('Screen protein sequence for potential T-cell epitopes (MHC-II binding)') and immediately qualifies the method (9-mer windows, 8 HLA-DRB1 alleles, positional scoring matrices). An agent can distinguish this from siblings like covabio_protein_profile or covabio_peptide without opening a 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?
Usage is implied rather than routed: it explains what the tool does and explicitly warns it is 'NOT an ADA rate and not calibrated against measured affinities', which helps an agent decide fitness. However, it never names when to prefer this over alternatives (e.g. developability or protein_profile) or states prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Consolidated Multi-Attribute Method hotspot report: every sequence-liable modification site in one ranked list, across seven modification types — deamidation, oxidation, isomerization, N-glycosylation sequons, acid-labile cleavage, N-terminal pyroglutamate, and C-terminal lysine clipping. This is the site list a MAM peptide-mapping method has to cover, and the starting point for an attribute-criticality assessment.
Sequence-derived only: it tells you which residues CAN carry an attribute, not which ones DO in a given lot. It replaces neither the LC-MS measurement nor the criticality ranking.
Parameters:
sequence: Protein/antibody amino acid sequence.
Returns: {hotspots: [{position, modification_type, motif, risk, context}]}| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| sequence | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses a critical behavioral trait: the report is sequence-derived only, telling which residues CAN carry an attribute, not which DO in a given lot. It also clarifies that it replaces neither experimental measurement nor criticality ranking, which is important context for an agent.
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 front-loaded: the first sentence defines the tool and its scope, the second explains its role in a workflow, and the third states limitations. It is mostly efficient, though slightly longer than strictly necessary.
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?
Given the output schema exists, the description needn't explain return values, but it still provides a summary. It covers the tool's purpose, scope, limitations, and output shape. The main gap is the missing detail on input format and the unmentioned api_key parameter, but for a sequence-based analysis tool, it is largely 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 0%, so the description must compensate for both parameters. It only briefly describes 'sequence' as 'Protein/antibody amino acid sequence' and does not mention the 'api_key' parameter at all. Format expectations (e.g., one-letter code, plain text) are not specified, leaving significant gaps.
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 (consolidated report) and resource (MAM hotspot report) and enumerates seven modification types covered, clearly distinguishing it from single-attribute siblings like covabio_deamidation or covabio_cleavage_sites.
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?
It explains when to use it (as the site list a MAM peptide-mapping method must cover and the starting point for attribute-criticality assessment) and what it is not (a substitute for LC-MS measurement or criticality ranking). It does not name alternative tools for those excluded use cases, but the boundaries are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evaluate mRNA therapeutic sequence: codon adaptation index (CAI), GC content optimization, CpG dinucleotide analysis, uridine content, and overall optimization score for translational efficiency.
Parameters:
coding_sequence: mRNA coding DNA sequence (ATG...stop).
organism: Target organism — "human" (default) or "ecoli".
Returns: {cai_score, gc_content, cpg_count, uridine_fraction, optimization_score}| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| organism | No | human | |
| coding_sequence | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It does disclose the computed metrics and the return keys, and the operation is implicitly a read-only computation, but it never mentions authentication needs despite an api_key parameter, nor how invalid or non-coding input is 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?
Front-loaded purpose sentence followed by a compact parameter list and a returns line; little waste. The explicit 'Returns' block is slightly redundant given a declared output schema, but it is brief.
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 3-parameter analysis tool with an output schema present, the core is covered: input format, organism options, and metrics. Gaps remain around sibling differentiation (covabio_codon_adaptation) and the api_key parameter, which the agent would need to understand to invoke the tool successfully.
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%, so the description must compensate, and it does for two of three parameters: it specifies the coding_sequence format (ATG...stop) and the organism enum values ('human' default, 'ecoli'). Only api_key is left unexplained.
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 (Evaluate) and resource (mRNA therapeutic sequence) and enumerates the exact metrics computed (CAI, GC, CpG, uridine, optimization score), so the agent knows what it produces. However, it does not distinguish itself from the closely related sibling covabio_codon_adaptation, which appears to overlap on codon adaptation scoring.
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 guidance on when to use this tool versus alternatives such as covabio_codon_adaptation or covabio_sequence_utils, and no prerequisites or exclusions stated. The agent must infer applicability from the metric list alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute oligonucleotide properties: melting temperature (Tm via SantaLucia 1998 nearest-neighbor), GC content, molecular weight, extinction coefficient, hairpin detection, and self-complementarity check.
Parameters:
sequence: Nucleotide sequence (e.g. "ATCGATCG").
oligo_type: "DNA" (default) or "RNA".
Returns: {tm_celsius, gc_content, molecular_weight, hairpin_detected, self_complementary}| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| sequence | Yes | ||
| oligo_type | No | DNA |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral-disclosure burden. It transparently describes the computation and return fields, including the Tm method, but omits operational details such as whether an API key is required, input length/validity constraints, and error behavior.
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 front-loaded and clearly sectioned into purpose, parameters, and returns. It contains no filler sentences, and the return list is short enough to be useful despite an output schema existing.
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?
The output schema exists, so return values need not be explained, but the description still omits the api_key parameter and any usage context. With no annotations and 0% schema description coverage, the definition is minimally adequate for a simple compute tool but leaves clear gaps.
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%, so the description must compensate. It documents sequence with an example and oligo_type with allowed values and default, but it completely omits the api_key parameter, leaving one of three parameters undocumented.
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: compute oligonucleotide properties. It enumerates the exact properties computed (Tm, GC content, molecular weight, extinction coefficient, hairpin detection, self-complementarity) and names the Tm algorithm, making it distinct from sibling tools focused on proteins, mRNA, siRNA, or general sequence utilities.
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 explains what the tool does but gives no guidance on when to use it versus alternatives such as covabio_sequence_utils or other covabio_* tools. There are no exclusions, prerequisites, or routing cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse FASTA text into named sequence entries. Handles multi-line sequences, multiple records, and raw sequence without a header (auto-named seq_1, seq_2, ...). Use to turn a pasted or downloaded FASTA into the input for covabio_batch_profile or any single-sequence tool.
Parameters:
fasta_text: FASTA-formatted text (one or more records).
Returns: {entries: [{name, sequence}]}| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| fasta_text | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses edge-case handling (multi-line sequences, multiple records, headerless input auto-named seq_1, seq_2), but never states that parsing is side-effect-free/non-mutating, says nothing about error behavior on malformed FASTA, and does not mention the api_key requirement.
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: parsing purpose and edge-case handling come first, then usage guidance. Tight overall, though the trailing 'Returns: {entries: ...}' line restates what the existing output schema already provides and is minor dead weight.
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 text-parsing tool with an output schema present, the description covers purpose, edge cases, and downstream wiring well; return format need not be explained. The only real omission is the undocumented api_key parameter, which is a minor but real gap.
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%, so the description must compensate. It adequately defines fasta_text ('FASTA-formatted text (one or more records)') and its headerless behavior, but the second parameter (api_key) is never mentioned in either the schema or the description, leaving one of two parameters undocumented.
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+resource ('Parse FASTA text into named sequence entries') and immediately differentiates itself from the many analysis siblings by naming the downstream consumer (covabio_batch_profile / any single-sequence tool). An agent can tell this is the ingestion/preprocessing step, not an analysis step.
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 says when to use it: to turn pasted or downloaded FASTA into input for covabio_batch_profile or single-sequence tools. It does not name what to use instead when the input is already structured (e.g., vs. covabio_sequence_utils), so it stops short of full when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Profile a peptide sequence: biophysical properties plus peptide-specific analyses including cell-penetrating peptide (CPP) score, antimicrobial peptide (AMP) prediction, proteolytic stability (trypsin/chymotrypsin/pepsin cleavage sites), and N-end rule half-life.
Parameters:
sequence: Peptide amino acid sequence (typically 5-50 residues).
Returns: {properties, cpp_score, amp_score, protease_sites, half_life}| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| sequence | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the analyses performed and the return object structure, which is helpful beyond the schema. However, it does not cover behavioral aspects such as whether the sequence is validated, error handling, or rate 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?
The description is two concise sections: a bulleted list of analyses and a short return structure. It is front-loaded with the core purpose and avoids unnecessary detail, though the parameter mention is brief and the return list could be integrated more smoothly.
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 and the description lists the top-level return keys, which is sufficient. However, with no annotations and a missing api_key description, the tool lacks behavioral context (e.g., authentication requirements, input validation) that an agent might need to invoke it correctly.
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%, so the description must compensate. It adds meaning for 'sequence' by specifying it is an amino acid sequence and giving a typical length range (5-50 residues). The 'api_key' parameter is not mentioned in the description, leaving it undocumented, but it is likely a standard authentication parameter. The description partially compensates but misses one parameter.
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 ('Profile') and resource ('peptide sequence'), then enumerates the exact analyses performed (CPP score, AMP prediction, proteolytic stability, N-end rule half-life). This clearly distinguishes it from general protein tools like covabio_protein_profile.
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 specificity of 'peptide' and the listed analyses imply usage for short peptide sequences, but there is no explicit statement of when to use this tool versus alternatives like covabio_cleavage_sites or covabio_protein_profile, nor any listed exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute 30+ biophysical properties of a protein from its amino acid sequence. Returns molecular weight, isoelectric point, extinction coefficient, GRAVY (hydrophobicity), instability index, aromaticity, charge profile across pH range, amino acid composition, and secondary structure fractions.
Parameters:
sequence: Amino acid sequence (1-letter code, e.g. "MKWVTFISLLLLFSSAYS...").
Returns: {molecular_weight, isoelectric_point, gravy, instability_index, charge_profile, ...}| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| sequence | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses the outputs and that it is a pure computation, but says nothing about whether an api_key is required, authentication, cost/rate limits, or failure behavior on invalid sequences.
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 and efficiently enumerates outputs. The trailing 'Returns: {...}' line is somewhat redundant since an output schema already exists, but overall it is tight and well-structured.
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 the return-value listings are more than needed, yet the description omits the api_key prerequisite and any auth/cost context for a tool with no annotations. Adequate but with clear gaps for correct invocation.
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%. The description compensates well for the 'sequence' parameter (1-letter code plus a concrete example), which the schema lacks, but the second parameter 'api_key' is undocumented in both schema and description. Net effect is partial compensation for a 2-param tool.
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+resource ('Compute 30+ biophysical properties of a protein from its amino acid sequence') and enumerates the concrete outputs, so an agent knows exactly what it produces. It does not distinguish itself from overlapping siblings like covabio_charge_profile or covabio_batch_profile, which also cover some of the same properties.
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 when-to-use or when-not-to-use guidance, and no alternatives are named despite several sibling tools (covabio_charge_profile, covabio_developability, covabio_batch_profile) that clearly overlap. The agent is left to infer the selection criteria entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sequence toolbox for construct design: 1-letter to 3-letter code conversion, codon table, reverse translation optimized for E. coli and for human codon usage, signal-peptide check, simple domain search, and restriction-enzyme sites found in the reverse-translated DNA. Use when going from a protein sequence to an expression construct.
Parameters:
sequence: Protein amino acid sequence.
Returns: {length, one_to_three, codon_table, reverse_translate_ecoli, reverse_translate_human, signal_peptide_check, domain_search, restriction_sites_in_dna}| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| sequence | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries the full burden. It discloses the operations and the two codon-usage optimizations, which is useful behavior, but says nothing about the api_key authentication requirement, cost, rate limits, or limitations of the 'simple' domain search.
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-loads the toolbox purpose and packs the operations into one dense, mostly waste-free paragraph. The trailing 'Returns:' block partially duplicates the existing output schema, a minor redundancy.
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 multi-function toolbox with an output schema but no annotations, the description adequately covers what each function does and the intended workflow. Only the undocumented api_key and the absence of any sibling routing keep it from being fully 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 0%, so the description must compensate. It documents 'sequence' as a protein amino acid sequence, which is helpful, but the second parameter (api_key) is neither in the schema text nor the description, leaving a gap for a tool that evidently needs auth.
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 resource and enumerates the concrete operations (code conversion, codon table, reverse translation for E. coli/human, signal-peptide check, domain search, restriction sites) and the goal ('protein sequence to an expression construct'). It is distinguishable from most siblings, though it overlaps with covabio_codon_adaptation and covabio_cleavage_sites without naming them.
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 going from a protein sequence to an expression construct' gives situational context, but with dozens of bio siblings (covabio_codon_adaptation, covabio_cleavage_sites, covabio_protein_profile) there is no explicit when-not or named alternative to route the agent. Usage is implied rather than delimited.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Design siRNA candidates against a target mRNA sequence using Reynolds 2004 rules. Scores 19-mer windows for efficacy, GC content, thermodynamic asymmetry, and off-target risk. Returns ranked candidate list.
Parameters:
target_sequence: Target mRNA sequence (DNA, minimum 21 nt).
Returns: {n_candidates, candidates: [{position, sense, antisense, score, gc_content}]}| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| target_sequence | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose meaningful behavior: the scoring dimensions (efficacy, GC, thermodynamic asymmetry, off-target risk) and the 19-mer windowing approach. However, it never states this is a pure computation with no side effects, nor that an api_key credential is required, leaving safety/operational context thin.
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-loads the purpose in the first sentence and organizes parameters and returns compactly with no filler. The explicit Returns block is somewhat redundant since an output schema already exists, costing a small amount of space.
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 two-parameter tool, the description covers what it does, how it scores, the key input constraint, and the return shape. The only meaningful gap is the undocumented api_key parameter and absence of any usage routing context.
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%, so the description must compensate. It explains target_sequence well, adding the key constraint of minimum 21 nt and clarifying it is DNA even though the input is mRNA-derived. It says nothing about the api_key parameter, leaving one of two params undocumented.
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 (Design) and resource (siRNA candidates against a target mRNA), and names the exact methodology (Reynolds 2004 rules) plus the scored criteria. An agent can distinguish this from sibling design/analysis tools like covabasic_reynolds or covabio_mrna 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?
Usage is only implied: an agent infers this is the tool for designing siRNA from an mRNA sequence. There is no explicit when-to-use/when-not guidance, no mention of prerequisites, and no routing to alternatives among the many covabio/covabasic siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate viscosity of a protein solution at high concentration. Uses sequence-based heuristic model (Sharma 2014) considering charge, hydrophobicity, and molecular weight. Critical for antibody formulation development.
Parameters:
sequence: Protein amino acid sequence.
concentration_mg_ml: Protein concentration (default 150 mg/mL for subcutaneous).
ph: Formulation pH (default 6.0).
Returns: {viscosity_cP, risk_level, contributing_factors}| Name | Required | Description | Default |
|---|---|---|---|
| ph | No | ||
| api_key | No | ||
| sequence | Yes | ||
| concentration_mg_ml | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It credits itself by naming the heuristic model and its basis (charge, hydrophobicity, molecular weight), which sets expectations that this is an estimate, not an experimental measurement. But it omits accuracy/limitations, error behavior, and any authentication or rate-limit context, and it silently ignores the api_key parameter.
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-loads the purpose, then method, then a clean parameter list, then returns. Each block is short and scannable; nothing is padding, and the structure maps to how an agent would read it.
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 restating the return fields is mildly redundant but harmless. For a heuristic predictor the description covers intent, method, and main inputs, yet it leaves the api_key requirement unaddressed and says nothing about applicability limits or input validation (e.g., sequence length bounds), which an agent needs to call it correctly.
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%, so the description must compensate, and it documents three of four parameters (sequence, concentration_mg_ml, ph) with domain rationale such as 'default 150 mg/mL for subcutaneous' and 'formulation pH'. It adds real meaning over the bare schema, but the fourth parameter (api_key) is left completely unexplained in both schema and description.
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 ('Estimate viscosity of a protein solution at high concentration') and names the underlying model (Sharma 2014), so an agent immediately knows this is a predictive biophysical calculation rather than a generic analysis. No sibling tool covers viscosity, and the description distinguishes itself from the broader covabio_* profiling tools by naming the exact quantity produced.
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?
'Critical for antibody formulation development' gives implied context for when it applies, which is useful domain framing. However, it never states when NOT to use it, what alternatives exist (e.g., covabio_developability or covabio_protein_profile for broader characterization), or what input prerequisites must hold before calling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare 2-5 molecules side by side.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| smiles_list | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing: no indication of how molecules are aligned, whether missing/invalid SMILES cause failure, whether the call is a pure read, or what the comparison reports. Only the input cardinality is revealed.
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 short, front-loaded sentence with no wasted words; the 2-5 range is immediately visible. The brevity is efficient, though it is achieved by omission rather than by tight writing.
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 described, but with zero annotation coverage and 0% schema description coverage the definition leaves the agent guessing on input format, auth via api_key, and when to pick this tool among the many compare siblings.
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%, so the description must compensate for both parameters and does not. 'smiles_list' is only inferable from the word 'molecules', and the api_key parameter is never mentioned at all — an agent would not know it exists or what it does.
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 verb (compare) and resource (molecules) and adds a size constraint (2-5). However, 'side by side' says nothing about what dimensions are compared (properties, scaffolds, similarity scores), and there is no differentiation from the several sibling compare tools (covair_compare, covnmr_compare, covauv_compare).
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 guidance on when to choose this over alternatives such as covachem_profile or covabasic_similarity, nor any prerequisite or exclusion. Only the implicit 2-5 molecule range constrains use, and that is a format constraint, not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evaluate drug-likeness filters (Lipinski, Ghose, Veber, PAINS, etc.).
| Name | Required | Description | Default |
|---|---|---|---|
| smiles | Yes | ||
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It says nothing about which filters are actually returned, whether the evaluation is read-only, whether api_key authentication is required, or how results are structured. The vague trailing "etc." leaves the filter set undefined.
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 no wasted words, naming the operation and giving illustrative filter examples. Appropriately sized, though slightly under-specified rather than truly concise.
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 described. But for a compute tool with zero annotations and undocumented parameters, the description omits whether filter selection is configurable and leaves both inputs unexplained, making it minimally adequate at best.
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% for two parameters, and the description adds no meaning for either. It neither explains the SMILES input format nor what api_key is for, so it fails to compensate for the coverage 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?
States a specific verb ("Evaluate") and resource ("drug-likeness filters") and enumerates concrete filter names (Lipinski, Ghose, Veber, PAINS), so the agent knows exactly what the tool computes. However, it does not distinguish itself from the near-identically named sibling covabasic_druglikeness, so an agent cannot tell why it should pick one over the other.
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 when-to-use guidance, no prerequisites, and no mention of alternatives. With siblings like covabasic_druglikeness, covabasic_filter_check, and covabasic_reynolds all plausibly overlapping, the absence of routing guidance is a real gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Broad physicochemical scan — 80+ properties in one call (logP, TPSA, H-bond donors/acceptors, rotatable bonds, druglikeness flags, heuristic logS, etc).
Use this when the user wants a general overview of a molecule.
Do NOT use this if the user asks specifically about:
• SOLUBILITY in a solvent → use `covasolve_predict` (ML model with
confidence intervals, ~10× more accurate than this tool's heuristic
logS, and cheaper at 5 credits vs 6).
• DRUGLIKENESS only → `covachem_druglikeness` (1 cr).
• pKa values → `covachem_pka` (5 cr).
• ADME parameters only → `covachem_adme` (15 cr).
Cost: 6 credits (broad-scan premium). The targeted tools above are 1-5 cr
each and produce better results within their domain.| Name | Required | Description | Default |
|---|---|---|---|
| smiles | Yes | ||
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does disclose cost (6 credits, 'broad-scan premium') and a candid accuracy limitation (its heuristic logS is ~10× less accurate than covasolve_predict). It does not disclose auth requirements or any rate/input-size limits, but the cost and self-limiting accuracy disclosure is well beyond 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?
Front-loads the capability and size of the scan, then uses a tight bulleted exclusion list and a one-line cost note. Every sentence earns its place — the examples, the routing rules, and the price comparison all affect tool selection.
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 described, and the description fully covers selection, alternatives, and cost. The remaining gap is parameter-level guidance for the undocumented smiles/api_key inputs, which keeps it short of 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 0% — neither 'smiles' nor 'api_key' has any schema documentation, so the description must compensate and it does not. It never explains the SMILES input format, whether salts/stereochemistry are accepted, or how api_key is obtained, leaving both parameters effectively undocumented.
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+resource ('Broad physicochemical scan') and quantifies scope ('80+ properties in one call') with concrete examples (logP, TPSA, H-bond donors/acceptors, druglikeness flags). It explicitly distinguishes itself from siblings like covasolve_predict and covachem_druglikeness, so an agent can route without opening any 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?
Gives an explicit when-to-use rule ('general overview of a molecule') and a structured when-NOT-to-use list naming four alternatives with the exact condition that selects each (solubility→covasolve_predict, druglikeness→covachem_druglikeness, pKa→covachem_pka, ADME→covachem_adme). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute alias/confounding structure and design resolution.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | ||
| api_key | No | ||
| max_order | No | ||
| factor_columns | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, yet it only says what is computed. It does not disclose whether the operation is read-only, whether it requires a design object, what computational cost or limitations exist, or what the output structure 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?
The single sentence is front-loaded and free of filler, but for a four-parameter, annotation-free tool it is under-specified rather than genuinely concise. Brevity here reflects missing information, not efficient communication.
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, but the description still leaves the agent without usage context or parameter meaning for a non-trivial statistical tool. Given zero annotation and schema coverage, it is insufficiently 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 0% across four parameters, and the description mentions none of them. It does not explain the expected shape of 'data', what 'factor_columns' should contain, or what 'max_order' controls, leaving parameters completely undocumented.
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 gives a specific verb and technical resource: 'Compute alias/confounding structure and design resolution.' An agent familiar with DoE terminology can identify it as an alias-structure computation tool, though it does not distinguish this from related siblings like covadoe_analyze or covadoe_design_space.
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 use this tool versus the many other covadoe design-analysis tools. The description implies a design-evaluation context but never states prerequisites, alternatives, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run ANOVA analysis on experimental results.
Returns OLS coefficients (coded + uncoded, with a plain-language model_equation_uncoded),
Type III ANOVA (+ Type I sequential SS under anova_type1), and significance. Blocking and
split-plot terms are picked up automatically from "Block"/"WholePlot" columns. Optional:
`factor_info` (list of {name, type:"categorical", levels:[...]}) enables multi-df categorical
F-tests; `response_family` ("gaussian"|"binomial"|"poisson") fits a GLM for non-normal responses.| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | ||
| api_key | No | ||
| response | Yes | ||
| factor_info | No | ||
| model_terms | No | linear | |
| factor_columns | No | ||
| response_family | No | gaussian |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden and does so well: it discloses the return contents (coded/uncoded OLS coefficients, model_equation_uncoded, Type III vs Type I SS), automatic detection of 'Block'/'WholePlot' terms, and GLM behavior for non-normal families. It omits error conditions, data-format expectations, and the role of api_key.
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?
Dense but well ordered: purpose first, then outputs, then optional behaviors. Each sentence carries information, though the paragraph is long and mixes return-value detail with parameter guidance.
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-value detail is largely redundant, and the real gap is the undocumented majority of the input parameters (5 of 7 with 0% schema coverage). The description is adequate for calling the tool but leaves key inputs like model_terms and factor_columns unexplained.
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 7 parameters, so the description must compensate. It gives real semantics for only two (factor_info with its element shape and purpose, response_family with its enum values), leaving data, response, api_key, model_terms, and factor_columns entirely undocumented.
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 ('Run ANOVA analysis on experimental results') and details what it produces (OLS coefficients, Type III ANOVA, significance). It is clearly a DOE analysis tool, but it never distinguishes itself from close siblings such as covadoe_fit_rsm, covadoe_canonical_analysis, or covadoe_model_selection.
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 explicit when-to-use or when-not-to-use guidance, and no alternative tool is named. Usage is only implied by 'on experimental results' and the automatic blocking/split-plot handling, leaving the agent to infer when this beats fit_rsm or canonical_analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Augment a screening design with RSM runs (axial, fold-over, BBD).
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| target_type | No | central_composite | |
| existing_design | Yes | ||
| n_center_points | No | ||
| selected_factors | Yes | ||
| reuse_center_points | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and largely fails it. It does not say whether existing_design is modified in place or a new design is returned, what permissions/api_key are needed, how run count is determined, or what the resulting augmented design 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?
A single sentence with no filler, and the core action is front-loaded. It is efficient, though its brevity edges toward under-specification rather than ideal conciseness.
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?
Even though an output schema exists and return values need not be explained, this is a 6-parameter, required-input mutation-like design operation with no annotations and no schema descriptions. The description is not complete enough for an agent to invoke it confidently.
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% and there are 6 parameters, so the description must compensate but mostly does not. It gestures at augmentation type via 'axial, fold-over, BBD' (likely mapping to target_type) but says nothing about existing_design, selected_factors, n_center_points, reuse_center_points, or api_key.
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 ('Augment') and resource ('screening design') and narrows the scope to 'RSM runs (axial, fold-over, BBD).' This lets an agent distinguish it from design-creation siblings like covadoe_create_design or analysis siblings like covadoe_fit_rsm, though it never names those alternatives.
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 sentence implies the tool is used to add RSM runs to an existing screening design, but it gives no explicit when-to-use condition, no prerequisite for the required existing_design, and no comparison against alternatives such as covadoe_create_design or covadoe_suggest_design.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Canonical analysis: eigenvalues, stationary point, surface nature.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | ||
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, and it says almost nothing: no indication of required input (a fitted RSM model), no permission/auth notes beyond an api_key param, no statement of what the output contains. It only lists three result artifacts without explaining their meaning or the tool's 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?
It is a single tight sentence with the key outputs front-loaded and no filler, which is good structure. But the brevity reflects under-specification rather than economy, so it cannot score high.
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 described. Still, for a nested-object input with no annotations and no schema documentation, the description omits what the tool requires and when it applies, leaving an agent unable to invoke it correctly with confidence.
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%; the required 'model' object has no description and api_key is undocumented beyond a default. The description never mentions either parameter, so it does not compensate for the coverage gap — an agent gets no guidance on the shape or provenance of the required model.
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 analysis (canonical analysis) and enumerates its outputs (eigenvalues, stationary point, surface nature), which lets an agent infer it characterizes a fitted response-surface model. However it uses a noun-phrase listing rather than a verb+resource statement and does not distinguish it from close siblings like covadoe_ridge_analysis or covadoe_fit_rsm, whose outputs overlap.
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, prerequisites, or alternatives are given. An agent cannot tell from the text whether a fitted model must exist first or when to prefer this over covadoe_ridge_analysis (which handles ridge/stationary-ridge cases). Usage must be inferred entirely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare and rank candidate designs for given factors.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | No | screening | |
| api_key | No | ||
| factors | Yes | ||
| max_runs | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, yet it says nothing about whether the operation is read-only, how the api_key is used, or what side effects occur. The output schema covers return values, but safety and auth behavior remain undisclosed.
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 no filler or repetition. It is structurally clean, though its extreme brevity contributes to the larger completeness gaps rather than being a model of efficient elucidation.
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?
The tool has moderate complexity (four parameters, including nested factor objects) and zero schema descriptions, so the description should supply context the schema lacks. It does not explain factor structure, goal values, or max_runs behavior, leaving the agent under-informed despite the output schema handling return values.
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%, so the description must compensate for all four parameters. It only references the required "factors" parameter by name with no structural detail, and says nothing about goal, api_key, or max_runs, leaving most parameters semantically dark.
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 pair (compare and rank) and resource (candidate designs), so an agent can distinguish it from generative siblings like covadoe_create_design or covadoe_suggest_design. It does not explicitly name or contrast those alternatives, which keeps it 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?
There is no indication of when to use this tool versus alternatives such as covadoe_analyze, covadoe_design_power, or covadoe_find_optimum. The phrase "for given factors" implies a comparison context but provides no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create an experimental design (factorial, fractional, CCD, BBD, D/I-optimal, Taguchi, LHS, simplex mixture, etc.).
Optional: `constraints` — list of {terms:{factor:coef}, op:"<="|">="|"==", rhs} in REAL units —
filters the D/I-optimal candidate set. `mixture=True` with a simplex `design_type`
("simplex_lattice"/"simplex_centroid") builds a bounded-mixture design (L-pseudocomponent,
components sum to 1, each ≥ its `low`); `degree` sets the simplex-lattice degree; `n_levels` sets
the D/I-optimal candidate-grid density.
Model-aware optimal designs: `model_terms` ("linear"|"interaction"|"quadratic") sets the model
matrix the D/I-optimal criterion optimizes for. `n_blocks` (>1) adds a "Block" column, confounding
the highest-order interaction(s) for factorial designs. `n_runs` / `resolution` / `generators`
control the `fractional_factorial` fraction, in that precedence order: `n_runs` (a power of 2,
counting base runs before center points) pins the fraction exactly — e.g. n_runs=16 on 5 factors
gives 2^(5-1), resolution V; `resolution` (3/4/5...) picks the smallest fraction reaching it;
`generators` gives the defining generators verbatim as pyDOE2 tokens, one per factor
(e.g. ["a","b","c","ab","ac"] for 2^(5-2)).
`design_type="taguchi"` builds an orthogonal-array design (`taguchi_levels` 2 or 3). `hard_to_change`
(list of factor names) produces a split-plot layout with a "WholePlot" column. `process_factors`
(with `mixture=True`) builds a mixture-process crossed design (`process_design_type`,
`process_center_points`). `n_runs` also sets the run count for D/I-optimal designs (default
len(factors)*3+1) and the sample count for latin_hypercube / sobol_sequence.
CCD variant: `face` — "circumscribed" (default), "faced" (star points on the faces, α = 1, for
factors that cannot physically exceed their range) or "inscribed" (the CCC scaled so the star
points land on the stated range). `axial_alpha` sets the axial distance; the default is
ROTATABLE, (2**k)**0.25, and "orthogonal" gives the α where Σx² = n_runs. The choice is worth
several points of power — check it with `covadoe_design_power` before running the design.
Common `design_type` aliases resolve ("full_factorial", "ccd", "dsd", "bbd"); the response
reports the canonical name actually built.| Name | Required | Description | Default |
|---|---|---|---|
| face | No | ||
| degree | No | ||
| n_runs | No | ||
| api_key | No | ||
| factors | Yes | ||
| mixture | No | ||
| n_blocks | No | ||
| n_levels | No | ||
| generators | No | ||
| resolution | No | ||
| axial_alpha | No | ||
| constraints | No | ||
| design_type | Yes | ||
| model_terms | No | linear | |
| n_replicates | No | ||
| hard_to_change | No | ||
| taguchi_levels | No | ||
| n_center_points | No | ||
| process_factors | No | ||
| process_design_type | No | full_factorial_2k | |
| process_center_points | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does it well: it explains that `constraints` filters the candidate set, that `mixture=True` forces components to sum to 1 and each ≥ its `low`, that `n_blocks` confounds highest-order interactions, that aliases resolve and the response reports the canonical name. It omits any mention of auth (`api_key`), rate limits, or the effort cost of D/I-optimal generation.
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?
Long, but the length is proportionate to a 21-parameter combinatorial tool, and the purpose is front-loaded in the first line. The parameter prose is dense and only lightly segmented, which slightly hinders scanning but every sentence carries substantive 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?
An output schema exists, so return values need not be explained, and the description still adds the useful note that the response reports the canonical design name. For a 0%-coverage, 21-parameter tool it covers the design-space parameters thoroughly; the gaps are the shape of the required `factors` objects and the few unmentioned knobs (`n_replicates`, `n_center_points`).
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 0%, so the description must compensate, and it documents roughly fifteen of the twenty-one parameters with real semantics (precedence rules, defaults, token format for `generators`, α rules for `axial_alpha`). The required `factors` structure, `api_key`, `n_replicates`, and `n_center_points` remain undocumented in both schema and description, which keeps it short of a 5.
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?
Opens with a specific verb+resource ('Create an experimental design') and enumerates the design families it can build, so the agent immediately knows the scope. It does not distinguish itself from close siblings, however — notably `covadoe_suggest_design`, `covadoe_augment_design`, and especially `covadoe_taguchi`, whose functionality is duplicated here via `design_type="taguchi"` with no routing note.
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 real usage context for parameters (e.g., when to use `face="faced"` for factors that cannot exceed their range, precedence order for `n_runs`/`resolution`/`generators`) and points to `covadoe_design_power` as a follow-up check. What is missing is when to choose this tool over `covadoe_suggest_design` or the dedicated `covadoe_taguchi` tool, leaving sibling routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Planning-time statistical power from a design's REAL model matrix — no data needed.
Builds the design and takes `ncp = effect_size² / (X'X)⁻¹_jj`, so it is correct for centre
points, axial points and unbalanced designs — unlike `covadoe_power_analysis`, which assumes
orthogonality and overstates power on a CCD, Box-Behnken or DSD. Use this when planning an
experiment; use `covadoe_post_hoc_power` only once you have measured responses.
`design_type` + `n_factors` builds the design (same generator as `covadoe_create_design`, so the
answer describes the design you would actually get). Common aliases resolve ("full_factorial",
"ccd", "dsd"). Alternatively pass `design`, an explicit coded run matrix, to score a design you
already hold — D/I-optimal, mixture, split-plot or hand-built. `n_runs` / `model_terms` are
forwarded to the generator for the optimal designs.
`model`: "linear" | "interaction" | "quadratic" | "quadratic_no_interaction" (a DSD supports only
the last). `term` names the coefficient — "x1", "x1^2", "x1*x2"; omit it to get power for every
term and group, which differ sharply on the same design. `alpha` is the significance level;
the CCD axial distance is `axial_alpha`, and the two are easy to confuse.
CCD variant: `axial_alpha` defaults to ROTATABLE, (2**n_factors)**0.25 — the design JMP,
Design-Expert and Minitab hand you. Pass a number, or "orthogonal" for the α where Σx² = n_runs
(at 3 factors: main-effect power 0.9400 against the rotatable 0.8846 on the same 17 runs; the
orthogonal α is also the premise of `covadoe_power_analysis`, so on that design the two agree
for a main effect and disagree for every other term). `face` — "circumscribed" (default),
"faced" (star points on the faces, α = 1) or "inscribed"; a bool works, and an unknown value is
rejected rather than quietly treated as circumscribed.
Returns power, power_by_term, power_by_group, df_error, relative_variance ((X'X)⁻¹_jj), the
resolved design_summary (the α and factorial level actually built — read both, an inscribed CCD
always reports α = 1), and `orthogonal_shortcut_power` — what `covadoe_power_analysis` would
have claimed — with its signed error (signed: the shortcut does not always overstate). Returns
`estimable: false` plus a reason when the model cannot be fitted on the design.| Name | Required | Description | Default |
|---|---|---|---|
| face | No | ||
| term | No | ||
| alpha | No | ||
| model | No | quadratic | |
| design | No | ||
| n_runs | No | ||
| api_key | No | ||
| n_factors | No | ||
| axial_alpha | No | ||
| design_type | No | ||
| effect_size | No | ||
| model_terms | No | ||
| factor_names | No | ||
| n_center_points | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, and it delivers: it states when the result is estimable (returns estimable:false with a reason), that unknown `face` values are rejected rather than silently defaulted to circumscribed, the alpha-vs-axial_alpha confusion risk, and what the return payload contains. This is unusually rich behavioral disclosure for an unannotated tool.
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 promise, and every paragraph earns its place given the tool's complexity (formulas, CCD variants, aliases). It is dense and long rather than padded, though the parenthetical statistics (e.g. 'main-effect power 0.9400 against the rotatable 0.8846') add more example depth than an agent strictly needs.
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 14-parameter, formula-driven tool with no annotations, the description covers the build-vs-pass-a-design paths, the model/term/alpha semantics, and the CCD special cases. Return values are documented even though an output schema exists, and the estimable:false edge case is noted, so nothing essential 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 0% across 14 params, so the description must compensate, and it does: it defines `model` values, `term` syntax ('x1', 'x1^2', 'x1*x2'), `alpha` vs `axial_alpha`, `face` variants, `design_type` aliases, the role of `n_runs`/`model_terms`, and the `effect_size²/(X'X)⁻¹_jj` formula. Only `api_key`, `factor_names`, and `n_center_points` go unaddressed.
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 first sentence states a specific computation ('planning-time statistical power from a design's REAL model matrix') and explicitly names the sibling it differs from ('unlike covadoe_power_analysis, which assumes orthogonality'). An agent can distinguish it from covadoe_power_analysis and covadoe_post_hoc_power without opening any 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?
Explicit when-to-use routing: 'Use this when planning an experiment; use covadoe_post_hoc_power only once you have measured responses.' It also names the alternative (covadoe_power_analysis) and the condition under which the two agree or diverge, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute ICH Q8 design space (NOR, PAR, probability of meeting specs).
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | ||
| api_key | No | ||
| n_samples | No | ||
| confidence | No | ||
| factor_columns | No | ||
| response_specs | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It only names the computed outputs and says nothing about authentication (api_key), side effects, determinism, rate limits, or how the simulation parameters (n_samples, confidence) affect the run.
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 short imperative sentence with the key concept ('ICH Q8 design space') front-loaded. Every word carries information, though the parenthetical output list is slightly dense and the fragment could be structured for easier scanning.
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 complex statistical computation with 6 parameters, no annotations, and 0% schema coverage, the description leaves critical input semantics, prerequisites, and usage context unexplained. The existing output schema relieves it of explaining return values, but the input side remains largely 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 6 parameters, and the description adds no meaning for data, api_key, n_samples, confidence, factor_columns, or response_specs. With zero schema documentation and no compensating explanation, an agent cannot infer the required input formats.
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 a specific resource ('ICH Q8 design space'), with the computed outputs (NOR, PAR, probability of meeting specs) named. It clearly identifies the domain concept, though it does not explicitly contrast itself with related DoE siblings like covadoe_optimize or covadoe_find_optimum.
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 gives no indication of when to use this tool versus alternatives such as covadoe_find_optimum, covadoe_optimize, or covadoe_predict. There are no prerequisites, no conditions, and no exclusions stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find optimal factor settings for a single response.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | No | maximize | |
| model | Yes | ||
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full disclosure burden, yet it says nothing about how the optimization is performed, whether it is read-only, what happens if the model is unfitted, or how api_key/model interact. The only behavioral hint is the single-response scope.
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 short, front-loaded, waste-free sentence — structurally fine. The problem is under-specification rather than verbosity, so it earns only a middling score: nothing could be cut, but far more should be there.
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 tool with a required nested object and no parameter documentation, the description leaves the agent guessing about inputs; the existence of an output schema excuses it from explaining return values, but the input side remains unexplained. The gap is not compensated by annotations, since none are provided.
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 3 parameters, including a required nested 'model' object and a 'goal' string with a default of 'maximize'. The description adds no meaning for any of them — it never explains what shape 'model' must take, what 'goal' values are accepted, or what api_key is for.
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 gives a specific verb and object ('Find optimal factor settings') and scopes it to 'a single response', which implicitly separates it from a multi-response optimizer sibling such as covadoe_optimize. It stops short of naming that alternative, leaving the agent to infer the boundary from the word 'single'.
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 versus covadoe_optimize, covadoe_predict, or covadoe_fit_rsm, and no prerequisites such as needing a previously fitted model. The 'single response' phrase is the only usage signal and it is never made explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fit a response surface model (quadratic RSM).
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | ||
| api_key | No | ||
| response | Yes | ||
| model_terms | No | quadratic | |
| factor_columns | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It says nothing about the presence of an api_key parameter (implying a networked/credited call), rate limits, whether the fit is deterministic, error behavior on malformed data, or how the model is returned.
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 no filler, which is structurally sound. However, it is underwritten for a five-parameter statistical modeling tool, so the brevity reflects under-specification rather than discipline.
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 described. But with no annotations, 0% parameter coverage, an api_key parameter, and no usage or prerequisite context, the definition is not sufficient for an agent to invoke this tool correctly without external knowledge.
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 five parameters. The description hints at the 'response' input and the quadratic default for 'model_terms', but 'data', 'api_key', and 'factor_columns' are entirely undocumented in both schema and description, leaving the most important inputs (the dataset and factor specification) unexplained.
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 ('Fit') and resource ('response surface model'), with a parenthetical naming the model form. It does not distinguish itself from close siblings such as covadoe_analyze, covadoe_model_selection, or covadoe_ridge_analysis, so an agent cannot route confidently on this text alone.
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 when-to-use guidance, no prerequisites, and no mention of alternatives. An agent must guess whether to fit here versus running covadoe_analyze or covadoe_model_selection on the same design data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Select best model terms via stepwise, all-subsets, or hierarchical selection.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | ||
| method | No | stepwise | |
| api_key | No | ||
| response | Yes | ||
| factor_columns | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It does not say whether this is read-only or mutating, does not mention the api_key credential requirement visible in the schema, and does not describe cost, side effects, or whether it modifies the input design.
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 no filler; the core action leads and the method options follow. Appropriately sized for a tool whose remaining detail should live in schema/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?
An output schema exists, so return values need not be described. But with 5 parameters, 0% schema description coverage, and no annotations, the description is too thin for an agent to invoke the tool correctly with meaningful inputs.
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. The description only obliquely covers the 'method' parameter by naming the three strategies; 'data', 'response', 'factor_columns', and 'api_key' receive no explanation of expected format or role, so the description does not compensate for the coverage 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?
The description states a specific verb ('Select') and resource ('best model terms') and enumerates the three selection strategies, which is more than a tautology. However, it does not distinguish this from closely related DOE siblings such as covadoe_fit_rsm, covadoe_ridge_analysis, or covadoe_analyze, so an agent cannot route between them from the description alone.
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 when-to-use guidance, no prerequisite statement, and no mention of when one selection method is preferable to another or when to prefer this tool over the fitting/analysis siblings. The three method names are listed but not explained or tied to conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Multi-response optimization (desirability, Pareto, weighted sum).
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | ||
| method | No | desirability | |
| api_key | No | ||
| factor_columns | No | ||
| response_specs | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, yet it only names method options. It does not say what the tool returns, whether it mutates anything, what permissions or api_key are required, or how it handles missing factor columns for a statistical operation.
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?
It is extremely short and front-loads the core concept, which is structurally fine, but the brevity reflects under-specification rather than disciplined conciseness. A single unexplained fragment is insufficient for a 5-parameter tool.
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 described, but with zero annotation coverage, 0% parameter descriptions, and two required structural inputs, the definition leaves too much unresolved for an agent to invoke this statistical optimizer correctly.
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 must compensate and largely does not. Only the method parameter is indirectly clarified by the listed method names; data, response_specs (both required), factor_columns, and api_key remain entirely undocumented.
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 capability, multi-response optimization, and lists three method families (desirability, Pareto, weighted sum). However, it is a bare fragment with no verb-object framing and does nothing to distinguish it from the sibling covadoe_find_optimum, leaving the agent to guess which optimization tool applies.
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 when-to-use guidance, no prerequisites, and no mention of alternatives such as covadoe_find_optimum or covadoe_predict. The agent gets no signal about what problem this tool should be selected for versus its many DoE siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate plot data for DoE visualizations (14 plot types).
Analysis plots (need analysis_result, or design_data+response_col to auto-fit): main_effects,
interaction, pareto_effects, half_normal, normal_effects (signed Daniel plot; `alpha` sets the
reference threshold). Model plots (need model_result, or design_data+response_col): contour_2d,
surface_3d, residuals_4plot, prediction_profiler, cube_plot, ternary_mixture. Optimization plots:
desirability, pareto_front. `overlaid_contour` (sweet-spot / green-zone) takes `response_specs`
(list of {name, lower/upper}) + `factor_x`/`factor_y`; it fits one RSM per response from
design_data and returns the combined in-spec mask (`fixed_factors` pins the other factors).| Name | Required | Description | Default |
|---|---|---|---|
| alpha | No | ||
| api_key | No | ||
| factors | No | ||
| factor_x | No | ||
| factor_y | No | ||
| grid_size | No | ||
| plot_type | Yes | ||
| components | No | ||
| response_x | No | ||
| response_y | No | ||
| design_data | No | ||
| model_result | No | ||
| response_col | No | ||
| fixed_factors | No | ||
| response_specs | No | ||
| analysis_result | No | ||
| optimization_result | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose meaningful behavior: some plots auto-fit a model from design_data+response_col, and overlaid_contour fits one RSM per response and returns a combined in-spec mask while fixed_factors pins the other factors. It does not cover safety/permission profile or failure behavior, but the computational semantics are well surfaced.
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-loads the purpose then organizes content by plot category (analysis, model, optimization, overlaid_contour), which is efficient given 14 plot types. It is dense with parentheticals but nearly every clause carries a distinct instruction, with minimal 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?
An output schema exists, so return values need not be explained, and the description focuses appropriately on the plot-type/data-requirement matrix that determines a correct call. It is largely complete for the core task, though the unaddressed optional parameters and the absence of any auth/api_key note leave minor gaps for a 17-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 coverage is 0%, so the description must compensate and largely does: it gives meaning for alpha (reference threshold for normal_effects), response_specs (list of {name, lower/upper}), factor_x/factor_y, fixed_factors (pins other factors), and the design/model/analysis input params. Several params (grid_size, components, factors, response_x, response_y, api_key, optimization_result) remain opaque, so coverage is partial rather than complete.
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 ('Generate plot data for DoE visualizations') and immediately scopes it to 14 enumerated plot types, making it trivially distinguishable from sibling DoE tools like covadoe_fit_rsm or covadoe_analyze that are not plotting tools.
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?
Groups the 14 plot types and states the input each category requires (analysis plots need analysis_result or design_data+response_col to auto-fit; model plots need model_result; optimization plots), which effectively tells the agent how to invoke per plot type. It stops short of explicitly naming an alternative tool to use instead, but provides clear invocation context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Post-hoc power analysis from existing experiment.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | ||
| api_key | No | ||
| response | Yes | ||
| model_terms | No | linear | |
| factor_columns | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does not disclose data format requirements, permissions, whether the operation is read-only or mutating, or any rate limits, making behavioral disclosure essentially absent.
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 a single front-loaded sentence with no wasted words. Its brevity reflects under-specification rather than disciplined concision, but structurally it is efficient.
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 annotations, 0% schema description coverage, five parameters, and no parameter explanation in the description, the definition is not complete enough for an agent to invoke the tool correctly. The existence of an output schema does not offset the missing input and behavioral context.
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% for five parameters, yet the description says nothing about what 'data', 'response', 'model_terms', 'factor_columns', or 'api_key' should contain. It fails to compensate for the undocumented schema, adding no meaning beyond the 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 analysis type and data source ('Post-hoc power analysis from existing experiment'), which is more specific than a bare resource. However, it does not differentiate from sibling power tools such as covadoe_power_analysis or covadoe_design_power, so an agent cannot tell which to select without opening 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?
No when-to-use guidance, no alternatives, no prerequisites. The description only gives a one-line purpose statement, leaving the agent to infer the correct context among many covadoe_* design and power tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Statistical power ASSUMING AN ORTHOGONAL ±1 DESIGN — prefer covadoe_design_power.
Takes only scalars, so it never sees the design and cannot check its own premise. It uses
`ncp = n_runs · effect_size²`, which requires `(X'X)⁻¹_jj = 1/n_runs` — true for two-level
factorial and Plackett-Burman designs, and FALSE for a central composite, a Box-Behnken, a
definitive screening design, or a plain factorial WITH CENTRE POINTS.
On those it is wrong by a lot, and confidently: 0.8677 against a true 0.6228 on a Box-Behnken,
0.3874 against 0.2909 on a DSD, 0.3874 against 0.2491 on a 14-run factorial with centre points
(each Monte Carlo confirmed, 2026-08-07).
Use `covadoe_design_power` for ANY design carrying centre or axial points — it builds the design
and takes the non-centrality from `(X'X)⁻¹`, needs no data, and also reports what this tool would
have claimed. Use this one only when the design really is an orthogonal two-level design.
Every response carries `assumes_orthogonal_design: true` and a `validity` note.| Name | Required | Description | Default |
|---|---|---|---|
| alpha | No | ||
| n_runs | Yes | ||
| api_key | No | ||
| n_terms | Yes | ||
| effect_size | Yes | ||
| residual_variance | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden and does so unusually well: it discloses the internal formula (ncp = n_runs · effect_size²), the assumption that makes it valid ((X'X)⁻¹_jj = 1/n_runs), the fact that it cannot self-check its premise, quantified failure cases with Monte Carlo evidence, and the response fields it always emits (assumes_orthogonal_design, validity note). This is exactly the behavioral disclosure a numeric tool needs.
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 assumption and the sibling pointer, and every sentence serves the warning purpose. The three verbatim Monte Carlo comparisons with dates are arguably more evidence than an agent needs to act, which costs a point, but the density earns its space for a caveat-heavy tool.
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, and the description still flags the always-present assumes_orthogonal_design and validity fields. The main remaining gap is parameter-level meaning, which is left entirely to an undocumented 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 description coverage is 0% across 6 parameters, so the description must compensate. It implicitly clarifies n_runs and effect_size through the ncp formula, but n_terms, alpha, residual_variance and api_key are never defined or given units, defaults, or expected ranges. Partial compensation only.
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 first sentence names the exact operation (statistical power) and the precise modeling assumption it is built on (orthogonal ±1 design), and immediately contrasts itself with the sibling covadoe_design_power. An agent can distinguish it from every other covadoe_* power tool without opening a 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?
It states explicitly when to use it ('only when the design really is an orthogonal two-level design') and when not to (any design carrying centre or axial points), naming the alternative and the reason to prefer it. Conditions are concrete: CCC, Box-Behnken, DSD, factorial with centre points.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Predict response at given factor settings with CI and PI.
| Name | Required | Description | Default |
|---|---|---|---|
| alpha | No | ||
| model | Yes | ||
| api_key | No | ||
| settings | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions CI and PI output, but does not state that the operation is read-only, that a pre-fitted model is required, that authentication via api_key is needed, or any other behavioral trait such as error handling or side effects.
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 a single, front-loaded sentence with no wasted words. However, given the nested object parameters and required model input, it is arguably too terse to be fully helpful, missing even a minimal structured hint about prerequisites.
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?
The tool has four parameters including nested objects and an api_key, yet the description provides only a one-line purpose. It omits key context such as what the 'model' object should contain, what 'settings' represent, and how authentication works, though the presence of an output schema means return values need not be described.
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 four parameters. The description names 'factor settings' (settings) and implies a model is needed, but it says nothing about the 'alpha' significance level or the 'api_key' parameter, leaving half the parameters semantically undocumented in both schema and description.
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 ('Predict'), resource ('response'), and context ('at given factor settings'), and adds the interval types (CI and PI). It is clear what the tool does, but it does not explicitly differentiate itself from sibling tools like covadoe_fit_rsm or covadoe_optimize beyond the name.
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 use this tool versus alternatives, nor any stated prerequisites (e.g., requiring a fitted model from covadoe_fit_rsm). Usage is only implied by the phrase 'at given factor settings'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Residual diagnostics: normality (Shapiro-Wilk), Cook's distance, leverage.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | ||
| api_key | No | ||
| response | Yes | ||
| model_terms | No | linear | |
| factor_columns | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It lists the diagnostic statistics but says nothing about what inputs are required to run them (a fitted model? raw data plus terms?), whether anything is mutated, or what conditions cause failure. Listing test names is surface-level, not behavioral disclosure.
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 wastes no words. It is efficient, though its brevity comes partly from omitting necessary information rather than from disciplined editing.
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 described. However, for a 5-parameter statistical tool with 0% schema coverage and no annotations, the definition omits how to supply the model/data, what model_terms controls, and what factor_columns does. Key information an agent needs to call this correctly 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 0% across 5 parameters, so the description must compensate and does not. It never mentions data, response, model_terms, factor_columns, or api_key. At best, the mention of Cook's distance and leverage implicitly implies a regression model with a response and terms, but this is weak inference rather than parameter documentation.
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 the resource (residual diagnostics) and enumerates the specific analyses performed (Shapiro-Wilk normality, Cook's distance, leverage). This clearly distinguishes it from modeling siblings like covadoe_fit_rsm or covadoe_ridge_analysis, which build models rather than diagnose them. It lacks an explicit verb (compute/run), but the content is specific enough to act on.
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 about when to use this tool versus alternatives such as covadoe_model_selection or covadoe_analyze, and no stated prerequisites (e.g., that it operates on an existing fitted linear model). The agent must infer the entire workflow context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ridge / steepest-ascent path of a quadratic RSM (Draper; Myers & Montgomery).
When the unconstrained optimum is a saddle or sits outside the studied region, this traces the
locus of best predicted response on spheres of increasing radius around the design center — the
direction to run the next experiments. Pass a fitted `model` (from fit_rsm) OR raw `data` +
`response` to auto-fit one. Returns the eigenvalue nature, stationary point, and the ridge `path`
(radius, real-unit settings, predicted response ± CI) ending at `recommended_settings`.| Name | Required | Description | Default |
|---|---|---|---|
| data | No | ||
| goal | No | maximize | |
| model | No | ||
| api_key | No | ||
| n_steps | No | ||
| response | No | ||
| include_ci | No | ||
| max_radius | No | ||
| factor_columns | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose what the computation does and returns (eigenvalue nature, stationary point, path ending at recommended_settings). It omits operational behavior such as the role of api_key/auth, how n_steps or max_radius affect the trace, and goal direction handling, 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 tight paragraphs: the first gives method and when-to-use, the second gives input/output contract. No waste, though the last sentence is somewhat long and partly duplicates what the output schema already conveys.
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 9-parameter, zero-required, compute-heavy tool with an output schema, the description covers the critical invocation modes and the return shape. The gaps are the undocumented secondary parameters and auth behavior, which an agent could stumble on.
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 0%, so the description must compensate. It explains model, data, and response well, but leaves goal, api_key, n_steps, include_ci, max_radius, and factor_columns entirely undocumented; the remaining titles/defaults are only weakly self-explanatory. Partial compensation, not full.
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 method (ridge / steepest-ascent path of a quadratic RSM) with citations, and clearly distinguishes it from fit_rsm (which produces the model) and the plain-optimum siblings by framing it as the tool for saddle/out-of-region cases. An agent can identify the resource, method, and scope 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?
It states the exact triggering condition — 'when the unconstrained optimum is a saddle or sits outside the studied region' — and offers two explicit invocation paths ('Pass a fitted model ... OR raw data + response to auto-fit one'). This is a genuinely routing-quality guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recommend a design type based on number of factors and goal.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | No | screening | |
| api_key | No | ||
| n_factors | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It states only that it recommends a design type from two inputs, without disclosing what design types are possible, what goal values are accepted, whether the recommendation is deterministic, or what role api_key plays.
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 a single front-loaded sentence with no wasted words. It is arguably too terse for a 3-parameter tool, but structurally it is clean and immediately states the core action.
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 described. However, with no annotations, 0% schema description coverage, and three parameters, the description omits necessary context about parameter meaning, usage conditions, and behavioral constraints, leaving the definition incomplete.
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%, so the description must compensate. It names 'number of factors' and 'goal' but adds no semantics such as valid ranges for n_factors, allowed goal values, or any explanation of api_key, leaving two of three parameters effectively undocumented.
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 ('Recommend') and resource ('design type') with the inputs ('number of factors and goal'). It is clear enough to distinguish from siblings like covadoe_create_design or covadoe_augment_design, but it never explicitly names or contrasts those alternatives.
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 gives no when-to-use or when-not-to-use guidance, and it does not mention any alternative tools. The only usage signal is implicit in the inputs ('based on number of factors and goal'), which is insufficient routing guidance among many covadoe_* design tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Taguchi robust-design analysis: signal-to-noise ratios + main effects on the S/N.
Computes the S/N ratio per run and the factor-level S/N means to find the most robust setting.
`sn_type` selects the ratio ("larger_better"|"smaller_better"|"nominal_better"); if omitted it is
inferred from `response_goal` ("maximize"|"minimize"|"target"). Returns per-factor S/N tables,
the recommended robust level per factor, and a delta/rank contribution ordering.| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | ||
| api_key | No | ||
| sn_type | No | ||
| response | Yes | ||
| response_goal | No | ||
| factor_columns | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries the full behavioral burden. It usefully discloses the sn_type/response_goal inference logic and the shape of the output, but says nothing about required data structure, permissions, or computational limits. Adds real value but leaves notable behavioral gaps.
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 tight sentences, purpose front-loaded before the parameter and return details. No filler; every clause carries information.
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?
The presence of an output schema makes the return-value listing somewhat redundant, while the 6-parameter tool with 0% schema description coverage still leaves the data/response/factor_columns contract underspecified. Adequate but with clear gaps for a tool this parameter-heavy.
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 0%, so the description must compensate. It explains sn_type values and its fallback to response_goal, which is genuinely useful, but leaves data, response, factor_columns, and api_key entirely undocumented in both schema and description.
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 method (Taguchi robust-design analysis) and the concrete computation (S/N ratios + main effects). The Method name is unique among the covadoe_ sibling set (analyze, fit_rsm, optimize), so an agent can distinguish it 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?
The description conveys that this is for Taguchi designs, implying usage context, but never states when to pick this over covadoe_analyze or covadoe_fit_rsm, nor any prerequisite about the design/data format. Usage must be inferred from the method name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Annotate IR spectrum with known molecular structure (SMILES).
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| smiles | Yes | ||
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It says only that the tool annotates an IR spectrum with a known structure and does not disclose side effects, authentication needs (api_key), processing behavior, or what 'annotate' actually entails operationally.
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 a single front-loaded sentence with no filler. It is efficient, though arguably too terse for the tool's complexity.
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?
The existence of an output schema means return values need not be described, but the description remains inadequate for a three-parameter tool with no annotations and 0% schema description coverage. It omits essential operational details such as what path represents, whether api_key is required, and how annotation is performed.
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%, so the description must compensate for all three parameters. It mentions SMILES as the molecular structure but does not explain the required 'path' parameter (spectrum file?) or the optional 'api_key', nor does it state accepted SMILES or path formats.
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 ('Annotate'), resource ('IR spectrum'), and the required structural input ('known molecular structure (SMILES)'). It is clear what the tool does at a high level, but it does not distinguish itself from IR siblings such as covair_identify, covair_verify, or covair_auto_analyze.
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 choose this tool over alternatives like covair_identify or covair_predict_ir. No prerequisites or exclusions are mentioned, leaving the agent to infer usage entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full IR analysis in one call: load, optimize processing, detect peaks, report.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| smiles | No | ||
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden; it does disclose the observable pipeline stages (load, optimize processing, detect peaks, report), which helps an agent understand what will happen. However, it says nothing about the required api_key/authentication, cost, or side effects of running a full analysis, leaving real behavioral gaps.
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 zero filler; the pipeline stages are compactly ordered. It is lean, though the terseness is partly what leaves parameters and routing unexplained.
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 described, but with three fully undocumented parameters and no annotations the description should do more. It also fails to position this pipeline against the many sibling covair step tools an agent must choose between.
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 three parameters (path, smiles, api_key). The description never mentions any of them – not that path is required, that smiles is an optional alternative input, or that api_key handles auth. Nothing compensates for the undocumented 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?
It names a specific verb and resource ('Full IR analysis') and clarifies the tool is an end-to-end pipeline by enumerating the internal steps (load, process, detect peaks, report). It does not differentiate itself from close siblings such as covair_process or covair_batch, so it falls 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?
The phrase 'in one call' hints that this is the convenience wrapper versus the granular siblings, but there is no explicit 'use this when…' guidance and no named alternative. An agent must infer when to pick this over covair_process or covair_quality_check.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Batch-process all IR spectra in a folder with auto-optimized parameters.
| Name | Required | Description | Default |
|---|---|---|---|
| folder | Yes | ||
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, and it says nothing about what 'auto-optimized parameters' actually does, whether processing overwrites inputs, how errors on individual spectra are handled, or how long a batch runs. The schema exposes an api_key parameter with an empty default, but the description never states whether authentication is required or optional.
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 no filler, stating the operation and its scope immediately. It is efficient, though its brevity is partly under-specification rather than disciplined concision.
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, but for a folder-wide batch processing tool with no annotations and 0% schema coverage the description is too thin. It omits the api_key parameter, failure semantics for a batch, and any distinction from the single-spectrum siblings.
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%, so the description must compensate, and it only loosely implies the 'folder' parameter while adding nothing about path format, recursion, or file-type expectations. The api_key parameter is never mentioned at all, leaving its role and whether it is required completely unexplained.
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 ('batch-process all IR spectra in a folder') with a scope qualifier (batch, folder-wide). It does not distinguish itself from near siblings such as covair_process or covair_auto_analyze, so an agent cannot tell from the text alone which of these to pick for a single spectrum versus a folder.
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 when-to-use or when-not-to-use guidance. With siblings named covair_process, covair_auto_analyze and covnmr_batch in the same namespace, the description never says that this tool is the folder/multi-file variant or what the alternatives are for single-spectrum work.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare two IR spectra: correlation, distance, verdict.
| Name | Required | Description | Default |
|---|---|---|---|
| path_a | Yes | ||
| path_b | Yes | ||
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing: it does not say whether paths point to raw files, processed spectra, or identifiers; whether an API key is required (the default-empty api_key param hints at auth but is unexplained); or whether the operation is read-only. The output preview (correlation, distance, verdict) is the only real disclosure, and the output schema already covers return values.
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?
It is a single front-loaded line with no filler, but the brevity is under-specification rather than economy — the colon list substitutes for explanation of inputs and semantics.
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 described, but for a three-parameter tool with no annotations and 0% schema coverage the description is far too thin. Input format, auth expectations, and when to reach for this tool over its siblings are all 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 0% and there are three parameters, none of which the description mentions. It never explains what path_a and path_b accept (file paths? spectrum strings?) nor the role of api_key, so the agent gets no help beyond bare property 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?
The fragment names a specific verb (compare) and resource (two IR spectra) and previews the outputs (correlation, distance, verdict), so an agent knows this is an IR spectral comparison rather than a generic compare. It does not distinguish itself from near-name siblings like covnmr_compare or covauv_compare, but the 'IR spectra' qualifier is enough to disambiguate within the covair_* family.
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 versus covair_identify, covair_verify, or covair_auto_analyze, and no prerequisites are given. The agent must infer the use case entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Identify unknown IR spectrum: functional groups, substance class, contaminants.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| api_key | No | ||
| library_path | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, and it discloses almost nothing behavioral. It does not say whether the spectrum is read from a file or supplied another way, whether a reference library or api_key is required, whether results are ranked, or what happens when no match is found.
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 output list; every word is doing work and the action is stated first. It is terse to the point of under-specification, but there is no filler to trim.
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, but for a three-parameter tool with zero annotation coverage and 0% schema description coverage the definition is far too thin. Nothing explains the auth/API-key requirement, the optional library override, or the input format, leaving the agent unable to call it correctly without guessing.
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 three parameters (path, api_key, library_path), and the description supplies no parameter-level information. The phrase 'unknown IR spectrum' only loosely implies that 'path' points to a spectrum file; the roles of api_key and library_path are completely undocumented.
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 ('Identify unknown IR spectrum') and enumerates the outputs it produces (functional groups, substance class, contaminants). It is clear what the tool does, but it never distinguishes itself from IR siblings such as covair_annotate, covair_auto_analyze, or covair_predict_ir.
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 is given: nothing says when identification is preferable to annotation, verification, or quality checking, nor when a full pipeline (covair_auto_analyze) should be used instead. The agent must infer usage entirely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Predict expected IR absorption bands from SMILES string.
| Name | Required | Description | Default |
|---|---|---|---|
| smiles | Yes | ||
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, yet it discloses almost nothing beyond the core action. It does not state whether the api_key is required for the call to succeed, whether predictions are deterministic, or the underlying model's limits; an output schema exists but that only covers return shape, not call behavior.
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 no filler, stating the action and input up front. It is efficient, though its brevity contributes to the missing contextual detail rather than being purely a virtue.
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?
Because an output schema exists, return values need not be explained, which covers part of the completeness burden. However, for a tool with no annotations and a completely undocumented api_key parameter, the description leaves meaningful gaps about authentication and invocation context.
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% and there are two parameters. The description only implies the 'smiles' input and says nothing about 'api_key' (its purpose, whether it is needed, or how authentication works), so it fails to compensate for the undocumented 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 ('predict'), a specific resource ('IR absorption bands'), and the input modality ('SMILES string'), which clearly separates it from identify/annotate/process siblings. It does not explicitly name or contrast with the other prediction-style siblings, but the verb+resource pairing 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?
No guidance on when to use this versus covair_identify, covair_annotate, covair_process, or other covair tools. There is no mention of prerequisites such as needing a valid SMILES or the api_key, and no exclusions 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.
IR analysis with explicit processing parameters (baseline + normalization).
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| api_key | No | ||
| baseline | No | airpls | |
| normalize_method | No | minmax |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that a baseline correction and a normalization step are applied, which is real procedural information, but it says nothing about whether the operation mutates state, what the api_key implies (auth requirement), how long it takes, or how failures surface.
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 compact sentence with no filler, so it is concise, but the brevity comes at the cost of substance rather than from efficient front-loading of necessary detail.
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 described. However, for a 4-parameter tool with zero schema documentation and no annotations, the description leaves auth, parameter values, and method selection 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 0%, so the description must compensate. It names only two of the four parameters (baseline, normalization) and gives no valid values despite the schema defaults airpls and minmax; path and api_key are entirely unexplained.
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?
"IR analysis with explicit processing parameters (baseline + normalization)" states a resource (IR spectra) and gestures at a distinct scope (preprocessing with explicit parameters), but "IR analysis" alone is broad and does not clearly separate it from siblings like covair_analyze, covair_auto_analyze, covair_identify, or covair_predict_ir. The parenthetical is the only differentiating signal.
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 explicit when-to-use statement. The word "explicit" faintly implies a contrast with covair_auto_analyze (which presumably picks parameters automatically), but this alternative is never named and no conditions or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Assess IR spectrum quality: S/N, water vapor, CO2, saturation, grade.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses what is measured (S/N, water vapor, CO2, saturation, grade), which hints at a non-destructive read operation, but it never states that it is read-only, whether it needs a valid IR file, or what the api_key requirement entails.
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 no filler, listing the checked dimensions efficiently. It is terse to the point of under-specification, but no sentence is wasted.
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, and the purpose plus QC dimensions are covered. However, with two parameters at 0% schema coverage and zero usage guidance, the definition is not complete enough for an agent to invoke it confidently.
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% and the description mentions neither parameter. The required 'path' is never explained (what file type, what format), and 'api_key' is not addressed at all, so the description does not compensate for the coverage 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?
States a specific verb ('Assess') and resource ('IR spectrum') plus the concrete quality dimensions checked (S/N, water vapor, CO2, saturation, grade). That clearly separates it from siblings like covair_process, covair_compare, and covair_predict_ir, though it never names those alternatives.
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 prerequisites, and no routing to alternatives such as covair_verify or covair_process. The agent must infer from the name alone that this is a pre-analysis QC step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a structure against a measured IR spectrum: verdict, band recall, and what is left unexplained.
Pass `path` whenever you have the spectrum file. The curve is baseline-corrected
and normalised the way covair_auto_analyze does it, and the verdict then requires
two things: that the structure's expected bands were found AND that the structure
accounts for the absorption actually measured. With neither a `path` nor peaks
there is nothing to verify against and the verdict is `no_evidence` -- not
`inconsistent`, which would assert evidence against the structure where none was
supplied. With peaks but no curve, `verdict_basis` reads `peak_recall_only` and
the verdict cannot reach `consistent`.
Do NOT read a verdict off `match_score`. It is the fraction of the CANDIDATE's own
expected bands that were found, so the denominator belongs to the candidate and a
structure predicting few bands scores high on any spectrum. Measured on a real
aspirin spectrum: hexane, which contains no oxygen, scores 1.00 where aspirin
scores 0.92, because all four of hexane's expected bands are C-H. Read `match_score`
with `n_expected_bands` beside it; `band_recall_verdict` shows what recall alone
would have concluded, and `verdict_note` says in words why the verdict differs.
Two measured limits. This blocks the "explains almost nothing" class, not wrong
structures in general -- nitrobenzene still reads `consistent` against an aspirin
spectrum. And on featureless input the unexplained-absorption test collapses onto
its chance level, so a broad candidate can pass on noise; check
`claimed_axis_fraction` in that case.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | ||
| smiles | Yes | ||
| api_key | No | ||
| tolerance_cm | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so: it explains verdict semantics (no_evidence vs inconsistent), the peak_recall_only limitation, the match_score denominator trap with a concrete aspirin/hexane example, and two explicitly measured limits including chance-level collapse on featureless input. This is unusually rich behavioral disclosure.
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?
Long but front-loaded: verdict scope first, then input handling, then the match_score warning, then limits. Every section carries actionable content, though the match_score paragraph is dense enough to be tightened 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?
An output schema exists, yet the description goes further and explains how to read the returned fields (match_score, n_expected_bands, band_recall_verdict, verdict_note, claimed_axis_fraction), which is genuinely helpful. The remaining gap is the missing/phantom `peaks` parameter and undocumented tolerance_cm, which leaves the invocation surface incompletely specified.
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 0%, so the description must compensate, but it only clarifies `path` and never explains `smiles`, `tolerance_cm`, or `api_key`. Worse, it repeatedly discusses a `peaks` input that does not appear in the schema, which could mislead an agent about the actual call signature.
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 ('Verify a structure against a measured IR spectrum') and enumerates the outputs (verdict, band recall, unexplained absorption). It also implicitly distinguishes itself from covair_auto_analyze by noting the curve is corrected 'the way covair_auto_analyze does it', so an agent can place it relative to siblings.
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 clear input-conditional usage: 'Pass `path` whenever you have the spectrum file', and spells out the degraded modes (no path/peaks -> no_evidence; peaks only -> peak_recall_only and consistent unreachable). It does not, however, route the agent between covair_verify and siblings like covair_identify or covair_compare when the structure itself is unknown.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full automated analysis of an unknown MS/MS spectrum (quality + processing + identify + classify + annotate).
| Name | Required | Description | Default |
|---|---|---|---|
| peaks | Yes | ||
| adduct | No | [M+H]+ | |
| api_key | No | ||
| databases | No | ||
| index_path | No | ||
| library_dirs | No | ||
| precursor_mz | Yes | ||
| tolerance_ppm | No | ||
| max_candidates | No | ||
| ionization_mode | No | positive | |
| scoring_backend | No | hybrid | |
| processing_steps | No | ||
| enable_processing | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does not disclose that analysis may hit external databases/API (implied by the api_key parameter), whether it is slow or billable, what happens when databases/index_path are omitted, or how errors/rate limits surface. 'Full automated' conveys sequencing but no operational traits.
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 the pipeline stages parenthetically summarized; no filler. However, given the tool's complexity, the terseness borders on under-specification rather than economy.
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 need not be explained, but for a 13-parameter pipeline with no annotations and zero schema descriptions, the description leaves the agent without prerequisites, defaults behavior, or the meaning of key knobs. It is not sufficient to call this tool safely.
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 13 parameters, and the description adds no parameter meaning at all — api_key, databases, index_path, library_dirs, scoring_backend, tolerance_ppm, ionization_mode, processing_steps, and enable_processing are all left opaque. Low-coverage schemas require the description to compensate, and here it does not.
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+resource ('analyze_unknown' of an MS/MS spectrum) and decomposes it into the composed stages (quality + processing + identify + classify + annotate), which tells the agent this is a composite pipeline rather than a single-purpose operation. It does not explicitly distinguish itself from the siblings it wraps (covams_identify, covams_process_spectrum, covams_spectral_quality, covams_fragment_annotate), 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?
The word 'unknown' implies a use case, but there is no explicit when-to-use, when-not-to-use, or direction to the individual sibling tools for a targeted single-step call. An agent cannot tell from this text whether to run the full pipeline or call covams_identify directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Predict compound class from MS/MS spectrum using diagnostic fragment rules.
| Name | Required | Description | Default |
|---|---|---|---|
| peaks | Yes | ||
| api_key | No | ||
| precursor_mz | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the method ('diagnostic fragment rules') but says nothing about authentication (the api_key parameter), input format expectations, limitations, or what happens if no class is matched. This is a significant gap for a prediction tool with zero structured behavioral hints.
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 a single front-loaded sentence with no wasted words. Its brevity is appropriate in form, though it is arguably too sparse given the tool's complexity – but the conciseness dimension itself is well satisfied.
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?
Given three undocumented parameters, no annotations, and a non-trivial prediction task, the description is far too thin. It does not explain input formats, required api_key semantics, or limitations. The presence of an output schema reduces the need to describe return values, but the input side remains largely unexplained.
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?
The schema description coverage is 0% and the description does not mention any of the three parameters (peaks, precursor_mz, api_key). Critical details such as the expected format of 'peaks', whether precursor_mz is in Da or m/z, and the purpose of api_key are entirely absent. The description adds no meaning beyond the bare 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?
The description states a specific verb ('Predict'), resource ('compound class'), and input ('MS/MS spectrum'), plus a method ('diagnostic fragment rules'). It distinguishes itself from siblings like covams_identify or covams_fragment_annotate by focusing on classification rather than identification or annotation, 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?
The description gives no guidance on when to use this tool versus siblings such as covams_identify or covams_analyze_unknown. It implies the input is an MS/MS spectrum but provides no context about appropriate use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Predict degradation products for an API molecule.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| pathways | No | ||
| api_smiles | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It implies a non-destructive prediction computation from the verb 'predict,' but says nothing about authentication (api_key is a parameter), rate limits, cost, or what the prediction actually produces.
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 a single front-loaded sentence with no wasted words. It is structurally clean, though its brevity is also the source of the missing information captured in other dimensions.
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 3-parameter tool with no annotations and 0% schema description coverage, the description is far too sparse. An output schema exists, so return values need not be explained, but parameter meaning and usage context are still 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 0%, and the description does not explain any of the three parameters. It does not clarify that api_smiles is the required input, what the optional pathways array controls, or why api_key exists.
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: predict degradation products for an API molecule. This is clear and actionable, but it does not differentiate itself from nearby siblings such as covams_forced_degradation or covams_impurity_profiling.
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 use this tool versus alternatives, nor any prerequisites or exclusions. The one-line description implies a computational prediction task but leaves the agent to infer all routing decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect LC-MS features (m/z + retention time + intensity + charge) from a whole mzML/mzXML run.
Unlike the peak-list MS tools, this takes the RAW LC-MS FILE by reference
(path = a signed URL or local path) and returns EVERY detected feature, not
one collapsed spectrum — the entry point for untargeted metabolomics. Uses
pyOpenMS FeatureFinderMetabo when available, else a scipy m/z-binning
fallback (the response's method_used field reports which ran).| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| api_key | No | ||
| noise_threshold | No | ||
| min_trace_length | No | ||
| mass_trace_mz_tolerance | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden, and it does well: it discloses that the file is taken by reference (signed URL or local path), that ALL features are returned rather than one spectrum, and that the backend silently falls back from pyOpenMS FeatureFinderMetabo to a scipy binning method with method_used reporting which ran. It omits runtime/compute cost, file size limits, and whether api_key is required for this call.
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 sentences, front-loaded with the action and payload, then the differentiator, then the implementation detail. No filler and every sentence adds decision-relevant information.
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 structure need not be explained, and the description usefully flags the method_used field. The remaining gap is the undocumented numeric tuning parameters, which matter for a feature-detection tool where sensitivity depends on them.
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 must compensate and it only explains 'path' (signed URL vs local path). The three tuning knobs (noise_threshold, min_trace_length, mass_trace_mz_tolerance) and api_key get no guidance at all, leaving an agent unable to reason about units or sensible ranges.
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 ('Detect LC-MS features') plus the exact payload (m/z + retention time + intensity + charge) and input format (whole mzML/mzXML run). It explicitly distinguishes itself from the peak-list MS siblings and identifies its niche ('entry point for untargeted metabolomics'), so an agent can tell it apart from covams_process_spectrum or covams_analyze_unknown.
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?
Strong contextual routing: it says what it is for (untargeted metabolomics entry point) and contrasts itself against 'the peak-list MS tools' that collapse to one spectrum. It stops short of naming the specific alternative tool an agent should call instead when it already has a peak list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Screen sample peaks against known extractable/leachable (E&L) compounds.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| sample_peaks | Yes | ||
| container_type | No | glass |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden but only implies a read-only screening operation. It does not state what reference set is used, whether the screen is exact or tolerance-based, what the container_type default of 'glass' actually changes, or that api_key is needed.
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?
It is a single front-loaded sentence with no waste, so it is concise. But that brevity comes at the cost of under-specification rather than disciplined editing.
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, but the tool has three undocumented parameters, no usage guidance, and no behavioral detail, which is inadequate for a domain-specific screening tool in a crowded sibling set.
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% for 3 parameters, and the description adds nothing: it never explains the required sample_peaks format or the role of the container_type parameter beyond its 'glass' default. The undocumented parameters are left entirely unaddressed.
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 gives a specific verb and resource: it screens sample peaks against a known extractable/leachable (E&L) compound set, which is a distinct operation from generic identification cousins like covams_identify or covams_search_db. It does not, however, explicitly name how it differs from those sibling tools.
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 versus alternatives such as covams_identify, covams_search_db, or covams_impurity_find. An agent must infer the E&L-specific use case (packaging/container leachables) from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run forced degradation study across multiple stress conditions (ICH Q1A/Q1B).
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| api_smiles | Yes | ||
| stress_data | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, and it discloses almost nothing beyond the headline action. It does not say what the stress conditions are, what 'stress_data' must contain, whether an api_key/authentication is required, or what the study returns. Only the ICH citation hints at expected behavior.
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 no filler; the action is stated immediately. It is appropriately sized, though its brevity reflects under-specification rather than disciplined economy.
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?
This is a domain-complex tool with a nested input object, 0% schema coverage, and no annotations, so the description needs to do far more work than one sentence. An output schema exists, so return values need not be covered, but stress-condition semantics, required inputs, and auth expectations are all 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 0% for three parameters, including a nested free-form object ('stress_data' with additionalProperties true), so the description must compensate and does not. It never explains api_smiles, api_key, or the expected shape/keys of the stress data object; ICH Q1A/Q1B is the only indirect hint.
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 ('run forced degradation study'), and the ICH Q1A/Q1B parenthetical signals the regulatory framing. It does not differentiate from close siblings such as covams_degradation_predict or covams_impurity_profiling, so an agent cannot tell which to pick from the description alone.
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, and no mention of the sibling alternatives (covams_degradation_predict, covams_impurity_find) that clearly overlap. The ICH reference only implies a regulatory context; it does not tell the agent when this tool is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve molecular formula candidates from a measured m/z value.
| Name | Required | Description | Default |
|---|---|---|---|
| adduct | No | [M+H]+ | |
| api_key | No | ||
| measured_mz | Yes | ||
| tolerance_ppm | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does not disclose how adduct or tolerance affect the search, whether an API key is required for authentication, rate limits, or that multiple candidates may be returned ranked.
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 zero filler, which is efficient. However, that brevity comes at the cost of under-specification for a four-parameter tool rather than being genuinely complete.
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. But with no annotations, 0% parameter coverage, and undocumented adduct/tolerance semantics, the definition is too thin for an agent to invoke this confidently without guessing at defaults and behavior.
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%, and the description only implicitly touches measured_mz. It adds no meaning for adduct (default [M+H]+), tolerance_ppm (default 5), or api_key, leaving three of four parameters undocumented in both schema and text.
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 ('Resolve') and resource ('molecular formula candidates') with the input ('measured m/z value'). This distinguishes it from siblings like covams_isotope or covams_fragment_predict, but it does not explicitly name or contrast with those alternatives.
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 description's phrasing - an agent can infer it applies when it has an m/z value and wants formula candidates. There is no explicit when-to-use, when-not-to-use, or mention of alternatives like covams_identify or covams_search_db.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Annotate measured MS/MS peaks against predicted fragments for a structure.
| Name | Required | Description | Default |
|---|---|---|---|
| peaks | Yes | ||
| smiles | Yes | ||
| api_key | No | ||
| tolerance_ppm | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does not state whether this requires a license/api_key, whether it is a pure computation or a server call, how peaks input should be formatted, or how tolerance is applied. Only the basic transformation is conveyed.
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 no filler, immediately establishing verb and resource. Appropriately sized, though its brevity is partly under-specification rather than economy.
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, but for a 4-parameter tool with 0% schema coverage and no annotations the description is too thin: input formats, the tolerance parameter, and authentication are all 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 0%, so the description must compensate. It only loosely implies that 'structure' maps to smiles and 'measured peaks' maps to peaks; it says nothing about api_key or tolerance_ppm, and gives no format/syntax for the peaks array.
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 (annotate) and resource (measured MS/MS peaks against predicted fragments for a structure), which clearly distinguishes it from sibling covams_fragment_predict (prediction) and covams_process_spectrum. Clear but does not explicitly name the alternative it differs from.
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, and no mention of the natural alternative covams_fragment_predict when the agent needs fragments generated rather than labeled. The agent must infer the workflow context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Predict MS/MS fragmentation spectrum from a SMILES structure.
| Name | Required | Description | Default |
|---|---|---|---|
| adduct | No | [M+H]+ | |
| smiles | Yes | ||
| api_key | No | ||
| collision_energy | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing. It does not say the prediction is model-based, how adduct or collision energy affect output, whether an api_key is required for calls to succeed, or any latency/rate behavior.
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 zero filler. It is efficient, though the brevity shades into under-specification rather than tightness.
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 described, but with no annotations, 0% parameter coverage, and four parameters, the definition leaves an agent unable to call the tool confidently. Critical context about adduct/energy semantics and API key usage 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 0%, so the description must compensate for four undocumented parameters, yet it addresses only the SMILES input. The significance of adduct ([M+H]+ default), collision_energy (30 default), and api_key is left entirely unexplained.
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 (Predict) and resource (MS/MS fragmentation spectrum) with the input source (SMILES structure) named. It is clear what the tool does, but it draws no boundary against adjacent siblings such as covams_fragment_annotate or covams_predict_fingerprint, so an agent must infer which fragmentation tool applies.
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 use this tool versus the many neighboring covams_* alternatives, nor any stated prerequisites. The agent gets a capability statement but no context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Identify an unknown compound from MS/MS peaks and precursor m/z.
| Name | Required | Description | Default |
|---|---|---|---|
| peaks | Yes | ||
| adduct | No | [M+H]+ | |
| api_key | No | ||
| databases | No | ||
| index_path | No | ||
| enable_sota | No | ||
| library_dirs | No | ||
| precursor_mz | Yes | ||
| scoring_backend | No | hybrid |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full burden of behavioral disclosure, and it says nothing about whether identification queries a remote service, runs locally against library_dirs/index_path, costs credits, or requires api_key. For a 9-parameter identification tool spanning local indexes, external databases, and an SOTA scoring backend, this is a substantial disclosure gap.
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 tightly written sentence that front-loads the verb and the inputs with zero filler. It is efficient, though the brevity comes at the cost of coverage rather than being paired with additional useful detail.
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 described, but with 0% schema coverage and no annotations the description leaves the substantial configuration surface (databases, index_path, library_dirs, api_key, scoring_backend, enable_sota) unexplained. An agent cannot confidently construct a valid non-trivial call from this definition alone.
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%, and the description only names the two required parameters (peaks, precursor_mz), which are already marked required in the schema. Seven optional parameters — adduct, api_key, databases, index_path, enable_sota, library_dirs, scoring_backend — receive no explanation of format, defaults, or trade-offs anywhere.
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 ('Identify') and resource ('unknown compound') plus the two signal types consumed ('MS/MS peaks and precursor m/z'), so the agent immediately understands the tool's function. However, it does nothing to separate itself from near-identical siblings such as covams_identify_batch, covams_analyze_unknown, or covams_search_db, leaving the agent to guess which entry point applies.
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 when-to-use guidance, no mention of prerequisites such as needing an API key or a local index, and no routing to alternatives like covams_identify_batch for multiple spectra. The agent must infer the calling context entirely from the required parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Identify multiple spectra in parallel (batch mode for LC-MS/MS runs).
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| spectra | Yes | ||
| databases | No | ||
| enable_sota | No | ||
| max_workers | No | ||
| scoring_backend | No | hybrid |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. 'In parallel' hints at concurrency, but nothing states the effect of max_workers, what enable_sota or scoring_backend do, whether API credentials are required, or how failures in a batch are reported.
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 naming the operation, the batching behavior, and the domain. Nothing is padded and the key scoping detail comes first.
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, but for a 6-parameter tool with zero schema-coverage and no annotations the description is far too thin. An agent has no basis for choosing databases, tuning parallelism, or understanding scoring_backend.
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 6 parameters, so the description must compensate and largely does not. 'In parallel' loosely gestures at max_workers, but spectra, databases, enable_sota, scoring_backend, and api_key are left completely undocumented in both the schema and the description.
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 ('Identify') and resource ('multiple spectra') and clarifies the batch scope with 'batch mode for LC-MS/MS runs', which implicitly distinguishes it from the singleton covams_identify. It stops short of naming the single-spectrum sibling explicitly, so an agent must infer the pairing from the name.
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?
'batch mode for LC-MS/MS runs' implies the usage context (many spectra from one run) but gives no explicit when-to-use vs. covams_identify, no exclusions, and no prerequisite guidance. Usage is inferable but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find and identify impurities by matching against degradation products.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| api_smiles | Yes | ||
| unknown_peaks | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses that matching is done against degradation products, but says nothing about authentication (the api_key parameter), what happens when no match is found, confidence/reliability of matches, or any constraints on input peaks.
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 no filler or redundancy. It is efficient, though its brevity is partly a symptom of under-specification rather than disciplined concision.
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?
The existence of an output schema relieves the description of explaining return values, but that is the only relief. With zero schema coverage on three parameters, no annotations, and no usage guidance, the definition is too thin for an identification tool operating on structured peak input.
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% for all three parameters, so the description must compensate and does not. It never explains api_smiles (the API structure to match against), unknown_peaks (the peak data to be identified), or api_key, leaving their formats and roles undocumented.
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 gives a specific verb pair ('Find and identify') and resource ('impurities'), plus the matching mechanism ('against degradation products'). This clearly separates it from generic siblings like covams_identify or covams_analyze_unknown, though it never explicitly names an 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?
There is no statement of when to use this tool versus siblings such as covams_impurity_profiling, covams_degradation_predict, or covams_identify. The intended context is only weakly implied by the phrase 'matching against degradation products'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ICH Q3A/Q3B compliant impurity profiling with regulatory thresholds.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| api_smiles | Yes | ||
| batch_peaks | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds the useful context that thresholds follow ICH Q3A/Q3B guidance, but says nothing about the api_key authentication requirement, what is computed or returned, or how batch_peaks are processed. For an unannotated tool this is a significant gap.
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 single sentence is efficient and front-loaded, but it is under-specified rather than truly concise, packing regulatory jargon without actionable detail. Every word earns its place, yet too few words are present to guide invocation.
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 needn't be explained, but with three undocumented parameters, no annotations, and no usage context, the definition is inadequate for an agent to call this tool correctly. It supplies regulatory framing but not operational completeness.
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 all three parameters. The description adds no meaning for api_smiles, batch_peaks, or api_key, so the agent cannot tell what form the SMILES should take, what peak data is expected, or how the key is used. It fails to compensate for the coverage 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?
The description states a specific resource (impurity profiling) and its regulatory framing (ICH Q3A/Q3B with thresholds), so an agent knows this tool evaluates impurities against regulatory limits. However, it does not differentiate itself from close siblings like covams_impurity_find or covams_mass_balance, leaving ambiguity about which impurity tool to pick.
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 when-to-use guidance, no prerequisites, and no named alternative. The agent must infer from the name alone when profiling is appropriate versus covams_impurity_find or covams_degradation_predict.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Predict theoretical isotope pattern for a molecular formula.
| Name | Required | Description | Default |
|---|---|---|---|
| charge | No | ||
| api_key | No | ||
| formula | Yes | ||
| n_peaks | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It says 'predict theoretical' but doesn't state whether the result is deterministic, what units/charge conventions apply, or what the response contains. An output schema exists, which helps, but the preconditions (e.g., api_key requirement) are undisclosed.
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 no waste. Efficient, though the size reflects under-specification rather than deliberate brevity.
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 4-parameter tool with 0% schema coverage, no annotations, and no parameter guidance in the description, this is too thin. An api_key parameter suggests auth requirements that are never mentioned.
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 4 parameters. The description mentions 'molecular formula' (mapping to formula) but says nothing about charge, n_peaks, or api_key. The agent must infer these from bare 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 ('Predict') and resource ('theoretical isotope pattern') tied to a 'molecular formula'. Distinguishes it from siblings like covams_formula or covams_fragment_predict, though it doesn't name a specific 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?
No when-to-use guidance, prerequisites, or alternatives. Nothing tells the agent how this differs from covams_formula or covams_predict_fingerprint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate mass balance from API and impurity peak areas.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| api_area | Yes | ||
| impurity_areas | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosure. It does not say whether this is a pure calculation or a stored operation, whether api_key is required for authentication, what units the areas are assumed to be in, or what happens with malformed input. For a tool with zero annotation coverage, this is a notable gap.
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 no filler. It is efficient, though its brevity is partly under-specification rather than discipline.
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. Still, for a 3-parameter computational tool with 0% schema coverage and no annotations, the description omits units, the api_key/auth requirement, and the mass-balance convention assumed, leaving gaps an agent would need to guess at.
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%, so the schema contributes nothing. The description maps loosely onto api_area and impurity_areas but says nothing about the optional api_key, the accepted form of impurity_areas (array of numbers? pairs with names?), or units, so it only partially compensates for the coverage 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?
States a specific verb ('Calculate') and resource ('mass balance') and names the inputs that feed it (API and impurity peak areas), so an agent knows what operation it performs. It does not, however, differentiate itself from adjacent covams siblings like covams_impurity_profiling or covams_impurity_find, which also work on impurity data.
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 versus the many other covams_* tools, no prerequisites, and no exclusions. The agent is left to infer that this is the mass-balance calculator only from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Identify drug metabolites by mass shift matching (Phase I and Phase II).
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| drug_smiles | Yes | ||
| metabolite_peaks | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, and it discloses very little: only that matching is mass-shift based and covers Phase I/II transformations. It says nothing about required input formats, whether an api_key is needed, mass tolerance/adduct assumptions, or limitations of the approach.
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 tight sentence with no filler, and the key information (identification method and phase scope) is front-loaded. It is efficient, though its brevity is partly a symptom of missing detail rather than disciplined editing.
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 described, but for a 3-parameter tool with zero schema descriptions and no annotations, the definition omits critical call-time context: input formats, authentication, and matching assumptions. An agent could not reliably invoke this correctly from the description alone.
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 three parameters, so the description should compensate but does not. It never explains that drug_smiles expects a SMILES string or what the metabolite_peaks array should contain (formats, units, tolerance), leaving two required parameters effectively undocumented.
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 gives a specific verb (Identify) and a specific resource (drug metabolites) plus the underlying technique (mass shift matching) and scope (Phase I and Phase II). It is clear enough to distinguish from generic siblings like covams_identify or covams_identify_batch, though it never names those alternatives 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?
There is no indication of when to use this tool versus siblings such as covams_identify, covams_identify_batch, or covams_analyze_unknown, and no prerequisites or exclusions are stated. The agent must infer positioning from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Annotate neutral losses between precursor and fragment peaks.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| precursor_mz | Yes | ||
| fragment_peaks | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the operation but omits read vs write nature, permission requirements, rate limits, or any other behavioral trait. Output schema exists, but the description adds no further context.
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, compact sentence that is front-loaded and contains no wasted words.
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 specialized mass-spectrometry tool with no annotations and 0% schema coverage, the one-sentence description is insufficient. It lacks usage context and parameter details, though the output schema covers return values.
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%, so the description must compensate. It mentions precursor and fragment peaks, loosely mapping to the two required parameters, but gives no format, units, or array structure, and does not mention api_key. Compensation is minimal.
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 ('Annotate') and resource ('neutral losses between precursor and fragment peaks'). Clear what it does, but does not differentiate from sibling tools such as covams_fragment_annotate or covams_mass_balance.
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 guidance on when to use this tool versus alternatives. Usage is only implied by the domain terms (precursor and fragment peaks); no context or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Predict a molecular fingerprint (ECFP4-style bit probabilities) from an MS/MS spectrum.
A CSI:FingerID-style structural descriptor of the unknown, inferred from its
fragmentation. Useful as a scaffold-level fingerprint to compare against
candidate structures (see covams_search_by_fingerprint).| Name | Required | Description | Default |
|---|---|---|---|
| peaks | Yes | ||
| adduct | No | [M+H]+ | |
| api_key | No | ||
| precursor_mz | Yes | ||
| fingerprint_type | No | ecfp4_1024 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose the output's nature (bit probabilities, CSI:FingerID-style, fragment-derived), which is real added context, but says nothing about cost/latency, whether an api_key is required, or accuracy limits of an inferred fingerprint.
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 short sentences, purpose front-loaded, with the middle sentence earning its place by explaining the descriptor's provenance. No filler, though the trailing parenthetical reference is the only part doing routing work.
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-value shape need not be explained. However, for a 5-parameter tool with zero annotation and zero schema-description coverage, the description should at least sketch the peaks input format and the meaning of adduct/fingerprint_type; those gaps leave the agent guessing.
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, and the prose only obliquely addresses fingerprint_type via the phrase 'ECFP4-style'. The format expected for peaks (list of m/z-intensity pairs?), the role of adduct (default [M+H]+), and use of api_key are all left entirely undocumented in both schema and description.
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 ('Predict a molecular fingerprint... from an MS/MS spectrum') and immediately qualifies the output as ECFP4-style bit probabilities, which distinguishes it from the sibling covabasic_fingerprint (structure-based) and places it in the MS/MS branch of the toolset.
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 routes the agent downstream, saying the result is 'useful as a scaffold-level fingerprint to compare against candidate structures (see covams_search_by_fingerprint)'. That is a clear usage context, though it stops short of stating when this is preferred over covams_search_db or covams_identify directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Predict chromatographic retention time for a molecule.
| Name | Required | Description | Default |
|---|---|---|---|
| smiles | Yes | ||
| api_key | No | ||
| model_path | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, yet it discloses nothing about determinism, model selection, API-key requirements (the api_key param defaults to an empty string), or expected latency. It only restates the operation.
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 no filler or redundancy. It is efficient, though the brevity reflects under-specification rather than tight editing.
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-value explanation is not needed, but the description leaves usage context, the api_key/model_path parameters, and model-selection behavior entirely unexplained for a 3-parameter prediction 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 0% across 3 parameters. The word 'molecule' loosely implies the smiles input, but api_key and model_path are completely undocumented in both the schema and the description, so the description fails to compensate.
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 gives a clear verb and resource ('Predict chromatographic retention time'), which is distinct from sibling prediction tools like covams_predict_fingerprint or covair_predict_ir. It does not, however, differentiate itself from those siblings or clarify scope (e.g., which chromatography method or model).
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 when-to-use guidance, no prerequisites, and no reference to alternative prediction tools such as covams_predict_fingerprint. The agent must infer entirely from the tool name when this is the right call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pre-process an MS spectrum (smoothing, peak picking, deisotoping, normalization).
| Name | Required | Description | Default |
|---|---|---|---|
| peaks | Yes | ||
| steps | No | ||
| params | No | ||
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full behavioral burden, yet it only lists operation names. It does not disclose whether preprocessing mutates the input peaks, whether the steps run in a fixed or specified order, that an api_key parameter implies authentication, or any rate-limit/error behavior.
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 tight sentence with the verb and resource front-loaded and zero filler. It is appropriately sized, though its brevity reflects under-specification rather than genuine conciseness.
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 described, but the tool has 4 undocumented parameters, no annotations, and no usage guidance. For a non-trivial preprocessing tool, the description is far too thin to let an agent call it correctly.
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% for 4 parameters, so the description must compensate. The parenthetical 'smoothing, peak picking, deisotoping, normalization' loosely hints at the values for `steps`, but `peaks` format, the `params` object contents, and `api_key` are entirely unexplained in both schema and description.
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 ('Pre-process') and resource ('MS spectrum') and even enumerates the sub-operations, so the agent knows exactly what the tool does. However, it gives no differentiation from adjacent siblings like covams_detect_features or covams_spectral_quality, which an agent could easily confuse with a preprocessing step.
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 when-to-use, when-not-to-use, or alternative-tool guidance. The only clue is the implicit role of preprocessing in an MS pipeline, which the agent must infer. Among dozens of covams siblings, no routing information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Shorten a candidate list for an UNKNOWN spectrum — triage, not identification.
Predicts the query's fingerprint from its peaks and ranks each candidate
SMILES by Tanimoto agreement. The ranking rests only on the subset of bits
the predictor actually learned; the rest sit at an untrained 0.5 prior and
would otherwise order candidates by molecular size. That subset is a small
fraction of the fingerprint, so `bit_coverage` in the response is the
authoritative live number — read it, and the `warning` that accompanies a
low one, before acting on the order.
Measured on open structure retrieval against MassSpecGym candidate pools
(median 256 candidates): the correct structure comes first about 3.5 % of
the time, against a 2.4 % permutation noise floor. The lift is real but
roughly one percentage point, so the right answer is NOT at rank 1 in about
96 % of cases. Use it to cut a long candidate list down, never to name a
compound.
If you already suspect what the compound is, use covams_search_db instead:
matching the spectrum against the packaged 169k-spectrum library is a far
stronger signal, and dereplicating a known compound is the common case.| Name | Required | Description | Default |
|---|---|---|---|
| peaks | Yes | ||
| top_k | No | ||
| adduct | No | [M+H]+ | |
| api_key | No | ||
| precursor_mz | Yes | ||
| candidate_smiles | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, and it discharges most of it: the predictor only learned a subset of bits, untrained bits sit at a 0.5 prior, bit_coverage is the authoritative live number, and a warning accompanies a low value. It even quantifies reliability (correct first ~3.5% vs 2.4% noise floor). It stops short of noting auth (api_key) or performance limits, keeping it below 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?
It is long, but front-loaded with the core purpose and structured as purpose -> mechanism -> caveat -> evidence -> alternative. Given the misuse risk (being mistaken for identification), the sentences earn their place, though it could be tightened 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?
An output schema exists, so return values (including bit_coverage and warning) need not be re-explained, and the description references them appropriately. However, with 3 required and 6 total parameters at 0% schema coverage, the input contract is left under-specified, which is a real gap for a tool of this power.
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 6 parameters, so the description must compensate. It names 'candidate SMILES' and implies the query peaks, but gives no format or meaning for peaks, top_k, adduct, precursor_mz, or candidate_smiles. Most parameters remain undocumented in both schema and description.
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+resource and scope: 'Shorten a candidate list for an UNKNOWN spectrum — triage, not identification.' It also explicitly names what it is not (identification) and routes to the sibling covams_search_db, so an agent can distinguish it from alternatives without opening a 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?
Explicit when-to-use (cut a long candidate list for an unknown spectrum) and when-to-use-something-else ('If you already suspect what the compound is, use covams_search_db instead'). The condition that selects the alternative (dereplicating a known compound, 169k-library match) is spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search spectral databases for matching compounds by spectral similarity.
| Name | Required | Description | Default |
|---|---|---|---|
| peaks | Yes | ||
| api_key | No | ||
| databases | No | ||
| index_path | No | ||
| library_dirs | No | ||
| library_path | No | ||
| precursor_mz | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It does not disclose whether local libraries must be configured first, what the library_path/index_path parameters do, or what happens when no library is supplied. Return values are covered by the output schema, but operational behavior is not.
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 no wasted words. However, its brevity leaves too little information relative to the tool's 7-parameter complexity.
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 complex 7-parameter tool with no annotations, the description does not supply the missing behavioral or parameter context. The output schema handles return values, but the definition remains incomplete for correct invocation.
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 7 parameters, and the description explains none of them. Five optional parameters (api_key, databases, index_path, library_dirs, library_path) are wholly undocumented, so the description fails to compensate for the coverage 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?
States a specific verb (search) and resource (spectral databases) with the matching criterion (spectral similarity). It is clear what the tool does, but it never distinguishes itself from close siblings like covams_identify or covams_search_by_fingerprint.
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 versus the many sibling identification/search tools. No prerequisites, context, or alternatives are given, leaving routing entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Assess quality of an MS/MS spectrum (grade A through D).
| Name | Required | Description | Default |
|---|---|---|---|
| peaks | Yes | ||
| api_key | No | ||
| precursor_mz | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose that the output is a letter grade A–D, which is genuinely useful behavioral information, but says nothing about authentication expectations (an api_key parameter exists), the grading criteria at each boundary, or determinism. That leaves substantive behavioral gaps for a scoring tool.
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 no padding or repetition. It is efficient, though its brevity contributes to the gaps scored elsewhere.
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?
Because an output schema exists, the description need not explain return values, but the tool still has three completely undocumented parameters and no annotation coverage. One sentence is not sufficient context for correctly invoking a scoring endpoint.
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% and the description adds no parameter information at all. It never explains the expected shape of 'peaks' (e.g., m/z–intensity pairs), what precursor_mz contributes to the grade, or how api_key is used, so all three parameters remain undocumented.
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 ('Assess quality of an MS/MS spectrum') and names the output form (grade A through D), which clearly separates it from siblings like covams_identify or covams_process_spectrum. It does not explicitly name or rule out any sibling, but the purpose 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?
There is no when-to-use or when-not-to-use guidance and no mention of alternatives such as covams_process_spectrum or covams_fragment_annotate. Usage is only implied by the fact that a spectrum is required as input.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
SOLUBILITY PREDICTION — gradient-boosted model (ensemble_v12) trained on 115,862 experimental solubility rows (BigSolDB and other sources).
**Always use this tool when the user asks about solubility, log S, dissolution,
or "how much X dissolves in Y".** Much more accurate than the heuristic logS
in `covachem_profile` and explicitly accounts for the solvent (covachem only
gives intrinsic water-logS).
Returns: log S (mol/L), mg/mL, g/L, mole fraction (dilute approximation with the
solvent's real density; null with a warning when the solvent's density is not in
the solvent table), applicability-domain verdict, warnings, and model_version.
Uncertainty: use `conformal_interval_90` — a calibrated 90 % interval on log S
(measured coverage about 0.90 on held-out data). With v12, `confidence` and
`confidence_interval_95` are null: the model's seed replicates do not give a
meaningful spread, so no such number is reported.
Solvent SMILES examples:
water = "O"
ethanol = "CCO"
methanol = "CO"
DMSO = "CS(C)=O"
acetone = "CC(C)=O"
ethyl acetate = "CCOC(C)=O"
Cost: 5 credits, available on Free tier.| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| solute_smiles | Yes | ||
| temperature_k | No | ||
| solvent_smiles | No | O |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so: it enumerates returned quantities, discloses the density-table limitation and the resulting null-plus-warning behavior, explains why confidence/confidence_interval_95 are null for v12, and states cost (5 credits) and tier availability. These are exactly the non-obvious behaviors an agent needs.
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 one-line purpose and the routing rule, then organized into clearly labeled blocks (Returns, Uncertainty, Solvent SMILES, Cost). The solvent example list is the only stretch, but it earns its place by preventing SMILES formatting mistakes.
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, yet the description still usefully characterizes the return payload and its edge cases (null mole fraction when density is missing, null confidence on v12), plus cost and applicability-domain verdict. The remaining gap is the unaddressed temperature and api_key parameters.
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%, so the description must compensate. It does well for solvent_smiles by supplying concrete SMILES examples (water "O", DMSO "CS(C)=O"), which prevents a common formatting error. However, temperature_k, api_key, and the solute_smiles input are never addressed, leaving three of four parameters with no semantic guidance anywhere.
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+resource (solubility prediction), identifies the underlying model (gradient-boosted ensemble_v12) and its training corpus, and explicitly distinguishes itself from the heuristic logS in covachem_profile. An agent can route to it 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?
States the trigger condition plainly ("Always use this tool when the user asks about solubility, log S, dissolution, or 'how much X dissolves in Y'") and names both the alternative (covachem_profile) and the companion tool for uncertainty (conformal_interval_90). Explicit when-to-use and when-to-prefer-something-else.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop a running async GPU job and refund its credits.
Parameters:
job_id: The id returned by the submitting tool, e.g. "covafold-fold_protein:abc123".
Returns: {status: cancelled|already_finished|not_found, message}.
FREE — and the job's own credits are returned automatically.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | ||
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden, and it does well: it discloses the operation is FREE, that credits are refunded automatically, and enumerates outcome statuses (cancelled|already_finished|not_found), which signals idempotent-ish behavior. It doesn't address auth requirements (the api_key parameter) or whether in-flight work is irrecoverable.
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 action and effect, then broken into compact labeled sections for parameters and returns. Every line is useful, though the Returns section is partially redundant with the existing output schema.
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?
Covers the primary action, its cost/refund behavior, id format, and outcomes, but omits api_key semantics and any prerequisite/permission context, leaving a real gap for an unannotated mutation 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 coverage is 0%, so the description must compensate; it does so for job_id by giving the expected format and origin ('the id returned by the submitting tool, e.g. "covafold-fold_protein:abc123"'), but says nothing about api_key, leaving one of two parameters undocumented.
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+resource+effect: 'Stop a running async GPU job and refund its credits.' No sibling tool performs cancellation, so an agent can identify it immediately.
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?
It implies usage via 'Stop a RUNNING async GPU job' and clarifies the job_id comes from the submitting tool, but never states when to cancel versus inspecting status first (e.g. covasyn_job_detail / covasyn_job_result) or what happens if the job already finished.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show your current credit balance, tier, and pre-paid pack pricing.
Returns:
- balance: subscription credits remaining (resets weekly to weekly_allocation, capped at max_balance)
- prepaid_balance: pre-paid credits remaining (no expiration; consumed after sub balance is empty)
- total_available: balance + prepaid_balance (the actual amount you can spend right now)
- weekly_allocation: sub credits added every 7 days
- max_balance: rollover ceiling for sub credits (4× weekly_allocation)
- tier: free / pro / unlimited / enterprise
- max_concurrent_calls: parallel call limit for your tier
- next_reset_at: ISO timestamp when next weekly grant happens
- pricing_version: currently active pricing version
- prepaid_packs: list of available credit-pack sizes + EUR prices for your tier
This tool is FREE in all tiers — never costs credits to check your balance.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and delivers: subscription resets weekly and is capped at max_balance, prepaid credits never expire and are consumed only after the subscription balance empties, rollover ceiling is 4× weekly_allocation, and the call itself is free in all tiers. That is precisely the behavioral context an agent needs.
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 purpose sentence, then a clean bulleted field list, closing with the free-of-charge note. Every line is informative, though the field-by-field breakdown overlaps with the existing output schema, making it slightly longer than strictly necessary.
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 balance lookup with one auth parameter and an output schema, the description covers everything an agent needs: what it returns, how balances behave, tier limits, and that invoking it costs nothing. No ambiguity remains about calling it.
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% and the single parameter is api_key. The description never mentions the parameter, but an api_key is self-evident authentication and is likely injected globally, so the omission is minor. It adds no semantics beyond the parameter name itself.
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 ('Show') and resource ('your current credit balance, tier, and pre-paid pack pricing'), which is unmistakably distinct from every sibling (job management, analyzers, predictors). An agent reading only the first line knows exactly what this tool is for.
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?
It signals that the tool is safe to call ('FREE in all tiers — never costs credits'), which implicitly encourages its use, but it never states when to call it relative to alternatives (e.g., 'call before submitting a job to verify you can afford it'). Usage is implied rather than specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit feedback to the CovaSyn team.
Use this when something doesn't work, you have a feature request,
or a question. Your data (SMILES, structures, results) is NEVER
included — only your message and optional contact info.
Args:
subject: Short summary of the feedback.
message: Detailed description.
severity: One of "bug", "feature", "question", "other".
contact: Optional email/name so we can follow up.
tool_name: Which tool the feedback is about (optional).
error_message: Error text if reporting a bug (optional).
api_key: Your API key (used for rate limiting only).
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| contact | No | ||
| message | Yes | ||
| subject | Yes | ||
| severity | No | bug | |
| tool_name | No | ||
| error_message | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose meaningful behavior: submitted data (SMILES, structures, results) is NEVER included, and api_key is used for rate limiting only. It does not state what happens after submission (confirmation, idempotency, whether the tool mutates server state), which is a modest gap for a write operation.
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 purpose followed by a compact Args block; every line earns its place. The privacy note and per-parameter glosses are dense but not padded, though the Args list is somewhat longer than strictly necessary.
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 tool with 0% schema coverage and no annotations, the description covers purpose, when-to-use, privacy/behavioral guarantees, and every parameter. With an output schema present, return-value explanation is correctly omitted.
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%, so the description must compensate and it does: all seven parameters are documented, including severity's enum values ('bug', 'feature', 'question', 'other'), which the schema does not enumerate. This adds substantial meaning beyond the bare titles.
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 ('Submit feedback to the CovaSyn team'), and its purpose is unmistakably distinct from every sibling, which are all chemistry/bio analysis tools. An agent can route here without ambiguity.
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 triggering conditions: 'Use this when something doesn't work, you have a feature request, or a question.' No alternatives or exclusions are named, but this is a self-contained utility with no competing sibling, so the omission is minor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show one job's inputs — the sequence it was given, and its timings.
Parameters:
job_id: The id from covasyn_jobs, e.g. "covafold-fold_protein:abc123".
Returns: {job: {...}} or {error}. FREE — never costs credits.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | ||
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose a meaningful behavioral trait — 'FREE — never costs credits' — and 'Show' implies read-only, plus it gives the return shape ({job} or {error}). It does not mention authentication needs (the api_key parameter) or any rate limits, so the disclosure is partial.
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?
Short and front-loaded: the purpose sentence comes first, followed by a labeled parameter note, return shape, and cost note. Each line adds something; the returns line is mildly redundant given an output schema exists but is not wasteful.
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 single-job lookup with an output schema present, the description covers purpose, the key parameter's format, return shape, and cost. The one real gap is the unexplained api_key parameter, which an agent would otherwise have 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 description coverage is 0%, so the description must compensate. It does a good job on job_id, clarifying the source and giving a concrete format example ('covafold-fold_protein:abc123'), but it never mentions the api_key parameter at all, leaving one of two parameters undocumented everywhere.
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: 'Show one job's inputs — the sequence it was given, and its timings.' This scopes it to a single job's inputs/timings, which implicitly contrasts with the list-style covasyn_jobs and the result-returning covasyn_job_result. It stops short of naming those siblings explicitly, so differentiation is inferred rather than stated.
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 explicit when-to-use or when-not-to-use statement. However, 'The id from covasyn_jobs' implicitly routes the agent: call covasyn_jobs first, then this tool. That implied workflow is useful but leaves the choice between this and covasyn_job_result to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the result of an async GPU job (returned by a long-running tool).
Some GPU tools return a ``job_id`` instead of an inline result because the
computation runs too long for one response (e.g. chemreason_retrosynthesis).
Call this with that job_id; if it is not ready, re-call every ~20 seconds
until ``status`` is ``completed`` or ``failed``.
Parameters:
job_id: The id returned by the submitting tool, e.g. "chemreason:abc123".
Returns: {status: running|completed|failed, result?, error?}.
FREE — never costs credits.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | ||
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the async nature, the polling cadence, the terminal states, and that the call is FREE and never costs credits. It omits auth/permission behavior and what a 'failed' job implies for retries, keeping it just 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?
Front-loaded with the core action, then organized into Parameters and Returns blocks. The polling cadence sentence is high-value; the Returns line partially duplicates the output schema, but overall the structure is efficient and scannable.
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 async polling tool this covers the whole workflow: origin of job_id, poll interval, terminal statuses, and cost. An output schema exists so the return-value restatement is optional, and the only substantive gap is the undocumented api_key parameter.
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 0%, so the description must compensate. It documents job_id well, including the format example ('chemreason:abc123'), but says nothing about the second parameter api_key (no description in the schema either). Half the parameters remain undocumented, so this is only partial compensation.
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?
First sentence gives a specific verb and resource ('Fetch the result of an async GPU job') and ties it to the job_id produced by long-running tools. It never distinguishes itself from sibling covasyn_job_detail or covasyn_jobs, so an agent must guess which of the three to call, but the purpose itself 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?
It states exactly when to use it (a submitting tool returned a job_id instead of an inline result), the polling protocol (re-call every ~20 seconds), and the termination condition (status completed or failed). It gives no guidance against covasyn_job_detail/covasyn_jobs, which is the only real gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List your async GPU jobs — running, finished and failed.
Parameters:
scope: "canvas" (default) for jobs started from the current canvas,
or "account" for every job on your account.
tool: optional filter, e.g. "covafold". Empty (default) returns EVERY
durable job — an LLM asked "what jobs do I have?" must not be
handed a silently truncated answer. A UI that can only act on one
kind of job passes its own filter explicitly.
Returns: {jobs: [{job_id, tool, state, submitted_at, credits, importable}]}.
FREE — never costs credits. Never returns sequences or structures; fetch
those with covasyn_job_detail / covasyn_job_result.
| Name | Required | Description | Default |
|---|---|---|---|
| tool | No | ||
| scope | No | canvas | |
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does it well: it declares the tool is FREE and never costs credits, warns that sequences/structures are never returned, and highlights that an empty tool filter deliberately returns every durable job to avoid silent truncation. Missing only auth/permission notes for the api_key parameter.
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 purpose line, then a parameter block and a returns block, which makes it easy to scan. The parenthetical about an LLM asking "what jobs do I have?" is a slightly chatty justification but earns its place by explaining the default.
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 zero-required-param listing tool with an output schema, this is close to complete: parameters, defaults, cost, and sibling routing are all covered. The only redundancy is restating the return shape that the output schema already provides, and the omitted api_key semantics.
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%, so the description must compensate, and it documents scope and tool in detail, including defaults and the anti-truncation rationale. It adds meaning well beyond the bare typed fields, though api_key is unaddressed.
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 your async GPU jobs") and enumerates the states covered (running, finished, failed). It also names the sibling tools (covasyn_job_detail / covasyn_job_result) that carry the data this tool deliberately omits, so an agent can separate it from adjacent job tools.
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?
Explains the semantics of the scope filter (canvas vs account) and the tool filter, including the intent behind the empty default (don't silently truncate). It routes the agent to covasyn_job_detail / covasyn_job_result for sequences and structures, though it never states an explicit when-not-to-use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Environmental fate screen: bioaccumulation (BCF), persistence (biodegradation half-life, ready biodegradability), ecotox structural alerts, and the REACH P/B criteria.
Does NOT report acute aquatic toxicity. The fish 96 h LC50, Daphnia 48 h
EC50 and algae 72 h ErC50 come back as "not_served" with a reason: on
held-out EPA ECOTOX reference values these predictors show no usable
ranking skill and a larger error than a single fixed number, so no value
is published that a user could not tell apart from a real one. For acute
aquatic toxicity use a measured OECD 203/202/201 result or the EPA ECOTOX
Knowledgebase. Consequently no GHS aquatic category is returned, and the
PBT T criterion is reported as unassessed rather than negative.| Name | Required | Description | Default |
|---|---|---|---|
| smiles | Yes | ||
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description carries the full burden and does unusually well: it pre-announces that some endpoints return the literal status 'not_served' with a reason, explains the validation rationale (no usable ranking skill on held-out EPA ECOTOX values, larger error than a fixed baseline), and warns that no GHS aquatic category is produced and the PBT T criterion is 'unassessed' rather than negative. It never mentions the api_key credential requirement or any rate/credit limits, which is the remaining behavioral gap.
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 capability before the caveat, which is the right order, and every sentence carries routing or expectation-setting value. The middle rationale ('no usable ranking skill and a larger error than a single fixed number') is slightly more argumentative detail than an agent needs to select the tool, but it justifies the 'not_served' behavior that would otherwise look like a bug.
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-value documentation is not owed, yet the description still explains the most confusing return semantics (not_served placeholders, absent GHS category, unassessed PBT T criterion), which is the right use of the space. The credential parameter is the one element left underexplained for a tool that has zero annotation coverage.
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%, so the description must compensate and it largely does not: it never mentions 'smiles' (only implied by 'structural alerts') and never mentions 'api_key' at all, including whether it is required, where to obtain it, or whether an empty default works. An agent must infer input format and credential handling entirely from bare property 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?
The opening clause names the verb+resource precisely: an environmental fate screen covering BCF, biodegradation half-life/ready biodegradability, ecotox structural alerts, and REACH P/B criteria. It then explicitly states what it is not (acute aquatic toxicity), so an agent can distinguish it from any acute-tox or generic tox sibling 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?
Explicit when-not guidance: no acute fish/Daphnia/algae endpoints, and a named alternative route (measured OECD 203/202/201 or EPA ECOTOX Knowledgebase) for those endpoints. The exclusion is front-and-center rather than buried, which is exactly what routing decisions need.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Liveness/readiness check + cache occupancy. Returns status:
ready (warm), warm_required (models on disk but caches empty),
or no_models. Use as K8s liveness/readiness probe.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| model_dir | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose the meaningful behavioral trait: a three-state status machine with defined meanings for each state. It omits whether api_key is required for access and any latency/cost behavior, 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?
Three short sentences, front-loaded with the core purpose and followed by the return states and usage context. 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?
An output schema exists, so the return format need not be explained, yet the description helpfully enumerates states anyway. For a two-param health-check tool this is nearly complete, with the only gap being the role of the api_key parameter.
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% for both parameters. The phrase "models on disk" loosely gestures at model_dir, but the description never explains model_dir or api_key semantics, defaults, or format, so it does not compensate for the coverage 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?
States a specific verb+resource (liveness/readiness check plus cache occupancy) and enumerates the exact return states (ready, warm_required, no_models). This distinguishes it from sibling covatox_warmup, which the warm_required state implicitly points to.
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 as K8s liveness/readiness probe" gives a clear operational context for calling it. It does not explicitly name covatox_warmup as the follow-up when warm_required is returned, leaving that inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pre-load all CovaTox inference caches (models, AD references, conformal calibrators). Call once after container start so the first user prediction skips the ~5-10s of cold disk reads. Idempotent.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| model_dir | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does reasonably well: it discloses the side effect (populating caches), the measurable latency benefit, and that the operation is idempotent. It does not cover auth requirements for api_key, failure modes when caches are already warm, or whether it is a pure local or network operation.
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, verb front-loaded, no filler. The 'so that' clause earns its place by quantifying the benefit.
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, output-schema-backed setup tool, the description adequately covers what it does and when to invoke it. The only real gap is parameter intent, which is already penalized under parameter semantics.
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% and the description never mentions the two parameters (api_key, model_dir) it accepts. It adds no semantic meaning beyond the bare property titles, leaving the agent to guess what model_dir overrides or why api_key is needed for a cache warm-up.
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+resource ('Pre-load all CovaTox inference caches') and enumerates exactly what is loaded (models, AD references, conformal calibrators). This is clearly distinguishable from the only siblings, covatox_ecotox and covatox_health, which are prediction tools.
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 an explicit when ('Call once after container start') and the concrete payoff (skips ~5-10s of cold disk reads), plus the idempotency note that tells the agent repeat calls are harmless. An agent knows exactly when this is warranted versus simply calling a prediction tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full UV-Vis spectrum analysis in one call (recommended entry point).
Loads, processes, detects peaks, identifies chromophores, assesses quality, and formats UV-Vis reporting strings.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| smiles | No | ||
| api_key | No | ||
| solvent | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It does disclose the internal pipeline (load, process, peak detection, chromophore identification, quality assessment, reporting), which is genuinely useful behavioral context. It stops short of disclosure an agent would want for a network-backed tool: authentication (the api_key parameter hints at it but the description never says so), failure behavior, or whether the analysis is read-only.
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 plus a parenthetical, with the highest-value information ('Full UV-Vis spectrum analysis in one call') front-loaded. The pipeline enumeration is compact and 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?
An output schema exists, so return values need not be explained. But for a four-parameter, zero-annotation, network-requiring tool, the description omits parameter meaning and any behavioral notes (auth, quality thresholds, failure modes), leaving the agent with a solid high-level picture but insufficient detail to invoke it confidently.
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% and the description adds nothing about any of the four parameters. path, smiles, solvent, and api_key are only visible as bare titles with no meaning, and the description never connects them (e.g., that solvent affects peak assignment or that smiles is optional structural input). With four undocumented parameters this is a real gap rather than a baseline case.
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+resource ('Full UV-Vis spectrum analysis') and enumerates the pipeline stages it performs, so the agent knows exactly what the tool does. It partially differentiates from siblings by labeling itself the 'recommended entry point', but never names covauv_quantify, covauv_validate, covauv_compare, or covauv_predict, so the boundary against those tools 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?
'(recommended entry point)' implies this should be called first when you want an end-to-end analysis, which is real usage context. However, there are no explicit conditions, no statement of when a narrower sibling is preferable, and no prerequisites (e.g., api_key requirements) are described.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Biomolecule analytics: protein A280, DNA/RNA A260, or enzyme kinetics.
mode="protein" | "nucleic_acid" | "enzyme_kinetics"
| Name | Required | Description | Default |
|---|---|---|---|
| mw | No | ||
| a260 | No | ||
| a280 | No | ||
| mode | No | protein | |
| api_key | No | ||
| epsilon | No | ||
| na_type | No | dsDNA | |
| timepoints | No | ||
| wavelength | No | ||
| absorbances | No | ||
| epsilon_280 | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It hints at three modes but never discloses that behavior branches per mode, which parameters matter for each branch, or that api_key is required for authentication. For an unannotated multi-mode tool this is a substantial gap.
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 lines with no filler, and the mode enumeration is easy to scan. The trade-off is under-specification rather than verbosity, which is preferable for conciseness but leaves content gaps elsewhere.
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, three-mode tool with zero annotation and zero schema-description coverage, the description omits the critical mode-to-parameter mapping. An output schema exists so return values need not be explained, but the input story is largely 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 coverage is 0% across 11 parameters and there are no enums despite 'mode' having three discrete values. The description helpfully enumerates the mode values, but leaves mw, a260, a280, api_key, epsilon, na_type, timepoints, wavelength, absorbances and epsilon_280 totally undocumented, including which belong to which mode.
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 concrete analytical outputs (protein A280, DNA/RNA A260, enzyme kinetics) and enumerates the mode values, so an agent can tell this computes biomolecule quantitation. The verb 'analytics' is broad and it does not distinguish itself from the covauv_* or covabio_* siblings, but the resource is specific.
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 choose this tool versus alternatives (e.g. covauv_quantify, covauv_predict) or when-not to use it. The mode list implies usage variants but never states the condition that selects each one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare two UV-Vis spectra for similarity (correlation/euclidean/cosine).
| Name | Required | Description | Default |
|---|---|---|---|
| method | No | correlation | |
| path_a | Yes | ||
| path_b | Yes | ||
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, yet it omits whether the operation is read-only, what permissions or api_key are needed, and whether it has side effects. It mentions similarity methods but no operational traits.
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 includes the key method options without waste. Every part 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 4-parameter tool with no annotations and an output schema, the description covers the core purpose but leaves critical invocation details missing, such as the meaning of api_key and whether paths are file paths or identifiers. The output schema covers return values, but the input side remains partially 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%, so the description must compensate. It lists the method options (correlation/euclidean/cosine) and implies path_a and path_b are the two spectra, but it never mentions the api_key parameter or path format.
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 (Compare), resource (UV-Vis spectra), and scope (for similarity), including method options. The 'UV-Vis' qualifier distinguishes it from other modality compare tools (e.g., covnmr_compare, covair_compare) in the sibling list.
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?
Provides no when-to-use or when-not-to-use guidance, nor does it name alternative tools for comparing spectra. It only restates the core action, so an agent must infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate dissolution profile from UV-Vis absorbance time series.
concentration_unit is REQUIRED and must match the unit the calibration
curve was built in: "mg/mL", "mg/L" or "ug/mL" (the latter two are
equivalent). Dissolution calibrations are most often built in ug/mL — a
100 mg tablet in 900 mL is ~111 ug/mL at full release. Getting this wrong
shifts every result by a factor of 1000, so there is deliberately no
default; the response echoes the unit back and flags implausible profiles
in unit_check.
Optionally calculates f2 similarity if reference_profile is provided.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| volume_ml | No | ||
| timepoints | Yes | ||
| absorbances | Yes | ||
| label_claim_mg | Yes | ||
| calibration_slope | Yes | ||
| reference_profile | No | ||
| concentration_unit | Yes | ||
| calibration_intercept | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does so well: it declares that concentration_unit is REQUIRED, that there is deliberately no default, that a wrong choice shifts results by 1000x, and that the response echoes the unit and flags implausible profiles in unit_check. It omits any statement about auth/api_key handling or result structure beyond unit_check.
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-loads the purpose, then devotes its space to the one genuinely dangerous parameter. The unit paragraph is longer than strictly necessary but every sentence addresses a real failure mode, so it 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 6-required-parameter tool with zero schema descriptions, the definition leaves most inputs unexplained. The output schema spares it from describing return values, but the missing explanation of timepoints/absorbances encoding and calibration inputs is a substantive gap an agent must guess around.
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 9 parameters, yet the description explains only concentration_unit thoroughly (plus a passing mention of reference_profile and the 900 mL default). The formats of timepoints and absorbances — critical string inputs — and the roles of calibration_slope/intercept and label_claim_mg are left entirely undocumented.
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 opening sentence gives a specific verb+resource+input domain: 'Calculate dissolution profile from UV-Vis absorbance time series.' That clearly separates it from generic siblings like covauv_quantify or covauv_validate, though it never names an alternative tool to contrast against.
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 concrete conditional usage for the f2 calculation ('Optionally calculates f2 similarity if reference_profile is provided') and strong guidance on when the unit choice matters. It stops short of saying when to prefer this tool over covauv_quantify or covauv_auto_analyze.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Predict UV-Vis absorption bands and phototoxicity risk from SMILES.
| Name | Required | Description | Default |
|---|---|---|---|
| smiles | Yes | ||
| api_key | No | ||
| solvent | No | methanol |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, yet it discloses only the two prediction outputs. It says nothing about authentication requirements despite an api_key parameter, cost/rate limits, whether the prediction is deterministic, or how solvent affects behavior.
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 no filler and no redundancy. It is efficient, though the brevity comes at the cost of coverage rather than serving as disciplined conciseness.
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 described. However, with zero annotation coverage, zero schema description coverage, and an impactful solvent parameter left undocumented, the definition is too thin for an agent to call the tool reliably.
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%, so the description must compensate for three undocumented parameters, and it does not. 'from SMILES' hints at the required smiles input, but solvent (which materially shifts UV-Vis bands) and api_key are left unexplained in both schema and description.
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 ('Predict') and two concrete outputs (UV-Vis absorption bands and phototoxicity risk) from a specific input (SMILES). It is clearly distinguishable from action siblings like covauv_compare or covauv_quantify, though it does not explicitly differentiate itself from covauv_bio or covauv_auto_analyze.
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 when-to-use guidance, no mention of prerequisites, and no routing to alternative tools such as covauv_auto_analyze or covauv_bio. The agent must infer entirely from the name and description when this tool is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Quantification via Beer-Lambert law or calibration curve.
Mode 1: Provide 2 of (absorbance, epsilon, concentration) for Beer-Lambert.
Mode 2: Provide standards JSON + unknown_absorbance for calibration.
| Name | Required | Description | Default |
|---|---|---|---|
| mw | No | ||
| api_key | No | ||
| epsilon | No | ||
| standards | No | ||
| absorbance | No | ||
| path_length | No | ||
| concentration | No | ||
| unknown_absorbance | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the two computational paths and the parameter counts that trigger each, which is useful, but says nothing about the required api_key parameter, error behavior when fewer than 2 mode inputs are supplied, or that this is a deterministic read-only computation.
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 short lines, front-loaded with the purpose and then the two modes. Every sentence earns its place and the label structure (Mode 1 / Mode 2) makes it easy to scan.
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 described. However, for an 8-parameter tool with two distinct operating modes, zero schema descriptions, and no annotations, the description leaves real gaps: api_key need, path_length, mw, and the standards JSON format are all 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%, so the description must compensate for all 8 parameters. It names absorbance, epsilon, concentration, standards, and unknown_absorbance, but leaves mw, path_length, and api_key entirely unexplained, and gives no units or format for the 'standards JSON' string.
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 action (quantification) and the two underlying methods (Beer-Lambert law, calibration curve) plus the inputs each requires. An agent can distinguish it from the analytical siblings like covauv_auto_analyze or covauv_predict, though the description never names those siblings 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?
Gives clear context for selecting between Mode 1 (supply 2 of absorbance/epsilon/concentration) and Mode 2 (standards JSON + unknown_absorbance), which is exactly the decision an agent must make. It does not, however, state when to pick this tool over sibling tools such as covauv_auto_analyze or covauv_validate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run full ICH Q2(R2) method validation (linearity + accuracy + precision).
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| standards | Yes | ||
| accuracy_data | Yes | ||
| precision_data | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It says nothing about the required api_key/authentication, whether validation is computationally heavy or long-running, what happens on data-format mismatch, or what the pass/fail output contains; only the regulatory framework name (ICH Q2(R2)) is added.
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 no filler; the verb and the regulatory scope come first. It is terse to the point of under-specification, but nothing extraneous is present.
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, but the tool takes three required, undocumented data inputs, has no annotations, and the description omits format, prerequisites and alternatives. For a multi-input regulatory validation routine this is far from 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 0% across 4 parameters, including the required standards, accuracy_data and precision_data. The description names 'linearity, accuracy, precision' but gives no hint about the expected data format, units, or how a linearity dataset maps onto the three required string parameters, so it fails to compensate for the schema 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?
States a specific verb (Run) and resource (ICH Q2(R2) method validation), and enumerates the three sub-analyses it performs (linearity + accuracy + precision). That is enough for an agent to distinguish it from generic siblings like covauv_auto_analyze or covauv_quantify.
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 statement of when to use this tool, what prerequisites must hold, or which alternatives exist. Siblings such as covauv_auto_analyze, covviv... covnmr_method_validate and covauv_quantify are plausible substitutes but are never referenced, leaving the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze one 2D NMR experiment (HSQC/HMBC/COSY/NOESY/TOCSY/ROESY): crosspeaks and the correlations they imply.
The experiment is read from the file's own pulse sequence; pass
`experiment` only for formats that record none. A value contradicting the
file is reported in `experiment_warning` and does not override it. To use
2D data for an atom-by-atom assignment, give the files to covnmr_sudoku.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| api_key | No | ||
| experiment | No | ||
| max_crosspeaks | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description does real work: it discloses that file metadata wins over the `experiment` argument and that a contradicting value surfaces in `experiment_warning` rather than being honored. It stops short of covering file-format support, failure modes for unreadable spectra, or what a truncated `max_crosspeaks` result looks like.
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 tight paragraphs: what it does and returns, then argument-precedence rules, then routing to a sibling. No filler, and the core purpose is front-loaded in the first line.
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 like `experiment_warning` needn't be detailed further, and the description covers the main behavioral surprises for a read-only analysis call. Minor gaps remain around accepted file formats and the meaning of the crosspeak cap, but nothing that would cause a wrong invocation.
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 4 parameters, so the description must compensate; it fully explains the trickiest one (`experiment`) including override semantics. But `path`, `api_key`, and especially `max_crosspeaks` (default 200, implying result truncation) get no explanation at all, leaving the practical impact of that cap invisible.
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 ('Analyze one 2D NMR experiment') plus the expected output ('crosspeaks and the correlations they imply'), and enumerates the supported experiment types (HSQC/HMBC/COSY/NOESY/TOCSY/ROESY). This lets an agent distinguish it from 1D siblings like covnmr_analyze and from assignment-oriented tools like covnmr_sudoku.
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?
Explicit conditional guidance: pass `experiment` only when the file's pulse sequence records none. It also names the alternative path — hand 2D files to covnmr_sudoku for atom-by-atom assignment — which is a clear use-vs-use-else rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full 1D NMR analysis of one spectrum file: processing, peaks, integrals,
multiplets, the publication NMR string, and, with smiles, structure
verification in the same call.
With `smiles`, pass `hrms` too (e.g. {"formula": "C9H8O4", "mz": 181.0495,
"adduct": "[M+H]+"}) and `verification` checks the HRMS formula and mass
(within `hrms_ppm_tolerance` ppm, default 10), the proton count from the
spectrum's integrals (1H) or the carbon line count (13C), and gives one
answer in `verification.verdict_combined` (see covnmr_verify).
Absorbs three retired tools:
* covnmr_format -> `output_format="nmr_string"` (or "acs").
* covnmr_export -> `output_format` "peaks_csv" (alias "csv"), "spectrum_csv",
"jcamp" or "nmredata" (pass `smiles` and `compound_name` for NMReData).
The file comes back INLINE as `content` with `filename` and `mime`;
nothing is written on the server. `content_truncated` says whether it was
capped at `max_content_chars` (2,000,000); curve formats are decimated to
fit rather than cut (`curve_reduced_to_fit`).
* covnmr_audit_report -> `audit=true` (and `operator`): adds `audit_record`
with input and output hashes taken over the complete output. The record
names your file: `display_name` if you give one, else the file name in
the URL you sent.
`output_format="asm"` returns an Allotrope-style ASM JSON document inline.
It is EXPERIMENTAL and UNVALIDATED: no NMR ASM schema was available to
check it against, and the response says so (`maturity: "experimental"`,
`maturity_note`, `asm_validation`). Do not hand it to a system that
expects a validated ASM file.
Nucleus and spectrometer frequency are read from the file; give them only
for a file that declares none. Without `smiles` the 1H entries of the NMR
string carry no integrals (there is no honest anchor to scale them
against); with it they do. With `smiles` the response also adds
`verification` and `impurities` -- read `verification.verdict` and its
`evidence`, not `match_score`. For a structure check alone, or one from a
peak list without a file, use covnmr_verify.
| Name | Required | Description | Default |
|---|---|---|---|
| hrms | No | ||
| path | Yes | ||
| audit | No | ||
| smiles | No | ||
| api_key | No | ||
| nucleus | No | ||
| solvent | No | CDCl3 | |
| operator | No | ||
| field_mhz | No | ||
| display_name | No | ||
| compound_name | No | ||
| export_points | No | ||
| output_format | No | ||
| max_content_chars | No | ||
| hrms_ppm_tolerance | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does so well: it states export content is returned inline with no server-side file, explains truncation and curve decimation behavior, discloses that ASM output is experimental and unvalidated, and clarifies that integrals depend on `smiles`. These are exactly the behavioral traits an agent needs 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?
Despite its length, the description is front-loaded with the core purpose and then organized by mode and parameter group. The bullets and warnings about retired-tool absorptions and ASM maturity all earn their place for a 15-parameter multimodal tool.
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 complex tool with 15 parameters and no annotations, the description is complete enough to invoke correctly: it covers the main modes, prerequisites for structure verification, output-format behavior, truncation semantics, and routing to covnmr_verify. Even with an output schema present, it helpfully names key return fields such as `verification.verdict_combined`, `content_truncated`, and `maturity`.
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%, so the description must compensate, and it explains many important parameters: `smiles`, `hrms`, `hrms_ppm_tolerance`, `output_format` aliases, `max_content_chars`, `audit`, `operator`, `nucleus`, and `field_mhz`. It leaves some parameters such as `api_key`, `solvent`, and `export_points` unexplained, so it is strong but not fully comprehensive.
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 opens with a specific verb and resource: full 1D NMR analysis of one spectrum file, enumerating processing, peaks, integrals, multiplets, NMR string, and optional structure verification. It distinguishes the tool from siblings such as covnmr_verify and makes the 1D scope explicit, so an agent can select it without opening other 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?
It gives explicit conditions for using optional modes: with `smiles` pass `hrms`, and for a structure check alone use covnmr_verify. It also maps output_format values to the retired tools they replace and warns not to treat ASM output as validated ASM, which is unusually actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Batch-analyze every NMR data file in an archive (zip/tar URL): per-file
summaries plus statistics, files_processed and files_failed.
Nucleus and spectrometer frequency are read from each file, so an archive
holding spectra from two instruments is handled correctly and every row
reports its own `field_mhz` and `field_source`. Give `field_mhz` only for
files that declare no frequency; a file that states one always wins. An
archive without NMR data returns status "error" (`no_data_found`).
| Name | Required | Description | Default |
|---|---|---|---|
| folder | Yes | ||
| api_key | No | ||
| nucleus | No | ||
| solvent | No | CDCl3 | |
| field_mhz | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With zero annotations the description carries the full burden, and it does disclose real behavior: per-file nucleus/frequency extraction, per-row field_mhz and field_source reporting, explicit precedence (a file's stated frequency always wins over the field_mhz argument), and the no_data_found error status. It omits authentication requirements for api_key, any limits on archive size or concurrency, and whether partial failures still return results.
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 short paragraphs, front-loaded with what the tool does and what it returns, followed by the precedence rule and the failure mode. No filler sentences, though the frequency-precedence point is restated across two sentences.
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?
Return shape is covered by the output schema, so the description correctly doesn't dwell on it while still naming the key aggregates. With a 5-parameter, 1-required tool at 0% schema coverage and no annotations, the missing semantics for nucleus, solvent and api_key leave the definition incomplete for correct invocation.
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 0%, so the description must compensate, and it only partly does: it clarifies that the required `folder` argument is a zip/tar URL and fully specifies field_mhz as a fallback-only value. The nucleus, solvent and api_key parameters receive no semantics at all in either schema or description, leaving half the surface undocumented.
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: batch-analyze every NMR data file in an archive, with the accepted container types (zip/tar URL) and the returned aggregates named. It distinguishes itself from the single-spectrum covnmr_analyze only implicitly via 'batch' and 'archive', never naming the sibling or the contrast 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?
'Give field_mhz only for files that declare no frequency' and the no_data_found error case give useful conditional guidance for one input. But there is no explicit statement of when to choose this over covnmr_analyze or covnmr_identify, nor any prerequisites (api_key, archive size/format limits).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare two NMR spectra of the same nucleus: matched peaks, correlation, RMS shift difference and a similarity verdict (e.g. batch against reference).
Each file declares its own nucleus; two different nuclei return status
"error" (`nucleus_mismatch`, with `nucleus_a` and `nucleus_b`) rather than
a meaningless score. Peaks are matched within `tolerance_ppm` (0.05).
| Name | Required | Description | Default |
|---|---|---|---|
| path_a | Yes | ||
| path_b | Yes | ||
| api_key | No | ||
| nucleus | No | ||
| solvent | No | ||
| tolerance_ppm | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does disclose a key failure mode: mismatched nuclei return status "error" with nucleus_mismatch, nucleus_a and nucleus_b instead of a bogus score, plus the default matching window of 0.05 ppm. It omits auth/api_key requirements, what happens on unreadable paths, and whether any state is written.
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 paragraphs, output capabilities front-loaded, error semantics second. No filler and nothing 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?
An output schema exists, so return values needn't be explained, and the comparison semantics are well covered. But for a 6-parameter tool with 0% schema coverage, leaving api_key, solvent, and the nucleus override unexplained is a real gap an agent could trip on.
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 6 parameters, so the description must compensate. It only clarifies tolerance_ppm (default 0.05) and indirectly nucleus (each file declares its own), leaving path_a, path_b, api_key, and solvent undocumented — notably raising the question of what the `nucleus` parameter does if files already declare one.
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+resource ("Compare two NMR spectra") and enumerates the outputs produced: matched peaks, correlation, RMS shift difference, similarity verdict. An agent can tell this apart from covnmr_analyze, covnmr_verify, or covnmr_identify without opening any 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?
Gives a concrete intended use ("e.g. batch against reference") and specifies the invariant that both files must share a nucleus, which effectively rules out cross-nucleus comparisons. It doesn't explicitly name sibling alternatives such as covnmr_verify or covnmr_analyze, so the routing guidance is contextual rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Interpret ONE peak, or one 2D crosspeak: what is this signal? The answer
is in explanation.
Peak mode (default): `ppm` and optionally `multiplicity` ("t", "dd"),
`j_values` (comma-separated Hz, "7.1,2.4") and `nucleus` (default 1H).
Returns the spectral region, the functional groups consistent with it, and
what the coupling pattern implies.
Correlation mode: give `c_ppm` AND `experiment` ("HSQC", "HMBC", "COSY")
and it interprets the crosspeak instead -- bond type and the groups on each
axis. This mode returns a different key set; `mode` says which you got.
With `smiles` you also get `atom_attribution`: the atom whose predicted
shift is closest to `ppm`. It is a nearest neighbour on one axis, not an
assignment, and it names an atom even when nothing is within tolerance --
read `attribution_status` first ("matched", "no_atom_within_tolerance",
"no_structure_prediction", "not_requested"). For a full assignment use
covnmr_verify or covnmr_sudoku.
| Name | Required | Description | Default |
|---|---|---|---|
| ppm | Yes | ||
| c_ppm | No | ||
| smiles | No | ||
| api_key | No | ||
| nucleus | No | ||
| solvent | No | CDCl3 | |
| j_values | No | ||
| experiment | No | ||
| multiplicity | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses that the two modes return different key sets and that `mode` disambiguates, and it warns that `atom_attribution` is a nearest neighbour, not an assignment, and will name an atom even when nothing is within tolerance. It omits whether the call is read-only/costly and that an `api_key` may be required.
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 one-line purpose, then organised under explicit mode headings with the caveat paragraph last. Dense but every paragraph maps to a distinct decision the caller must make; only the attribution paragraph runs slightly long for the value it adds.
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 enumerated, yet the description still names the key that carries the answer and flags the mode-dependent key set — the piece an agent cannot infer. With 9 parameters and no annotation coverage, the only real gaps are the undocumented `solvent` and `api_key` inputs.
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%, so the description must compensate, and it does for most parameters: `ppm`, `multiplicity` ("t", "dd"), `j_values` (comma-separated Hz with an example), `nucleus` (default 1H), `c_ppm`, `experiment` (HSQC/HMBC/COSY) and `smiles` all get meaning beyond their bare types. It leaves `solvent` (default CDCl3) and `api_key` entirely undocumented.
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?
Opens with a specific verb+resource framed as a question the tool answers ("Interpret ONE peak, or one 2D crosspeak: what is this signal?") and names the output key holding the answer. It then splits the tool into two clearly named modes, so an agent can tell exactly which capability it is invoking, distinct from siblings like covnmr_analyze or covnmr_2d_analyze.
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?
Mode selection is explicit: peak mode is the default, and correlation mode requires `c_ppm` AND `experiment`. It also routes the adjacent task away ("For a full assignment use covnmr_verify or covnmr_sudoku"). What's missing is guidance on when to reach for this tool versus the broader covnmr_analyze / covnmr_2d_analyze siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Identify a spectrum against a curated reference set: 7 qNMR standards + 32 common impurities/solvents (39 entries total) -- not a general or natural-product compound database. Good for confirming a known standard or a common impurity; it will not identify an unknown natural product or a novel structure.
Nucleus coverage differs and the response states it in `nucleus_coverage`.
1H: all 39 entries, 7 solvents. 13C: 30 of the 32 impurities, CDCl3 and
DMSO-d6 only (Fulmer et al., Organometallics 2010, 29, 2176-2179, on the
77.16 scale); the 7 qNMR standards carry no 13C. A nucleus with no
reference data returns status "error" (`unsupported_nucleus`).
Read the top score, not the ranking: a random 8-peak carbon list averages
0.24 against its best entry and has reached 0.625, while every compound
that IS in the table self-matches at 0.800 or better. Only a score near 1.0
is an identification; anything lower is the nearest neighbour in a
39-compound table. To test a structure you already suspect, use
covnmr_verify; to choose between suspects, covnmr_rank_candidates.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| api_key | No | ||
| nucleus | No | ||
| solvent | No | CDCl3 | |
| tolerance_ppm | No | ||
| max_candidates | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: it discloses nucleus-dependent coverage (1H full, 13C only 30 entries in CDCl3/DMSO-d6, standards carry no 13C), the error path (`unsupported_nucleus` on a nucleus with no data), and the crucial score-interpretation behaviour (self-match >= 0.800, random carbon lists average 0.24 and reach 0.625). This is exactly the operational context structured fields cannot convey.
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 purpose and scope, then coverage, then scoring semantics — a sound ordering with no filler. It runs long across three blocks, and the Fulmer citation plus exact self-match numbers are dense, but each block carries decision-relevant information rather than restating 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?
An output schema exists, so return values (including `nucleus_coverage`) need not be described, and the interpretive guidance is unusually complete. However, for a tool whose only required argument is an input file path, failing to state the accepted spectrum format or the auth requirement implied by `api_key` leaves a real gap before an agent can call it successfully.
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 6 parameters, so the description must compensate and largely does not. It clarifies nucleus coverage and solvent constraints indirectly, but never explains the required `path` parameter's accepted format (peak list, JCAMP, raw string?), nor what `tolerance_ppm`, `max_candidates`, or `api_key` mean or how defaults behave. The single most important parameter, the input spectrum, is left undefined.
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 (identify a spectrum against a curated reference set) and immediately bounds the scope: 39 entries, 7 qNMR standards, 32 impurities/solvents. It explicitly distinguishes itself from a general or natural-product database, so an agent knows exactly what class of problem this solves.
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 when-to-use (confirming a known standard or common impurity), explicit when-not (unknown natural products, novel structures), and names both alternatives with the condition that selects each: covnmr_verify to test a suspected structure, covnmr_rank_candidates to choose between suspects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Impurity profiling + ICH Q3C(R8) residual-solvent screen of a spectrum.
The NMR solvent the file declares wins over `solvent`. Residual solvents
are named by chemical shift for lines the compound (`smiles`) does not
explain; the screen does not quantify them, so it gives limits, not
pass/fail. Each identified line lists every solvent within tolerance
(`ambiguous`, `alternatives`), its ICH class, and `limit_ppm_at_dose`.
Without `dose_g_per_day` the Option 1 dose of 10 g/day is used and
`dose_source` says so. `coverage` names the Q3C solvents this NMR solvent
cannot screen for, so a clean result can be read correctly. A nucleus with
no tables returns status "error" (`unsupported_nucleus`).
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| smiles | No | ||
| api_key | No | ||
| nucleus | No | ||
| solvent | No | CDCl3 | |
| dose_g_per_day | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: it discloses the solvent-precedence rule, that the screen gives limits rather than pass/fail, how ambiguous lines are reported, the default dose and dose_source behavior, the COVERAGE limitation, and the unsupported_nucleus error. These are meaningful behavioral traits 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?
The purpose is front-loaded in the first sentence, followed by compact, information-dense behavioral notes. There is no filler; each sentence adds operational context for a complex tool.
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?
Given that an output schema exists, the description does not need to enumerate return fields, yet it still explains key outputs such as ambiguous, alternatives, dose_source, and coverage. For a six-parameter analysis tool with no annotations, it supplies enough behavioral and semantic context to call the tool correctly.
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%, so the description must add meaning. It explains the important non-obvious parameters: solvent precedence, the role of smiles in explaining lines, dose_g_per_day defaulting to 10 g/day, and nucleus unsupported behavior. It does not explain path or api_key, but those are generic and less critical to domain use.
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: impurity profiling plus an ICH Q3C(R8) residual-solvent screen of a spectrum. It is clear what the tool does, but it does not explicitly distinguish itself from the sibling tool covnmr_purity or explain when to choose one over the other.
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 purpose and by behavior notes such as the default dose fallback and unsupported-nucleus error. However, there is no explicit when-to-use guidance, no when-not-to-use guidance, and no named alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ICH Q2(R2) method validation: linearity, precision, LOD/LOQ.
`concentrations` and `responses` are comma-separated series of equal
length, AT LEAST FIVE points ("1,2,5,10,20"). Linearity is tested with
Mandel's F-test, so it is a verdict on curvature, not an R-squared
threshold. `overall_passes` is true only when every criterion holds:
positive slope, r2 >= 0.999, Mandel linear, and RSD <= 1 % when
`precision_measurements` (comma-separated repeats) are given; the criteria
are listed in `criteria`.
Give `noise_rms` for LOD/LOQ from the calibration slope; without it
`lod_loq.status` is "not_computed" with the reason. Bounded: `max_points`
(1000) per series, `max_residuals` (500) on the residuals echoed back.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| noise_rms | No | ||
| responses | Yes | ||
| max_points | No | ||
| max_residuals | No | ||
| concentrations | Yes | ||
| precision_measurements | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it explains the decision logic (Mandel's F-test vs. R-squared threshold), the exact conjunction required for `overall_passes`, the "not_computed" degraded path when `noise_rms` is absent, and hard bounds. It stops short of stating that the call is a pure computation with no persistence, or how `api_key`/authentication is 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?
The statistics are front-loaded in one line and the parsing constraints follow immediately; every sentence adds information. The closing bounds sentence ("`max_residuals` (500) on the residuals echoed back") is telegraphic and slightly harder to parse than the rest.
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 statistical tool with no annotations, the description covers inputs, pass criteria, degraded paths, and limits, which is what an agent needs to call it correctly; an output schema exists so return structure needn't be spelled out, though the description usefully names `overall_passes`, `criteria`, and `lod_loq.status`. The only real omission is auth/`api_key` context and any sibling routing.
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 0%, so the description must compensate, and it largely does: it gives format (comma-separated, equal length), a minimum cardinality with an example for `concentrations`/`responses`, the role of `noise_rms`, and the meaning of `precision_measurements` as repeats. `api_key` and the effect of the `max_points` default per series are not explained.
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 opening line names a specific regulatory standard and the exact statistics computed (linearity, precision, LOD/LOQ), so the verb+resource is unambiguous. It does not, however, distinguish itself from nearby siblings such as covnmr_qnmr_advanced or covauv_validate, leaving the agent to infer the boundary.
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 through input requirements ("AT LEAST FIVE points", "Give `noise_rms` for LOD/LOQ") and the criteria for `overall_passes`, which tells the agent what data it must supply. There is no explicit statement of when to prefer this over a sibling validation or QNMR tool, and no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Publication-style NMR text -> a structured peak list.
Paste the string as it appears in an SI or a paper, e.g.
"13C NMR (100 MHz, CDCl3): d 58.4, 18.2" or
"1H NMR (400 MHz, CDCl3): d 7.26 (d, J = 8.1 Hz, 2H), 1.25 (t, 3H)".
The nucleus is read off the header and stamped on every peak, which is
what stops a pasted 13C list from being scored against proton
predictions; text with several headers comes back in `peaks_by_nucleus`.
Multi-step: pass `peaks` to covnmr_verify (one structure) or
covnmr_rank_candidates (several). Bounded at `max_peaks` (1000);
`n_parsed` is the untruncated count. Read `warnings`: every value that was
repaired (e.g. "149. 6" read as 149.6) or dropped is named there, so a
clean parse has `warnings: []`.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| api_key | No | ||
| max_peaks | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden and does so: it discloses nucleus inference from the header, the `peaks_by_nucleus` shape for multi-header text, the 1000-peak truncation boundary with `n_parsed` as the untruncated count, and that silent repairs/drops are named in `warnings`. That is precisely the behavior an agent needs to interpret results.
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 one-line summary followed by examples, routing, and behavioral notes — each block earns its place. It runs long and the final block packs several distinct facts (truncation, multi-step, warnings) into dense prose, but nothing is 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?
An output schema exists so return-shape explanation is optional, yet the description still covers nucleus stamping, truncation, and warnings. The only real gaps are authentication expectations for `api_key` and whether API-key setup is required before calling.
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%, so the description must compensate; it explains `text` (paste verbatim as in an SI) and `max_peaks` (bounded at 1000, with truncation semantics tied to `n_parsed`). The `api_key` parameter is left entirely undocumented in both schema and description.
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?
Opens with a precise verb+resource mapping: "Publication-style NMR text -> a structured peak list." It is instantly distinguishable from siblings like covnmr_verify or covnmr_rank_candidates, which are explicitly named as downstream consumers rather than peers.
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 concrete input examples (13C and 1H header formats) and then routes the agent: "pass `peaks` to covnmr_verify (one structure) or covnmr_rank_candidates (several)." Alternatives and the condition selecting each are stated outright, not inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Predict NMR from a SMILES, no spectrum needed: chemical shifts, a synthetic spectrum, or a DEPT subspectrum. For planning and comparison before measurement.
`output`:
* "shifts" (default): per-atom predicted shifts for `nucleus` (default
1H). Where an atom has an uncertainty interval it is given, and where it
has none the response says why; `predictor` says which predictor
answered and for how many atoms.
* "spectrum": the coupling-resolved synthetic spectrum with multiplets,
J-couplings and integrals. Absorbs the retired covnmr_predict_spectrum.
* "dept135" / "dept90": a 13C DEPT subspectrum (CH/CH3 positive, CH2
negative, quaternaries absent; DEPT-90 CH only); each peak carries its
`sign` and `dept_class`. Absorbs the retired
covnmr_predict_dept_spectrum.
The curve is decimated to `max_points` (2048, ceiling 16384; 0 returns the
peak list only). Without `field_mhz` a 400 MHz spectrometer is assumed and
`field_mhz_source` says "default". To score the prediction against a
measured spectrum, use covnmr_verify.
Nuclei: 1H, 13C and 19F. 31P is REFUSED (`unsupported_nucleus`): there is
no 31P predictor, only one typical value per bonding class, and it missed
real compounds by 21-38 ppm. Pass `allow_experimental=true` to get it
anyway, marked `maturity: "experimental"` with a +/-40 ppm uncertainty.
| Name | Required | Description | Default |
|---|---|---|---|
| output | No | ||
| smiles | Yes | ||
| api_key | No | ||
| nucleus | No | ||
| solvent | No | ||
| field_mhz | No | ||
| max_points | No | ||
| linewidth_hz | No | ||
| allow_experimental | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so thoroughly: it explains default assumptions (400 MHz, field_mhz_source), output-mode behavior, decimation limits, uncertainty reporting, predictor metadata, DEPT sign conventions, and a reasoned refusal of 31P with an experimental override and uncertainty range.
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 front-loaded with purpose and uses clear bullet structure for output modes. It is somewhat long due to detailed 31P and retired-tool explanations, but those details are relevant and not redundant with the schema.
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?
Given a complex prediction tool with no annotations, 0% schema coverage, and nine parameters, the description covers most critical behavior and output modes. The remaining gap is limited semantic coverage for a few parameters such as solvent and linewidth_hz.
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%, so the description must compensate. It adds substantial meaning for key parameters—output modes, nucleus defaults and refusals, max_points default/ceiling/zero behavior, field_mhz default, and allow_experimental—but it does not explain solvent, linewidth_hz, or api_key.
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 opens with a specific verb and resource: 'Predict NMR from a SMILES' and enumerates the concrete outputs (chemical shifts, synthetic spectrum, DEPT subspectrum). It distinguishes itself from sibling covnmr_verify by pointing to it for scoring predictions against measured spectra.
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?
It states the use case ('For planning and comparison before measurement'), names the explicit alternative for a related task ('To score the prediction against a measured spectrum, use covnmr_verify'), and gives a detailed when/when-not for 31P including the escape hatch via allow_experimental=true.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
qNMR purity with an internal standard (USP <761>), with an uncertainty
budget. Needs standard_protons, analyte_protons, analyte_mw (or
analyte_formula), and standard_conc_mm unless the masses are given.
NAME THE TWO SIGNALS: `standard_peak_ppm` (older name `reference_peak_ppm`)
and `analyte_peak_ppm`. A named signal that is not found within
`selection_tolerance_ppm` (0.3) is an error, never the nearest line
instead; 0.0 is a real shift (TMS). The response's `selection` block names
the regions integrated, so the number can be checked against the spectrum.
Optional `analyte_signals`, e.g. [{"ppm": 3.80, "protons": 3}, {"ppm": 1.20,
"protons": 6}], quantifies the analyte on each listed signal and reports
the signals that disagree beyond the integration uncertainty -- the usual
sign of an overlapping impurity. Give `sample_mass_mg` and
`sample_volume_ml` for a mass-based purity. `smiles` is accepted for older
callers and not used.
Traceable purity (USP <761> budget): give `analyte_mass_mg`,
`standard_mass_mg` and `standard_purity`. `purity_traceable` then holds the
mass-fraction purity, a row per input in `budget` (value, uncertainty,
share of the variance), the dominant source, and the expanded uncertainty
with its coverage factor. Inputs you gave no uncertainty for are filled
with stated defaults and listed in `assumed`. Name the standard with
`internal_standard` (e.g. "maleic_acid", "dss", "tms") to take its molar
mass and signals from the table; an unknown name is an error
(`unknown_internal_standard`), and a standard whose signals overlap an
analyte region is refused (`internal_standard_overlap`).
`system_suitability` always checks S/N, baseline, phase and relaxation;
give `t1_longest_s` and `relaxation_delay_s` (else read from the file) or
the relaxation test stays untested. A failed check is listed; it does not
withhold the number. `audit=true` adds `audit_record`, a hash-chained
record of inputs, steps and result (no electronic signature); it names
your file as `display_name`, else the file name in the URL. For ERETIC,
PULCON or a purity from integrals you already have, use
covnmr_qnmr_advanced.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| audit | No | ||
| smiles | No | ||
| api_key | No | ||
| nucleus | No | ||
| solvent | No | CDCl3 | |
| analyte_mw | No | ||
| min_sn_qnmr | No | ||
| standard_mw | No | ||
| display_name | No | ||
| t1_longest_s | No | ||
| u_analyte_mw | No | ||
| u_balance_mg | No | ||
| u_standard_mw | No | ||
| sample_mass_mg | No | ||
| analyte_formula | No | ||
| analyte_mass_mg | No | ||
| analyte_protons | No | ||
| analyte_signals | No | ||
| coverage_factor | No | ||
| standard_purity | No | ||
| analyte_peak_ppm | No | ||
| confidence_level | No | ||
| sample_volume_ml | No | ||
| standard_conc_mm | No | ||
| standard_formula | No | ||
| standard_mass_mg | No | ||
| standard_protons | No | ||
| internal_standard | No | ||
| standard_peak_ppm | No | ||
| standard_purity_k | No | ||
| u_analyte_mass_mg | No | ||
| u_analyte_protons | No | ||
| u_integration_rel | No | ||
| u_standard_purity | No | ||
| acquisition_time_s | No | ||
| reference_peak_ppm | No | ||
| relaxation_delay_s | No | ||
| u_standard_mass_mg | No | ||
| u_standard_protons | No | ||
| selection_tolerance_ppm | No | ||
| integral_ratio_replicates | No | ||
| expanded_u_standard_purity | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses hard error conditions (signal not found, unknown_internal_standard, internal_standard_overlap), states that system_suitability failures are reported but do not withhold the number, and warns that audit_record is hash-chained but not an electronic signature. What it omits is operational context — whether api_key implies a remote/paid service, and what auth or rate limits apply.
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?
Roughly 350 words, but nearly all of it is load-bearing for a 43-parameter tool, and the minimum viable call (path + two named peaks + standard quantity) is front-loaded. Some param lists are prose-dense and could be tightened, but there is 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?
An output schema exists, so return values need no exposition; the description still points at the key response blocks (selection, budget, assumed, purity_traceable, audit_record) so the agent knows how to verify results. For a complex multi-mode tool it covers each mode — basic, multi-signal, mass-based, traceable, audit — and names when another tool applies.
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 43 parameters, so the description must compensate. It explains the critical workflow parameters well (standard/analyte protons, mw/formula, conc, peak ppm names, selection_tolerance_ppm default 0.3, analyte_signals shape), but roughly half the surface is untouched: nucleus, solvent, min_sn_qnmr, acquisition_time_s, integral_ratio_replicates, coverage_factor, confidence_level, standard_purity_k, expanded_u_standard_purity, and the ten u_* uncertainty inputs are only obliquely implied by the 'assumed defaults' sentence.
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?
Opens with a specific verb+resource: qNMR purity by internal standard per USP <761> with an uncertainty budget. It explicitly separates itself from the sibling covnmr_qnmr_advanced (ERETIC, PULCON, pre-computed integrals), so an agent can route without opening either 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?
The description names the alternative tool and the exact condition that selects it. It also gives conditional guidance: give sample_mass_mg/sample_volume_ml for mass-based purity, give the three masses plus standard_purity for a traceable budget, and use covnmr_qnmr_advanced otherwise.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
qNMR from integrals you already have: ERETIC, PULCON, a full uncertainty budget, or a traceable purity. For an internal-standard purity from a spectrum file use covnmr_purity.
`method` selects which arguments are read; a missing required one is an
error that names it (`missing`), never a silent default:
* "eretic" (electronic reference): `analyte_integral`, `eretic_integral`,
`eretic_response_factor`, `analyte_protons`, `analyte_mw`. Give
`sample_mass_mg` for `weight_percent`; without it `weight_percent` is
null and `weight_percent_status` says "not_computed".
* "pulcon" (reference in a separate tube): `analyte_integral`,
`analyte_protons`, `analyte_mw`, `reference_integral`,
`reference_protons`, `reference_conc_mm`; optional T1s, recycle delay and
the two fields. Check `t1_correction_factor` -- that is where an
over-short recycle delay shows up.
* "uncertainty" (GUM budget of an internal-standard result):
`analyte_integral`, `standard_integral`, `standard_conc_mm`,
`standard_protons`, `analyte_protons`, `analyte_mw`; optional
`standard_purity` and the u_* inputs. Returns `components`,
`dominant_source`, `combined_u_rel` and the k=2 expanded uncertainty;
`n_sources_default_constant` counts the sources you did not supply.
* "purity" (USP <761> mass-fraction purity, no spectrum):
`analyte_mass_mg`, `standard_mass_mg`, `standard_purity`,
`analyte_protons`, `standard_protons`; the ratio from
`analyte_integral` + `standard_integral`, `integral_ratio` or
`integral_ratio_replicates`; the molar masses from `analyte_mw` /
`analyte_formula` and `standard_mw` / `standard_formula` /
`internal_standard`. Returns the same budget as covnmr_purity's
`purity_traceable`, at top level, plus `system_suitability` (from your
`sn_standard`, `sn_analyte`, `relaxation_delay_s`, `t1_longest_s`) and
`internal_standard_check` (from the shifts you state; an overlap is the
error `internal_standard_overlap`). `audit=true` adds `audit_record`.
Each method returns a different key set; `method` is echoed back.
| Name | Required | Description | Default |
|---|---|---|---|
| audit | No | ||
| method | Yes | ||
| api_key | No | ||
| solvent | No | ||
| analyte_mw | No | ||
| sn_analyte | No | ||
| min_sn_qnmr | No | ||
| sn_standard | No | ||
| standard_mw | No | ||
| u_volume_ml | No | ||
| analyte_t1_s | No | ||
| t1_longest_s | No | ||
| u_analyte_mw | No | ||
| u_balance_mg | No | ||
| u_standard_mw | No | ||
| u_weighing_mg | No | ||
| integral_ratio | No | ||
| reference_t1_s | No | ||
| sample_mass_mg | No | ||
| u_baseline_rel | No | ||
| analyte_formula | No | ||
| analyte_mass_mg | No | ||
| analyte_protons | No | ||
| coverage_factor | No | ||
| eretic_integral | No | ||
| recycle_delay_s | No | ||
| standard_purity | No | ||
| u_lineshape_rel | No | ||
| analyte_integral | No | ||
| analyte_peak_ppm | No | ||
| confidence_level | No | ||
| sample_volume_ml | No | ||
| standard_conc_mm | No | ||
| standard_formula | No | ||
| standard_mass_mg | No | ||
| standard_protons | No | ||
| analyte_field_mhz | No | ||
| internal_standard | No | ||
| reference_conc_mm | No | ||
| reference_protons | No | ||
| standard_integral | No | ||
| standard_peak_ppm | No | ||
| standard_purity_k | No | ||
| u_analyte_mass_mg | No | ||
| u_analyte_protons | No | ||
| u_integration_rel | No | ||
| u_standard_purity | No | ||
| u_temperature_rel | No | ||
| acquisition_time_s | No | ||
| analyte_ranges_ppm | No | ||
| reference_integral | No | ||
| relaxation_delay_s | No | ||
| u_standard_mass_mg | No | ||
| u_standard_protons | No | ||
| analyte_signals_ppm | No | ||
| reference_field_mhz | No | ||
| u_t1_saturation_rel | No | ||
| overlap_tolerance_ppm | No | ||
| eretic_response_factor | No | ||
| integral_ratio_replicates | No | ||
| expanded_u_standard_purity | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and largely does: it states that a missing required argument raises a named error rather than silently defaulting, that weight_percent is null with weight_percent_status='not_computed' when sample_mass_mg is absent, that audit=true adds audit_record, and that each method returns a different key set. It does not mention api_key/auth requirements or whether calls are side-effect free, which is the remaining gap for a computational tool with no 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?
Long but well structured: a one-line summary, an explicit sibling redirect, then a bulleted per-method block keyed on the `method` value, which is the natural reading order for a dispatcher tool. Almost every clause carries information (the t1_correction_factor warning is a genuine tip), though 'the two fields' and a few unelaborated key names cost clarity.
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 61-parameter polymorphic tool with no annotations, the description covers the critical dispatch information — which parameters each method reads, what error semantics to expect, and which result keys differ — and the output schema handles return shapes. It is not fully complete because roughly a third of the parameters (uncertainty-budget knobs like coverage_factor and confidence_level, overlap_tolerance_ppm, solvent, api_key) are never explained, leaving the agent to guess when to supply them.
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 61 parameters, so the description must compensate, and it does for the core: it enumerates the exact required inputs per method plus notable optionals (sample_mass_mg, T1s, recycle delay, standard_purity, the u_* inputs, integral_ratio_replicates). A substantial tail remains undocumented — confidence_level, coverage_factor, overlap_tolerance_ppm, min_sn_qnmr, solvent, api_key, analyte_peak_ppm/standard_peak_ppm — and the phrase 'the two fields' is ambiguous where it should say analyte_field_mhz/reference_field_mhz.
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 first line states a precise verb and resource — quantitative NMR computed from integrals the caller already has — and enumerates the four supported calculation modes (ERETIC, PULCON, GUM uncertainty, USP <761> purity). It explicitly names the sibling it is not (covnmr_purity for internal-standard purity from a spectrum file), so an agent can route without opening either 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?
The sibling boundary is stated explicitly ('For an internal-standard purity from a spectrum file use covnmr_purity'), and each parenthetical gloss ('electronic reference' vs 'reference in a separate tube') hints at when a method fits. It stops short of explicit when-not guidance for each mode (e.g. no stated condition that rules out ERETIC in favour of PULCON), so it is clear context rather than a full decision rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rank several candidate structures against one measured spectrum.
Candidates: `candidates` (list of SMILES), `candidates_csv`
("CCO,CC(=O)O") or `candidates_json`. Spectrum: `path`, else a peak list
(`peaks` / `peaks_json`, `experiments` / `experiments_json`).
GIVE `path` IF YOU HAVE THE FILE: only the file makes the second axis --
overlap of each candidate's full predicted curve with the measured one --
available. Measured on a real 13C APT of a triterpene, the correct
structure ranked first on both axes against n-hexadecane and glucose
(curve 0.37 vs 0.06/0.08). With `path` the order is the curve axis and each
row says whether the peak axis agrees (`agreement`); with a peak list only,
the order is the evidence log-likelihood ratio. The peak axis DECLINES --
`ranking_basis` "declined_unassessable_peak_list", every `rank` null --
when a candidate's evidence cannot be computed (19F/31P, fallback
predictor). Read `ranking_basis` before `ranked`: a null `rank` is the tool
declining to answer, not a tie.
Capped at `max_candidates` (50). With `path` the file decides nucleus,
solvent and field (`nucleus_source`). Multi-step: confirm the winner with
covnmr_verify, or covnmr_sudoku when you have 2D data.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | ||
| peaks | No | ||
| api_key | No | ||
| nucleus | No | ||
| solvent | No | CDCl3 | |
| field_mhz | No | ||
| candidates | No | ||
| peaks_json | No | ||
| experiments | No | ||
| tolerance_ppm | No | ||
| candidates_csv | No | ||
| max_candidates | No | ||
| candidates_json | No | ||
| experiments_json | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and largely meets it: it discloses that result ordering depends on input mode, that a null `rank` means the tool declined rather than tied (`ranking_basis` "declined_unassessable_peak_list" for 19F/31P or fallback predictor), the 50-candidate cap, and that the file overrides nucleus/solvent/field. It stops short of covering the api_key/auth requirement and tolerance_ppm behavior, which leaves a residual gap for a 14-parameter tool.
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 purpose, then inputs, then the critical `path` guidance, then failure semantics and next steps — a sensible order with little pure filler. It is dense and slightly over-long for the payoff in a couple of spots (the triterpene benchmark anecdote), but nothing is meaningfully wasted.
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?
Given an output schema exists, the description needn't explain return values, and it still pre-empts the one thing the schema cannot convey: that `ranking_basis` should be read before `ranked` and that null ranks are refusals. Combined with input-mode tradeoffs and follow-up routing, an agent has enough to call it correctly.
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%, so the description must compensate, and it does for most input parameters: it explains the three candidate formats (with a CSV example), the path vs peaks/peaks_json/experiments/experiments_json split, and max_candidates = 50. It never mentions api_key or tolerance_ppm, and it only implicitly covers nucleus/solvent/field_mhz via the file, leaving several of 14 parameters undocumented anywhere.
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 first line states a specific verb and both operands: rank candidate structures against one measured spectrum. The body then distinguishes the two candidate-input families and the two spectrum-input families, and it names the sibling tools (covnmr_verify, covnmr_sudoku) that follow, so an agent can place it in the workflow 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?
Explicit conditional guidance: "GIVE `path` IF YOU HAVE THE FILE" with the consequence (second axis only available with a file), plus what happens when only a peak list is supplied. It also ends with a concrete next-step routing to covnmr_verify and covnmr_sudoku. This is about as close to when/when-not/alternatives as a description gets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up NMR reference data -- no spectrum needed.
`category`:
* "shift_range" -- typical shift window for a functional group, for
`nucleus` (1H by default, or 13C). A nucleus with no table returns status
"error" (`unsupported_nucleus`) with `results: []`, never the proton
table.
* "coupling" -- J-coupling ranges by type (vicinal, geminal, ...).
* "solvent" -- residual solvent peaks, one record per solvent with its
1H / 13C / 19F / 31P shifts.
* "all" (default) -- every table, grouped matches.
An empty `query` is a legitimate "show me the table" request. Bounded at
`max_results` (50) per category; `n_results` is the untruncated count.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| api_key | No | ||
| nucleus | No | ||
| category | No | all | |
| max_results | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description does substantial work: it discloses the unsupported_nucleus error contract ('results: [], never the proton table'), truncation semantics (bounded at max_results 50 per category, n_results is the untruncated count), and that empty query is valid. It does not address the api_key parameter, auth requirements, or cost, which is the remaining gap for an unannotated tool.
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 front-loaded sentence states purpose and precondition, then a tightly structured bullet list gives per-category semantics. Every line carries distinct information — defaults, error behavior, or truncation — with no restatement of the tool name or 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?
An output schema exists, so return shape needn't be described, and the description instead covers what the schema cannot: error status values, the no-fallback guarantee for unsupported nuclei, truncation accounting, and default category/nucleus behavior. That is everything needed to invoke this correctly aside from auth details.
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%, so the description must carry parameter meaning, and it does for four of five: category values are fully enumerated with per-value semantics, nucleus gets its default (1H) and the allowed alternate (13C), query gets the empty-string interpretation, and max_results gets a bound. Only api_key is left completely unexplained.
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 ('Look up NMR reference data') and immediately carves out scope with 'no spectrum needed', which separates it from the many covnmr_* analysis tools that do require spectra. The four enumerated category values make the tool's coverage concrete rather than generic.
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 'no spectrum needed' precondition implicitly routes agents away from covnmr_analyze/identify toward this table-lookup tool, and 'An empty query is a legitimate "show me the table" request' gives explicit guidance on an edge case agents would otherwise avoid. It stops short of naming sibling tools or stating when this should be skipped in favor of them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
USP <761> system suitability: linewidth (FWHM) of the reference line,
signal-to-noise, peak asymmetry. Also the quick quality check: it absorbs
the retired covnmr_quality, whose S/N block is now the quality field.
`verdict` is pass / fail / incomplete, or "reference_not_found" when no
line is in reach of `reference_peak_ppm` (default 0.0, TMS). S/N is
evaluated only when `signal_ppm` is given, and a suite with an unevaluated
criterion reports "incomplete" (`not_tested`), never a pass. Limits default
to `max_linewidth_hz` 1.0 and `min_sn` 250. The linewidth is the
instrument's (no line broadening unless `line_broadening_hz` is given); the
spectrometer frequency comes from the file unless `field_mhz` is given.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| min_sn | No | ||
| api_key | No | ||
| nucleus | No | ||
| solvent | No | CDCl3 | |
| field_mhz | No | ||
| signal_ppm | No | ||
| max_linewidth_hz | No | ||
| line_broadening_hz | No | ||
| reference_peak_ppm | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden well: it discloses the full verdict vocabulary (pass/fail/incomplete/reference_not_found), the rule that an untested criterion can never yield pass, and the limit defaults (1.0 Hz, 250 S/N, 0.0 ppm reference). It does not state that this is a read-only analysis (no mutation, no data destruction) or anything about auth/api_key expectations, which leaves a small gap for a zero-annotation tool.
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 first sentence front-loads what is measured, followed by verdict semantics and defaults, so the important content is early. It is dense but nearly every sentence carries operational information; the regression note about absorbing covnmr_quality is mildly extraneous but brief.
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?
Because an output schema exists, the description needn't describe return structure, and its coverage of verdict logic, defaults, and conditional evaluation is enough for a 10-parameter tool. The gaps are the undocumented nucleus/solvent/api_key/path parameters and the absence of any read-only/mutation disclosure.
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 0%, so the description must supply parameter meaning, and it does for the domain-critical ones: min_sn (250), max_linewidth_hz (1.0), reference_peak_ppm (0.0, TMS), plus the conditional semantics of signal_ppm, field_mhz, and line_broadening_hz. However, four parameters — path, api_key, nucleus, and solvent (default CDCl3) — receive no explanation at all, leaving a material gap at 0% schema coverage.
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 standard (USP <761>) and the exact quantities measured: FWHM linewidth of the reference line, signal-to-noise, and peak asymmetry. It also explicitly distinguishes itself from a retired sibling (covnmr_quality), so an agent can place it among covnmr_method_validate and covnmr_verify 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?
It gives clear conditional guidance: S/N is only evaluated when `signal_ppm` is supplied, linewidth reflects the instrument unless `line_broadening_hz` is given, and the frequency comes from the file unless `field_mhz` is provided. What's missing is explicit routing against other nmr validation siblings (e.g., method_validate/verify), so it stops short of full alternative selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Assign every atom of a KNOWN molecule from several experiments at once (1H, 13C, APT, DEPT-135, DEPT-90, HSQC, HMBC, COSY), by constraint propagation across all of them.
Absorbs the retired covnmr_multi_analyze (`output="table"`: one row per
atom, per-experiment summaries, publication NMR strings, and the atoms
nothing could be assigned to with a reason) and the 2D form of
covnmr_assign (`paths_2d`: [{"experiment": "HSQC"|"HMBC"|"COSY",
"path": "<url>"}]). Default `output="assignments"` returns the solver's
assignment with `explanation`, which says why atoms stayed unassigned.
The carbon-edited slots say different things: an APT shows every carbon
and separates them by the PARITY of the proton count; a DEPT-135 shows only
protonated carbons (CH2 negative); a DEPT-90 shows CH only. Supply a
DEPT-135 together with a plain 13C whenever you have both: the quaternary
carbons come from the difference. The file decides which sequence it is --
a spectrum in the wrong slot is analysed as what it is and named in
`experiment_warnings`, as is every experiment that did not enter the
solve. `path` takes one 1D file whose own nucleus picks the slot.
Omit `tolerance_ppm` and each experiment gets its nucleus' window (1H 0.3
ppm, 13C 3.0). In the table, `sudoku_result.verdict` is the most cautious
of the per-nucleus verdicts; `match_score` is coverage and decides nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | ||
| output | No | ||
| smiles | Yes | ||
| api_key | No | ||
| path_1h | No | ||
| solvent | No | CDCl3 | |
| max_rows | No | ||
| path_13c | No | ||
| path_apt | No | ||
| paths_2d | No | ||
| field_mhz | No | ||
| path_cosy | No | ||
| path_dept | No | ||
| path_hmbc | No | ||
| path_hsqc | No | ||
| path_dept90 | No | ||
| path_dept135 | No | ||
| tolerance_ppm | No | ||
| max_crosspeaks | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: it explains the two output modes (assignments vs table), that unassigned atoms come with a reason, that experiment_warnings names misfiled or unused experiments, that tolerance defaults are per-nucleus (1H 0.3, 13C 3.0), and that verdict is the most cautious per-nucleus result while match_score decides nothing. These are exactly the behavioral details an agent cannot infer elsewhere.
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-loads the core action in the first sentence, then layers output options and per-experiment semantics in a logical order. It is dense and the retired-tool paragraph is somewhat historical, but nearly every sentence conveys information an agent needs to fill slots correctly.
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, yet the description still usefully explains the shape of assignments/table results and warning behavior. For a 19-param tool with no annotations it is nearly complete, with the main gaps being the role of solvent, field_mhz, and the max_rows/max_crosspeaks limits.
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 0% across 19 params, so the description must compensate, and it does for the hard ones: output modes, paths_2d format with experiment/path pairs, the single-file path slot, the APT/DEPT-135/DEPT-90 distinctions, and tolerance_ppm defaults. It leaves several parameters (solvent, field_mhz, max_rows, max_crosspeaks, api_key) unexplained, so it is strong but not complete.
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 — 'Assign every atom of a KNOWN molecule' — and adds the distinguishing mechanism ('constraint propagation across all of them'). The emphasis on KNOWN molecule implicitly separates it from identification siblings like covnmr_identify or covnmr_rank_candidates, so an agent can tell what it is for 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?
Gives concrete when-to guidance: supply DEPT-135 with a plain 13C when both exist, and the quaternary carbons come from the difference; it also notes that a spectrum in the wrong slot is analysed as what it is. It stops short of explicitly routing against live siblings (e.g. covnmr_analyze) and only names the retired tools it absorbs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Does this NMR data match this structure (smiles, required)? Returns a
verdict, the evidence it was read from, and per-atom assignments.
The data is ONE of: a spectrum file (`path`), a peak list (`peaks`, or its
JSON text `peaks_json`), or peak lists keyed by experiment (`experiments` /
`experiments_json`, e.g. {"1H": [...], "13C": [...]}). Absorbs the retired
covnmr_verify_peaks (the peak-list form) and the 1D form of covnmr_assign.
Multi-step: paste literature text into covnmr_parse_nmr_string first and
pass its `peaks` here.
READ `verdict` AND `evidence`, NOT `match_score`. `verdict` ("match" /
"possible match" / "inconclusive" / "no match") comes from decoy-calibrated
evidence (`evidence.z`, the share of the spectrum left unexplained, and
thresholds set on decoy structures in `evidence.verdict_calibration`).
`match_score` is coverage (`match_score_basis`) and decides nothing. A
structure with fewer predicted signals than any calibrated one gets
"inconclusive"; 19F and 31P have no error model, so on their own they are
always "inconclusive".
A peak list that declares its nucleus outranks `nucleus`; a list spanning
several nuclei is scored per nucleus (`per_nucleus`) and the combined
verdict is the most cautious of the nuclei that have an error model. 19F
and 31P are still scored but do not set that verdict
(`nuclei_not_in_verdict` says why). With `path` the file decides the
nucleus.
`peaks_json` may also be the whole answer of covnmr_parse_nmr_string
({"nucleus": ..., "peaks": [...]}); its nucleus counts as the list's own.
Combine 1H/13C with HRMS, from a file or a peak list: pass `hrms`, e.g.
{"formula": "C9H8O4", "mz": 181.0495, "adduct": "[M+H]+"}. The response
then lists each check in `evidence_checks` -- HRMS formula, HRMS mass
within `hrms_ppm_tolerance` ppm (default 10), the 1H integral sum against
the proton count, the 13C line count against the carbon count, and the
shifts -- and gives one answer in `verdict_combined`: a failed HRMS check
makes it "no match", a failed count check caps it at "inconclusive",
otherwise it is the shift verdict. `verdict` itself is unchanged. The count
checks run on a file too (from its integrals and picked lines).
Give `candidates` (up to 20 alternative SMILES) and `verdict_relative` says
whether this structure beats the best alternative. It may also say the
data cannot tell this structure from a regioisomer: then it is
"inconclusive" with `regioisomer_ambiguous: true`, and
`competing_candidate` names the regioisomer that is not ruled out. Omit
`tolerance_ppm` and the window follows the nucleus (1H 0.3 ppm, 13C 3.0).
For several spectra or 2D data of one compound use covnmr_sudoku.
| Name | Required | Description | Default |
|---|---|---|---|
| hrms | No | ||
| path | No | ||
| peaks | No | ||
| smiles | No | ||
| api_key | No | ||
| nucleus | No | ||
| solvent | No | CDCl3 | |
| max_peaks | No | ||
| candidates | No | ||
| peaks_json | No | ||
| experiments | No | ||
| tolerance_ppm | No | ||
| max_unassigned | No | ||
| experiments_json | No | ||
| hrms_ppm_tolerance | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so: it warns that `match_score` is coverage and 'decides nothing', that verdicts come from decoy-calibrated evidence, that 19F/31P have no error model and are always 'inconclusive' alone, and how `verdict_combined` is capped by failed HRMS/count checks. It also discloses the default ppm windows (1H 0.3, 13C 3.0) and the regioisomer-ambiguity outcome.
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 question and the input-form menu before the interpretive detail, and each paragraph has a distinct job (inputs, verdict semantics, multi-nucleus, HRMS, candidates). It is dense and long at ~350 words, though nearly every sentence carries non-obvious behavioral information rather than 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 15-parameter, annotation-free tool the description covers the decision-relevant surface: how to supply data, how the verdict is computed, HRMS combination logic, and candidate comparison. Gaps remain around max_peaks, max_unassigned, solvent, and api_key; the output schema being present means return-value enumeration is rightly omitted.
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 0% across 15 params, so the description must compensate and largely does: it explains smiles, path, peaks, peaks_json (which may be a whole covnmr_parse_nmr_string answer), experiments/experiments_json, nucleus precedence, hrms sub-fields, hrms_ppm_tolerance default (10), tolerance_ppm defaults, and candidates (up to 20). It leaves max_peaks, max_unassigned, solvent, and api_key unexplained, so not fully compensating.
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?
Opens with a specific question-form verb+resource: 'Does this NMR data match this structure', with `smiles` flagged as required. It also positions itself against siblings by naming covnmr_parse_nmr_string as a prerequisite step and covnmr_sudoku as the tool for multi-spectrum/2D cases, and notes it absorbs the retired covnmr_verify_peaks and the 1D form of covnmr_assign.
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?
Explicit routing: 'paste literature text into covnmr_parse_nmr_string first and pass its `peaks` here', and 'For several spectra or 2D data of one compound use covnmr_sudoku.' It also states which input form to pick (path vs peaks vs peaks_json vs experiments) and when to add `hrms` to combine 1H/13C with mass spec.
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.
covnmr_analyze9 fields changedInput schema / properties / auditAdded value: +{
+ "default": false,
+ "title": "Audit",
+ "type": "boolean"
+}Input schema / properties / compound_nameAdded value: +{
+ "default": "",
+ "title": "Compound Name",
+ "type": "string"
+}Input schema / properties / display_nameAdded value: +{
+ "default": "",
+ "title": "Display Name",
+ "type": "string"
+}Input schema / properties / export_pointsAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Export Points"
+}Input schema / properties / hrmsAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Hrms"
+}Input schema / properties / hrms_ppm_toleranceAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Hrms Ppm Tolerance"
+}Input schema / properties / max_content_charsAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Max Content Chars"
+}Input schema / properties / operatorAdded value: +{
+ "default": "",
+ "title": "Operator",
+ "type": "string"
+}Input schema / properties / output_formatAdded value: +{
+ "default": "",
+ "title": "Output Format",
+ "type": "string"
+}covnmr_assigncovnmr_audit_reportcovnmr_batch1 field changedInput schema / properties / nucleus / defaultPrevious value: -"1H"New value: +""covnmr_compare3 fields changedInput schema / properties / nucleus / defaultPrevious value: -"1H"New value: +""Input schema / properties / solventAdded value: +{
+ "default": "",
+ "title": "Solvent",
+ "type": "string"
+}Input schema / properties / tolerance_ppmAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Tolerance Ppm"
+}covnmr_elucidatecovnmr_exportcovnmr_formatcovnmr_identify1 field changedInput schema / properties / tolerance_ppmAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Tolerance Ppm"
+}covnmr_impurity1 field changedInput schema / properties / nucleusAdded value: +{
+ "default": "",
+ "title": "Nucleus",
+ "type": "string"
+}covnmr_method_validate3 fields changedInput schema / properties / noise_rms / anyOfAdded value: +[
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / noise_rms / defaultPrevious value: -0New value: +nullInput schema / properties / noise_rms / typeRemoved value: -"number"covnmr_multi_analyzecovnmr_predict7 fields changedInput schema / properties / allow_experimentalAdded value: +{
+ "anyOf": [
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Allow Experimental"
+}Input schema / properties / field_mhzAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Field Mhz"
+}Input schema / properties / linewidth_hzAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Linewidth Hz"
+}Input schema / properties / max_pointsAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Max Points"
+}Input schema / properties / nucleus / defaultPrevious value: -"1H"New value: +""Input schema / properties / outputAdded value: +{
+ "default": "",
+ "title": "Output",
+ "type": "string"
+}Input schema / properties / solventAdded value: +{
+ "default": "",
+ "title": "Solvent",
+ "type": "string"
+}covnmr_predict_dept_spectrumcovnmr_predict_spectrumcovnmr_purity56 fields changedInput schema / properties / acquisition_time_sAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Acquisition Time S"
+}Input schema / properties / analyte_formulaAdded value: +{
+ "default": "",
+ "title": "Analyte Formula",
+ "type": "string"
+}Input schema / properties / analyte_mass_mgAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Analyte Mass Mg"
+}Input schema / properties / analyte_mw / anyOfAdded value: +[
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / analyte_mw / defaultAdded value: +nullInput schema / properties / analyte_mw / typeRemoved value: -"number"Input schema / properties / analyte_peak_ppm / anyOfAdded value: +[
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / analyte_peak_ppm / defaultPrevious value: -0New value: +nullInput schema / properties / analyte_peak_ppm / typeRemoved value: -"number"Input schema / properties / analyte_protons / anyOfAdded value: +[
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / analyte_protons / defaultAdded value: +nullInput schema / properties / analyte_protons / typeRemoved value: -"integer"Input schema / properties / auditAdded value: +{
+ "anyOf": [
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Audit"
+}Input schema / properties / confidence_levelAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Confidence Level"
+}Input schema / properties / coverage_factorAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Coverage Factor"
+}Input schema / properties / display_nameAdded value: +{
+ "default": "",
+ "title": "Display Name",
+ "type": "string"
+}Input schema / properties / expanded_u_standard_purityAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Expanded U Standard Purity"
+}Input schema / properties / integral_ratio_replicatesAdded value: +{
+ "anyOf": [
+ {
+ "items": {
+ "type": "number"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Integral Ratio Replicates"
+}Input schema / properties / internal_standardAdded value: +{
+ "default": "",
+ "title": "Internal Standard",
+ "type": "string"
+}Input schema / properties / min_sn_qnmrAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Min Sn Qnmr"
+}Input schema / properties / nucleusAdded value: +{
+ "default": "",
+ "title": "Nucleus",
+ "type": "string"
+}Input schema / properties / reference_peak_ppm / anyOfAdded value: +[
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / reference_peak_ppm / defaultPrevious value: -0New value: +nullInput schema / properties / reference_peak_ppm / typeRemoved value: -"number"Input schema / properties / relaxation_delay_sAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Relaxation Delay S"
+}Input schema / properties / sample_mass_mgAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Sample Mass Mg"
+}Input schema / properties / sample_volume_mlAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Sample Volume Ml"
+}Input schema / properties / selection_tolerance_ppmAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Selection Tolerance Ppm"
+}Input schema / properties / smiles / defaultAdded value: +""Input schema / properties / standard_conc_mm / anyOfAdded value: +[
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / standard_conc_mm / defaultAdded value: +nullInput schema / properties / standard_conc_mm / typeRemoved value: -"number"Input schema / properties / standard_formulaAdded value: +{
+ "default": "",
+ "title": "Standard Formula",
+ "type": "string"
+}Input schema / properties / standard_mass_mgAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Standard Mass Mg"
+}Input schema / properties / standard_mwAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Standard Mw"
+}Input schema / properties / standard_peak_ppm / anyOfAdded value: +[
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / standard_peak_ppm / defaultPrevious value: -0New value: +nullInput schema / properties / standard_peak_ppm / typeRemoved value: -"number"Input schema / properties / standard_protons / anyOfAdded value: +[
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / standard_protons / defaultAdded value: +nullInput schema / properties / standard_protons / typeRemoved value: -"integer"Input schema / properties / standard_purity / anyOfAdded value: +[
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / standard_purity / defaultPrevious value: -1New value: +nullInput schema / properties / standard_purity / typeRemoved value: -"number"Input schema / properties / standard_purity_kAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Standard Purity K"
+}Input schema / properties / t1_longest_sAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "T1 Longest S"
+}Input schema / properties / u_analyte_mass_mgAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "U Analyte Mass Mg"
+}Input schema / properties / u_analyte_mwAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "U Analyte Mw"
+}Input schema / properties / u_analyte_protonsAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "U Analyte Protons"
+}Input schema / properties / u_balance_mgAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "U Balance Mg"
+}Input schema / properties / u_integration_relAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "U Integration Rel"
+}Input schema / properties / u_standard_mass_mgAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "U Standard Mass Mg"
+}Input schema / properties / u_standard_mwAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "U Standard Mw"
+}Input schema / properties / u_standard_protonsAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "U Standard Protons"
+}Input schema / properties / u_standard_purityAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "U Standard Purity"
+}Input schema / requiredPrevious value: -[
- "path",
- "smiles",
- "standard_conc_mm",
- "standard_protons",
- "analyte_protons",
- "analyte_mw"
-]New value: +[
+ "path"
+]covnmr_qnmr_advanced98 fields changedInput schema / properties / acquisition_time_sAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Acquisition Time S"
+}Input schema / properties / analyte_field_mhz / anyOfAdded value: +[
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / analyte_field_mhz / defaultPrevious value: -400New value: +nullInput schema / properties / analyte_field_mhz / typeRemoved value: -"number"Input schema / properties / analyte_formulaAdded value: +{
+ "default": "",
+ "title": "Analyte Formula",
+ "type": "string"
+}Input schema / properties / analyte_integral / anyOfAdded value: +[
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / analyte_integral / defaultAdded value: +nullInput schema / properties / analyte_integral / typeRemoved value: -"number"Input schema / properties / analyte_mass_mgAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Analyte Mass Mg"
+}Input schema / properties / analyte_mw / anyOfAdded value: +[
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / analyte_mw / defaultPrevious value: -0New value: +nullInput schema / properties / analyte_mw / typeRemoved value: -"number"Input schema / properties / analyte_peak_ppmAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Analyte Peak Ppm"
+}Input schema / properties / analyte_protons / anyOfAdded value: +[
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / analyte_protons / defaultAdded value: +nullInput schema / properties / analyte_protons / typeRemoved value: -"integer"Input schema / properties / analyte_ranges_ppmAdded value: +{
+ "anyOf": [
+ {
+ "items": {
+ "items": {
+ "type": "number"
+ },
+ "type": "array"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Analyte Ranges Ppm"
+}Input schema / properties / analyte_signals_ppmAdded value: +{
+ "anyOf": [
+ {
+ "items": {
+ "type": "number"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Analyte Signals Ppm"
+}Input schema / properties / analyte_t1_s / anyOfAdded value: +[
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / analyte_t1_s / defaultPrevious value: -1New value: +nullInput schema / properties / analyte_t1_s / typeRemoved value: -"number"Input schema / properties / auditAdded value: +{
+ "anyOf": [
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Audit"
+}Input schema / properties / confidence_levelAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Confidence Level"
+}Input schema / properties / coverage_factorAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Coverage Factor"
+}Input schema / properties / eretic_integral / anyOfAdded value: +[
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / eretic_integral / defaultPrevious value: -0New value: +nullInput schema / properties / eretic_integral / typeRemoved value: -"number"Input schema / properties / eretic_response_factor / anyOfAdded value: +[
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / eretic_response_factor / defaultPrevious value: -0New value: +nullInput schema / properties / eretic_response_factor / typeRemoved value: -"number"Input schema / properties / expanded_u_standard_purityAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Expanded U Standard Purity"
+}Input schema / properties / integral_ratioAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Integral Ratio"
+}Input schema / properties / integral_ratio_replicatesAdded value: +{
+ "anyOf": [
+ {
+ "items": {
+ "type": "number"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Integral Ratio Replicates"
+}Input schema / properties / internal_standardAdded value: +{
+ "default": "",
+ "title": "Internal Standard",
+ "type": "string"
+}Input schema / properties / min_sn_qnmrAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Min Sn Qnmr"
+}Input schema / properties / overlap_tolerance_ppmAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Overlap Tolerance Ppm"
+}Input schema / properties / recycle_delay_s / anyOfAdded value: +[
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / recycle_delay_s / defaultPrevious value: -30New value: +nullInput schema / properties / recycle_delay_s / typeRemoved value: -"number"Input schema / properties / reference_conc_mm / anyOfAdded value: +[
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / reference_conc_mm / defaultPrevious value: -0New value: +nullInput schema / properties / reference_conc_mm / typeRemoved value: -"number"Input schema / properties / reference_field_mhz / anyOfAdded value: +[
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / reference_field_mhz / defaultPrevious value: -400New value: +nullInput schema / properties / reference_field_mhz / typeRemoved value: -"number"Input schema / properties / reference_integral / anyOfAdded value: +[
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / reference_integral / defaultPrevious value: -0New value: +nullInput schema / properties / reference_integral / typeRemoved value: -"number"Input schema / properties / reference_protons / anyOfAdded value: +[
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / reference_protons / defaultPrevious value: -1New value: +nullInput schema / properties / reference_protons / typeRemoved value: -"integer"Input schema / properties / reference_t1_s / anyOfAdded value: +[
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / reference_t1_s / defaultPrevious value: -1New value: +nullInput schema / properties / reference_t1_s / typeRemoved value: -"number"Input schema / properties / relaxation_delay_sAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Relaxation Delay S"
+}Input schema / properties / sample_mass_mg / anyOfAdded value: +[
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / sample_mass_mg / defaultPrevious value: -10New value: +nullInput schema / properties / sample_mass_mg / typeRemoved value: -"number"Input schema / properties / sample_volume_ml / anyOfAdded value: +[
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / sample_volume_ml / defaultPrevious value: -0.6New value: +nullInput schema / properties / sample_volume_ml / typeRemoved value: -"number"Input schema / properties / sn_analyteAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Sn Analyte"
+}Input schema / properties / sn_standardAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Sn Standard"
+}Input schema / properties / solventAdded value: +{
+ "default": "",
+ "title": "Solvent",
+ "type": "string"
+}Input schema / properties / standard_conc_mm / anyOfAdded value: +[
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / standard_conc_mm / defaultPrevious value: -0New value: +nullInput schema / properties / standard_conc_mm / typeRemoved value: -"number"Input schema / properties / standard_formulaAdded value: +{
+ "default": "",
+ "title": "Standard Formula",
+ "type": "string"
+}Input schema / properties / standard_integral / anyOfAdded value: +[
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / standard_integral / defaultPrevious value: -0New value: +nullInput schema / properties / standard_integral / typeRemoved value: -"number"Input schema / properties / standard_mass_mgAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Standard Mass Mg"
+}Input schema / properties / standard_mwAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Standard Mw"
+}Input schema / properties / standard_peak_ppmAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Standard Peak Ppm"
+}Input schema / properties / standard_protons / anyOfAdded value: +[
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / standard_protons / defaultPrevious value: -1New value: +nullInput schema / properties / standard_protons / typeRemoved value: -"integer"Input schema / properties / standard_purity / anyOfAdded value: +[
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / standard_purity / defaultPrevious value: -0.999New value: +nullInput schema / properties / standard_purity / typeRemoved value: -"number"Input schema / properties / standard_purity_kAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Standard Purity K"
+}Input schema / properties / t1_longest_sAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "T1 Longest S"
+}Input schema / properties / u_analyte_mass_mgAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "U Analyte Mass Mg"
+}Input schema / properties / u_analyte_mwAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "U Analyte Mw"
+}Input schema / properties / u_analyte_protonsAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "U Analyte Protons"
+}Input schema / properties / u_balance_mgAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "U Balance Mg"
+}Input schema / properties / u_baseline_relAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "U Baseline Rel"
+}Input schema / properties / u_integration_relAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "U Integration Rel"
+}Input schema / properties / u_lineshape_relAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "U Lineshape Rel"
+}Input schema / properties / u_standard_mass_mgAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "U Standard Mass Mg"
+}Input schema / properties / u_standard_mwAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "U Standard Mw"
+}Input schema / properties / u_standard_protonsAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "U Standard Protons"
+}Input schema / properties / u_standard_purityAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "U Standard Purity"
+}Input schema / properties / u_t1_saturation_relAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "U T1 Saturation Rel"
+}Input schema / properties / u_temperature_relAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "U Temperature Rel"
+}Input schema / properties / u_volume_mlAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "U Volume Ml"
+}Input schema / properties / u_weighing_mgAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "U Weighing Mg"
+}Input schema / requiredPrevious value: -[
- "method",
- "analyte_integral",
- "analyte_protons"
-]New value: +[
+ "method"
+]covnmr_qualitycovnmr_rank_candidates3 fields changedInput schema / properties / candidatesAdded value: +{
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Candidates"
+}Input schema / properties / experimentsAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Experiments"
+}Input schema / properties / peaksAdded value: +{
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Peaks"
+}covnmr_reference1 field changedInput schema / properties / nucleus / defaultPrevious value: -"1H"New value: +""covnmr_sst10 fields changedInput schema / properties / line_broadening_hzAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Line Broadening Hz"
+}Input schema / properties / max_linewidth_hz / anyOfAdded value: +[
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / max_linewidth_hz / defaultPrevious value: -1New value: +nullInput schema / properties / max_linewidth_hz / typeRemoved value: -"number"Input schema / properties / min_sn / anyOfAdded value: +[
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / min_sn / defaultPrevious value: -250New value: +nullInput schema / properties / min_sn / typeRemoved value: -"number"Input schema / properties / reference_peak_ppm / anyOfAdded value: +[
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / reference_peak_ppm / defaultPrevious value: -0New value: +nullInput schema / properties / reference_peak_ppm / typeRemoved value: -"number"covnmr_sudoku7 fields changedInput schema / properties / field_mhzAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Field Mhz"
+}Input schema / properties / max_crosspeaksAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Max Crosspeaks"
+}Input schema / properties / max_rowsAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Max Rows"
+}Input schema / properties / outputAdded value: +{
+ "default": "",
+ "title": "Output",
+ "type": "string"
+}Input schema / properties / pathAdded value: +{
+ "default": "",
+ "title": "Path",
+ "type": "string"
+}Input schema / properties / path_deptAdded value: +{
+ "default": "",
+ "title": "Path Dept",
+ "type": "string"
+}Input schema / properties / paths_2dAdded value: +{
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Paths 2D"
+}covnmr_triagecovnmr_verify12 fields changedInput schema / properties / candidatesAdded value: +{
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Candidates"
+}Input schema / properties / experimentsAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Experiments"
+}Input schema / properties / experiments_jsonAdded value: +{
+ "default": "",
+ "title": "Experiments Json",
+ "type": "string"
+}Input schema / properties / hrmsAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Hrms"
+}Input schema / properties / hrms_ppm_toleranceAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Hrms Ppm Tolerance"
+}Input schema / properties / max_peaksAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Max Peaks"
+}Input schema / properties / max_unassignedAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Max Unassigned"
+}Input schema / properties / path / defaultAdded value: +""Input schema / properties / peaksAdded value: +{
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Peaks"
+}Input schema / properties / peaks_jsonAdded value: +{
+ "default": "",
+ "title": "Peaks Json",
+ "type": "string"
+}Input schema / properties / smiles / defaultAdded value: +""Input schema / requiredRemoved value: -[
- "path",
- "smiles"
-]covnmr_verify_peakscovabasic_name_to_structurecovabasic_analyzecovabasic_atom_indicescovabasic_bricscovabasic_canonicalizecovabasic_convertcovabasic_convert_formatcovabasic_depictcovabasic_describe_structurecovabasic_druglikenesscovabasic_equationcovabasic_filter_checkcovabasic_fingerprintcovabasic_functional_groupscovabasic_green_chemistrycovabasic_image_to_smilescovabasic_iupac_namecovabasic_pubchemcovabasic_reynoldscovabasic_scaffold_analysiscovabasic_similaritycovabasic_standardizecovabasic_stoichiometrycovabasic_substructurecovabasic_tautomerscovabasic_validatecovabio_adccovabio_aligncovabio_antibodycovabio_batch_profilecovabio_charge_profilecovabio_cleavage_sitescovabio_codon_adaptationcovabio_deamidationcovabio_developabilitycovabio_immunogenicitycovabio_mam_reportcovabio_mrnacovabio_oligocovabio_parse_fastacovabio_peptidecovabio_protein_profilecovabio_sequence_utilscovabio_sirnacovabio_viscositycovachem_comparecovachem_druglikenesscovachem_profilecovadoe_alias_structurecovadoe_analyzecovadoe_augment_designcovadoe_canonical_analysiscovadoe_compare_designscovadoe_create_designcovadoe_design_powercovadoe_design_spacecovadoe_find_optimumcovadoe_fit_rsmcovadoe_model_selectioncovadoe_optimizecovadoe_plot_datacovadoe_post_hoc_powercovadoe_power_analysiscovadoe_predictcovadoe_residual_diagnosticscovadoe_ridge_analysiscovadoe_suggest_designcovadoe_taguchicovair_annotatecovair_auto_analyzecovair_batchcovair_comparecovair_identifycovair_predict_ircovair_processcovair_quality_checkcovair_verifycovams_analyze_unknowncovams_compound_classcovams_degradation_predictcovams_detect_featurescovams_extractables_leachablescovams_forced_degradationcovams_formulacovams_fragment_annotatecovams_fragment_predictcovams_identifycovams_identify_batchcovams_impurity_findcovams_impurity_profilingcovams_isotopecovams_mass_balancecovams_metabolite_idcovams_neutral_losscovams_predict_fingerprintcovams_predict_rtcovams_process_spectrumcovams_search_by_fingerprintcovams_search_dbcovams_spectral_qualitycovasolve_predictcovasyn_cancel_jobcovasyn_creditscovasyn_feedbackcovasyn_job_detailcovasyn_job_resultcovasyn_jobscovatox_ecotoxcovatox_healthcovatox_warmupcovauv_auto_analyzecovauv_biocovauv_comparecovauv_dissolutioncovauv_predictcovauv_quantifycovauv_validatecovnmr_2d_analyzecovnmr_analyzecovnmr_assigncovnmr_audit_reportcovnmr_batchcovnmr_comparecovnmr_elucidatecovnmr_explaincovnmr_exportcovnmr_formatcovnmr_identifycovnmr_impuritycovnmr_method_validatecovnmr_multi_analyzecovnmr_parse_nmr_stringcovnmr_predictcovnmr_predict_dept_spectrumcovnmr_predict_spectrumcovnmr_puritycovnmr_qnmr_advancedcovnmr_qualitycovnmr_rank_candidatescovnmr_referencecovnmr_sstcovnmr_sudokucovnmr_triagecovnmr_verifycovnmr_verify_peaksTurn any LLM into your lab assistant: search samples, track experiments, analyze data with AI.
Find open biology and chemistry AI models, bioinformatics tools and databases, and run them online.
Biotech rNPV/PoS engine for AI agents. Signed exports, evidence register, asset landscape.
FTIR spectral search and material identification for AI agents via MCP.
Add one secure layer between your agents and this server.
