SanYu Research Engine

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

Annotations already cover safety (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds one genuinely useful behavioral fact — the result comes from a real algorithm engine, not LLM generation — which tells the agent the output is deterministic and citable. It says nothing about what the returned checklist looks like beyond '条目核对', or whether a pass/fail verdict versus a gap list is produced.

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

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

Two compact clauses, front-loaded with the bracketed tool label, followed by trigger and return value. No filler, and the most useful distinguishing phrase ('真实算法引擎执行，非大模型生成') is preserved rather than padded away.

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-param, no-output-schema, read-only tool the description is nearly sufficient: it states the trigger and the return shape. The remaining gap is operational — how the study data reaches the tool and what a failing checklist looks like — which matters here because the agent can supply no arguments to steer it. It also lacks a fallback route to the sibling checklist 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?

With zero parameters the baseline is 4, but this tool's zero-param design raises a real question the description ignores: nothing indicates where the experiment description to be checked comes from. An agent cannot tell whether it must first state the study details in the conversation or whether the tool reads prior context. That ambiguity costs a point despite the empty 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 names a specific standard and action — checking an animal experiment against ARRIVE 2.0 and returning an item checklist. It distinguishes itself from the many statistical siblings by the ARRIVE/animal-research framing, though it never explicitly contrasts with the closest relatives act_checklist_check, act_consort_flow, or act_prisma_flow.

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 a concrete trigger condition: use when the user asks whether an animal experiment complies with ARRIVE 2.0. That is clear positive guidance. It stops short of exclusions — nothing says when to prefer act_checklist_check or what to do if the user asks about CONSORT/PRISMA instead.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds two useful behavioral facts beyond that: the return values (给药量 and 体积) and that the result comes from a deterministic algorithm engine rather than model generation. It does not state output units, rounding, or species/route assumptions, which matter for a dosing 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?

Three compact clauses: topic label, usage trigger, return values and execution note. Well front-loaded with no filler, though the bracketed label largely repeats the annotated title.

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-required-parameter pure calculator with no output schema, the description does the important remaining work by stating what is returned (dose amount and volume). Nothing critical is missing for correct invocation, though output units and formula assumptions would have made it complete.

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

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

Schema description coverage is 100%, with both parameters (dose_mg_per_kg and animal_weight_g) documented including units, so the schema carries the parameter burden. The description only restates that weight drives the computation and adds no unit-conversion or range 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 names a specific verb+resource: computing dosing volume/dose from body weight ('按体重算给药体积/剂量'). An agent can tell it apart from most siblings, though the closely related act_dose_convert_pharm is never mentioned or contrasted.

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?

A trigger scenario is implied ('用户要按体重算给药体积/剂量' = when the user wants to compute dose volume by body weight), which is sufficient to route most requests. However there is no explicit when-not guidance and no routing away from the near-duplicate act_dose_convert_pharm sibling.

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?

The annotations already establish that this is a safe, non-destructive, closed-world read operation. The description adds two genuinely new points: the output is the organ coefficient, and it is computed by a real algorithm engine rather than generated by an LLM. That determinism note is useful, but units, precision, and error 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?

The description is two short, front-loaded clauses with zero filler, and the formula appears immediately after the purpose. Minor repetition of the annotation title in brackets keeps it from being maximally tight.

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 three-parameter tool with no required params and no output schema, the description omits several things an agent would need: the response shape (single value or per-item array), units, behavior when a weight array is empty or mismatched, and what 'label' does. It covers the core purpose but is thin on operational detail.

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 each of the three parameters (label, body_weights, organ_weights) is already documented in the schema. The description restates the organ weight and body weight relationship, but it does not clarify roles such as what 'label' controls or how the weight arrays are paired. With the schema doing the documentation work, the baseline of 3 applies.

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

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

The description names a specific resource, the organ coefficient, and states the exact formula (organ weight divided by body weight), which no sibling tool computes. The bracketed label at the start just repeats the annotation title, so the real clarity comes from the second clause rather than the first.

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 '用户要算脏器系数' implies when to use it, which is to compute an organ coefficient, but there is no explicit statement of when not to use it, no prerequisite conditions, and no comparison against the many other act_animal_* siblings. Usage is implied rather than guided.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds the meaningful claim that results come from a real algorithm engine rather than LLM generation, which is useful trust context, but says nothing about determinism, whether the seed makes runs reproducible, or what the method parameter changes.

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?

Very compact and front-loaded: the bracketed category tag, the trigger condition, and the return value come in order with no filler. The fragmentary phrasing is slightly telegraphic 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?

For a simple four-parameter tool with full schema coverage and no output schema, the description covers purpose and return type ('分组表'). It falls short on the statistical behavior an agent might need to explain to a user, such as reproducibility via seed and the available randomization methods.

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 all four parameters (n_total, groups, method, seed) already carry descriptions and the baseline is 3. The description adds no meaning beyond that – it never mentions seeding, method choice, or how group names interact with group count.

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: randomly assigning animals into groups, and ties it to the ARRIVE reporting requirement. An agent can tell this is animal-subject randomization rather than a generic randomizer, though the distinction from the sibling act_randomize is never made explicit.

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 '用户要把动物随机分组（ARRIVE 要求）' – invoke when a user needs animal allocation for an ARRIVE-compliant study. There is no statement of when not to use it, and no routing to or from the closely-named sibling act_randomize.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the useful claim that results come from a deterministic algorithm engine rather than LLM generation, which matters for trust in a statistical tool, but it says nothing about default alpha/power assumptions or method limitations.

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 compact block with the purpose front-loaded, followed by user intent and the return value. The bracketed label is somewhat redundant with the tool title, and the parenthetical engine disclaimer is promotional, though it does carry informational value.

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?

There is no output schema, and the description does state the returned quantity (animals per group), which is adequate for the return side. However, for a statistical tool with three optional parameters whose defaults drive results, the description leaves an agent without guidance on what happens when alpha, power or groups are 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 100%, so all four parameters (alpha, power, groups, effect_size) are already documented in structured data, setting the baseline at 3. The description adds no extra meaning such as which parameters are optional in practice or typical default values used when only effect_size is supplied.

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 resource and computation (animal experiment sample size) and states the return value ('每组动物数'), so an agent can tell it is a sample-size calculator for animal studies rather than a general one. It does not explicitly name the close sibling act_design_sample_size to disambiguate, 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?

Usage is only implied through trigger phrasing ('用户问动物实验要多少只、ARRIVE 要求怎么写'), which does give an agent a recognizable user-intent cue. There is no explicit when-not guidance, and the ARRIVE mention overlaps with the sibling act_animal_arrive_check without saying which to prefer for checklist-writing questions.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuine value by stating the computation is done by a real algorithm engine rather than model generation and by naming the return artifacts, but it says nothing about input format requirements (how times and events must be encoded) 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?

The description is two short clauses with the purpose front-loaded and the return value stated immediately after. The bracketed title repeats the tool's title field, which is mild redundancy, but nothing else 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?

With no output schema, the description correctly compensates by naming what is returned (KM curve and log-rank). For a four-parameter statistical tool with fully documented parameters and clear read-only annotations, the only meaningful gap is the event-encoding convention, which keeps it short of a 5.

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 each of the four parameters is already labeled in Chinese (control/treatment times and events). The description adds no meaning beyond that — in particular it does not clarify the event coding (e.g., 1 = death, 0 = censored) or expected time format, even though events are declared as string arrays, which is genuinely 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?

The description names a specific analysis (animal survival analysis) and the concrete outputs it produces (KM curve and log-rank test), so the agent knows exactly what the tool computes. It does not, however, differentiate itself from close siblings such as act_km_curve and act_survival_analyze, so the agent cannot tell from this text alone which survival 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?

The phrasing '用户有动物死亡时间要做生存曲线' gives an implied trigger: use this when you have animal death/follow-up data and need a survival curve. There is no explicit when-not guidance, no prerequisites (e.g., censoring conventions, minimum sample size), and no reference to the other survival-related siblings, leaving selection partly to inference.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that — that the result comes from a real algorithm engine rather than LLM generation — but says nothing about input constraints (e.g. equal or differing group sizes, whether volumes must be numeric strings) or what the statistical test returns.

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?

Very short and front-loaded: the resource label comes first, then the trigger, then the return. The clause '用户要算抑瘤率 TGI' partially restates the bracketed title, which is mild waste, but no sentence is otherwise superfluous.

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 only two required parameters, full schema coverage and no output schema, the description does state the return values (TGI plus a statistical test), which is the main missing piece for most tools. However, for a statistics-producing tool it omits what the statistical test actually is and what format the volumes should take, leaving real gaps for an agent composing the call.

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 ctrl_volumes and treat_volumes documented in Chinese, so the schema carries the semantic load. The description adds nothing about the two parameters — no unit expectations, no note that they are arrays of string-formatted numbers, no minimum sample count — so the baseline 3 applies.

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

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

The description names a specific verb (calculate) and resource (抑瘤率 TGI), and the bracketed label plus the 'returns TGI and statistical test' clause make the output unambiguous. It is distinguishable from act_animal_tumor_volume, which computes volumes rather than the inhibition rate, though it never explicitly says so.

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?

'用户要算抑瘤率 TGI' functions as an implicit trigger condition: call this when the user wants a TGI calculation. There is no guidance on when not to use it and no sibling tool is named as an alternative, so the agent must infer routing from the tool name alone.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description does add genuine value beyond them by noting the result comes from a real algorithmic engine rather than LLM generation, and by naming the two outputs. It omits units, the underlying volume formula, and any constraint that the days/widths/lengths arrays must be the same length.

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 clauses with the core purpose front-loaded in a bracketed label, so an agent can scan it instantly. There is mild redundancy between '要算肿瘤体积与生长曲线' and '返回：体积与生长曲线', which restates the output without adding 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 four optional parameters, 100% schema coverage, and no output schema, the description covers what is needed to select and call the tool: inputs are lengths/widths, outputs are volume and growth curve. The remaining gaps — array-length consistency, units, and the algorithm variant — are refinements rather than blockers.

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 each parameter (days, widths, lengths, group_name) is already documented in the schema and the baseline of 3 applies. The description corroborates the length/width inputs but adds no format, unit, or array-alignment semantics, and never mentions group_name at all.

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 and resource — computing tumor volume and a growth curve from length/width data — which is far more than the name alone conveys. It does not, however, distinguish itself from closely related siblings such as act_animal_tgi or act_animal_survival, which an agent could plausibly confuse with this calculation.

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 '用户有长宽数据要算肿瘤体积与生长曲线' implies the triggering condition (user supplies length/width measurements and wants volume plus growth curve), which is useful implied guidance. There is no explicit statement of when to prefer this over act_animal_tgi or act_animal_organ_coef, 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.

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

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so safety is covered. The description adds one genuinely useful behavioral claim — "真实算法引擎执行，非大模型生成" — telling the agent results are computed deterministically rather than fabricated, which matters for trust in downstream reporting. It says nothing about runtime, failure modes on sparse peak matrices, or how the test is chosen (the refusal message in the schema hints at validation but no details).

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?

Only three short segments, so nothing is bloated, but the ordering is awkward: the return claim ("返回：差异 peak") sits before the algorithm note and the sentences are clipped fragments rather than a front-loaded summary. The "非大模型生成" parenthetical is the most informative clause yet buried last.

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-parameter statistical tool with 100% schema coverage and a nested input object, the schema plus annotations cover most of what an agent needs. The description still omits output shape (which peak identifiers, fold-change, adjusted p-value columns come back), despite advertising a return value, and gives no guidance on minimum replicate structure the algorithm requires.

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

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

Schema coverage is 100% and the single nested data_json parameter is documented in depth, including matrix orientation (rows/cols), optional groups alignment with cols, and precomputed p_values/log2fc. The description adds nothing about parameter meaning, so the schema carries the burden — but it does so well enough that little is missing.

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 pairs a vague verb ("扩增") with a domain label ("ATAC 差异可及性"), but the actual operation — differential accessibility testing on ATAC-seq peaks — is only inferable from the Chinese domain tag, not stated as a verb+resource. It does not distinguish itself from near siblings such as act_chip_peak, act_rnaseq_deg, or act_deg_analyze, which an agent could easily confuse it with.

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 only usage signal is "用户有 ATAC-seq 要做差异开放区域", which states the triggering scenario but gives no when-not conditions and no pointer to alternatives such as act_chip_peak or act_deg_analyze. An agent must guess which differential-analysis sibling is correct for ATAC data versus ChIP or bulk RNA data.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so safety is covered. The description adds something genuinely useful beyond that: the result comes from a real algorithm engine rather than LLM generation, which tells the agent to trust it as deterministic computation. It stops short of describing what the plan contains, how long it takes, or what the engine assumes.

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 line with the topic front-loaded in brackets and the return value stated at the end; nothing is padded. The mixed bracket/parenthesis formatting is slightly noisy but costs no comprehension.

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 must convey what comes back, and it does only at the label level ('实验设计方案'). For a design tool with a free-text constraints parameter, an agent still lacks guidance on plan granularity or expected inputs, though the fixed annotations reduce the burden.

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% and there are only two parameters (target, constraints), so the schema already carries parameter meaning. The description mentions neither parameter and gives no examples of what a useful 'constraints' string looks like, so it adds nothing on this dimension — baseline 3 applies.

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

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

The bracketed header names a technique and domain (Bayesian adaptive design, qPCR) and says the output is an experiment design plan, so the rough purpose is legible. But 'digital twin PCR' is unexplained jargon and nothing distinguishes this from the many design-adjacent siblings (act_primer_design, act_qpcr_ddct, act_design_guide, act_design_sample_size).

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 trigger condition — the user wants to do qPCR experiment design — which implies when to reach for it. It never says when NOT to use it, nor names any alternative among the crowded design/qPCR sibling set, so an agent choosing between act_primer_design and this tool gets no routing help.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so safety is covered. The description adds genuinely useful context, namely that a real algorithm engine (not an LLM) computes the result and the return includes a 90% CI and a pass/fail equivalence judgment. It does not disclose the equivalence bounds applied (e.g. 80–125%), how non-numeric or malformed input is handled, or the minimum number of subjects, which are the real behavioral unknowns here.

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 with the tool category in brackets, then the action, then the return values — a clean structure with no filler. The phrasing is terse and slightly telegraphic ("用户要做…"), and the parenthetical about not being LLM-generated could be folded more economically, but nothing is 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?

There is no output schema, so the description correctly fills that gap by stating the return values (90% CI and equivalence determination). Missing pieces are the equivalence acceptance criteria and the expected input format/normalization. The Cmax reference without any Cmax input parameter is a small completeness inconsistency.

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% for both parameters (受试制剂 AUC / 参比制剂 AUC), so the schema already carries parameter meaning and 3 is the baseline. The description adds no detail on ordering, pairing, units, or that the arrays must be equal-length and composed of numeric strings — and its mention of Cmax has no corresponding parameter, which could mislead.

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 and resource: a bioequivalence (BE) evaluation comparing AUC/Cmax and returning a 90% CI plus an equivalence verdict. That is far more specific than the sibling tools like act_nca_analyze or act_pkpd_eval, though it never explicitly names or rules out those siblings. The Cmax mention is slightly off since the schema only accepts AUC arrays, but the core purpose is unmistakable.

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?

"用户要做 BE 试验的 AUC/Cmax 比较" implies the usage context (BE trial comparison), which is enough to route an agent in the right general direction. However, it gives no guidance on when to prefer this over act_nca_analyze, act_pkpd_eval, or act_data_quick_stats, and no prerequisites such as minimum sample size or required data format.

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

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

Annotations already declare readOnlyHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds genuinely non-obvious behavioral context: results come from a real algorithm engine rather than LLM generation, and it names the kind of output returned. It does not discuss input length limits or handling of ambiguous findings.

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, front-loaded lines: bracketed scope, usage condition, then return value. No filler sentences, though the bracketed header is slightly redundant with the annotation title and the parenthetical trust claim could be tightened.

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 read-only tool with no output schema, the description covers purpose, trigger conditions and the shape of the return value. What remains thin is how a 'finding' should be phrased and what happens with sparse or ambiguous input, but nothing critical is missing 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 100%, so both parameters are already documented, and the description's prose ('from clinical findings to basic mechanisms, or from mechanism to clinical application') mirrors the direction parameter's two values without adding format or default guidance. Baseline 3 is appropriate when the schema does the heavy lifting.

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 pair: converting between clinical findings and basic mechanisms ('临床↔基础转化配对', 'Bridge'), and names the output (translational hypotheses and experimental protocols). It is clear what the tool does, though it does not explicitly contrast itself with any sibling such as act_gene_pathway or act_decision_followup.

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 concrete when-to-use conditions in both directions: when the user wants to find a basic mechanism behind a clinical finding, or a clinical application for a mechanism. There are no explicit exclusions or named alternatives, 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.

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds one piece of real value, that a deterministic algorithm engine computes the result rather than an LLM, but says nothing about input validation, error behavior, or how bins are chosen.

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?

Very short and front-loaded: purpose first, then return values, then the engine note. The bracketed 【校准曲线】 prefix duplicates the annotation title and is slightly redundant, but nothing else is padded.

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

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

There is no output schema, so naming the calibration curve and Brier score in the description is genuinely useful. However, for a tool whose inputs are counterintuitively string-typed arrays, the description leaves input format and length-matching expectations unaddressed, which is a meaningful 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 100%, so the schema carries most of the parameter burden and the baseline is 3. The description adds no clarification of the notable ambiguity, namely that labels and scores are typed as strings while scores are described as probabilities in 0-1, nor whether n_bins has a default.

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: evaluate a prediction model's calibration and draw a calibration curve, plus the returned artifacts (curve and Brier score). It does not distinguish itself from the nearest sibling act_roc, so an agent must infer the calibration-vs-discrimination split on its own.

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 'when the user wants to assess calibration / draw a calibration curve' framing gives an implicit trigger, but there is no explicit when-not and no mention that act_roc is the discrimination counterpart. Nothing is said about prerequisites or which inputs are required versus optional.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description does add a genuinely useful behavioral claim beyond the annotations: results come from a real algorithm engine, not LLM generation, which tells the agent the output is deterministic and trustworthy. It says nothing about what happens with an unsupported tool_id or missing params, which matters for a dispatcher.

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 clauses, purpose front-loaded, no filler, and the trust signal is placed last where it reads as a qualifier rather than the headline. Minor redundancy with the annotation title ('细胞实验通用计算') is the only 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?

This is a polymorphic dispatcher with an unconstrained nested params object and no output schema, yet the description never explains the per-tool_id parameter shape or what the returned calculation actually contains beyond '计算结果'. For a tool of this complexity, the definition leaves too much to trial and error.

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 nominally 100%, so the baseline is 3, and the description's enumeration of assay types does help the agent choose a tool_id. However, the 'params' property is a free-form nested object described only as '该工具所需参数', and the description does not explain which fields each tool_id requires — the highest-value information it could have added.

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 concrete verb and resource ('细胞实验通用计算') and enumerates the assay families it covers (CCK8/划痕/Transwell/克隆形成), which maps directly to the tool_id values. It does not, however, distinguish this generic dispatcher from the many specific sibling calculators (e.g. act_ic50_fit, act_qpcr_ddct) that an agent might otherwise 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?

It gives an implied trigger — the user wants a cell-experiment calculation for CCK8/wound healing/Transwell/colony formation — which is usable guidance. There is no explicit when-not, no mention of which sibling to prefer for adjacent analyses, and the trailing '等' leaves the coverage boundary undefined.

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

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

Annotations already declare readOnlyHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely new behavioral context: the output is item-by-item (逐条核对结果) and is produced by a real algorithm engine rather than LLM generation, which tells the agent the result is deterministic and citable. It does not describe how many guidelines are supported or how results are structured.

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 compact segments — operation label, usage trigger, return value — with no filler, and the trigger is front-loaded. The bracketed label partially repeats the annotation title, which is the only redundancy, but it costs almost nothing.

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, read-only check with no output schema, the description covers what goes in (a paper) and roughly what comes out (per-item results). Gaps remain: which reporting guidelines are actually supported, and what role design_type plays in selecting a guideline. Adequate but not complete.

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

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

Schema description coverage is 100%, so both parameters (text = 论文正文, design_type = 研究设计类型) are already documented in the schema. The description adds no extra meaning about the expected format of text, valid design_type values, or why design_type matters for guideline selection. Baseline 3 applies when the schema carries the parameter burden.

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

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

The description names a specific operation (核对/check) against a specific resource (报告规范清单, e.g. CONSORT/STROBE), plus a concrete trigger scenario (user asks whether a paper complies). This clearly separates it from analysis siblings like act_consort_flow, which produces a flow diagram rather than a compliance checklist, though no sibling is named 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 phrase '用户问论文符不符合 CONSORT/STROBE 等报告规范' is an explicit when-to-use trigger tied to a user intent, which is stronger than most siblings get. It stops short of stating when NOT to use it or which sibling to pick instead (e.g. act_consort_flow vs this tool), so it is not a full 5.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuine context by stating the computation is run by a real algorithm engine rather than generated by an LLM, but it says nothing about input expectations, runtime, or what the peak list contains beyond its name.

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 clauses, front-loaded with the bracketed domain tag, with zero filler. It is efficient, though the extreme brevity leaves no room for the operational detail an agent would need.

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?

Peak calling is a non-trivial domain operation, and the only return-value guidance is 'peak list' with no output schema to fall back on. More importantly, the input schema describes a generic feature-by-sample matrix with groups/p-values, which does not obviously match ChIP-seq peak calling inputs (aligned reads/controls), and the description never bridges that 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?

There is a single parameter and schema description coverage is 100%; the schema itself explains data_json in detail (matrix/rows/cols/groups/p_values and the required-field rejection). The description adds no parameter meaning at all, so the baseline 3 for fully documented schemas applies.

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

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

The description names a specific verb+resource pair (ChIP-seq peak calling) and states the return artefact (a peak list), which is enough to distinguish it from neighbouring omics tools such as act_atac_diff, act_rnaseq_deg and act_enrich. It stops short of explicitly contrasting with those siblings, so it is clear but not maximally differentiated.

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?

"用户有 ChIP-seq 要做 peak calling" implies the trigger condition (user brings ChIP-seq data and needs peaks called), but nothing is said about prerequisites (what form the input must take, whether input/control samples are needed) or when a sibling tool would be the better choice. Usage is inferable rather than stated.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: it is a deterministic algorithm engine rather than LLM generation, and it states what is returned (the formatted citation), which matters for an agent judging output trustworthiness.

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?

Very short and front-loaded: purpose, then return value, then an implementation note. Every line carries information, though the bracketed title tag duplicates the annotation title and could be dropped.

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, non-destructive formatting tool with full schema coverage and no output schema, this is close to adequate. The main gap is input expectation: it never clarifies whether 'references' are free-text citation strings that the engine parses or pre-structured fields, which directly affects how an agent prepares the call.

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 both the style enumerations and the references list are already documented in the schema. The description repeats three of the style values but adds no format details, no constraints on what a 'reference string' should look like, and no info on how many can be passed at once.

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 references into Vancouver/APA/GB-T 7714 citation formats) and distinguishes the tool from siblings such as act_lit_verify_citations or act_pubmed_search. It is slightly narrower than the actual capability, since the schema also supports mla and chicago but the description names only three styles.

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 framing 'when a user wants to convert references into X format'; there is no explicit when-to-use/when-not guidance or named alternative. An agent can infer the trigger context, but must open the schema to see the full style list and required input shape.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds a real behavioral claim, namely that results come from an actual algorithm engine rather than LLM generation, which helps trust calibration. It still says nothing about validation failures, mismatched-length handling, or how threshold interacts with string labels.

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?

Very short and front-loaded: the bracketed label states the resource, then the use case, then the return value. The only redundancy is that the metric list is effectively stated twice (use case and 'returns' clause), but nothing is padded.

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

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

With no output schema, the description usefully names the returned metric set, which is the main thing an agent needs. For a three-parameter statistical tool it is nonetheless thin: input-format expectations for labels versus 0/1 predictions and the effect of threshold 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 description coverage is 100%, so labels, predictions, and threshold are already documented in the schema, and the baseline of 3 applies. The description mentions no parameter-level detail at all, and notably omits any explanation of what threshold does when predictions are described as 0/1 strings.

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 (classification performance report) and enumerates the concrete outputs: accuracy, sensitivity, specificity, PPV, NPV. An agent can tell this is a binary/multiclass metric computation rather than a curve fit or a statistical test, but the description never contrasts it with nearby tools such as act_roc, act_delong, or act_calibration.

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 '用户要看准确率/敏感度/特异度/PPV/NPV 全套指标' implies the trigger condition: use it when the user wants the full panel of classification metrics. However, there is no explicit statement of when to prefer act_roc or act_delong, no prerequisites (paired label/prediction arrays of equal length), and no exclusions.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond that: execution is by a real algorithm engine rather than an LLM, and the output includes a cloning scheme and primers. It does not describe fallback behavior or method defaults, which keeps it from 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?

The description is compact and front-loads the purpose, applicable scenarios, and return values. The bracketed title partially duplicates the annotation title, but otherwise there is little unnecessary wording.

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

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

With no output schema, the description's note that it returns a cloning scheme and primers is useful, and the schema fully covers inputs. However, it does not explain what the scheme contains, how primers are formatted, or how to choose among Gibson, Golden Gate, and restriction cloning, leaving meaningful gaps for a design tool.

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

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

Schema description coverage is 100%, so method, insert_seq, and vector_seq are already documented. The description does not add any syntax, default value, or constraint details beyond what the schema provides, so the baseline of 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 task: designing a cloning scheme for molecular cloning, plasmid construction, and homology arm design, and says it returns a cloning scheme plus primers. This is clear, but it does not explicitly distinguish the tool from primer/plasmid sequence siblings such as act_primer_design or act_sequence_plasmid.

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 usage context by naming the scenarios: when the user wants to do molecular cloning, construct a plasmid, or design homology arms. It does not state when not to use it or name alternative sibling tools, 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.

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

The annotations already declare this is a read-only, closed-world, non-destructive operation, so the safety profile is covered. The description adds genuinely new behavioral context by stating the diagram comes from a real algorithm engine rather than LLM generation, which tells the agent the output is deterministic and trustworthy. It does not say what output format (image, SVG, code) is returned, which leaves a small 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 clauses in brackets: the scenario/trigger first, then the return value with the engine note. Zero filler, and the most decision-relevant 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?

Given 8 all-optional parameters at full schema coverage, annotations covering the safety profile, and no output schema, the description says enough to call it correctly. The one meaningful omission is that all parameters are optional, so the description never indicates whether a minimal call (e.g., only screened and randomized) produces a valid partial diagram or degrades.

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

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

Schema coverage is 100%, and each of the 8 parameters has a Chinese description that is essentially mirrored by the description text (screening, randomization, loss-to-followup). No additional semantics such as defaults, interdependencies, or what happens when a parameter is omitted are provided, so the baseline 3 applies.

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

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

The description states a specific verb+resource pair: draw a CONSORT flow diagram from screening/randomization/loss-to-followup counts. That is far more informative than the name alone. It stops short of a 5 because the nearest sibling, act_prisma_flow, is a closely related flow-diagram tool and the description never says how CONSORT differs from PRISMA or from act_forest_chart.

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 a clear trigger condition: the user has screening, randomization, or loss-to-followup numbers and wants a CONSORT diagram. There is no explicit when-not guidance and no named alternative for cases where the user actually needs a PRISMA diagram, so routing depends on the agent already knowing the study type.

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

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

Annotations already declare readOnlyHint, destructiveHint=false and openWorldHint=false, so safety is covered structurally. The description adds one genuinely useful behavioral fact – results come from a real algorithm engine rather than being LLM-generated, implying authoritative/deterministic output. It does not say what checks run, whether issues are returned with severity levels, or what happens when no form_id is 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?

Front-loaded with the tool's domain, then the user trigger, then the return value, with no filler sentences. The bracketed heading largely repeats the annotation title, which is the only wasted element.

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, one-optional-parameter tool this is roughly adequate, but with no output schema the description should indicate what '校验结果' looks like – a pass/fail verdict, a list of violated rules, or a report – so the agent knows how to present and follow up on results.

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% and the single parameter form_id is documented as '表单 id', so the baseline of 3 applies. The description adds nothing about the parameter and does not clarify the meaningful case of omitting it, given zero required parameters.

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 and resource – CRF data validation against SDTM/CDISC – and no sibling tool covers CRF or CDISC validation, so it is easy to place. It stops short of 5 because the scope of 'validation' (which rule set, which SDTM IG version, field-level vs. export-level checks) is left unspecified.

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 a concrete trigger condition: use when the user asks whether CRF data is compliant or can be exported to CDISC. There are no exclusions or named alternatives, but the sibling list contains nothing close enough to require routing guidance.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds useful context that execution is by a real algorithm engine rather than an LLM, and that it returns descriptive statistics and a quality overview, but it does not detail what specific statistics or quality checks are included.

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 compact sentences with a front-loaded bracketed label, followed by the user need and return value. There is no unnecessary wording; every part contributes to understanding the tool's 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?

For a simple tool with two parameters and no output schema, the description covers the core purpose, inputs implied, and the nature of the return. It could be slightly more complete by specifying which descriptive statistics or quality dimensions are included, but it is adequate for correct selection and 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 100%, so file_id and study_design are already documented in the schema. The description does not add any parameter-level meaning beyond what the schema provides, making the baseline score appropriate.

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

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

States a specific action and resource: a quick data profile that shows what the data looks like, its distribution, and missingness, and returns descriptive statistics plus a quality overview. It is clear what the tool does, but it does not explicitly distinguish itself from siblings such as act_file_columns or act_distribution_fit.

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 '用户想先看看' gives a clear usage context: an initial exploratory look at a dataset. It does not state when not to use it or name alternative tools for deeper analysis, so it lacks explicit exclusions.

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?

The annotations already establish the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds genuine context beyond them: results come from a real algorithmic engine rather than LLM generation, which tells the agent the output is deterministic and citable. It stops short of describing input expectations (generic vs. brand names, handling of unknown drugs) or any failure mode.

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 compact segments — bracketed purpose, user trigger, return value — with the most important information first and no filler. Every clause carries signal, including the provenance note at the end.

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

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

There is no output schema, so the description must say what comes back; it does, specifying interaction severity level plus mechanism. That covers the essential contract for a two-parameter lookup tool. The remaining gap is input conventions for drug names, which an agent would have to guess.

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%, but the two field descriptions are only '药物 A' and '药物 B', so the schema itself adds little meaning. The tool description likewise says nothing about what form the drug identifiers should take. Baseline 3 applies because the schema nominally covers both parameters, but no real semantic value is added on top.

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 operation and resource — drug-drug interaction checking — and states the concrete question it answers ('can these two drugs be used together, is there an interaction'). That is far more than a restatement of the name. It does not, however, explicitly contrast itself with neighboring clinical tools such as act_tox_eval or act_pkpd_eval, so it falls short of full 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?

The trigger condition is stated plainly: use it when a user asks whether two drugs are compatible or whether an interaction exists. This gives an agent a clear selection context rather than implying one. No exclusions or alternative tools are named, which keeps it at a 4 rather than a 5.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely non-structured context: results come from a '真实算法引擎' and are not LLM-generated ('非大模型生成'), which tells the agent the output is deterministic/computed and should be trusted as such — a meaningful behavioral disclosure. It still does not explain how multi-round state is carried or what happens if 'round' is omitted.

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 compact segments — bracketed label, trigger condition, return value — with the purpose front-loaded and only the parenthetical provenance clause as extra weight. The bracketed title largely duplicates the annotation title, which is minor waste but not harmful.

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 does state the return ('追问答复'), which is the key gap filled. For a 4-parameter, multi-round tool with no annotations gap, though, it should say how rounds are sequenced, whether prior rounds must be supplied, and whether a report step follows; those are left unstated.

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 each parameter already carries a description ('轮次', '标题', '摘要', '追问问题'). The description's '多轮' loosely maps to the 'round' parameter and '已录入的证据' to title/abstract, but it adds no format, default, or sequencing guidance beyond the schema. Baseline 3 applies.

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

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

The description names a specific verb and resource: continue questioning ('继续追问') already-recorded evidence and making causal judgments ('做因果判断'), plus it states the return value ('追问答复'). This distinguishes it from intake/report siblings implicitly, but no sibling is named in the text, so an agent must infer that act_decision_intake comes first.

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 '已录入的证据' implies a precondition — evidence must already exist before this tool is used — and '多轮' implies it is called repeatedly. However, there is no explicit when-not guidance, no statement of how it relates to act_decision_intake or act_decision_report, and no indication of what to do on the first round.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description does add real value beyond that: it states the output is a structured evidence card and that it is produced by a deterministic algorithm engine rather than LLM generation, which is meaningful trust context. It says nothing about how missing or sparse inputs (e.g., only a title, no abstract/DOI) are handled, nor about deduplication 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?

The text is short, but the bracketed lead '【文献证据分级录入】' verbatim repeats the annotation title, and 'Decision OS' and '真实算法引擎执行' are packed into run-on fragments without clear sentence boundaries. Information is front-loaded, yet a meaningful share of the text is redundant with structured fields.

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

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

For a simple read-only intake tool with four flat parameters and no output schema, the description covers the essential loop: one paper in, a structured evidence card out. It leaves gaps around what the evidence card contains, what input completeness is required, and where this sits in the surrounding decision workflow (followup, report), which matters given the dense 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 100%, so the baseline is 3; the schema itself, however, only labels fields ('DOI', '标题', '摘要', '文献类型') without format or role guidance. The description adds no parameter-level meaning — it never mentions which fields are required or how abstract/literature_type influence the evidence grading. Credit is limited to the schema doing the minimal work.

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 concrete verb and resource: taking one piece of literature and structurally decomposing it by evidence grade into a structured evidence card ('按证据等级结构化拆解... 返回：结构化证据卡'). The purpose is clear, but no sibling is named or contrasted (e.g., act_decision_followup, act_decision_report, act_lit_verify_citations, act_checklist_check), so an agent cannot tell which of the decision/literature tools apply. The 'Decision OS' label is unexplained jargon.

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 '用户给一篇文献要按证据等级结构化拆解' hints at the trigger (a user supplies one paper needing evidence-grading), but this mainly restates the purpose rather than providing explicit when-to-use guidance. There are no exclusions, no prerequisites, and no routing to the obvious siblings in this crowded family. An agent must infer the choice among dozens of act_* tools.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds a genuinely useful trait: output comes from a deterministic algorithm engine rather than LLM generation, and that the return value is the report body. It does not discuss report length, formatting, or failure modes, so it is solid but not rich.

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, front-loaded fragments with zero filler: scenario, return value, execution guarantee. It is telegraphic rather than prose and could be slightly clearer about the upstream dependency, 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?

For a two-parameter tool whose only complex input is a nested object fully documented in the schema, the description covers what it does and what it returns, and the schema covers the chaining requirement. No output schema exists, but the return ('证据报告正文') is stated explicitly, leaving no major 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 100% and already explains the lang enum default and that result must be the verbatim object from act_decision_intake / act_decision_followup, including the observed error message. The description adds nothing about parameters, so the baseline 3 applies.

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

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

The description states a specific action and output: turn evidence cards into a readable evidence report body, labeled '证据报告叙述'. An agent can tell it is a report-generation step, though differentiation from the closely related act_decision_intake / act_decision_followup only appears in the input schema, not the description itself.

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 scenario phrase '用户要把证据卡生成可读报告' (when the user wants evidence cards turned into a readable report), which is enough to trigger the tool. However, there is no explicit when-not guidance and no alternatives named in the description; the prerequisite (must follow intake/followup) is only visible in the schema.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds one genuinely useful trait beyond that: results come from a real algorithm engine rather than LLM generation. It says nothing about runtime, dataset size limits, or how defaults are chosen when no thresholds 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?

Four short clauses, front-loaded with the bracketed topic and the user scenario before the return statement. Little waste, though the bracketed label partially duplicates the annotation title.

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 description covers the return value (DEG list), which matters since there is no output schema, and it names the input artifact. However, with five parameters—all optional, which is unusual for an analysis requiring two expression matrices—an agent gets no guidance on which inputs are actually needed for a valid run.

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 each of the five parameters is already labeled in the schema; baseline 3 applies. The description adds no meaning beyond that—it does not explain what happens when pval_threshold or log2fc_threshold are omitted, nor what format group_a/group_b CSV strings must take.

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: differential expression analysis over an expression matrix producing a DEG list, plus volcano plot support. Clear on its own, but it never distinguishes itself from the very close sibling act_rnaseq_deg, so an agent cannot route between the two 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?

The phrase '用户有表达矩阵要做差异基因分析' implies the precondition (user has an expression matrix), which is mild usage context. There is no when-not guidance, no prerequisites, and no mention of the alternative tools (act_rnaseq_deg, act_atac_diff, act_metabo_volcano) that compete for the same request.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds two useful pieces beyond that — the return contents (two AUCs plus the difference P value) and the assurance that a real algorithm engine executes it rather than an LLM. It says nothing about assumptions such as paired samples, equal-length arrays, or minimum sample size, which matter for a statistical comparison.

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 segments with the core purpose front-loaded, no filler, and the return value stated in one clause. The bracketed header largely restates the annotation title, which is minor redundancy rather than 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 low-complexity, deterministic three-parameter test with full schema coverage and no output schema, the description covers purpose, when to invoke, return values, and execution trustworthiness. The remaining gap is that it does not state that the three arrays must be the same length and index-aligned, which an agent could get wrong.

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 labels, scores1 and scores2 are already documented in the schema, and the description adds no further syntax, ordering, or length constraints. Baseline 3 applies because the schema carries the parameter burden rather than the prose.

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 statistical procedure and resource — DeLong's test comparing two ROC AUCs — with a bracketed header that states it up front. An agent can tell this apart from act_roc (single AUC computation) by the words 'two metrics... compare which is better.' It stops short of naming act_roc as the sibling to use for a single AUC, so it is clear but not exhaustively differentiated.

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 a clear triggering condition: the user already has two AUCs and wants to know which is better and whether the difference is statistically significant. There is no explicit when-not or named alternative (e.g. 'to compute a single AUC use act_roc'), so the routing guidance is implied rather than complete.

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

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

The annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the description's read-only behavior is already covered. The description adds: the returned keys (pico / design_type / population / topic) and the note that a real algorithm engine, not an LLM, produces the results. Together these tell the agent what kind of data to expect, though it does not say what happens when a step has no prior 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?

The description is short and useful. It leads with the core intent, then gives the use condition, the returned fields, and the engine provenance. The bracketed title repeats the annotations title, which is mild redundancy, but nothing else 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?

For a 2-parameter, non-destructive read tool with no output schema, the description covers the purpose, the trigger, and the returned keys. It is only slightly incomplete in that it does not describe the behavior for steps that lack prior context or the response shape when fields are 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 100%: the schema documents 'step' (data index 1-11) and 'project_id'. The description adds no syntax or format details beyond restating the returned fields, so the schema does the work here. A baseline of 3 is appropriate.

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

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

The description states a specific action and resource: fetching the context available for one step of a design workflow, based on prior steps (PICO / design type / population). Because the scope is so narrow, an agent can identify what the tool does; the sibling list does not name a competing 'get context' tool, so no explicit sibling contrast is needed.

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 a clear trigger for use: when drafting the content of a step that should build on earlier steps, fetch the context first so the agent does not re-ask the user for information already supplied. It does not say when not to use the tool or name an alternative, so it is slightly 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.

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

Annotations already establish it as a read-only, closed-world, non-destructive lookup, so the description is free to add the more valuable context: rules are executed by a real algorithm engine rather than generated by an LLM, and explanations must be grounded in them rather than improvised. That trust/provenance signal is genuinely beyond what the annotations 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 the bracketed resource label, followed by trigger phrases and then what is returned — a sensible order with little filler. The parenthetical 'don't make it up' clause is slightly redundant with the preceding 'keep explanations consistent with platform rules' but it is short.

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 input parameters and no output schema, the description carries the return-value burden and does describe the shape of the payload conceptually (per-step gate boolean, three named cross-step gates, verbatim rule text). It does not describe the field structure or what the referenced 'steps' are, leaving a modest gap for a zero-arg, no-output-schema 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?

The tool takes zero parameters, so the baseline of 4 applies; there is no argument semantics for the description to explain and it does not waste space pretending otherwise.

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 concrete resource (design gate rules) and states exactly what the tool yields: per-step hard-gate status plus the verbatim text of the three cross-step gates G1/G2/G3. That is specific enough to distinguish it from look-alike siblings such as act_design_guide or act_design_context, though it never names them 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?

Trigger conditions are given as concrete user utterances ('why won't this step let me pass', 'what conditions must the design satisfy', 'which are hard requirements') plus the assistant-side case of explaining a blocked step, along with an instruction to read this before answering. No exclusions or named alternative tools are offered, which keeps it from a 5.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. Beyond that, the description adds genuine context: the return value is a recommended design with rationale, and it is produced by a real algorithm engine rather than an LLM, which tells the agent the output is reproducible and citable. It does not cover input edge cases, such as what happens with a vague PICO.

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 compact and front-loads the user situation before stating the return value. The trailing parenthetical about the algorithm engine, while useful, reads as a bolted-on credibility claim rather than integrated 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 correctly carries the burden of saying what comes back (design plus rationale), which an agent needs in order to route results onward. The remaining gap is guidance on handling vague or underspecified PICO input, which matters given 'pico' is free text and the only required 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 100%: both 'pico' and 'feasibility' are documented in the schema with clear meaning. The description does not add meaning about either one, notably not explaining how the optional feasibility constraints (case volume, timeline, budget) influence the recommendation. Baseline 3 is appropriate when the schema does the work.

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 function: it recommends a research design plus the reasoning behind it, for a user who doesn't know which design their question requires. That distinguishes it from siblings that execute a chosen design (act_randomize, act_design_sample_size) or refine the question itself (act_pico_refine), though it 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?

It gives an implied trigger condition: use this when the user doesn't know which design they need, or needs to choose an option. It offers no explicit exclusions or hand-offs, so an agent cannot tell from the description when to prefer act_pico_refine or act_design_context first, or what to do after a design is recommended.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds meaningful context beyond that: what is returned (每组例数与合计) and that results come from a deterministic algorithm engine rather than LLM generation — a relevant trust signal for a numeric 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?

Very compact and front-loaded: purpose, trigger, and return value in three short segments. The bracketed header duplicates the annotation title, and the engine-provenance note is a slight aside, but nothing is genuinely 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?

Describing the return value compensates for the missing output schema, and the annotations cover the read-only profile. The gap is that all six parameters are optional yet sample_type determines which are actually needed — the description never explains that dependency, which is the main thing an agent could get wrong.

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 all six parameters (sd, alpha, power, effect, dropout, sample_type) are already documented in the schema. The description adds no extra meaning about which parameters each sample_type requires or how defaults interact, so baseline 3 applies.

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

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

States a specific verb+resource (样本量计算, 设计口径) and makes clear it answers 'how many cases per group'. The '设计口径' qualifier implicitly separates it from act_animal_sample_size and act_randomize, though it never names 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?

Gives a trigger condition ('用户在设计阶段要算样本量、问要做多少例'), which is real usage context. However it offers no exclusions and no explicit routing away from the animal-design or randomization siblings, leaving the agent to infer the boundary.

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?

The annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured fields. The description's one behavioral addition is the claim that a real algorithm engine executes the computation rather than an LLM, which is meaningful trust context. It says nothing about what the goodness-of-fit return looks like, what sample-size or minimum-data assumptions apply, or how ties/non-numeric input are handled, so it adds only modestly beyond the annotations.

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

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

The description is two short clauses plus a return-value note, front-loaded with the operation label, with no filler or repetition. Every element carries signal, though the bracket-prefix duplicates the annotation title and the parenthetical engine claim is somewhat tangential to invocation. Efficient overall.

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 tool with two fully-described parameters and no output schema, the description covers the what and a hint of the return (goodness of fit), which is close to adequate. What is missing is the set of supported distributions for 'dist' and any note on input requirements, both of which an agent needs before calling. Given the low complexity, a 3 reflects minimum viability rather than a serious deficiency.

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 both parameters are already documented in the schema and the baseline of 3 applies. The description adds no meaning beyond that: it does not list which distribution names are accepted for the 'dist' parameter (there are zero enums, so this is the main gap the prose could have filled), nor does it constrain the numeric string array. No compensating information is provided.

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 bracketed tag names the operation (distribution fit test) and the following clause states the concrete user question it answers: is the data normal, and what distribution does it follow. That is a specific verb-plus-resource framing that an agent can match against a request, and it is distinguishable from neutral summary siblings like act_data_quick_stats or act_stat_center. It stops short of a 5 because it never states the method family or scope (single column, one-variable-at-a-time) explicitly in the prose, only via 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 gives an implied trigger, namely when a user asks whether data is normal or which distribution it follows, which is genuine usage guidance for routing. However, it names no alternative tools and no exclusions, so an agent cannot tell when it should prefer act_data_quick_stats, act_ic50_fit, or act_stat_center instead. Usage is inferable but not disambiguated.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered structurally. The description adds one genuinely useful behavioral claim — '真实算法引擎执行，非大模型生成' — signaling deterministic computation rather than generative output. It says nothing about supported species pairs, unit conventions, or limitations of the conversion model, which are the behaviors that matter for this 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 text is short and front-loads the purpose in a bracketed label, then states the trigger and the return value. The bracketed label largely duplicates the annotation title, and the parenthetical trust claim sits awkwardly at the end, 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?

For a three-parameter deterministic calculation with no output schema, the description does say what comes back (dose plus rationale), which is the main gap it needed to fill. It remains incomplete on the two things an agent most needs before calling: the dose unit convention and the supported species values for the free-text species fields.

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 baseline of 3 applies; the schema already documents all three parameters. The description adds no meaning beyond that — notably it never specifies the unit basis for source_dose (e.g., mg/kg) or accepted species naming, and it frames the operation as animal-to-human even though target_species is a free string allowing any pair.

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 operation — converting a dose between species (animal to human) — and states what it returns (converted dose plus rationale). It does not, however, distinguish itself from potentially overlapping siblings such as act_bridge_convert or act_pkpd_simulate, so an agent cannot rule out alternatives from the 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?

The phrase '用户要把动物剂量换算成人体剂量' supplies an implied trigger scenario, which is adequate context for when to call it. There are no explicit exclusions, no naming of alternatives, and no stated prerequisites (e.g., which species pairs are supported).

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

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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world). The description adds that results come from a real algorithm engine rather than LLM generation and that the payload is pairwise P values, which is useful since no output schema exists. It omits the multiplicity adjustment method, which materially affects how the returned P values should be read.

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, front-loaded sentences that state the method, the trigger, and the return value with no filler. The bracketed opening largely restates the annotation title, which is 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 single-parameter statistical test with no output schema, the description does state what comes back (pairwise P values). It leaves out the adjustment method and any prerequisite on group sizes, details that matter for correctly interpreting a Dunn result.

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?

Only one parameter (groups) exists and schema description coverage is 100%, with the schema already documenting the {group name: [values...]} shape. The description adds no constraint on minimum group count, equal-format requirements, or missing-value handling, so the baseline 3 applies.

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

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

The description names a specific method and resource — Dunn multi-group non-parametric pairwise comparison — and anchors it to the Kruskal-Wallis workflow, which implicitly separates it from parametric post-hoc siblings like act_tukey_hsd. It never names those siblings explicitly, so an agent must 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?

The trigger condition is stated clearly: use this after a Kruskal-Wallis test when multi-group pairwise comparisons are needed. There is no explicit when-not guidance or named alternative (e.g. Tukey HSD for parametric data), which keeps it just 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.

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds a genuinely useful non-annotation claim: the computation runs on a real algorithmic engine rather than being LLM-generated, plus it discloses the return shape (pathways + P values). It stops short of disclosing background/p-value correction method or gene-ID requirements.

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?

Very compact: a bracketed topic label, one sentence of use case, one sentence of return values, and a one-clause trust note. It is front-loaded and every clause carries information, though the bracketed title duplication of the annotation title is slightly redundant.

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

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

For a 3-parameter read-only analysis tool with no output schema, the description covers purpose and return values adequately. It is missing practical preconditions an agent would need to call it correctly — organism/species, gene identifier namespace, and how many genes are needed — which matter for an enrichment engine.

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 db_filter (GO_BP/GO_CC/GO_MF/KEGG), gene_list, and project_id each documented inline, so the schema carries the parameter burden. The description adds no extra semantics such as accepted gene ID types, minimum list size, or default db_filter behavior, so baseline 3 applies.

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

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

The description states a specific verb+resource: GO/KEGG pathway enrichment on a gene list, returning enriched pathways with P values. The GO/KEGG qualifier implicitly separates it from the metabolomic (act_metabo_enrichment) and protein (act_protein_enrichment) enrichment siblings, though it never explicitly names or contrasts with act_gene_pathway, which is the closest neighbor.

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 in the phrasing 'users with a batch of genes wanting GO/KEGG enrichment / finding pathways', which tells the agent the input precondition (a gene list) and the goal. There is no explicit when-not guidance, no named alternative, and no mention of prerequisites such as species or gene ID format, so the agent must infer routing among the several enrichment tools.

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

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description does add real value by disclosing that a genuine algorithm engine executes the computation rather than an LLM, plus what is returned. It says nothing about defaults, whether all parameters are optional, or failure 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?

Very compact and front-loaded: purpose first, then return values, then the execution-provenance note. The bracketed title repeats the annotation title, but overall 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?

Given all three parameters are optional and there is no output schema, an agent needs to know defaults and whether a no-argument call is meaningful — the description does not say. It does cover what is returned, which partly compensates for the missing output 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 100%, so baseline is 3. The description mentions none of the three parameters (events, grid_size, n_clusters) and adds no meaning about expected formats, defaults, or the effect of grid_size versus n_clusters.

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 and resource — unsupervised clustering of flow cytometry data — and states the output (cell populations and their proportions). That is enough to distinguish it from the nearest sibling, act_fcs_gate, though the distinction is never made explicit.

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 '用户要对流式数据做无监督聚类分群' functions as an implicit when-to-use trigger, and 'unsupervised' implicitly contrasts with gating-based workflows. However, no alternative tool is named, no prerequisite is stated, and there is no guidance on when not to use 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?

The annotations already establish read-only, non-destructive, closed-world behavior. The description adds meaningful behavioral context by stating that execution uses a real algorithm engine rather than an LLM and that the return is a gating ratio; it still omits error behavior and handling of omitted optional parameters.

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 short and front-loads the tool category and result, with no filler text. The bracketed title duplicates the annotation title, and the fragmentary phrasing slightly reduces 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 tool with a nested params object, three optional parameters, and no output schema, the description gives only high-level purpose and return type. The schema covers parameters, but the description does not explain accepted event formats, method values, nested parameter structure, or the shape of the gating-ratio output.

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 events, method, and params. The description adds no parameter-level detail beyond the schema, making the baseline score 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 the resource (flow cytometry gating), the use case (user has flow data needing gating), and the result (gating ratio), so the core purpose is clear. It does not explicitly differentiate from the sibling act_fcs_cluster, which also handles FCS data, 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 phrase '用户有流式数据要做圈门' gives an implied use case for flow cytometry data requiring gating. However, there is no when-not guidance, prerequisite information, or comparison to alternatives such as act_fcs_cluster.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds genuinely useful context beyond that: results come from a real algorithm engine rather than LLM generation (真实算法引擎执行，非大模型生成) and that it returns a conclusion plus interpretation. It does not explain what happens with zero required parameters, how stage and method interact, or whether an invalid stage value errors out.

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?

Very short and front-loaded: the bracketed topic label, then the use case, then the return/engine note. Every sentence carries information and nothing is padded. Slightly terse given the ambiguity around what the stage parameter means, but structure is clear.

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-optional-parameter, non-destructive read tool with no output schema, saying it returns a conclusion plus interpretation covers the return side adequately. The gap is that both parameters are optional yet the description never says what default behavior is when neither is supplied, nor how the two are combined to produce a stage.

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 both parameters (stage, method) are already documented in the schema and the baseline is 3. The description adds nothing about parameter meaning — notably it never clarifies whether 'stage' is a raw score to be converted or a stage label, which is the key ambiguity. It also does not state which method values are valid beyond the schema's ishak/metavir/nas list.

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: liver fibrosis staging (肝纤维化分期) with named systems Ishak/METAVIR. An agent can tell this apart from the many other act_* statistics and omics tools because none of the siblings cover fibrosis staging. It stops short of 5 only because it does not state scope precisely, e.g. whether it derives a stage from input data or just labels one.

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 '用户要做肝纤维化分期' implies the triggering condition (a user wants fibrosis staging), which is adequate context. However, no alternatives are named and no exclusions are given, e.g. when to use act_ihc_score or act_gleason-style pathology scorers instead, or which method to pick when the user is unspecified.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact beyond them – the output is produced by a real algorithm engine rather than an LLM, which tells the agent the result is deterministic and reproducible. It says nothing about how the chart_type value affects output or about any 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?

Very short and front-loaded: the bracketed action tag comes first, then the use case, then the return value. No filler sentences. Slightly hurt by mixed Chinese/English phrasing and the tag restating the title, but it is economical overall.

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 two-parameter read-only text generator with full schema coverage, the essentials (what it does and what it returns) are present. Gaps remain around the accepted chart_type values and whether context is optional, which an agent must infer from the schema 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 100% and both properties carry their own descriptions, so the baseline is 3. The description never mentions either parameter (chart_type or context), adding no meaning beyond the schema, though it also does not mislead about them.

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?

"【图注生成】" plus "用户有图要写图注、Figure legend" states a specific verb (generate/write) and resource (figure legend), and the description also names the output: legend text. Among the ~100 siblings there is no competing legend tool, so no explicit differentiation is needed; the purpose is unambiguous 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 a clear triggering condition: the user has a figure and needs a legend written. It does not name exclusions or point to any alternative (e.g. act_forest_chart for drawing the chart itself), so it stops short of full when/when-not routing.

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

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

The annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. Beyond that, the description discloses the return payload (column names and types); with no output schema, that is genuinely useful. It also adds a trust signal that the results come from a real engine rather than LLM generation. It says nothing about error behavior for invalid or missing file_id values, so it is not a 5.

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

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

The description is three compact segments: a bracketed label, the use case, and the return value; the purpose is front-loaded. Every clause carries information, and there is no filler. The bracketed tag mildly repeats the annotation title, but that is negligible.

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 one-parameter read tool with complete schema coverage and no output schema, the description covers purpose, the trigger, and the return shape. It is only slightly short of complete because it omits failure modes for invalid file ids and any note on output ordering or size.

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?

There is a single parameter, file_id, and schema description coverage is 100%, so the schema already documents it. The description adds no meaning beyond that: it does not explain how to obtain a file_id, or what happens if the id is unknown. A 3 is the correct baseline when the schema does the work.

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: read the variable column names of a given data file, returning column names and types. It is clearly distinct from analytical siblings such as act_data_quick_stats or act_table_one; those consume the file, while this one only inspects its schema. It does not explicitly name a sibling to avoid, 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?

It gives explicit when-to-use guidance: call it before doing a Table One or modeling, because you must see which variable columns exist. That is a concrete trigger tied to real downstream tasks. It stops short of a 5 because it never states exclusions, such as when to use a quick-stats or profiling tool instead, or which file types are acceptable.

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?

The annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: it states that the output is a vector graphic and that it is produced by a real computation engine rather than generated by an LLM, which tells the agent the result is reliable and reproducible. It says nothing about output format, how the artifact is returned, or any limits on the input, so a 3 is appropriate.

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 compact and front-loaded: it starts with the tool category in brackets, then gives the trigger condition, then the return value. The bracket label partly restates the title, but every clause still conveys something useful. Nothing is padded or buried.

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

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

For a simple 3-parameter tool with no output schema, the description still leaves one real gap: it says the result is a 'vector forest plot' but not how that artifact is delivered (a file path, a base64 blob, a URL), and it does not say how many data items are allowed. The purpose and input requirement are complete; the output contract is not.

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%; every parameter, including the item structure {name, estimate, ci_lower, ci_upper}, is already documented in the schema. The description's mention of HR/OR/RR and confidence intervals helps map the user's effect-size vocabulary onto those fields, but does not add syntax or constraints beyond the schema. The baseline of 3 is correct.

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 concrete verb and resource ('画森林图' / draw a forest plot) plus the required input condition: the user has HR/OR/RR values with confidence intervals. That is far more specific than the tool name alone. It never names a sibling or explains what makes it different from neighboring statistics tools (e.g. act_meta_egger, act_km_curve), 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 clause '用户有 HR/OR/RR 和置信区间，要画森林图' tells the agent exactly what situation triggers this tool: effect-size plus CI data and a request for a forest plot. That is clear when-to-use context. There are no explicit exclusions and no alternatives are mentioned, so it is not a 5.

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=true, destructive=false, and openWorld=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact: results come from a real algorithm engine rather than LLM generation. However, it says nothing about input-size limits, latency, or how associations are ranked or scored.

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 short and front-loaded: the bracketed title sets the domain, then the use case, then the return values. The bracket title duplicates the annotation title, which is minor waste, but no sentence is confusing or buried.

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

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

For a single-parameter, read-only tool with no output schema, the description covers the essential contours: what goes in, what comes out, and the provenance of the results. What is missing is detail on the shape of the returned associations and any identifier conventions, which would make it fully self-sufficient.

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?

There is a single parameter, genes, documented at 100% schema coverage as 'gene list'. The description does not add syntax guidance such as accepted gene identifier formats (symbol, Ensembl ID), species assumptions, or a maximum list length, so it stays at the baseline where the schema does the work.

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 and transformation: from a batch of genes, find pathway, disease, and drug associations, summarized in the bracket title as a gene-pathway-disease network. This distinguishes it reasonably well from nearby siblings like act_enrich or act_ppi_network, but 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?

It implies the usage scenario ('when the user wants to find pathway/disease/drug associations from a batch of genes') but gives no exclusions and does not route the agent away from similar tools such as act_enrich or act_ppi_network. The condition for use is clear only in the most general sense.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds one genuinely novel behavioral claim: results come from a real algorithm engine rather than LLM generation, which matters for trust. It says nothing about data sources, coverage, or what happens when a gene name is not recognized.

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 compact segments: a bracketed label, the trigger condition, and the return type plus provenance note — all front-loaded with zero filler. The bracketed label largely restates the annotation title (基因信息检索), which is minor duplication but not bloat.

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 simple one-parameter read tool with annotations and no output schema, so the description's coverage of purpose, trigger, and return kind is close to sufficient. It could be stronger by mentioning the underlying gene database or behavior for ambiguous gene symbols, which would matter for a lookup 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?

There is a single required parameter with 100% schema description coverage ('基因名/关键词'), so the schema already carries the semantics. The description's mention of aliases and function hints at what the query string can contain, but adds no format, spelling, or organism-scope guidance beyond the schema. Baseline 3 applies.

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

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

The description names a specific verb (检索/retrieval) and resource (基因信息), and even enumerates the question types it answers: what a gene does, its aliases, and its function. It does not distinguish itself from near-neighbors such as act_gene_pathway, act_enrich, or act_lit_search, so an agent still has 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?

It provides a clear activation condition — '用户问某个基因是干什么的、别名、功能' — which reads like a routing rule an agent can match against user intent. There is no explicit when-not guidance and no named alternative (e.g., use act_gene_pathway for pathway membership), so the selection boundary remains implicit.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds genuinely new context: that computation runs on a real algorithm engine rather than being LLM-generated, and it enumerates the outputs (differential genes, enrichment results) despite there being no output schema. It does not mention runtime or data-download behavior for large GEO series.

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 structure is well front-loaded: bracketed scope, then when-to-use, then returns, then the engine note. Some redundancy exists because the bracketed label duplicates the annotation title, but every element adds information and nothing is padding.

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

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

For a multi-stage pipeline tool with four parameters and no output schema, the description covers purpose, trigger condition, and return content, which is the essential core. It stops short of the operational detail such a heavy pipeline needs: expectations about input validity, runtime, and how partial failures are handled.

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 geo_id, species, pval_cutoff, and logfc_cutoff are already documented in the schema. The description adds no parameter-level meaning (no defaults, no example cutoffs, no species behavior), so the baseline 3 is appropriate.

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

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

The description names a specific resource (GEO dataset) and a specific composite operation: differential analysis, enrichment, and immune infiltration in one pipeline, plus the returns (differential genes, enrichment results). It implicitly distinguishes itself from single-step siblings like act_deg_analyze and act_enrich by being a full pipeline, but 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?

It gives a when-to-use condition: user supplies a GEO ID and wants the full differential/enrichment/immune-infiltration workflow. It does not say when to prefer the single-step siblings (act_deg_analyze, act_enrich, act_tme_analyze) or what prerequisites the GEO dataset must satisfy, so routing among similar tools 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.

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered structurally. The description adds one genuinely useful behavioral fact: '真实算法引擎执行，非大模型生成', signalling deterministic, auditable computation rather than generative output. It says nothing about how invalid or out-of-range grade combinations are handled, which is the main behavioral uncertainty for a 5x5 grade-pair 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 compact segments: a bracketed purpose label followed by a usage condition and return statement. It is front-loaded and free of padding, though the bracket-glyph formatting and the '返回：' colon introduce mild structural noise rather than flowing prose.

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

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

For a two-integer-parameter, no-output-schema tool, the description covers purpose, trigger context, deterministic execution note, and what is returned (Grade Group and risk stratification). Given there is no output schema, one could ask for slightly more detail on the return structure, but an agent has enough to invoke and interpret 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 100% (both primary_grade and secondary_grade are documented as integers 1-5), so the baseline is 3. The description adds no meaning beyond the schema — no clarification on ordering (primary vs secondary), no note on what happens with equal grades or grade 1+1, and no range/validity constraints beyond what the schema states.

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 the resource and operation precisely: Gleason grading grouping, mapping a prostate cancer Gleason score to its Grade Group plus risk stratification. It is unmistakably distinct from every sibling tool (all of which are unrelated statistical/omics utilities), so no disambiguation is needed. It stops short of a truly distinctive verb form, and the bracketed label repeats the annotation title.

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 '用户问前列腺癌 Gleason 评分对应哪个 Grade Group' implies the trigger condition (user asks about Gleason score to Grade Group conversion), which is usable context. However, there is no explicit statement of when not to use it, no mention of related tools (e.g. act_risk_ratio or act_survival_analyze for downstream risk analysis), and no prerequisites or input validation guidance.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral claim — that a real algorithm engine performs the fit rather than the LLM — but says nothing about default model selection, minimum data points, convergence failure behavior, or how the confidence interval is derived.

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

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

Two compact clauses: purpose/inputs first, then outputs and the execution-engine note. No filler, though the bracketed title prefix slightly duplicates the tool title in annotations.

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

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

With no output schema, the description correctly supplies the return values (IC50 and 95% CI), which is valuable. However, for a 4-parameter fitting tool it omits practical essentials: defaults for model and direction, required minimum number of concentration points, unit/format expectations for the string arrays, and what happens on a failed fit.

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 baseline of 3 applies. The description adds no meaning beyond the schema for 'model' (4PL/3PL), 'direction' (inhibition/activation), or the array-of-string format of concentrations and responses; notably it does not say which model is used when 'model' is omitted.

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 ('IC50 曲线拟合') plus the required input pairing (drug concentration + inhibition rate) and the output (IC50 with 95% CI). This clearly separates it from sibling analysis tools such as act_dose_convert_pharm or act_pkpd_eval, though no sibling is named 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?

Usage is implied by the phrase '用户有药物浓度和抑制率要算 IC50', which tells an agent the prerequisite data shape. It does not state when to prefer this over adjacent tools (e.g., dose conversion or PK/PD evaluation) or what to do when prerequisites are not met.

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

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description does add one genuinely useful behavioral fact — that a real algorithm engine executes the scoring rather than an LLM — which builds trust in the numbers. It says nothing about validation behavior (e.g. whether percentages must sum to 100 or how missing intensities are treated).

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?

Extremely compact and front-loaded: the label, trigger condition, and return values all appear in a single sentence with no filler. The only inefficiency is that the return list duplicates information already implied by the leading label.

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 states what is returned (H-score / Allred / 阳性率), which is the right thing to include. For a 5-parameter calculation tool it still omits the accepted stain_type values and any constraint on the four percentage inputs, leaving real ambiguity about how 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 100%, so the baseline is 3. The description adds no parameter meaning beyond the schema and never mentions stain_type, which is the one required parameter and has no enum — the valid stain type values (and whether they select which score is computed) are 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?

The description names a specific verb+resource (IHC 免疫组化评分) and enumerates the concrete outputs (H-score / Allred / 阳性率), so an agent knows exactly what computation this performs. It does not differentiate from nearby pathology-scoring siblings such as act_gleason or act_fibrosis_stage, but the domain 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?

"用户有 IHC 染色结果要算..." gives a usable trigger condition (user has IHC staining results and wants these scores). However, there are no exclusions, no prerequisites, and no pointer to any alternative tool, so the guidance is implied rather than explicit.

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=true, destructive=false and openWorld=false, so the safety profile is covered structurally. The description adds one genuinely useful behavioral claim — that execution goes through a real algorithm engine rather than LLM generation — but says nothing about estimand choice, convergence/fallback behavior, or output shape beyond 'weights and 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?

Very short and front-loaded: method name bracketed first, then trigger, then return value, then an execution-trust note. Every clause carries information; only the parenthetical engine note is somewhat promotional rather than operational.

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 at least states what is returned (weights and weighted effects), which is necessary. However, for a two-parameter inferential statistics tool it omits the estimand (ATE vs ATT), whether confidence intervals are produced, and how the odd string-typed numeric arrays should be formatted.

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 parameters (treatment 0/1 and propensity scores) documented inline, so the schema carries the parameter burden and 3 is the baseline. The description adds no extra meaning — notably it does not clarify that inputs are passed as string arrays or explain the expected propensity-score range.

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 statistical method (IPTW / inverse probability weighting) and the analysis it performs, plus what it returns (weights and weighted effect estimates). It does not differentiate itself from similar siblings such as act_psm_match or act_smd_balance, which keeps it from 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 '用户要做倾向评分加权分析' implies the trigger condition (user requests propensity-score weighting), but there is no explicit when-not guidance and no mention of the closely related alternative tools (matching, balance diagnostics, effect-size calculation) that an agent must choose between.

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?

The annotations already cover read-only, non-destructive, and non-open-world behavior. The description adds useful context beyond that by stating results come from a real algorithm engine rather than an LLM and by summarizing the return content, though it does not discuss limitations or rate/auth constraints.

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 short and front-loads the main purpose and return shape. The bracketed title repetition and parenthetical are slightly redundant, but there is no substantial wasted wording.

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

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

With no output schema, the description appropriately summarizes that candidate journals and a three-tier strategy are returned. Given the rich input schema and annotations, it is complete enough to call correctly, though it could say more about how optional parameters affect recommendations.

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 all six parameters are already documented in the schema. The description mentions title and abstract usage and the three tiers, but it does not clearly map those tiers to the target_tier parameter or clarify the other optional inputs 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 states a specific verb and resource: recommending journals based on title and abstract, with three recommendation tiers. It is clear what the tool does, though it does not explicitly distinguish itself from any sibling 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 gives a clear usage context: when the user wants journal recommendations by title/abstract and tiered strategy. It does not provide when-not-to-use guidance or name 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 readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds a genuinely useful trait: results come from a real computation engine, not an LLM. It says nothing about failure modes (for example, a single group or non-numeric times), so the behavioral disclosure stays 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?

Two short clauses, bracketed title first, then the return statement — every line carries content and the key information is front-loaded. The repeated title phrase is slightly redundant with the annotations' title.

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 does at least tell the agent what comes back (KM curve plus median survival), which is valuable. It still omits output shape, how grouping affects the result, and edge-case behavior, so it is adequate rather than complete for a statistical 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 100%, so times, events, and groups are already documented, and the description adds no further meaning about formats, event coding, or what happens when groups is omitted. Under the stated baseline, a 3 is the correct score when the schema does the work.

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 (Kaplan-Meier) and names the deliverables (KM curve and median survival), so what the tool does is unambiguous. It doesn't name the sibling it is meant to replace (act_survival_analyze / act_animal_survival), so the separation is implied 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?

"用户只要 KM 曲线和中位生存，不做多因素" states a selection condition: use this when only univariate KM plus median survival is needed rather than a multivariable model. That is real guidance, but the alternative tool is never named and no prerequisites or exclusions for the data 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?

The annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false. The description adds genuinely useful context beyond those: it discloses what is returned and that the result comes from a real algorithm engine rather than LLM generation, which the agent could not know otherwise. It still says nothing about where the user's own corpus comes from or what happens when no prior articles exist, so it is value-adding but not rich.

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 compact and front-loads the purpose in a bracketed label, followed by the trigger and the return value. It is terse rather than padded, though the parenthetical engine note slightly interrupts the flow.

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, non-destructive tool with a fully described schema, the description covers purpose, trigger, and return payload, which is enough to call it correctly. The residual gap is the provenance of the comparison corpus, which matters for interpreting results but is not required to invoke the tool.

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

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

Schema description coverage is 100%, so both `text` and `top_n` are already documented in the schema, and the description adds no syntax, length limits, or default for `top_n`. Baseline 3 applies since the schema carries parameter meaning.

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+resource: comparing a piece of text against the user's own previously written articles to measure textual overlap (查重), and states the return payload (overlap score plus similar literature). It is distinguishable from sibling literature tools like act_lit_search or act_lit_verify_citations, though it does not explicitly name them as 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?

It gives an implied trigger — 'when the user asks whether this text overlaps with my own earlier articles' — which is a usable situation cue. However, it gives no explicit when-not guidance and does not route the agent to or away from the sibling literature-search/verification tools, leaving selection to inference.

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

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

Annotations already establish readOnly=true, destructive=false, openWorldHint=false, and the description is consistent with that closed-world profile (a fixed in-site corpus of 1.53M PMC records). It adds genuinely non-obvious behavioral context beyond the annotations: results come back as a list including PMCIDs, and the retrieval is done by a real algorithm engine rather than LLM generation, which tells the agent the output is citable rather than synthesized.

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?

Extremely compact and front-loaded: corpus scope first, usage triggers second, return format third, reliability note last. No sentence is redundant, and the bracketed header lets an agent pattern-match the tool's domain at a glance.

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 does supply the one thing that matters for interpretation — results are a literature list with PMCIDs — which is enough to call and consume the tool. It stops short of saying how many results come back by default, whether abstracts are included, or how this differs from the PubMed sibling, leaving meaningful gaps for an agent choosing among search 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 100% for both parameters (q with an English-works-better note, limit), so the schema already carries parameter meaning. The description adds only the return-shape detail (list with PMCID) and says nothing about query syntax, ranking, or what limit defaults to — 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 names a specific verb+resource (文献检索 / literature search) and quantifies the corpus (站内 153 万篇 PMC), so an agent immediately knows what is searched and over what body of material. However, it never distinguishes itself from closely overlapping siblings such as act_pubmed_search, act_literature_overlap, or act_lit_verify_citations, so sibling disambiguation is left to guesswork.

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 usable positive triggers — '用户要找文献、找证据、看研究现状' (user wants to find literature, evidence, or the state of research) — which is real when-to-use guidance. But there are no exclusions or alternatives: with act_pubmed_search sitting right next to it, the description should say whether this replaces or complements external PubMed search; that is left entirely implicit.

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

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

Annotations already declare readOnlyHint, destructiveHint=false and closed-world scope, so the safety profile is covered. The description adds genuinely useful behavioral context beyond them: it says results come back item-by-item ('逐条核验结果') and emphasizes a deterministic algorithmic engine rather than LLM generation, which is a meaningful trust signal for this task. It still omits what a verdict looks like or how failures 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?

Three short segments, front-loaded with the user problem before the return-value note. The bracketed label slightly duplicates the annotation title, but overall there is no wasted wording.

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

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

There is no output schema, so the description bears the burden of explaining returns, and '逐条核验结果' is only a sketch – it does not say what fields or verdict types an agent should expect per citation. Combined with the absent usage exclusions, this is adequate but not complete for a verification tool.

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

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

Schema description coverage is 100% for both parameters ('text' – body text containing citations, and 'topic' – subject), so the schema already carries parameter meaning. The description adds nothing about how 'text' is parsed or what role 'topic' plays, so the baseline 3 applies.

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

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

The description names a specific verb and resource ('引文真实性核验' – verification of citation authenticity) and states the exact problem it solves (users suspecting fabricated references). It is clearly distinguishable from siblings like act_lit_search or act_citation_format, though it 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?

It gives a concrete trigger condition: use this when the user worries references may be fabricated and wants to check citation authenticity. It does not state when NOT to use it or point to related siblings such as act_lit_search or act_citation_format, so routing among the literature tools is still left partly to inference.

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

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

The annotations already cover the safety profile (readOnly=true, non-destructive, closed-world), so the description's job is to disclose behavior beyond that, and it does: it enumerates the statistical outputs (fixed effects with real variable names, omnibus tests, interaction tests, primary_test, ICC, variance components, subject/observation counts), states that missingness and convergence warnings are surfaced, and notes allowance for missing data. It also distinguishes itself from model-generated text by stating a real algorithmic engine executes the 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?

Purpose is front-loaded, which is good, but the opening bracketed header essentially restates the annotation title, and the parenthetical enumeration of follow-up patterns (measured once before/after, three or four per person...) is repetitive hedging rather than new information. The return-value sentence is a useful but very dense run-on list.

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 eight parameters, nested objects, and no output schema, the description carries the burden of telling the agent what comes back, and it does so thoroughly (coefficients, omnibus, ICC, variance components, counts, warnings). The main residual gap is that model-type choices such as link functions or assumption checks 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 description coverage is 100%, so every parameter (formula, subject, re_formula, reference, categorical, time_values, reml) already carries its own explanation, and the description adds little beyond reiterating the group-by-time interaction pattern. Baseline 3 is the correct ceiling when the schema already does the parameter-level work.

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 (linear mixed model) plus a specific mode (formula-based), then scopes it precisely to the longitudinal/repeated-measures case: the same subject measured at multiple time points, comparing group-by-time trends and interaction effects. That scoping alone lets an agent separate it from cross-sectional siblings such as act_two_way_anova or act_survival_analyze without reading 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 a concrete trigger list (pre/post, multiple follow-ups, three or four measurements per subject) and an explicit comparison against repeated-measures ANOVA, framed as the modern replacement that tolerates missing data without sphericity testing. What's absent is an explicit when-not-to-use clause and mention of the sibling it should defer to for non-longitudinal comparisons, so the routing is strongly implied rather than spelled out.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds one genuinely useful trait — results come from a real algorithm engine rather than LLM generation — but says nothing about which pathway database is queried, default FDR behavior, or correction method.

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 clauses, front-loaded with the purpose and followed by the return and engine-provenance note; nothing is wasted. The bracketed header is somewhat redundant with the title field but also restates the core purpose compactly.

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 read-only tool with full schema coverage, purpose and provenance are covered, but 'returns: pathway enrichment' does not tell the agent what fields come back (pathway name, p-value, FDR, hit metabolites) with no output schema to fill the gap. Adequate but with a clear omission.

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 both parameters (metabolites list, FDR threshold) are already documented in the schema. The description only implies the metabolites input through the scenario sentence and adds no syntax, identifier-format, or default-value guidance beyond that baseline.

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 (metabolite pathway enrichment) and the input condition (a batch of differential metabolites). It implicitly differentiates from siblings such as act_gene_pathway and act_protein_enrichment via the '代谢物' qualifier, but never names 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 phrase '用户有一批差异代谢物要找通路' gives a clear triggering scenario, so an agent knows when the tool applies. It stops short of exclusions or routing advice (e.g. when to use act_enrich or act_metabo_volcano instead).

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?

The annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered structurally. The description adds genuine context beyond this: the operation is run by a real algorithm engine rather than generated by an LLM, which tells the agent the output is deterministic. It says nothing about performance, size limits, or failure modes 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 definition is two short clauses with the intent front-loaded and the return value stated second. The bracketed title tag repeats the tool name and title, so it is slightly redundant, but nothing else 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?

The input side is fully covered by the schema and the description hints at the return type ('returns: clustering heatmap'). However, no output schema exists, and the description does not say whether the result is an image, a file path, or a data structure, which is a meaningful gap for a plotting 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?

Only one parameter is accepted, and the schema documents it exhaustively: matrix shape, rows/cols, optional groups, p_values, log2fc, and the exact rejection message when it is missing. The description adds no parameter detail of its own, but because schema coverage is 100%, the baseline of 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 names a specific verb-and-resource pair ('draw metabolite clustering heatmap'), which is clearly distinct from the nearby metabolomics siblings such as act_metabo_pca, act_metabo_volcano, and act_metabo_plsda. It does not explicitly say which sibling to use instead, 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 'user wants to draw a metabolite clustering heatmap' implies the trigger condition, so an agent can infer when to call it. However, the description gives no exclusions, prerequisites, or pointers to alternative tools when a heatmap is not what the user wants.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so safety is covered. The description adds two meaningful traits beyond that: the expected return payload (PCA scores and explained variance) and the assurance that a real algorithm engine, not an LLM, computes results — relevant for trust in numbers.

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 bracketed domain tag, then use case, then return contract in two short clauses. Every sentence carries information; nothing is redundant.

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

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

The description covers purpose and return values even though no output schema exists, which is good. But for a nested-object input the most error-prone detail — the structure of the metabolite matrix and its alignment with groups — is left entirely unaddressed, so an agent could still format the payload incorrectly.

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 both parameters are documented at the top level (groups = group labels, data_json = metabolite matrix). However, data_json is a nested object with no declared inner properties, and the description says nothing about expected orientation, feature/sample layout, or whether groups must align by row — the schema baseline of 3 applies with no added 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?

States a specific method and resource (metabolomics PCA) plus the analytical intent (sample grouping trends, outlier detection), which differentiates it from siblings like act_metabo_plsda or act_metabo_heatmap by domain only. It does not explicitly name those siblings, so an agent must 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?

Gives a clear trigger condition: use when the user wants to view sample grouping trends or check for outliers. There is no explicit when-not guidance and no named alternative (e.g. PLS-DA for supervised discrimination), but the use case is unambiguous.

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

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

The annotations already declare a safe, closed-world read operation, and the description adds real value on top: it states the outputs (model and VIP) and asserts that the computation runs on a real algorithm engine rather than being LLM-generated, which is a meaningful trust signal for a statistics tool. It still does not cover preconditions such as minimum sample size or group balance.

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 one compact line with the technique tag front-loaded, the use case second, and the return value last. Nothing is wasted, though the bracketed label is somewhat redundant with the annotated title.

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 no output schema exists, the one line about return values is helpful, but for a multivariate modeling tool that takes a nested object as input, details such as minimum sample counts, group requirements, and the structure of the VIP output are 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 100%, so both parameters (data_json metabolomics matrix and groups label array) are already documented in the schema. The description adds no additional meaning about how the group labels must align with matrix columns, so the baseline of 3 applies.

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

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

The description names a specific technique and goal: metabolomics PLS-DA for supervised discriminant analysis and differential metabolite discovery, plus what is returned (a PLS-DA model and VIP values). This clearly distinguishes it from unsupervised siblings like act_metabo_pca, but it 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?

Phrasing such as '用户要做有监督判别分析' implies the use case (supervised discrimination, as opposed to unsupervised PCA or simple volcano/heatmap visualizations), but the choice among the four sibling metabolomics tools is left to inference. There are no explicit when-not-to-use conditions or prerequisites.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact, that results come from a real algorithm engine rather than LLM generation, but says nothing about output format, failure modes, or data requirements beyond what the schema states.

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 short line with a bracketed label followed by the trigger and return value, so nothing is padded. The telegraphic phrasing is efficient but reads as stacked fragments rather than explanatory prose.

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