ivive.app

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

Annotations already declare a safe, idempotent, closed-world read, so the description is free to add real value — it discloses that the result carries an observed-CL band and applicability warnings, and flags the predicted-input provenance obligation. It stops short of describing the warning conditions or the return shape, but the added context is genuine.

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, zero filler. The computational purpose is front-loaded, and the provenance caveat follows as a secondary instruction. Nothing could be cut without losing meaning.

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 IVIVE calculator with no output schema, the description covers the computational basis, the presence of an observed-CL band and warnings, and the prediction-provenance duty. It could say more about what the warnings or band represent, but an agent has enough to call it correctly and interpret the response at a high level.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter (including rb, model, assay_type, correction_id, clint_censored) is already documented in more detail than the description provides. The description names the key inputs but adds no syntax, units, or constraints beyond the schema — the baseline 3 applies.

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

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

States a specific computed resource (hepatic and plasma clearance) and the exact inputs driving it (in-vitro CLint, fu,mic, fu,p, IVIVE), plus what comes back (observed-CL band, applicability warnings). That is enough to separate it from siblings such as scale_to_human or target_clint 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?

One explicit workflow rule is given: if fu,p or fu,mic came from predict_inputs, surface the predicted-input caveat. There is no guidance on when to choose this tool over scale_to_human or target_clint, so selection between siblings is only implied by the input signature.

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

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

Annotations already establish that this is a read-only, idempotent, non-destructive, closed-world computation. The description adds the useful behavioral framing that the tool varies inputs over ranges to measure plasma CL sensitivity, but it does not describe the return format or how outputs behave when multiple ranges are supplied.

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. The core sensitivity concept is stated immediately, followed by a compact illustrative example.

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 parameter schema is rich and fully described, and annotations cover safety behavior, so the description does not need to repeat those details. However, this is a complex 12-parameter computation with no output schema, and the description does not explain the return value structure or how the range inputs affect the result beyond the high-level 'how far plasma CL moves' phrase.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all parameters, including ranges, units, defaults, and enum meanings. The description only reinforces the range concept with one fu,p example and adds no additional parameter semantics beyond the schema.

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

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

The description clearly states that this tool computes how far plasma CL moves as each input is varied over a range, with a concrete fu,p example. It is specific about the metric and input perturbation, but it does not name or differentiate itself from sibling tools such as calc_clhep or predict_inputs.

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 phrase 'as each input is varied over a range' and by the example of a predicted fu,p over its 50% range. However, the description gives no explicit when-to-use guidance, no exclusions, and no comparison to calc_clhep or other alternatives.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior. The description adds genuinely useful context beyond them: results are predictions with an applicability verdict the caller must check, and CL/Vss are lower-confidence secondary outputs. It stops short of saying what the verdict contains or what happens when it fails.

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 no filler, front-loading the primary outputs before the caveats. Every clause (secondary CL/Vss, prediction-vs-measurement, applicability verdict) 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?

With no output schema, the description usefully enumerates the returned quantities and the applicability verdict, and annotations cover the safety profile. The main remaining gap is that the verdict's meaning and the handling of a failed applicability check are left unspecified.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so smiles, assay_type, and concentration are fully documented in the schema, including units and defaults. The description only repeats SMILES as input and does not clarify the assay_type/concentration interaction beyond what the schema already says. Baseline 3 applies.

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

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

States a specific verb (Predict) and precise resources (fu,p and fu,inc from a SMILES, plus secondary structure-only human CL and Vss). The named outputs distinguish it from siblings like calc_clhep, but no sibling is explicitly named or ruled out.

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?

"Predictions, not measurements" and "check the applicability verdict" imply a structure-only early-screening use case, and the CL/Vss are flagged as "second opinions." However, no explicit when-to-use/when-not-to-use conditions or named alternatives (e.g. calc_clhep, scale_to_human) are given.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds genuine value by disclosing the return shape (all applicable methods, each with a measured error) and the observed-vs-predicted input rule, but says nothing about how many methods exist, failure behavior, or whether results can be partially empty.

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, front-loaded with the operation and its scope, followed by the input constraint. No filler and nothing the agent must re-read.

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 2-parameter, no-output-schema tool this is nearly complete: it names the species set, the input semantics, and the broad return content. The only gap is that fu_p_human and its role in the fu-corrected methods are left entirely to the schema.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description earns an extra point by clarifying that the 'cl' values must be observed in-vivo measurements, never predicted or back-calculated — a semantic constraint the schema does not encode. It also implicitly enumerates the valid species.

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+resource: predict human plasma CL from observed animal in-vivo CL, enumerating the supported species (rat, dog, monkey) and noting it returns every applicable method with its measured error. That is clearly distinct from siblings like calc_clhep or target_clint, though it never names them explicitly to force the contrast.

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?

"Observed animal CL only, never predicted" is an explicit input-precondition that steers the agent away from misuse where sibling tools might be the right choice. It gives clear context for when this applies, but stops short of naming alternatives or stating when-not to call it.

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

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

Annotations already establish that this is a safe, read-only, idempotent lookup, and the description adds meaningful return context: each neighbour includes measured human plasma CL and predicted CL from measured inputs. It also explicitly bounds behavior by stating that it returns neighbours only, not a prediction for the query.

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 three tight sentences, front-loaded with what the tool returns and immediately followed by its intended diagnostic use. Every sentence carries useful information, including the limitation that this is not a prediction.

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 small read-only lookup with full parameter schema coverage and no output schema, the description supplies the return format and the interpretation rule an agent needs. Nothing relevant to selecting or using the tool correctly appears to be 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 100%, with both 'smiles' and 'n' documented directly in the schema. The description reinforces that the query is a SMILES and that results are nearest neighbours, but it adds no extra parameter semantics beyond what the schema already provides, so baseline 3 is appropriate.

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

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

The description states a specific verb and resource: it returns nearest reference drugs to a SMILES, using Tanimoto similarity with Morgan radius 2. It also clearly distinguishes itself from calc_clhep by framing itself as a trust-check on that prediction tool rather than a predictor.

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 explicitly says when to use it: to judge how far to trust calc_clhep for a chemotype, with the decision rule 'if IVIVE missed on the neighbours, expect it to miss here.' This is a direct usage relationship to the sibling tool rather than implied guidance.

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

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

Adds behavior beyond the annotations: it discloses a guard condition (refuses a target at or above the liver blood flow ceiling) and that the ceiling itself is returned on refusal. It also flags the accuracy caveat that the IVIVE is uncorrected with no error band, which is exactly the kind of domain limitation an agent cannot infer from readOnlyHint/idempotentHint.

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 that front-load the core quantity before the sibling comparison and the edge-case behavior. The parenthetical 'e.g. to set a CLint cut-off for a screening cascade' is the only slightly expendable clause, but it earns its place as usage context.

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 inverse-calculation tool with no output schema, it covers the failure mode, the return value on refusal, and the modeling caveat. What remains thin is how the model/assay_type choices interact with the returned units, but the schema largely carries that.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so every parameter is already documented, and the description's mention of needing fu,mic and fu,p merely restates two required fields. It adds no meaning for rb, species, model, or assay_type beyond what the schema states, so the baseline 3 applies.

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

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

States a specific quantity (the in-vitro CLint an assay must read) and its purpose (reach a target plasma clearance in mL/min/kg), which is a concrete verb+resource framing. It explicitly positions itself as the inverse of the sibling calc_clhep, so an agent can distinguish the two 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?

Gives a concrete use case (setting a CLint cut-off for a screening cascade) and frames the alternative relationship as 'calc_clhep run backwards', which implicitly routes forward-direction work to the sibling. It does not state explicit exclusions (e.g., when a target is unattainable for reasons other than the blood-flow ceiling), so it falls short of a full when/when-not statement.

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