106 deterministic medical research engines: ROC/AUC, survival, Table 1, DEG, pathway enrichment, primer design, literature search. Every response carries engine_status — auditable, not LLM guessing.
Scored across 146 tools
Many tools have overlapping purposes that an agent will struggle to separate: act_design_decision vs study_design_advisor, act_deep_review vs act_paper_review vs act_pre_review, act_design_pico_refine vs pico_refine vs act_pdf_pico, and toxicity_predict vs toxicology_assess. While individual descriptions are detailed, the sheer number of near-duplicate review/PICO/design tools makes misselection likely.
Most names are snake_case, but the set mixes two conventions: verb-first action names (act_write_chapter, act_design_generate) and method/resource names (kaplan_meier, forest_plot, roc_auc, table_one_baseline). Domain prefixes (animal_, scrna_, metabolite_) add grouping consistency, yet the overall pattern is not fully predictable.
146 tools is an extreme mismatch for any single server surface and far beyond the 50+ threshold for a score of 1. The catalogue tool (sanyu_list_actions) exists precisely because the count is too large to navigate directly, confirming the scope problem.
The surface is remarkably broad, covering study design, sample size, statistics, bioinformatics/omics, animal experiments, PK/PD, writing, and reporting checklists. Minor gaps exist (e.g., limited data manipulation/visualization beyond specific plots), but most research workflows have a corresponding tool.
投稿信 Cover Letter 用户要写投稿信、给编辑的信 投稿信正文
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | 论文题目 | |
| abstract | No | 摘要 | |
| highlights | No | 研究亮点 | |
| target_journal | Yes | 目标期刊 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, destructiveHint=false, and the description adds nothing beyond them — no output language, length, tone, or whether the generated letter is returned as text, saved, or requires the journal's name to be resolvable. For a generation tool with no output schema, that leaves the agent guessing what comes back.
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 short, but the three fragments ('投稿信 Cover Letter', '投稿信', '投稿信正文') restate the same noun without adding information, and there is no sentence structure to front-load. Brevity here reflects under-specification rather than disciplined concision.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A generation tool with no output schema and only annotations for safety hints needs the description to say what it produces and in what form; none of that is present. Two required parameters (title, target_journal) go unmentioned behaviorally, so the definition is incomplete relative to the task.
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 four clearly labeled parameters (title, abstract, highlights, target_journal), so the baseline is 3. The description adds no semantics beyond the schema — it does not say whether abstract/highlights are optional enrichments or how target_journal influences output.
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 text names the artifact ('投稿信 Cover Letter', '给编辑的信', '投稿信正文') so an agent can tell this concerns cover letters rather than the many sibling writing tools. But it is a noun-phrase restatement with no verb describing what the tool actually does to that artifact (generate? polish? review?). Purpose is inferable from the title/name, not stated in the description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is given, and no alternative is named despite siblings like act_writing_one_click, act_polish, or act_write_chapter that could plausibly overlap. The clause '用户要写投稿信' gestures at an intent trigger but not at exclusions or preconditions (e.g. does it need a manuscript or abstract first?).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
决策引擎裁决 用户要在多个方案/管线之间做取舍、要量化裁决 裁决结果与理由
| Name | Required | Description | Default |
|---|---|---|---|
| options | No | 候选方案 | |
| criteria | No | 评价维度与权重 |
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 by structured data. The description adds one genuinely useful behavioural fact — that the tool returns both a decision and its rationale — but says nothing about how weights are applied, what happens when options or criteria are omitted (all parameters are optional), or how ties are resolved.
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 short and front-loaded, but the first fragment merely repeats the tool title, and the remaining clauses are telegraphic fragments joined without structure. Space that could have specified the nested option/criteria shape is instead spent restating the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With two nested, entirely optional parameters, no output schema, and no annotation detail beyond read-only safety, the description should explain the option/criteria object shape and the result format. It mentions only that a decision and rationale come back, leaving an agent unable to construct a valid nested payload from the description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline applies; '候选方案' and '评价维度与权重' are restated by the description rather than expanded. This matters more than usual here because both parameters are nested (an array of free-form objects and a weights object) with no property definitions, and the description does not supply the expected shape or key names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete verb (裁决 / arbitrate) over a concrete resource (多个方案/管线), and adds that the arbitration is quantified against evaluation dimensions. It does not, however, distinguish the tool from closely related siblings such as act_design_decision or study_design_advisor, so an agent cannot tell them apart 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?
It gives an implied trigger condition — 'when the user needs to choose among multiple options/pipelines' and 'needs quantified arbitration' — which is enough to recognise the situation. It names no alternative tool and no exclusions, so the agent gets no routing help when several decision-related siblings are plausible.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
深度审稿（六维） 用户要一份接近真实审稿人的深度意见 深度审稿报告
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | 标题 | |
| methods | No | 方法 | |
| results | No | 结果 | |
| abstract | No | 摘要 |
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 clear without the description. The description adds nothing beyond that: it does not describe the output's structure, length, or the six dimensions, how missing optional sections are handled, or whether generation is deterministic or slow.
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 short, but it is not concise: '深度审稿（六维）' and '深度审稿报告' restate the same idea twice, and the middle phrase is a vague user-intent fragment rather than usable information. Nothing is front-loaded about behavior, inputs, or output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter generation tool with no output schema, the description should explain what the review contains and how the four sections are used. Instead, it leaves the agent guessing at output format and at what the six dimensions are, and it gives no contrast with the crowded set of review siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with title required and methods, results, and abstract optional, each briefly labeled. The description mentions no parameters at all, so the baseline of 3 applies. It neither compensates for nor degrades the schema, but it also gives no guidance on how partial inputs affect the depth of review.
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 essentially repeats the title '深度审稿（六维）' and the name 'act_deep_review', and then adds '用户要一份接近真实审稿人的深度意见 深度审稿报告'. That only tells the agent a deep review report is wanted. It never says what the 'six dimensions' are, what input is reviewed, or how it differs from near-siblings such as act_paper_review, act_pre_review, act_proposal_review, and act_pdf_review_outline.
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?
'用户要一份接近真实审稿人的深度意见' hints at a scenario: needing thorough reviewer-like input. But there is no statement about when and when not to use this tool, no prerequisites, and no routing to any of the many review-related siblings, which makes the tool choice ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
研究设计决策推荐 用户问「这个课题该用什么研究设计」「RCT 还是队列」「样本怎么取」，需要基于 PICO 给出设计类型与理由（决策树 + 评分矩阵，非大模型猜测） 推荐设计类型、框架、推荐依据、分配比例
| Name | Required | Description | Default |
|---|---|---|---|
| pico | Yes | PICO 四要素（同上） | |
| feasibility | No | 可行性约束：{can_randomize, budget_level, duration_months, single_center, rare_disease}（可选） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/ non-destructive/ closed-world, so safety is covered. The description adds meaningful behavior beyond that: the result is produced deterministically by a decision tree and scoring matrix rather than model guessing, and it enumerates what the user receives (design type, framework, rationale, allocation ratio). It does not state confidence handling or fallback behavior when PICO is incomplete.
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?
Content is dense but structurally flat: the title is restated at the start and "推荐设计类型" repeats near the end, creating redundancy. The quoted user questions are useful but packed into a single run-on block with no separators between purpose, method, and output.
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?
It discloses the return content, which matters since no output schema exists, and it signals determinism. However, the required nested PICO object is left as "同上", so the definition is not self-contained, and there is no indication of what happens when PICO elements are missing or contradictory.
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 feasibility object's keys are enumerated in the schema, so the schema carries most of the load. The description only adds that the reasoning is PICO-driven. The pico object is described as "PICO 四要素（同上）", a dangling reference that gives an isolated agent no field-level 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 action and resource: it recommends study design type and rationale from PICO, using a decision tree plus scoring matrix. It also covers design type, framework, rationale, and allocation ratio, which distinguishes it from pure LLM-guess siblings. It does not name the closest alternatives (study_design_advisor, act_design_generate, act_design_next_step), so sibling separation is only partial.
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?
Concrete trigger phrasing is supplied: when the user asks "what design should this topic use", "RCT or cohort", or "how to sample". That gives an agent clear activation conditions. No when-not-to-use or explicit routing to an alternate tool is stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
导出研究方案书 用户说「把方案导出来」「给我完整的方案书」「生成方案文档」。导出前应先跑「方案导出前检查」，有阻断项要如实告知用户，不要直接导出 方案书全文（分章节：题目/PICO/设计/假设/纳排/样本量/伦理/变量字典/干预/随机化/偏倚/预算）
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | 课题 id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/non-destructive/closed-world, so safety is covered; the description adds real behavioral context beyond them — the mandatory check gate, the handling of blocking items, and the sectioned structure of what is produced. The one gap is the output form (file download vs. rendered markdown vs. inline text), which matters for a tool literally named 'export' and is not stated.
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 front-loaded and purposeful: trigger phrases, then the prerequisite/gate warning, then the output contents. The long parenthetical section list is dense but earns its place by telling the agent what the export contains; minor tightening (e.g., trimming duplicate trigger phrases) would make it a 5.
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 one-parameter, no-output-schema export tool, the description covers the trigger, the prerequisite gate, the failure handling, and the returned content sections, which is close to everything an agent needs. The missing piece is delivery mechanics — output format/location — which the absence of an output schema leaves undocumented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single required parameter and schema coverage is 100%, with the schema already documenting project_id as 「课题 id」. The description adds no further meaning such as what happens if the project id is unknown or whether it must be the design-stage project; baseline 3 applies 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 gives a specific verb plus resource (export the full research protocol) and enumerates the exported content (title/PICO/design/hypotheses/eligibility/sample size/ethics/variable dictionary/intervention/randomization/bias/budget). It distinguishes itself from the sibling act_design_export_check by framing that tool as the pre-flight check and this one as the actual export.
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 lists concrete user phrasings that should route here (「把方案导出来」「给我完整的方案书」「生成方案文档」) and states an explicit prerequisite: run the pre-export check first, and if blocking items exist, report them truthfully rather than exporting. That is an explicit when-to-use plus a when-not-to-proceed condition with a named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
方案导出前检查 用户说「能不能导出了」「帮我检查方案有没有漏洞」「投稿/伦理提交前看看」，或要导出方案书之前必须跑这一步：含 SPIRIT 2025 覆盖度、GCP 审批状态、以及 G3 文档一致性（样本量是否前后一致、主要结局是否写进正文） can_export、SPIRIT 覆盖度与缺失项、G3 一致性问题清单与改法、阻断原因
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | 课题 id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already cover read-only and non-destructive behavior, but the description adds substantive context: what is verified, that it can block ('阻断原因'), and that it returns a can_export gate plus missing-item and issue lists with fixes. It does not state whether results are persisted or whether GCP status is fetched live, but for a read-only audit tool it discloses enough 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 content is dense and front-loaded with trigger phrases, but the whole definition is one unpunctuated run-on that merges triggers, the check list, and the return fields ('can_export、SPIRIT 覆盖度…、G3 一致性问题清单与改法、阻断原因') with no separators or labels. Splitting into when-to-use / what-it-checks / what-it-returns would materially improve scanability without adding words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, read-only gate tool with no output schema, the description covers both the inputs it examines and the shape of the result (export gate boolean, coverage gaps, consistency issue list with remediation, blocking reasons). The only real gap is the handoff to act_design_export after a passing check.
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, project_id, and the schema already documents it fully ('课题 id'), so schema coverage is 100% and the description adds no syntax, format, or constraint details about it. Baseline 3 applies because the schema carries the parameter meaning entirely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb (pre-export check) and resource (protocol/方案), and enumerates the three checks it runs: SPIRIT 2025 coverage, GCP approval status, and G3 document consistency. It is distinguishable from act_design_export and act_deep_review by scope, though it never names those siblings explicitly and the sentence is a run-on that blends the trigger phrases, capability list, and output list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives concrete trigger utterances (「能不能导出了」「帮我检查方案有没有漏洞」) and a hard rule ('must run this step before exporting'), which is strong when-to-use guidance. It stops short of explicit routing such as 'run this, then call act_design_export if can_export is true', so the alternative sibling is implied rather than named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
生成研究方案 用户要一份完整研究方案（含样本量、统计计划、伦理要点） 研究方案正文
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | 研究类型 | |
| title | No | 研究题目 | |
| prompt | Yes | 研究方案需求描述 |
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 elsewhere. Beyond that the description only adds the fragment '研究方案正文', which hints at output content but says nothing about generation behavior, length, determinism, or what inputs are ignored. It does not contradict the annotations, but it contributes almost no behavioral 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?
It is short with no wasted marketing language, but it is not front-loaded prose — it repeats the tool title verbatim as the first fragment and then stacks two more fragments without connectors. Terseness here reflects under-specification rather than discipline.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a generative tool with no output schema, so the description carries the burden of describing what comes back. Instead it offers only '研究方案正文', leaving the agent without guidance on output scope, structure, or how the three optional inputs interact. For a generation tool in a crowded sibling set, this is thin.
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 type, title and prompt are all documented in the schema itself. The description's mention of sample size, statistical plan and ethics points vaguely signals what the 'prompt' should contain, but adds no format, length, or constraint details 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 does state a verb+resource (生成研究方案 / generate a research protocol) and narrows the scope with the parenthetical '(含样本量、统计计划、伦理要点)'. However it is written as three unconnected fragments with no sentence structure, and it gives no differentiation from siblings that plausibly overlap, such as act_topic_research_plan, act_experiment_plan, or study_design_advisor. The purpose is inferable but not sharply drawn.
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 '用户要一份完整研究方案' gives an implicit trigger condition, but there is no explicit when-to-use/when-not guidance and no named alternative. With this many closely related design/writing siblings in the tool list, the agent has no basis in the description for choosing this tool over act_topic_research_plan or act_experiment_plan.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
建议下一步该做什么 用户问「接下来做什么」「下一步填什么」，或刚保存完一步想知道还缺哪几步 下一步的 step 编号、名称、为什么需要它
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | 课题 id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and closed-world, so the safety profile is covered. The description adds the return content (step number, name, why it is needed). However, it does not explain what the recommendation is based on, what happens when no steps remain, or error behavior when project_id is invalid.
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?
Compact and front-loaded with the core purpose, then trigger conditions, then return values. The clauses run together without punctuation, making it read as one telegraphed stream, but there is no wasted content.
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 purpose, triggers, and expected return fields. Nothing critical is missing for correct invocation, though the basis of the recommendation and the empty/terminal case are unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter (project_id) with 100% schema description coverage, so the schema already defines it. The description adds no further semantics about the id. Per the rules, this is the baseline 3.
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 (recommend the next step of a design workflow) and clarifies the output — step number, name, and rationale. It is clear what it does, but does not differentiate itself from nearby siblings such as design_step_context or design_gate_rules, 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?
It gives concrete trigger scenarios — the user asks '接下来做什么'/'下一步填什么', or has just saved a step and wants to know what remains. That is strong when-to-use guidance. It lacks explicit when-not-to-use conditions or named alternatives, 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.
PICO 结构化精炼 用户说「帮我精修 PICO」「把这句话做成 PICO」「PICO 怎么拆」，或拿着一句模糊的临床问题要做成可研究的问题；本动作只做结构化，不编造用户没说的内容，缺的要素会在结果里标出 PICO 四要素结构化结果 + 提示缺哪些要素
| Name | Required | Description | Default |
|---|---|---|---|
| pico | Yes | PICO 四要素：{population, intervention, comparison, outcome, topic} |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint=false and destructiveHint=false, so safety is covered. Beyond that, the description adds genuinely useful behavioral context: it only structures and does not fabricate content the user did not supply, and it signals that missing elements will be flagged in the output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The content is all relevant, but it is packed into one dense run-on sentence that opens by restating the title (PICO 结构化精炼), then jams triggers, the no-fabrication rule, and the return description together without clear separation.
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 single-parameter tool with no output schema, the description covers purpose, key guardrail (no fabrication), and what the result contains (structured four elements plus missing-element hints). The main gap is the absence of any differentiation from the near-identical sibling pico_refine.
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 nested pico object already enumerates population/intervention/comparison/outcome/topic. The description adds no format guidance (e.g., how to handle an empty comparison or string vs. structured input), 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 (refine/structure) and resource (PICO four elements) and lists concrete triggers such as 「帮我精修 PICO」 and 「把这句话做成 PICO」. It does not, however, distinguish itself from the sibling tools pico_refine and act_pdf_pico, which appear to overlap heavily, so an agent cannot fully disambiguate 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?
It gives explicit when-to-use conditions: when the user asks to refine/build PICO or brings a vague clinical question that needs to become a researchable one. It falls short of 5 because it never says when NOT to use it or which sibling (pico_refine / act_pdf_pico) should handle adjacent cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
实验方案生成 用户要做动物/细胞实验方案、实验设计（基础科研） 实验方案
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | 实验需求描述 | |
| experiment_type | No | 实验类型 |
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 nothing beyond them: no statement of what the tool returns, what the generated protocol looks like, latency, length limits, or what happens with an underspecified prompt.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Short but fragmentary, repeating "实验方案" three times without structure or front-loaded guidance. Brevity here comes from under-specification rather than efficient editing, so it does not earn the length it has.
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 generative tool with no output schema, so the description should convey output shape and constraints. Instead it leaves the return format, expected prompt granularity, and experiment_type vocabulary entirely unstated, which is insufficient for a two-parameter generation endpoint with many near-duplicate siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (prompt = 实验需求描述, experiment_type = 实验类型), so the schema already binds both parameters. The description adds no meaning about how to phrase the prompt or which experiment_type values are accepted, so the baseline 3 applies rather than anything higher.
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 text mostly restates the title and tool name ("实验方案生成" ... "实验方案"), with only a thin scope hint: animal/cell experiment protocols for basic research. It never states a distinct verb+resource combination that separates it from design-oriented siblings such as act_design_generate, act_topic_research_plan, or study_design_advisor.
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?
"用户要做动物/细胞实验方案、实验设计（基础科研）" implies a use case but gives no explicit when-to-use/when-not-to-use rule and names no alternative. With dozens of overlapping design/writing siblings, an agent has no basis for routing between them from this description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
想法点燃 用户只给一个模糊想法/一个词，要展开成可做研究的方向 扩展研究方向
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | 初始想法或关键词 |
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 no behavioral context beyond that: it does not say what the expansion produces (how many directions, how long, whether it includes rationale), nor whether the output is meant to feed a follow-up step. With annotations doing the safety work, the description still contributes almost nothing behavioral.
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 short and front-loaded, but wasteful: the title '想法点燃' is restated verbatim as the first token, and the expansion goal is expressed twice ('展开成可做研究的方向' and '扩展研究方向'). Removing the duplication would make it tighter without losing 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?
For a one-parameter, no-output-schema generation tool, the definition is minimally adequate: input condition and intent are covered. However, with no output schema the description should describe the shape of the returned directions and how they relate to sibling topic tools, and it does neither.
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 parameter is already documented as '初始想法或关键词'. The description mildly reinforces this by stating the input may be as thin as one vague word, which sets a useful expectation about input quality, but adds no format, length, or language constraints. Baseline 3 applies when the schema carries the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a concrete verb+resource pairing: it takes a vague idea or single keyword and expands it into a researchable direction ('展开成可做研究的方向'). That is distinguishable from execution-type siblings such as act_polish or act_write_chapter, but it does not separate itself from closely related siblings like act_topic_generate, act_topic_novelty, or act_topic_research_plan, which all operate on research topics.
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 clear entry condition is stated: the user supplies only a fuzzy idea or a single word ('用户只给一个模糊想法/一个词'). That tells the agent when this tool fits rather than a more structured topic tool. There are no explicit exclusions or named alternatives, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
文献摘要卡生成 用户给一篇文献要生成结构化摘要卡 摘要卡
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | 标题 | |
| source | No | 来源 | |
| abstract | No | 摘要 | |
| external_id | No | 外部 id |
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. However, the description does not clarify that this is a pure generation or summarization operation, does not say whether it returns text or a card object, and does not say what the card contains. With annotations carrying the safety story, the description adds almost nothing further.
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 tool's Chinese title is echoed twice, once as the title and once as the dangling trailing '摘要卡'. The middle sentence is the only one that carries information, so the definition reads as under-specified and repetitive rather than as a front-loaded statement of what the tool does. The first sentence and the trailing '摘要卡' could be removed without any loss.
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 should explain what a '结构化摘要卡' contains, such as fields, format, or typical use for later literature workflows; instead, it does not do this. For a tool in a large literature and writing suite with no documented output, that is a real gap. The agent is left guessing the return shape and the required input depth.
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 each of the four parameters (title, source, abstract, external_id) has its own schema description. Therefore, the baseline of 3 applies. The description does not say whether 'abstract' is the raw input the card is generated from, or whether the 'title' parameter is the card's title or the paper's title. It therefore adds no meaning 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 phrase '用户给一篇文献要生成结构化摘要卡' does state a verb and a resource: generate a structured abstract card from a paper. However, it never distinguishes this tool from the many siblings. For example, act_literature_compare, act_lit_systematic_review, act_pdf_pico, and act_pdf_review_outline all operate on literature as well. The final '摘要卡' merely repeats the title and adds no distinguishing information.
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 the implied trigger '用户给一篇文献', meaning the user supplies a paper. The description gives no when-to-use guidance, no when-not-to-use guidance, and no alternative tool it should route to, even though several literature tools exist. It does not state whether the tool requires a full text, an abstract, or just a title.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
与已有文献对比 用户想知道自己的发现和已发表文献比新在哪 对比结论
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | 标题 | |
| main_findings | No | 主要发现 |
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 known and the bar for the description is lower. The description adds nothing beyond that: it does not say what corpus is compared against (notably, openWorldHint=false implies a closed/local literature pool, which the description never explains), what permissions or inputs are required, or what form the "对比结论" takes.
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 short with no filler, and the core action is front-loaded. But the three fragments are run together without punctuation and read as raw notes rather than a sentence, so the low word count comes partly from under-specification rather than tight writing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, two-parameter tool there is no output schema, so the description must convey what the agent gets back — instead it only gestures at "对比结论" without saying whether that is a novelty statement, a list of comparable papers, or a structured verdict. It also omits the source of the literature being compared against, which is the single most decision-relevant fact for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with only two parameters (title required, main_findings optional), so the schema already carries the parameter meaning. The description mentions "自己的发现", which loosely maps to main_findings, but adds no format, scope, or richness guidance beyond that.
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 verb and resource (compare the user's findings against published literature to establish novelty), which is more than a restatement of the title, but the phrasing is telegraphic and fragmented ("对比结论" as a trailing noun phrase). It never distinguishes this from near-neighbours such as act_topic_novelty, act_pdf_local_compare, act_lit_digest, or literature_search_pmc, so an agent cannot tell which novelty-related 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?
"用户想知道自己的发现和已发表文献比新在哪" implies the triggering scenario (user wants to know how novel their findings are), which is genuine usage context. However there are no when-not conditions, no prerequisites (e.g. requires a written-up finding set), and no routing to alternatives among the many sibling literature/novelty tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
系统评价辅助 用户要做系统评价/Meta 的文献筛选与提取 系统评价框架
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 and only value-add context is required. The description supplies none: it does not say whether the tool returns a framework/template, a screening protocol, or guidance text, nor whether it depends on any prior conversation state. With zero parameters and no output schema, this is the only place that could have explained the return, and it does not.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is short, but it is three unpunctuated fragments rather than front-loaded prose, and '系统评价辅助' plus '系统评价框架' restate the title and each other. Minimal waste in length, but the structure does not put the operative information (what is produced) first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool takes no parameters and has no output schema, so complexity is low, yet an agent still cannot predict what comes back or how to present it to the user. For a generic 'framework' action tool whose entire value is the returned content, at least one clause describing the deliverable was needed. What remains is a topic label, not a callable contract.
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 input schema defines zero properties, so there are no parameter semantics to explain and the baseline of 4 applies. The description does not need to compensate for any schema gap, and it makes no misleading claims about inputs.
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 domain (systematic review / Meta) and two activities (literature screening and extraction) plus a 'systematic review framework', so the topic is identifiable. But it never states what the tool actually does — there is no verb describing the operation or the artifact produced (a framework prompt? a checklist? a workflow?). It is also a near-restatement of the title '系统评价辅助', leaving the agent to infer that this is a generic guidance/scaffold 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?
The phrase '用户要做系统评价/Meta 的文献筛选与提取' implies the trigger condition: invoke this when the user needs systematic-review screening and extraction. That is a usable implied when-to-use signal, but there are no exclusions and no named alternatives, despite close siblings such as act_lit_digest, literature_search_pmc, prisma_flowchart, act_pdf_pico, and meta-analysis helpers like forest_plot or egger_bias_test 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.
生成流程图（Mermaid） 用户要画流程图/时序图/思维导图（Mermaid） Mermaid 代码
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | 图的内容描述 | |
| diagram_type | No | 图类型：flowchart/sequence/mindmap |
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 trailing 'Mermaid 代码' fragment implies the return is Mermaid source text, which is genuinely useful since no output schema exists, but nothing is said about diagram size limits, error behavior, or whether the code is validated.
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 very short with no filler, but the three space-separated fragments lack connective structure and read as incomplete phrases rather than sentences. Brevity here comes at the cost of clarity rather than from tight writing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a code-generating tool with no output schema, the description should clarify what the returned Mermaid code looks like and how prompt quality affects it. Neither is addressed, so an agent must guess at output shape and any constraints on the generated diagram.
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 'prompt' and 'diagram_type' are already documented in the schema, including the flowchart/sequence/mindmap options. The description merely echoes those diagram types and adds no format, length, or syntax guidance 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 concrete verb+resource (生成流程图/Mermaid), and the fragments add that flowcharts, sequence diagrams and mindmaps are covered. However, the phrasing largely restates the title and reads as disconnected keywords rather than a coherent statement of what the tool produces, and it never distinguishes itself from the many other diagram/flowchart siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The clause '用户要画流程图/时序图/思维导图' implies the use case (when a user wants a diagram), which is useful context. No exclusions or alternatives are given — notably the specialized flowchart siblings (consort_flowchart, prisma_flowchart) are not mentioned, leaving the agent to infer when this generic generator is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
国自然申报分析 用户问国自然/省自然能不能报、报什么口子、命中率 国自然分析
| Name | Required | Description | Default |
|---|---|---|---|
| disease | Yes | 疾病/研究方向 |
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 nothing beyond that: it never says what the analysis produces, how deep it goes, or what data it relies on — it largely restates the title and the trigger keywords.
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 short and front-loads the tool name and trigger phrases, but the opening and closing fragments (国自然申报分析 … 国自然分析) are redundant keyword repetition rather than additional information. The phrasing is telegraphic and reads more like a search keyword list than a sentence.
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 one-parameter, read-only analysis tool with no output schema, the description does enough to let an agent pick it, but it is silent on what the analysis returns (a report? a score? recommendations?) and on the depth of the assessment. An agent knows when to call it, not what to expect back.
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 meaning. The description never mentions the disease/research-direction input or its expected format, so it adds no semantics over the structured field — 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 resource and scope (国自然申报分析) and enumerates the three concrete questions it answers: eligibility (能不能报), target category (报什么口子), and hit rate (命中率). It does not, however, distinguish itself from plausible siblings like act_proposal_review or act_predict_success, which an agent would need in order to route correctly.
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 explicit trigger condition — the user asks whether a national or provincial natural science foundation grant can be applied for, which category to pick, or the success rate. There is no when-not guidance and no named alternative, so the routing is stated but not exclusive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
论文预审（六智能体） 用户投稿前想先被审一遍、找会被拒的理由 审稿意见与评分
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | 标题 | |
| methods | No | 方法 | |
| results | No | 结果 | |
| abstract | No | 摘要 |
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 elsewhere. The description does add that six agents are involved and that the output is review comments and a score, but says nothing about depth, turnaround, or what happens when optional sections are 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?
It is short, but the structure is telegraphic: the title is restated verbatim, then three comma-separated fragments with no clear topic-to-detail flow. Nothing is wasted in length, but the front-loading is weak.
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 four-parameter, read-only tool with no output schema, the description conveys the input gist and the return content (comments and score). It falls short on sibling differentiation and on how partial inputs (only title required) 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 coverage is 100%, with all four fields (title, methods, results, abstract) documented in the schema itself, so the baseline is 3. The description adds no meaning about how much text each field should contain or how missing sections affect the review.
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 action (a pre-submission review of a paper by six agents) and states the intended outcome (review comments plus a score), which an agent can map to a concrete task. It does not, however, distinguish this from closely-named siblings such as act_pre_review, act_deep_review, or act_proposal_review.
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 about wanting to be reviewed before submission and find rejection reasons implies the usage scenario reasonably well. There is no guidance on when to prefer this over the many adjacent review tools, no prerequisites, and no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
本地文献对比 用户要给一个主题、做站内文献横向对比 对比表
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | 主题 | |
| keywords | No | 关键词 |
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's only additional disclosure is that the output is a comparison table. It says nothing about which local corpus is read, whether it needs preloaded PDFs, or how many documents it will consider — leaving the big unknown ("local" = what?) unexplained.
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 short and front-loaded, with no filler — but the fragments are choppy ("对比表" hangs as a bare noun phrase) and the same brevity is what leaves the sibling ambiguity unresolved. Brevity here is under-specification rather than tight writing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 params, no output schema, read-only), which lowers the bar, but the single most decision-relevant fact — what makes this "local" and how it differs from act_literature_compare — is absent. An agent can call it, but cannot confidently choose it over its closest sibling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both parameters are described ("主题", "关键词"), so the baseline is 3. The description restates the required topic but adds no meaning about how topic and keywords combine, whether keywords narrow the local corpus, or whether topic is a free-text query or a label.
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 verb (+comparison) and a resource (local literature), and "对比表" signals the output artefact. But "本地" is never defined (local PDF library? uploaded files? cached store?), and the definition gives no way to tell this apart from the near-identical sibling "act_literature_compare" — only the word "本地" distinguishes them and its meaning is left to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"用户要给一个主题" implies the entry condition (a topic is supplied) and matches the required parameter, but no guidance is given on when to prefer this over "act_literature_compare" or "act_lit_digest". No exclusions, no prerequisites, no note that this reads local material rather than searching PMC/PubMed like the sibling search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
从文本抽取 PICO 用户贴了一段文献摘要要抽出 PICO 结构化 PICO
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | 文献文本 |
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 needs no repetition. The description adds almost nothing beyond that: with no output schema, it should say what the returned structured PICO looks like (field names, language of output, behavior on text lacking PICO elements, input length limits), but only the vague word '结构化' is offered.
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 sentence is a run-on with no punctuation that repeats the same idea three times. Redundant restatement of 'PICO' wastes space without adding information, and the intended usage cue is buried mid-string rather than 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?
The tool itself is simple (one text input, read-only), but as an extraction tool with no output schema, an agent needs to know what the response contains to chain it into downstream steps (e.g., pico_refine or a systematic-review flow). That is missing, along with any note on handling text without PICO components.
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 mentions '文献摘要' (abstract), which slightly narrows what text is expected, but adds no format or length guidance. Baseline 3 applies 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 verb+resource (抽取 PICO / extract PICO) is identifiable, but the description is essentially the title restated three times ('抽取 PICO ... 抽出 PICO 结构化 PICO'). It does not distinguish this tool from siblings like pico_refine or act_design_pico_refine, which also deal with PICO.
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 scenario: the user has pasted a literature abstract and wants PICO extracted. There is no explicit exclusion or mention of when to use pico_refine (refinement of existing PICO) instead, so routing between PICO-related siblings 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.
文献综述提纲 用户要基于精读文献生成综述提纲 综述提纲
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations supply readOnlyHint=true and destructiveHint=false, so safety is already covered, and the description does add the notion that it works from deeply-read literature. Beyond that, it says nothing about what the outline looks like, how long it is, whether it is returned as text or a structured tree, or what happens when no read literature exists.
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 wastes words: 文献综述提纲, 综述提纲, and the restatement inside the user clause all repeat the same noun. What remains after removing the repetition is one short clause, so the description is under-specified rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a cheap-looking but conceptually complex generation tool: it produces a whole review outline. With no parameters, no output schema, and a closed-world annotation, the description should explain at least the expected output form and the prerequisite that PDFs must have been read. Instead it repeats the title.
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 description cannot add meaning beyond an empty schema, and the baseline of 4 applies. The single useful detail, that input is implicitly 精读文献, is not a parameter 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 contains one informative clause, 基于精读文献生成综述提纲, which identifies the verb (生成), the resource (综述提纲), and a key input constraint (精读文献). However, the title 文献综述提纲 and the trailing 综述提纲 restate the same noun three times, and the description never distinguishes this tool from siblings such as act_lit_systematic_review, act_topic_lit_review, or act_writing_outline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no signal for when an agent should choose this tool, nor when it should not. The only hint is the phrase 基于精读文献, which implies literature must already be read, but this is not stated as an explicit prerequisite. There is no mention of the many outline and review siblings, so the agent must guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
中英文润色 用户要把写好的段落润色、改学术英语、去中式表达 润色后文本
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | zh 或 en | |
| level | No | 润色力度：light/medium/heavy | |
| content | Yes | 待润色文本 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a local, non-destructive, read-only transformation (openWorldHint=false), so the safety profile is covered. The description adds that it returns '润色后文本', which matters because no output schema exists, but it says nothing about how light/medium/heavy differ, whether meaning or citations are preserved, or what the returned text looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is short, front-loaded with the purpose, and free of filler. The three telegraphic fragments read like a keyword list rather than prose, which keeps it compact but makes the boundary between intent and output slightly ambiguous.
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 text transformation with annotations and no output schema, the definition covers what the tool does and roughly what it returns. It stops short on the level parameter's behavior and on output characteristics, which an agent would need to set expectations for a polish request.
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 explains lang, level, and content; the baseline of 3 applies. The description's mention of '中英文' and '润色' loosely maps to those parameters but contributes no format, default, or behavioral detail beyond what is already structured.
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 beyond the title: '润色' applied to '写好的段落', with two concrete refinements ('改学术英语', '去中式表达') that tell an agent exactly what transformation is performed. It does not, however, distinguish itself from nearby writing siblings such as act_write_chapter or act_revision_track.
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: text already exists and needs refinement rather than generation. There is no explicit when-not guidance, no mention of alternatives, and no prerequisite or input-size constraints, so routing must be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
录用概率预测 用户问这篇稿子投某刊中稿概率有多大 中稿概率与依据
| Name | Required | Description | Default |
|---|---|---|---|
| paper | No | 论文信息 | |
| journal_id | No | 期刊 id |
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 fully covered structurally. The description adds only that output includes a probability plus supporting rationale ('中稿概率与依据'), which is modest but genuine context beyond the annotations; it says nothing about data sources, model basis, confidence, or required input completeness.
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 fragments with no wasted prose, and the topic is front-loaded via the repeated title. The repetition of the title plus a raw sample utterance reads more like an under-specified trigger note than a structured definition, so brevity here does not translate into 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 read-only prediction tool with an opaque nested 'paper' object and no output schema, the description should explain what the prediction is derived from and what the returned evidence covers. It only gestures at '中稿概率与依据', leaving an agent to guess the required input richness and the basis of the estimate.
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 carry descriptions and the baseline is 3. The descriptions are minimal ('论文信息', '期刊 id'), and since 'paper' is a nested object with no defined internal properties, the description does nothing to clarify what paper fields are expected — but per the schema-coverage baseline this remains adequate rather than deficient.
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 an action (predict) and an outcome (acceptance probability) for a manuscript submitted to a specific journal, so the core purpose is inferable. However, it largely restates the title '录用概率预测' and then quotes a sample user question rather than defining the operation, and it never distinguishes itself from nearby siblings such as journal_recommend or act_paper_review.
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 '用户问这篇稿子投某刊中稿概率有多大' effectively gives a trigger condition: use this when the user asks how likely a manuscript is to be accepted by a given journal. There is no guidance on when not to use it, what prerequisites exist, or which sibling to prefer for overlapping needs (journal selection versus review simulation).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
投稿前预审 用户投稿前要先被审一遍、找会被拒的点 预审意见
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | 标题 | |
| design | No | 研究设计 | |
| abstract | No | 摘要 | |
| sample_size | No | 样本量 |
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 that the output is 预审意见 (pre-review comments) aimed at rejection risk, which is modest but real context; it says nothing about depth, journal-specific standards, or how many issues are checked.
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 short with no filler, but the structure is a series of comma-free fragments that open by restating the title. The informative part (找会被拒的点 / 预审意见) arrives quickly, so it is front-loaded and economical despite the rough phrasing.
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 read-only tool with no output schema, the definition covers what goes in but not what comes back beyond the label '预审意见'. It never states the aspects evaluated (novelty, design, statistics, sample size) or the output shape, which an agent would want when presenting results to a user.
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 four clearly labelled fields (title, design, abstract, sample_size), so the schema carries the parameter burden. The description adds no meaning beyond that, not even indicating which fields drive the rejection analysis. 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 repeats the title verbatim (投稿前预审) then adds the actual function: reviewing a manuscript before submission to find rejection risks and produce pre-review comments. That is an understandable verb-plus-resource, but it is written as a keyword fragment rather than a stated purpose, and it never distinguishes itself from the many review-oriented siblings such as act_paper_review or act_deep_review.
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?
'用户投稿前要先被审一遍' implies a timing condition (before submission), but there is no explicit when-to-use versus when-not, and no mention of the obvious alternatives in the sibling list (act_paper_review, act_deep_review, act_proposal_review, act_decision_arbitration). An agent has to guess which review tool to pick.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
标书评审 用户贴了标书/方案正文要打分、找问题、提修改意见 五维评分与修改建议
| Name | Required | Description | Default |
|---|---|---|---|
| proposal_text | Yes | 标书正文全文（平台要求 ≥100 字） |
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 useful behavioral context about what comes back (five-dimension scoring plus revision suggestions), but says nothing about score scale, depth, or how strict the critique is.
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, front-loaded fragments with no filler, and the user-intent clause precedes the output clause. It loses a point for restating the title (标书评审) at the start and for keyword-style phrasing rather than a complete sentence.
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 definition is close to sufficient, but it leaves the '五维评分' unspecified — the five dimensions are never named, and no indication is given of output shape or length. An agent can invoke it, but cannot predict what it receives.
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 one parameter at 100% schema description coverage, the schema already explains that proposal_text is the full body and must meet the platform's ≥100-character minimum. The description adds no format or length guidance beyond that, 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 resource (标书/方案正文) and concrete actions (打分、找问题、提修改意见、五维评分), so an agent knows this is a scoring/critique tool rather than a generator. It does not, however, distinguish itself from near-siblings such as act_paper_review, act_pre_review, or act_deep_review, which also review text.
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 is implied clearly: use it when the user pastes proposal/plan body text and wants scoring, problem-finding, or revision advice. There is no explicit when-not guidance and no routing to the review-oriented siblings, so the agent must still infer which review tool applies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
结果段落生成 用户有统计结果，要自动写成结果段落 结果段落
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | zh 或 en | |
| model_type | No | 模型类型 | |
| design_type | Yes | 研究设计 |
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 discloses nothing: not the output form (a paragraph of text), not how lang/model_type/design_type influence the generated prose, and not whether it reads statistics from prior session state.
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 short, but the shortness comes from under-specification and redundancy: "结果段落" is repeated as a dangling fragment at the end, and the middle clause merely paraphrases the title. Nothing is front-loaded beyond the title fragment.
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 and only three configuration parameters, the description needed to explain the input contract — where the statistical results come from and what the returned paragraph looks like. Neither is addressed, so an agent cannot tell how to actually supply the statistics this tool is supposed to write up.
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 itself documents lang (zh/en), model_type and design_type, which sets the baseline at 3. The description adds no meaning beyond that — notably it never explains that design_type (研究设计) steers the reporting structure or that the actual statistical values are not passed as 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 restates the title ("结果段落生成") but does add a use-case clause: the user has statistical results and wants them written into a results paragraph. That gives a rough verb+resource, but it never specifies where the statistics come from (no such parameter exists) or what kind of paragraph is produced, so it stays generic relative to siblings like act_write_chapter or figure_legend.
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 guidance is the implied trigger "用户有统计结果" — use it when you have stats and need prose. There is no explicit when-not, no prerequisite (e.g. stats must already be computed by stats_toolbox/table_one_baseline first), and no routing to or from the many sibling writing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
审稿意见回复追踪 用户有审稿意见要逐条回复 逐条回复草稿
| Name | Required | Description | Default |
|---|---|---|---|
| original_text | Yes | 原文 | |
| reviewer_comments | Yes | 审稿意见 |
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 and the description does not contradict it (generating a draft is consistent with a read-only tool). Beyond that, the description adds almost nothing: it does not say whether drafts are produced for every comment at once or one at a time, how long the drafts are, whether the original text is quoted back, or what the agent should do with the result.
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 very short and front-loads the domain, which is good, but it is written as three loose noun fragments rather than a coherent sentence, and '逐条回复' is repeated in back-to-back fragments. The brevity is under-specification rather than efficient conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter generative tool with no output schema, the description should at minimum explain the shape of the result (e.g., one reply per reviewer comment) and how it relates to the other review-related siblings. It does not, so an agent knows the topic area but not what to expect back or when this is the right choice among many similar review 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%, so both parameters (original_text and reviewer_comments) are already documented in the schema. The description restates those same two concepts in prose ('审稿意见' and the implicit original text) without adding format, length, or structuring guidance, 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 the resource (审稿意见回复 = reviewer-comment responses) and indicates that the tool produces a point-by-point reply draft (逐条回复草稿), so the agent can tell roughly what domain it is in. However, it uses noun fragments rather than a clear verb+resource statement and never states what it actually produces — a single draft, one draft per comment, or a tracking table. Siblings such as act_paper_review, act_pre_review and act_proposal_review are also in the reviewer-comment space, and nothing here distinguishes this tool from 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 an implied trigger condition: the user has reviewer comments that must be answered item by item. That is enough to suggest when the tool is appropriate, but there is no explicit when-not guidance, no mention of prerequisites, and no naming of alternative siblings so the agent cannot disambiguate against act_paper_review or act_pre_review.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
研究技术路线图 用户要技术路线图、流程图、标书里的研究路线 SVG 路线图
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | 研究题目 | |
| outcome | No | 结局指标 | |
| sample_size | No | 样本量 | |
| intervention | No | 干预措施 | |
| study_design | No | 研究设计 |
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 elsewhere. The description contributes the one genuinely new behavioral fact, that the result is an SVG diagram, but says nothing about generation cost, completeness of output, or whether missing optional inputs degrade the figure.
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 no filler sentences. The only waste is the opening phrase repeating the tool name and title, but the use-case triggers are front-loaded and immediately readable.
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 generator with five well-documented parameters and no output schema, the definition is minimally adequate. It could add more by explaining that optional clinical fields populate the roadmap stages, but nothing critical for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all five parameters individually documented (title, outcome, sample_size, intervention, study_design), so the schema carries the load. The description adds no meaning about how these fields feed the roadmap layout or which are optional, 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 the artifact ('研究技术路线图') and adds that it is an SVG roadmap, which is more than the title alone gives. But there is no verb and the first phrase merely repeats the tool name/title, and it never distinguishes itself from diagram-producing siblings such as consort_flowchart, prisma_flowchart, or act_material_mermaid.
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?
Three usage triggers are listed (user wants a technical roadmap, a flowchart, or a research route for a grant proposal), which implies when to call it. There are no exclusions and no named alternative for related flowchart requests, so the agent must infer the boundary itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
选题可行性评估 用户问这个题能不能做、要多少病例、做得完做不完 可行性评分与建议
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | 研究主题/题目 |
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 that the result includes a feasibility score and recommendations, which is meaningful output context, but says nothing about what evidence the judgement rests on, prerequisites, or limits. With annotations carrying safety, this is adequate but 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?
Very short and front-loaded with the tool's Chinese title, so nothing is padded. However it is written as unpunctuated space-separated fragments, which makes the trigger conditions and outputs run together and slightly harder to parse.
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-input read-only assessment tool with no output schema, the description conveys purpose, triggers, and the shape of the return (score + suggestions), which is close to sufficient. It omits the criteria the feasibility judgement uses and any constraints on the topic string, leaving an agent with gaps about what to expect back.
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 with 100% schema description coverage, so the schema fully documents 'topic' as the research topic/title. The description refers to the topic implicitly ('这个题') but adds no format expectations, length guidance, or examples. 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?
Names a specific verb+resource combination: feasibility assessment of a research topic, and expands it with concrete questions the tool answers (can it be done, how many cases needed, can it be finished) plus outputs (feasibility score and suggestions). An agent can tell this apart from pure generation tools like act_topic_generate, though it does not explicitly disambiguate against near-neighbours such as act_topic_novelty, act_predict_success or sample_size_calculator.
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?
Supplies clear triggering conditions in user-intent form ('用户问这个题能不能做、要多少病例、做得完做不完'), which maps directly onto when to select this tool. There are no explicit exclusions or named alternatives, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
研究空白分析 用户问这个领域还有什么没做的、哪里有空白、从哪切入 研究空白清单
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | 研究领域 | |
| population | No | 目标人群 |
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 contributes one useful behavioral fact — the deliverable is a "研究空白清单" (a list of gaps) — but says nothing about depth, evidence basis, or limits of the analysis.
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 with no filler and the purpose front-loaded. The trade-off is that it is written as unpunctuated fragments, and the opening phrase merely restates the title, which makes it slightly harder to parse than a single clean sentence.
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 analysis tool with no output schema, stating that it returns a gap list is the minimum needed, and that is present. What the list contains, and how it differs from a novelty or feasibility assessment, is 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 topic and population are already documented in the schema. The description adds nothing about how topic scope or population choice affects the gap analysis, 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?
"研究空白分析" names a specific analytical resource, and the following clause ("这个领域还有什么没做的、哪里有空白、从哪切入") sharpens what kind of analysis it is. It does not, however, distinguish itself from close siblings such as act_topic_novelty or act_topic_feasibility, 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 phrase "用户问这个领域还有什么没做的" gives an explicit trigger condition — use it when the user asks what remains unexplored. There are no exclusions or named alternatives, so the agent gets clear context but no routing guidance against novelty/feasibility siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
AI 生成研究选题 用户想找选题、不知道做什么方向、给一个科室/疾病要几个可做的题目 若干候选选题
| Name | Required | Description | Default |
|---|---|---|---|
| keywords | No | 关键词 | |
| specialty | No | 亚专业方向 | |
| discipline | Yes | 学科/科室，如 心血管内科、重症医学 | |
| research_type | No | 研究类型：临床研究/基础研究/转化研究 |
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. With no output schema, the description's '若干候选选题' is the only signal about return content, and it doesn't say how many topics, whether they cite literature, or whether the model is constrained to the given discipline.
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 short, which is good, but it reads as a run-on concatenation of fragments with no punctuation or sentence boundaries, so purpose and usage blur together. Space is not wasted on repetition, but the lack of structure makes it harder to parse than a single well-formed sentence would be.
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-shot generation tool with no output schema, the description should convey what comes back and how constrained it is; '若干候选选题' covers the shape only superficially. It's adequate to attempt a call but leaves meaningful gaps about output quality, quantity, and grounding.
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 every parameter (discipline, specialty, keywords, research_type) is documented in the schema itself. The description only echoes the discipline idea via '给一个科室/疾病' and adds no meaning about how keywords or research_type shape the generated topics.
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 phrase 'AI 生成研究选题' names a verb and resource (generate research topics), and '若干候选选题' hints at the output. But it merely restates the title, and among the many topic siblings (act_topic_novelty, act_topic_feasibility, act_topic_gaps, act_idea_ignite, act_topic_research_plan) nothing distinguishes this tool from 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?
'用户想找选题、不知道做什么方向、给一个科室/疾病要几个可做的题目' does give a recognizable trigger scenario for the agent. However, it never says when NOT to use it or which sibling to prefer for feasibility, novelty, gap analysis, or a full research plan.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
选题文献综述 用户要就一个题目做文献综述、研究现状梳理 综述文本
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | 研究主题 | |
| question | No | 研究问题 | |
| population | No | 人群 | |
| intervention | No | 干预 |
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 only the trailing fragment '综述文本', hinting at a text output, but says nothing about depth, length, whether it draws on real retrieved literature versus generating a draft, or what the four PICO-style inputs actually change in the result. Given openWorldHint=false, whether external search occurs is exactly the question an agent would need answered, and it is not.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is short with no filler, but it is a run of three unpunctuated fragments rather than a structured statement, and the most useful information (output is a review text) is buried at the end. Brevity here comes from under-specification rather than disciplined editing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a four-parameter tool with no output schema, the description should at minimum say what the returned review covers and how it differs from sibling review tools. Neither is present, leaving an agent to guess at scope and at the choice among many adjacent literature 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%, so topic, question, population, and intervention are each documented in the schema. The description adds no meaning beyond those labels and never explains how the optional PICO fields alter the review. 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 the resource (文献综述) and the trigger condition (用户要就一个题目做文献综述、研究现状梳理), so the general purpose is graspable. However, it never distinguishes this from close siblings such as act_lit_systematic_review, act_lit_digest, act_literature_compare, or act_topic_gaps, all of which sound like literature-review work. An agent cannot tell from the text alone which one 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 phrase '用户要就一个题目做文献综述' implies a usage context but states no explicit when-to-use rule, no when-not-to-use rule, and no alternative tool. With a dozen literature-related siblings in the list, the absence of any routing guidance is a real gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
选题新颖性检索 用户问这个题目有没有人做过、新不新、会不会重复 新颖性评估与相似研究
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | 研究主题/题目 |
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 and the description only needs to add context. It contributes that output involves a novelty verdict plus similar studies, but says nothing about the searched corpus, coverage, or confidence limits of the assessment.
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 short and front-loads the trigger, which is good, but the leading phrase repeats the tool title verbatim and the rest is a run of unpunctuated keyword fragments rather than a structured sentence. Nothing is padded, yet the phrasing is dense enough to slow parsing.
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, single-parameter tool with no output schema, the description should at least indicate the kind of result returned (e.g., a novelty score, a list of similar papers). It only alludes to '新颖性评估与相似研究' without describing the shape of the response or the basis of the judgement, leaving a real gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single parameter with 100% schema description coverage ('研究主题/题目'), so the schema already does the work. The description adds no guidance on whether the topic should be a full title, a keyword string, or how specificity affects results, so it does not exceed the 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 pairs a specific action (检索/retrieval) with a specific resource (选题新颖性) and clarifies it covers novelty assessment plus similar-study discovery. It is clearly distinguishable from neighbours such as act_topic_gaps or act_topic_feasibility by intent, though it never names a sibling 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 triggering condition: use when the user asks whether a topic has been done before, whether it is new, or whether it would duplicate existing work. That is real when-to-use guidance, but there are no exclusions or pointers to the alternative topic tools (act_topic_gaps, act_topic_lit_review), so an agent must still infer boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
选题汇报 PPT 用户要把选题做成 PPT、汇报材料 PPT 内容
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | 研究主题 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as a non-destructive, read-only, closed-world operation, so the safety profile is covered. The description adds nothing beyond that: it does not say what artifact is generated (file? markdown? slides?), how long it is, whether it needs external sources, or what the user receives back. For a generation tool with no output schema, that is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is short, but not because it is efficient: the wording is fragmented, repeats 'PPT' three times, and lacks a front-loaded verb or clear sentence structure. Length is fine, but the text does not earn its place as a well-formed instruction.
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 content-generation tool with no output schema, one required parameter, and read-only annotations. An agent needs to know what output format, structure, or sections to expect and how the topic drives the deck; the description supplies none of that, so it is incomplete for the tool's complexity.
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?
Annotations and schema already exist (readOnlyHint=true, destructiveHint=false, openWorldHint=false) and the single parameter 'topic' has 100% schema description coverage ('研究主题'). The description adds no further meaning about the topic parameter, so the schema carries the burden; 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 text "选题汇报 PPT 用户要把选题做成 PPT、汇报材料 PPT 内容" mostly restates the tool name and title (选题汇报 PPT) and trails off into a fragment ('PPT 内容'). An agent can vaguely infer it produces a presentation deck from a research topic, but the phrasing is not a clean verb+resource statement and never says what kind of deck or what it contains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is a hint of usage context ('用户要把选题做成 PPT'), which is marginally better than nothing, but there is no when-to-use vs when-not guidance and no mention of any alternative among the many sibling tools such as act_writing_outline, act_writing_one_click, act_design_generate, or the act_topic_* family. The agent is left to guess how this differs from other writing/design generators.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
选题显示度分析 用户想知道某个研究方向热不热、有没有影响力 显示度指标
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | 研究主题 |
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 only that the output is prominence metrics ("显示度指标"), and says nothing about the data source, computation, or result structure. Given the lower bar set by annotations, this is adequate but 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?
Very short with no filler, but it is written as space-separated fragments with no verbs or punctuation, so it reads as a keyword dump rather than a structured statement. Front-loading the tool's purpose is fine, but the lack of sentence structure costs 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?
This is a computation tool with no output schema, so the description carries the burden of explaining what the agent will receive. It only hints at "prominence metrics" and never states the metric dimensions or return shape, leaving a real gap for correct downstream use.
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 whose schema description coverage is 100%, so the schema fully documents it. The description adds no format, scope, or granularity guidance for the topic string (e.g., keyword vs. phrase), 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 names a specific resource and analysis type (
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 "用户想知道某个研究方向热不热、有没有影响力" provides an implicit trigger condition tied to a user's question about topic heat/impact. However, there is no statement of when NOT to use it and no routing to the many other act_topic_* siblings (novelty, gaps, feasibility), leaving the agent to infer boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
生成研究计划 用户有了题目要一份研究计划/技术路线/研究方案框架 研究计划文本
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | 研究主题 | |
| design | No | 研究设计类型 |
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 elsewhere. The description adds only a trailing hint that the output is plan text ("研究计划文本") and discloses nothing about plan structure, length, determinism, or whether "design" changes the output shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is short and front-loads the action, but it reads as keyword fragments rather than a coherent sentence, and "研究计划" is repeated three times with a dangling final fragment that contributes little.
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 generation tool with no output schema, so the description is the only place to describe what the produced plan contains and how "design" shapes it. Neither is addressed, leaving a real gap for an agent that must decide whether to call this or a sibling planning 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 parameters are documented in the schema itself. The description adds no extra meaning for "topic" or for the optional "design" (research design type), 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 states the verb+resource ("生成研究计划" – generate a research plan) and broadens it with alternate phrasings ("技术路线/研究方案框架"), so the deliverable is identifiable. However, it largely restates the tool name and title rather than distinguishing it from close siblings such as act_roadmap, act_writing_outline, or act_experiment_plan.
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 trigger condition – the user already has a topic and needs a research plan – which is enough to imply when to call it. It names no alternatives and no exclusions, so an agent facing act_roadmap or act_design_generate 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.
顶刊挖掘 用户问某个领域顶刊在发什么、怎么对标顶刊选题 目标期刊与选题倾向
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | 研究主题 |
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 partial output hint ('目标期刊与选题倾向' – target journals and topic tendency), but says nothing about the data source behind the mining (local corpus vs live search), coverage, or depth, which matters given openWorldHint=false.
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 short, but it reads as space-separated keyword fragments rather than a front-loaded sentence, and the title is repeated verbatim at the start. Nothing is wasted, but the structure is loose enough that the intent takes a pass to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, read-only, no output schema), so the description is close to sufficient. It is still thin on the two things an agent would want for this kind of analysis: where the top-journal data comes from and what form the 'topic tendency' result takes.
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 ('研究主题' – research topic), so the schema already carries the meaning. The description does not clarify the granularity expected (a field, a keyword set, or a full topic statement), so it adds nothing 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 pairs a specific verb (挖掘, mining) with a specific resource (顶刊, top journals) and elaborates with 'what top journals in a field are publishing' and 'how to benchmark topic selection against top journals'. An agent can tell this is a trend-analysis tool rather than a literature search. It does not, however, name or contrast itself with neighbours like journal_recommend or act_topic_prominence.
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 scenario (the user asks what a field's top journals publish or how to align a topic with them). There are no explicit exclusions and no alternatives are named, so the routing has to be inferred from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
写单个章节 用户只要写某一段/某一章（摘要、方法、讨论、引言） 该章节正文
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | 论文题目 | |
| design | No | 研究设计 | |
| section | No | 章节：abstract/methods/discussion/intro | |
| population | No | 研究对象 | |
| main_outcome | No | 主要结局 |
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 clear without the description. The description adds one useful behavior fact — that the output is the section body text ('该章节正文') — but says nothing about length, formatting, or how the section-specific content is derived. The word '写' (write) is loose language for text generation rather than a persistence claim, so it does not clearly contradict readOnlyHint, but it is ambiguous enough to be worth noting.
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 short, but it is a run-on fragment with no punctuation or sentence structure, and the leading phrase is pure repetition of the title. The most valuable part (the section list and the 'only one section' condition) is not 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?
For a 5-parameter tool with no output schema, the description should explain the role of the four optional inputs (design, population, main_outcome, section) and what the returned body looks like. It offers only a one-line return note and no guidance on how to fill the optional context fields, leaving an agent to guess how to get a usable section.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter including the section enum is already documented in the schema. The description's mention of 摘要/方法/讨论/引言 duplicates the section enumeration already present in the schema and adds no meaning about design, population, or main_outcome, or about whether those optional fields are needed for good output.
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 verb and resource (write a single section) and enumerates the covered sections (abstract/methods/discussion/intro), which helps. However, the opening phrase '写单个章节' merely restates the tool title verbatim, and nothing distinguishes this from close siblings like act_writing_one_click, act_writing_outline, or act_results_paragraph.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'用户只要写某一段/某一章' gives an implied when-to-use condition: the user wants only one section, not a full manuscript. There is no statement of when NOT to use it and no named alternative for the full-paper case, so routing to siblings 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.
一键生成论文初稿（主线） 用户要写论文、写整篇、一键出初稿、生成正文 初稿任务（后台逐章生成）
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | 论文题目 | |
| category | No | 论文类型/分类 | |
| project_id | No | 项目 id。只有「你只有 1 个项目」时才自动使用；有多个项目时平台返回候选清单，须按标题/研究设计匹配后重试，或先问用户写进哪个课题 | |
| template_id | No | 模板 id |
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 one genuine addition is "初稿任务（后台逐章生成）", which discloses that generation runs as a background, chapter-by-chapter task, meaning the call returns a task rather than finished text. That is valuable, but there is mild tension with readOnlyHint=true since the tool produces a new draft artifact, and no note on duration, partial-failure behavior, or how to retrieve results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is a series of unstuctured trigger keywords with heavy repetition: title restated, then "写论文", "写整篇", "一键出初稿", "生成正文" all say nearly the same thing. The only non-redundant detail, background chapter-by-chapter generation, is buried in trailing parentheses. It is short but not front-loaded or organized.
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 that starts a whole-paper generation job, the description omits how the job is tracked, expected duration, and what happens when category or template is not supplied. The project_id ambiguity handling is covered only by the schema. No output schema exists, so a brief note on what is returned would have been worth the space.
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 explains title, category, project_id (including the multi-project retry rule) and template_id. The description adds no parameter guidance of its own, 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 phrase "一键生成论文初稿" names a specific verb and resource, and "写整篇" plus "后台逐章生成" hints at how this differs from chapter-level writing tools. However, the rest is a keyword list ("写论文、写整篇、一键出初稿、生成正文") that largely restates the title, and no sibling such as act_write_chapter or act_writing_outline is named. An agent can guess the purpose but 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 implicit trigger conditions, which is better than nothing. There is no explicit when-not guidance and no named alternative for the partial-chapter or outline-only cases. The agent must infer that this is the entry point for whole-paper drafting rather than being told so.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
生成论文提纲 用户先要提纲/目录/章节结构，再写正文 章节提纲
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | 论文题目 | |
| project_id | No | 项目 id | |
| design_type | No | 研究设计类型 |
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 fully covered by structured data. The description adds only workflow positioning and says nothing about what the generated outline looks like, how many sections it returns, or how project_id or design_type change the output — minimal value beyond 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?
It is short, but the text is a run of unpunctuated fragments ('生成论文提纲 用户先要提纲/目录/章节结构，再写正文 章节提纲') with a redundant trailing '章节提纲'. It is front-loaded with the core purpose, yet the fragmentary phrasing costs clarity for no compensating gain.
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 generation tool with no output schema, the description should explain what an outline contains and how the optional parameters affect it. Instead it repeats outline synonyms, leaving the agent to infer output shape and the role of project_id and design_type.
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 three parameters (title, project_id, design_type) are already documented in the schema. The description adds no additional meaning about how project_id scopes the request or how design_type influences the outline structure, 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 conveys that it produces a paper outline (提纲/目录/章节结构), which is a specific resource, but it largely restates the name and title rather than stating a distinct verb+scope. It does not differentiate this tool from close siblings such as act_writing_one_click or act_write_chapter, which also produce written structure for a paper.
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 sequencing: use this before drafting body text. That is implied usage guidance rather than an explicit when-to-use/when-not-to-use statement, and no alternative tool is named for cases where a full draft is wanted instead of an outline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Animal dose & injection volume / 动物给药量计算 | USE WHEN: compute the dose (mg) and injection volume (mL) for an animal from body weight and mg/kg | ALIASES: 动物给药量, 给药体积, 按体重给药, dose volume, mg/kg, 注射体积, 灌胃体积 | RETURNS: 给药量与体积
| Name | Required | Description | Default |
|---|---|---|---|
| dose_mg_per_kg | Yes | 剂量(mg/kg) | |
| animal_weight_g | Yes | 动物体重(g) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds a 'RETURNS' line naming the outputs, which is useful given there is no output schema, but it omits the fact that an injection volume cannot be derived from weight and mg/kg alone without a concentration — a behaviorally significant omission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single pipe-delimited line is compact and front-loads the title and use case. The bilingual ALIASES block is largely keyword padding that consumes space without helping an agent decide or call correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter pure calculation with full schema coverage and annotations, the definition is close to sufficient, and the RETURNS line compensates for the missing output schema. The unresolved question of how volume is computed without a concentration input leaves a real gap in understanding the tool's actual behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both parameters carry units (g, mg/kg), so the baseline is 3. The description names the same two inputs but adds no meaning beyond the schema — notably it does not explain how injection volume is produced when no dose concentration parameter exists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource (compute dose in mg and injection volume in mL) plus the exact inputs (body weight, mg/kg), so an agent can tell it apart from generic stats or writing tools. However, it never differentiates from close siblings such as species_dose_convert or renal_dose_adjust, which handle adjacent dosing math.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'USE WHEN' clause gives a triggering condition, but it essentially restates the purpose (compute dose from weight and mg/kg) rather than contrasting with alternatives. There is no guidance on when NOT to use it or when species_dose_convert / renal_dose_adjust would be the correct pick.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Animal randomization / 动物随机分组 | USE WHEN: randomly assign animals to groups as required by ARRIVE | ALIASES: 动物随机分组, animal randomization, 分组表, 动物分组 | RETURNS: 分组表
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | 种子 | |
| groups | No | 分组名 | |
| method | No | 随机化方法 | |
| n_total | Yes | 动物总数 |
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 fully covered by structured data. The description only adds that a group allocation table is returned ('RETURNS: 分组表'). It does not disclose whether the seed makes the allocation reproducible, what happens when seed is omitted, or what the default randomization method is — all material behavior for a randomization 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 pipe-delimited metadata block is compact and front-loads the trigger condition and aliases, which aids discovery across Chinese and English phrasings. The only waste is the opening segment repeating the tool name and title verbatim before reaching the useful 'USE WHEN' clause.
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, single-purpose computation tool with 4 flat parameters, full schema coverage, and trusted read-only annotations, the definition covers purpose, trigger, aliases, and return artifact. The gaps — seed determinism and default method behavior — are behavioral niceties rather than blockers to a correct 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 the baseline is 3 and the schema does the documenting work. The description adds no meaning about n_total, groups, method, or seed — notably nothing about seed reproducibility or the default method — so it neither compensates nor detracts.
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: 'randomly assign animals to groups,' qualified by 'as required by ARRIVE.' An agent can tell what the tool produces ('分组表', a group allocation table). It stops short of a 5 because it never distinguishes itself from the sibling randomization_allocate, which plausibly performs a similar allocation task.
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 'USE WHEN: randomly assign animals to groups as required by ARRIVE' clause gives a concrete trigger condition tied to a known reporting standard. There are no explicit exclusions and no mention of when to prefer randomization_allocate or animal_sample_size instead, 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.
Animal sample size (3R) / 动物实验样本量 | USE WHEN: how many animals per group are needed (power-based, ARRIVE/3R wording) | ALIASES: 动物样本量, 动物要多少只, 每组几只, animal sample size, 3R, power animals | RETURNS: 每组动物数
| Name | Required | Description | Default |
|---|---|---|---|
| alpha | No | α | |
| power | No | 把握度 | |
| groups | No | 组数 | |
| effect_size | Yes | 效应量 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already state readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so safety is covered. The description adds "RETURNS: 每组动物数", which is useful because there is no output schema. However, it says nothing about which statistical test it assumes, the defaults applied for alpha, power, and groups, or whether the effect_size is Cohen's d.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded line with clearly labeled sections, and every clause serves selection or invocation. The alias list is long, but it is keyword-oriented and supports retrieval rather than prose 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 simple, read-only calculator with full schema coverage, the description is adequate. Still, because the tool is a power calculation and has no output schema, the description should disclose default alpha and power values and the underlying test assumption; these details are needed to call the tool correctly and 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 description coverage is 100%, so the schema already documents all four parameters (α, 把握度, 组数, 效应量). The description adds no clarification beyond that, not even stating that greater power or more groups increases the required sample size, or that effect_size is the single required input. Baseline 3 applies when the schema carries the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource and outcome: computing the number of animals per group from a power calculation, framed in ARRIVE/3R terms. It distinguishes this tool from general statistics tools by explicitly stating that it is for animal experiments, although it does not directly name the sibling sample_size_calculator or explain how it differs from that 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?
The "USE WHEN: how many animals per group are needed (power-based, ARRIVE/3R wording)" clause gives a clear trigger, and the alias list resolves ambiguous user phrasings such as 每组几只 and 动物要多少只. It provides no when-not guidance and no explicit alternative such as sample_size_calculator.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Animal survival analysis / 动物生存分析 | USE WHEN: Kaplan-Meier and log-rank on animal death/survival times | ALIASES: 动物生存分析, 生存曲线, log-rank, animal survival, KM, 死亡时间 | RETURNS: KM 曲线与 log-rank
| Name | Required | Description | Default |
|---|---|---|---|
| ctrl_times | Yes | 对照组时间 | |
| ctrl_events | Yes | 对照组事件 | |
| treat_times | Yes | 给药组时间 | |
| treat_events | Yes | 给药组事件 |
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 and the description only needs to add computational context. It does state the two analyses performed and the high-level return (KM curve + log-rank), but says nothing about what the log-rank output contains (p-value, chi-square, df) or whether the curve is a rendered plot versus numeric data.
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 pipe-delimited, front-loaded layout puts the when-to-use condition ahead of aliases, and nothing is redundant filler. The bilingual aliases add length but serve genuine tool-matching value; the only weak segment is the terse RETURNS field.
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 carry the return-value burden, and "RETURNS: KM 曲线与 log-rank" is too thin for a four-required-parameter statistical tool. An agent still cannot tell what shape the result takes or what assumptions (paired arrays, event coding) must hold before calling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is nominally 100%, so the baseline is 3, and the description adds no parameter meaning at all. This is a real gap for ctrl_events/treat_events, which are labelled only "对照组事件"/"给药组事件" and never explained as 0/1 censoring indicators that must align element-wise with the corresponding time arrays.
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 pair and resource: "Kaplan-Meier and log-rank on animal death/survival times", which is more precise than the bare name. It does not, however, distinguish itself from the closely related siblings kaplan_meier and survival_cox, so an agent must infer that this tool is the animal-experiment variant.
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 "USE WHEN" clause gives a clear triggering condition (animal death/survival times analysed with KM and log-rank). It never states when NOT to use it or points to kaplan_meier / survival_cox as alternatives, so the routing is helpful but not complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ARRIVE 2.0 checklist / ARRIVE 2.0 检查 | USE WHEN: check an animal experiment against the ARRIVE 2.0 reporting guideline | ALIASES: ARRIVE, 动物实验规范, 动物伦理报告, animal reporting, ARRIVE 2.0 | RETURNS: ARRIVE 条目核对
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 that it checks against the ARRIVE 2.0 guideline and vaguely returns 'ARRIVE 条目核对', but it does not explain the return format or what a checklist check actually produces.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The pipe-delimited structure is front-loaded with the tool name and USE WHEN clause, making it easy to scan. It repeats the title in the description and includes aliases, but the overall text remains compact and functional.
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 zero-parameter checklist tool, the definition is nearly complete: usage context, aliases, and a hint at the return content are present. The main gap is that the exact output or checklist behavior is not described, and the relation to reporting_checklist is not clarified.
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?
This is a zero-parameter tool, so there are no input semantics to clarify. The baseline for zero parameters is 4, and the description does not create any parameter ambiguity.
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 (ARRIVE 2.0 checklist) and action context (check an animal experiment against the ARRIVE 2.0 reporting guideline). It is clear what the tool is for, though it does not explicitly distinguish itself from the sibling reporting_checklist 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?
The USE WHEN clause gives clear context: use it to check an animal experiment against ARRIVE 2.0. It does not state when not to use it or name the generic reporting_checklist alternative, so it falls short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ATAC-seq differential accessibility / ATAC 差异可及性 | USE WHEN: differential open regions from ATAC-seq counts | ALIASES: ATAC, 差异可及性, 染色质开放, differential accessibility, peak差异 | RETURNS: 差异 peak
| Name | Required | Description | Default |
|---|---|---|---|
| data_json | Yes | 必填。数据对象（不是字符串）。矩阵形式：{"matrix": [[行1各列数值...], [行2...]], "rows": ["基因/特征名"], "cols": ["样本名"]}；组学结果另可带 {"groups": ["组A","组A","组B"...]}（与 cols 一一对应）、{"p_values": [...], "log2fc": [...]}（若已有差异结果）。实测缺此字段会被拒：Field required: data_json |
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 only 'RETURNS: 差异 peak' and says nothing about the statistical method, thresholds, replicate requirements, or failure modes. With annotations carrying the safety burden, a 3 is fair, but the behavioral value added is 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?
The pipe-delimited header is front-loaded with the purpose, then USE WHEN, ALIASES, and RETURNS, so scanning is easy and there is no filler prose. The bilingual duplication and a long alias list cost a little density but are defensible for retrieval matching.
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 a single, fully documented parameter and no output schema, so the description is the only place to explain return values — yet it gives just '差异 peak' with no indication of the output fields, thresholds, or how many peaks come back. Complete enough to trigger a call, but not enough to interpret the 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?
Schema description coverage is 100% and the data_json description is unusually detailed about matrix/rows/cols/groups/p_values/log2fc shape and the required-field behavior, so the schema does the heavy lifting. The tool description adds no meaning beyond the schema, which is the baseline 3 case.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific analysis (differential accessibility on ATAC-seq counts) rather than restating the tool name, so an agent knows this takes ATAC count data and produces differential peaks. It does not explicitly contrast with close siblings such as differential_expression or chip_peak_calling, so the distinction is inferable 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?
The 'USE WHEN: differential open regions from ATAC-seq counts' clause gives a concrete triggering condition, including the required input type (counts) and the goal (differential open regions). There are no exclusion conditions or named alternatives, so an agent must still infer when to pick differential_expression or chip_peak_calling instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bioequivalence (BE) / 生物等效性评价 | USE WHEN: compare test vs reference AUC/Cmax and judge 80-125% bioequivalence with 90% CI | ALIASES: 生物等效性, BE, AUC Cmax, 90%CI, 等效性判定, bioequivalence | RETURNS: 90%CI 与等效性判定
| Name | Required | Description | Default |
|---|---|---|---|
| test_auc_list | Yes | 受试制剂 AUC | |
| reference_auc_list | Yes | 参比制剂 AUC |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish that this is a safe, read-only, closed-world computation, so the description need not restate that. It does add useful methodological context (90% CI with the 80-125% acceptance rule) and says what the result contains. It does not disclose requirements or failure modes, such as a minimum sample size per group or how unequal-length lists 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?
The definition is short and front-loaded, with the WHEN condition placed before aliases. The bilingual duplication and the long alias list are boilerplate padding, but they cost little and do not bury the core statement.
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 is responsible for describing the return value; 'RETURNS: 90%CI 与等效性判定' does this only in outline and does not say whether point estimates, ratios, or power are also returned. For a computational tool taking two array inputs, the description is 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% for both parameters, so the baseline is 3; the description adds no extra meaning beyond 'test vs reference AUC'. Worse, it advertises a Cmax input that does not exist in the schema, which could lead an agent to look for a nonexistent parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'compare test vs reference AUC/Cmax and judge 80-125% bioequivalence with 90% CI'. That is enough for an agent to tell it apart from neighboring PK/statistics tools such as pk_nca, delong_auc_compare, or clinical_basic_bridge. The only flaw is that it claims Cmax support, which the schema does not expose.
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 'USE WHEN' clause gives a trigger condition, which is more than most definitions offer. However, it names no alternatives and no exclusions, so an agent cannot tell when pk_nca or stats_toolbox would be the better choice. The mention of Cmax in the trigger is actively misleading, since no Cmax parameter exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calibration curve (prediction model) / 校准曲线 | USE WHEN: assess calibration of a risk model and get the curve plus Brier score | ALIASES: 校准曲线, 校准度, Brier, calibration, 预测模型校准, 可靠性曲线 | RETURNS: 校准曲线与 Brier 分数
| Name | Required | Description | Default |
|---|---|---|---|
| labels | Yes | 真实标签 | |
| n_bins | No | 分箱数 | |
| scores | Yes | 预测概率（0~1） |
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 value by disclosing the return payload (calibration curve plus Brier score), but omits prerequisites such as labels needing to be binary and scores needing identical length, and says nothing about binning defaults.
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 pipe-delimited layout is front-loaded: trigger first, then aliases, then return values, with no prose padding. Minor redundancy in that the title is restated verbatim as the first token of the description.
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 read-only statistics tool with full schema coverage, the description supplies the trigger, the outputs, and search aliases, which is adequate. The remaining gap is input preconditions (binary labels, equal-length arrays) that no other structured field covers.
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 explains labels, scores, and n_bins, and the description adds no parameter-level meaning on top. It does not clarify that scores must be probabilities in 0-1 range or that n_bins is optional with 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 resource (calibration curve) and a concrete output differentiator (Brier score) plus the verb 'assess calibration of a risk model', which separates it from roc_auc and classification_metrics. It does not explicitly name the sibling tools it competes with, 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 'USE WHEN: assess calibration of a risk model' clause gives an explicit trigger condition, which is clearer than most sibling definitions. However, it offers no when-not guidance and does not route the agent to alternatives such as roc_auc or classification_metrics for discrimination-vs-calibration questions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cell assay calculator / 细胞实验通用计算 | USE WHEN: CCK8 / wound healing / Transwell / colony formation calculations (pick tool_id: cck8, wound-healing, transwell, colony) | ALIASES: CCK8, 划痕实验, Transwell, 克隆形成, 细胞增殖, 迁移实验, cell viability, wound healing | RETURNS: 计算结果
| Name | Required | Description | Default |
|---|---|---|---|
| params | No | 该工具所需参数 | |
| tool_id | Yes | 工具 id，如 cck8/wound-healing/transwell/colony |
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 and the description need not restate it. What the description leaves out is the behavior an agent actually needs: what each tool_id computes, what 'params' must contain per assay, and what the result looks like beyond the placeholder 'RETURNS: 计算结果'. Nothing here contradicts 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 piped, front-loaded layout is scannable and the USE WHEN clause comes early. However, the long bilingual alias list and the zero-information 'RETURNS: 计算结果' line consume tokens without adding decision value, and the bilingual duplication of the title 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?
This is a dispatcher over four distinct computations with an opaque nested params object and no output schema, so the description carries the full burden of explaining per-assay inputs and outputs. It does not: an agent can choose a tool_id but cannot reliably construct a valid 'params' payload or know what comes back.
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?
Although nominal schema coverage reads 100%, the critical 'params' property is an unconstrained nested object described only as '该工具所需参数', and the description does not compensate by listing which fields each tool_id requires. The agent knows to pick cck8/wound-healing/transwell/colony but has no information about the payload, so the description adds almost no semantic meaning for the higher-risk parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states that the tool performs cell-assay calculations and enumerates four concrete assay types (CCK8, wound healing, Transwell, colony formation) via the tool_id selector, which distinguishes it from the statistics and imaging siblings. It never states the verb explicitly (compute what: viability %, migration area, colony count?), so purpose is clear but not fully pinned down.
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 'USE WHEN' clause gives explicit triggering conditions naming the exact assay scenarios, and the tool_id enumeration tells the agent how to route within the tool. There is no when-not guidance and no mention of alternatives (e.g. ic50_fit, tumor_growth_inhibition, or stats_toolbox for downstream analysis), which keeps it below a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ChIP-seq peak calling / ChIP-seq Peak calling | USE WHEN: call peaks from ChIP-seq reads | ALIASES: ChIP-seq, peak calling, 峰识别, 转录因子结合, ChIP | RETURNS: peak 清单
| Name | Required | Description | Default |
|---|---|---|---|
| data_json | Yes | 必填。数据对象（不是字符串）。矩阵形式：{"matrix": [[行1各列数值...], [行2...]], "rows": ["基因/特征名"], "cols": ["样本名"]}；组学结果另可带 {"groups": ["组A","组A","组B"...]}（与 cols 一一对应）、{"p_values": [...], "log2fc": [...]}（若已有差异结果）。实测缺此字段会被拒：Field required: data_json |
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 only adds "RETURNS: peak 清单" (a peak list), without saying what a peak record contains, whether thresholds or genome build matter, or what happens with an ill-formed matrix.
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 pipe-delimited tag format front-loads the purpose and the USE WHEN trigger well. However, the first segment duplicates the title bilingually ("ChIP-seq peak calling / ChIP-seq Peak calling") and the ALIASES list is largely search-engine padding rather than operational guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description is the only source for return values, and "peak 清单" is thin. It also leaves the mismatch unexplained: peak calling is normally read/genome/control driven, yet the only input is a generic gene-by-sample matrix, so an agent cannot tell how the matrix is interpreted.
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 data_json parameter is documented in detail (matrix form, rows/cols, optional groups/p_values/log2fc, plus the exact rejection message). The description adds nothing about the parameter, 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: "call peaks from ChIP-seq reads." That is far more informative than the title alone, though it never distinguishes this tool from adjacent omics siblings such as atac_diff or differential_expression.
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 "USE WHEN" clause gives an explicit trigger condition (ChIP-seq reads are the input), which is enough for an agent to know the context. It does not state when NOT to use it, nor point to an alternative for related assays, so it stops short of the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Citation formatting / 引文格式化 | USE WHEN: reformat references to Vancouver / APA / GB-T 7714 | ALIASES: 参考文献格式, 引文格式, Vancouver, APA, GB/T 7714, citation, 文献格式 | RETURNS: 格式化后的引文
| Name | Required | Description | Default |
|---|---|---|---|
| style | No | vancouver/apa/mla/chicago/gbt7714 | |
| references | Yes | 参考文献列表 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish this as a safe, read-only, sandboxed operation, so the safety burden is covered. The description adds only the return shape ('格式化后的引文') and an alias list, and does not say what happens with unparseable or missing metadata, nor why mla/chicago appear in the schema but not in the USE WHEN list.
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 pipe-delimited, front-loaded layout puts the trigger condition and capability in the first clause, which reads well. The ALIASES segment is largely keyword padding that does not help an agent decide when or how to call the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter, single-purpose transformation with annotations covering the safety profile, the description supplies enough to call it correctly. The main missing piece is any note on expected reference format or failure behavior, which is minor here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both the 'style' string and the 'references' array, and the baseline is 3. The description's mention of three style values adds nothing the schema does not already contain, and it does not clarify format expectations for the reference 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?
The description states a specific verb+resource combination (reformat references) and enumerates the target styles (Vancouver / APA / GB-T 7714), so the agent knows exactly what transformation is performed. It does not differentiate from the nearby sibling citation_verify, which is the only real gap.
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 explicit 'USE WHEN: reformat references to ...' line gives a concrete trigger condition, which is stronger than most definitions provide. It stops short of exclusions or pointing to alternatives (e.g. 'use citation_verify to check that a reference is real'), 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.
Verify citation authenticity / 引文真实性核验 | USE WHEN: check whether references are fabricated (existence check against the local corpus) | ALIASES: 核验参考文献, 引用是真的吗, 假文献, citation verify, 参考文献真实性, hallucinated reference | RETURNS: 逐条核验结果
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | 含引用的正文 | |
| topic | No | 主题 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish that the tool is read-only, non-destructive, and closed-world. The description adds meaningful behavior by saying it performs an existence check against the local corpus and returns per-item verification results, but it does not explain result fields, matching limits, 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 description is compact, front-loaded, and structured with clear USE WHEN and RETURNS sections. The alias list is somewhat long but serves discovery and does not obscure the core 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 two-parameter, read-only tool with full schema coverage and clear annotations, the description provides enough context to select and invoke it correctly. The main remaining gap is that it does not specify the structure of the per-item verification results returned.
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 schema documents both parameters: the body text containing citations and an optional topic. The description does not add further detail about input format, citation parsing, or how the topic parameter affects verification.
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: verify citation authenticity, specifically checking whether references are fabricated. It also scopes the operation as an existence check against the local corpus, which distinguishes it from citation formatting or ordinary literature search siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit USE WHEN trigger: checking whether references are fabricated. It does not state when not to use it or name alternative sibling tools for broader literature discovery, but the intended use case is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Classification metrics / 分类性能报告 | USE WHEN: full diagnostic performance set: accuracy, sensitivity, specificity, PPV, NPV, F1 | ALIASES: 分类性能, 准确率, 敏感度, 特异度, PPV, NPV, confusion matrix, 诊断指标 | RETURNS: 分类指标全套
| Name | Required | Description | Default |
|---|---|---|---|
| labels | Yes | 真实标签 | |
| threshold | No | 判定阈值 | |
| predictions | Yes | 预测结果（0/1） |
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 and the description only needs to add operational context. It adds that the full diagnostic set is returned, but says nothing about how the threshold parameter affects the binarization of predictions or what the output structure looks like — meaningful gaps for a metrics tool with a tunable cutoff.
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 pipe-delimited keyword-block format is dense, front-loaded, and easy to scan, with the primary use case stated before aliases. The alias list is somewhat long and partly duplicates the metric names already listed, but every segment is short and functional.
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 three-parameter statistics tool with full schema coverage and a read-only annotation profile, the description covers what it computes and the metric set returned. The only shortfall is the absence of any return-format detail, which matters slightly more because there is no 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% (labels, predictions, threshold all documented in Chinese), so the schema carries parameter meaning and a baseline of 3 applies. The description does not explain the threshold's default, its role in converting probabilities to 0/1, or the expected alignment between labels and predictions arrays.
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 (classification metrics) and enumerates the exact metric set returned (accuracy, sensitivity, specificity, PPV, NPV, F1, confusion matrix), which is concrete and distinguishable from single-metric siblings such as roc_auc or calibration_curve. The verb is only implied ('compute'), and no sibling is named explicitly, so differentiation is inferential 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?
'USE WHEN: full diagnostic performance set' gives a selection condition that implicitly steers an agent away from single-metric tools. However, it never names the alternative tools (roc_auc, calibration_curve, delong_auc_compare) or states when NOT to use this one, leaving the routing decision to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clinical ↔ basic translation bridge / 临床↔基础转化配对 | USE WHEN: from a clinical finding propose mechanistic hypotheses and experiments (or the reverse) | ALIASES: 转化研究, 临床到基础, 机制假说, bench to bedside, Bridge, 实验方案建议 | RETURNS: 转化研究假说与实验方案
| Name | Required | Description | Default |
|---|---|---|---|
| finding | Yes | 临床发现/基础发现 | |
| direction | No | clinical2basic 或 basic2clinical |
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 and closed-domain scope are covered structurally. The description adds the output content ('RETURNS: 转化研究假说与实验方案'), which matters because there is no output schema. It does not disclose that the output is generated hypotheses rather than evidence-backed findings, nor any caveats about validating them, which is the behavior an agent most needs to know 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 pipe-delimited layout is scannable and front-loads the title and USE WHEN trigger. However, a large share of the text is a bilingual alias/keyword list (转化研究, bench to bedside, Bridge, 实验方案建议) that serves retrieval matching rather than agent comprehension, and the title is restated in both the header and the 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?
For a two-parameter, single-purpose tool with no output schema, the description supplies the trigger and the return content, which is close to sufficient. Gaps remain: the optional 'direction' parameter's default is never stated, and there is no indication of output shape or depth (how many hypotheses, whether experiments come with rationale). 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 'finding' and 'direction' are already documented, including the two direction values. The description's 'or the reverse' reinforces the direction parameter's meaning but adds no syntax, defaults, or constraints (e.g. what happens if direction is omitted despite being optional). 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 USE WHEN clause states a concrete transformation: from a clinical finding, propose mechanistic hypotheses and experiments (and the reverse). That is a specific verb (propose hypotheses/experiments) plus a resource (translational bridge), so an agent can tell it apart from analysis siblings like roc_auc or qpcr_ddct. It stops short of naming the nearest conceptual neighbors (act_experiment_plan, act_idea_ignite, study_design_advisor), so sibling differentiation is implicit rather than 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?
There is one explicit trigger condition — 'from a clinical finding propose mechanistic hypotheses and experiments (or the reverse)' — which also implies the bidirectional case. It gives no when-not guidance and no named alternative for cases where the agent just needs a plain experiment plan (act_experiment_plan) or an idea brainstorm (act_idea_ignite). Clear context, but routing under ambiguity 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.
Molecular cloning design / 克隆方案设计 | USE WHEN: design a plasmid construct: homology arms, primers, assembly strategy | ALIASES: 分子克隆, 构建质粒, 同源臂, cloning, Gibson, 酶切连接, 引物设计克隆 | RETURNS: 克隆方案与引物
| Name | Required | Description | Default |
|---|---|---|---|
| method | No | Gibson / Golden Gate / 酶切连接 | |
| insert_seq | Yes | 插入片段序列（≥40bp） | |
| vector_seq | Yes | 载体序列 |
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 fully covered by structured data and the description need not restate it. The description contributes the 'RETURNS: 克隆方案与引物' line, which substitutes for the absent output schema, but says nothing about what the plan contains, whether an omitted 'method' falls back to a default, or what the ≥40bp insert constraint implies for 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 pipe-delimited layout is front-loaded and scannable, with the action verb appearing in the first segment. The bilingual title repetition and the long alias list (including 引物设计克隆, which overlaps a sibling's territory) consume space without improving invocation decisions.
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 compact 3-parameter computational tool with a fully described schema and a stand-in RETURNS line, the essentials are present. Gaps remain around what the returned plan looks like, how 'method' behaves if omitted (it is not required), and why the two sequence inputs are needed together, which matters given there is no 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 the schema already documents all three parameters including the Gibson / Golden Gate / 酶切连接 options for 'method'. The description only echoes those same method names in the ALIASES list, adding no new meaning about defaults, format, or interaction between insert_seq and vector_seq; 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 — design a plasmid construct — and enumerates the concrete outputs (homology arms, primers, assembly strategy), which is far more specific than the bare tool name. It does not, however, differentiate from closely related siblings such as plasmid_map, pcr_primer_design, restriction_sites, or primer_tm, which an agent could reasonably confuse with this 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 'USE WHEN' clause gives an explicit triggering condition ('design a plasmid construct'), so an agent knows the situation that selects this tool. It stops short of a when-not clause or naming an alternative sibling (e.g., 'for primer Tm only, use primer_tm'), so the routing is clear but not fully disambiguated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
CONSORT flow diagram / CONSORT 流程图 | USE WHEN: draw a CONSORT participant flow diagram from screening/randomization/loss counts | ALIASES: CONSORT流程图, 流程图, 入组流程, flow diagram, 筛选失访 | RETURNS: CONSORT 流程图
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | 研究题目 | |
| screened | No | 筛选人数 | |
| randomized | No | 随机化人数 | |
| allocated_control | No | 对照组分配数 | |
| excluded_screening | No | 筛除人数 | |
| allocated_intervention | No | 干预组分配数 | |
| lost_to_followup_control | No | 对照组失访数 | |
| lost_to_followup_intervention | No | 干预组失访数 |
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 without the description's help. The description adds nothing beyond that: 'RETURNS: CONSORT 流程图' merely restates the title and leaves the actual return medium ambiguous (image file, Mermaid source, or structured data), which is exactly what an agent needs to know before invoking a diagram generator.
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-loads the action verb, then scans cleanly through USE WHEN, ALIASES, and RETURNS. The 'RETURNS: CONSORT 流程图' line is pure redundancy with the title and wastes a slot that could carry output-format 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?
All eight parameters are optional, so an agent needs guidance on what happens when counts are omitted and what the finished artifact looks like; neither is addressed. With no output schema and a placeholder RETURNS line, the definition is adequate to identify the tool but not to predict its 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 all eight parameters already carry Chinese labels; the description only summarizes their categories ('screening/randomization/loss counts'). It adds no meaning beyond the schema, such as whether counts must be mutually consistent (screened = excluded + randomized) or how missing optional counts are rendered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and artifact ('draw a CONSORT participant flow diagram') plus the source data it consumes (screening/randomization/loss counts), so an agent knows exactly what the tool produces. It does not explicitly contrast with the closely related prisma_flowchart sibling, leaving the CONSORT-vs-PRISMA distinction to the agent's domain knowledge.
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 'USE WHEN' clause states a clear triggering condition tied to the study phase (participant flow counts from screening through loss to follow-up). There are no exclusion conditions and no named alternatives, so an agent unsure whether to use this or prisma_flowchart 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.
CRF / SDTM validation / CRF 数据校验（SDTM） | USE WHEN: check whether CRF data meets CDISC SDTM conventions before export | ALIASES: CRF校验, SDTM, CDISC, 数据合规, 导出前检查, CRF validate, data standards | RETURNS: 校验结果
| Name | Required | Description | Default |
|---|---|---|---|
| form_id | No | 表单 id |
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 settled and the description is not required to restate it. What the description adds beyond that is thin: "RETURNS: 校验结果" says nothing about whether the result is pass/fail, a list of rule violations, severity levels, or whether it blocks export. No mention of what standards version is applied or of any scoping behaviour.
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 pipe-delimited USE WHEN / ALIASES / RETURNS segmentation is easy to scan and the trigger condition is front-loaded. The opening clause duplicates the tool name and title verbatim, and the alias block is keyword padding rather than information, but neither is 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?
For a one-parameter, non-destructive read tool with annotations and no output schema, the definition covers the essentials but leaves two real gaps: the meaning of an absent form_id and the shape/behaviour of the validation result. Sibling differentiation is also missing in a catalog of ~130 tools, which raises the cost of choosing 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% and there is a single optional parameter (form_id), so the schema already documents it adequately; the baseline of 3 applies. The description adds no meaning beyond it — notably it never explains what happens when form_id is omitted (validate all CRFs? validate the whole study?), which is exactly the semantic an agent would need.
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?
"check whether CRF data meets CDISC SDTM conventions before export" gives a specific verb (validate/check) and a specific standard (CDISC SDTM), which is more than a name restatement. It does not differentiate from any sibling — the closest neighbours (act_design_export_check, reporting_checklist, data compliance-ish tools) are never named, so an agent must infer the boundary 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?
The "USE WHEN" clause supplies a concrete triggering condition: pre-export verification of CRF data against SDTM conventions. It does not state when NOT to use it nor point at any alternative for e.g. general reporting compliance, so the routing guidance is clear but open-ended.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse pasted data / infer column types / 数据解析与列类型识别 | USE WHEN: the user pasted a CSV/table blob: get shape, column types, missingness before analysis | ALIASES: 解析数据, 列类型, 粘贴表格, CSV解析, parse data, column types, 数据形状 | RETURNS: 行列数、列类型、缺失情况
| Name | Required | Description | Default |
|---|---|---|---|
| csv_data | No | CSV 文本 |
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 'RETURNS' line adds genuine value by naming shape, column types and missingness as outputs. However, nothing is said about malformed or non-CSV input, size limits, or how types are inferred, which are the real behavioral risks for a parsing 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 definition is a single front-loaded line with labelled sections (purpose, USE WHEN, ALIASES, RETURNS), so the agent can scan it quickly. The alias list is long and repeats the purpose in Chinese and English, which is useful for matching but is the least economical part.
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 one-parameter, read-only, side-effect-free utility with no output schema, the description covers trigger, aliases and return content, which is essentially everything needed to call it correctly. The remaining gap is sibling disambiguation against dataset_profile/dataset_columns.
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 with 100% schema description coverage ('CSV 文本'), so the schema carries the burden and baseline is 3. The description adds only the nuance that the data comes from a user paste rather than a file path or dataset id. No format details (delimiter, encoding, header presence) are added 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 ('Parse pasted data', 'infer column types') plus the concrete outputs it derives ('get shape, column types, missingness'). An agent can tell it is a data-ingestion/typing utility. It does not, however, differentiate itself from close siblings like dataset_profile or dataset_columns, which appear to overlap heavily.
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 'USE WHEN' clause gives a concrete trigger: the user pasted a CSV/table blob and the agent needs shape/types/missingness before analysis. That is a clear context for selection. It stops short of naming alternatives or stating when not to use it (e.g., for an already-loaded dataset), so it falls below a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List data columns / 读取数据列名 | USE WHEN: list the variables in an uploaded data file (do this before Table 1 / modeling so you use real column names) | ALIASES: 列名, 有哪些变量, 字段名, columns, variables, 变量清单, 表头 | RETURNS: 列名与类型
| Name | Required | Description | Default |
|---|---|---|---|
| file_id | Yes | 数据文件 id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, destructiveHint=false, so safety is covered. The description still adds value by stating what comes back ('列名与类型') in the absence of an output schema, and by framing this as a prerequisite step. It does not cover behavior on large files or pagination, 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?
Pipe-delimited sections are front-loaded and scannable: purpose, use-when, aliases, returns. The alias block is somewhat bulky but serves real query-matching value; no filler 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 single-parameter read-only tool this covers purpose, trigger, and return shape, leaving little an agent needs. Missing only large-file/limit behavior and explicit sibling routing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter, file_id, and schema description coverage is 100%, so the schema already carries the meaning. The description adds nothing about what file_id refers to or where it comes from (upload endpoint), 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 concrete verb and resource: listing variables in an uploaded data file, plus an explicit return of column names and types. An agent can tell this is a column-inventory operation, though it does not explicitly contrast with near neighbors like dataset_profile or dataframe_parse, which also surface file structure.
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 'USE WHEN' clause gives a clear trigger and even a sequencing rule (call it before Table 1 / modeling so real column names are used), which is genuinely actionable. It stops short of naming an alternative or a when-not condition, so routing versus dataset_profile 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.
Dataset profile / 数据快速画像 | USE WHEN: first look at a data file: distributions, missingness, outliers, data quality overview | ALIASES: 数据长什么样, 描述统计, 缺失情况, 数据质量, data profile, descriptive, summary stats, EDA | RETURNS: 描述统计与质量概览
| Name | Required | Description | Default |
|---|---|---|---|
| file_id | Yes | 数据文件 id | |
| study_design | No | 研究设计 |
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 only 'RETURNS: 描述统计与质量概览', with no mention of cost, runtime, sampling behavior on large files, or whether extra columns are written — modest added value over the structured data.
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 pipe-delimited tag format is front-loaded with the trigger condition and has no filler prose. The alias list is long by nature but earns its place for retrieval matching, so the only weakness is density 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 two-parameter, read-only tool with no output schema, the description covers the intent and the returned summary's nature, which is sufficient to call it correctly. It leaves open where an agent obtains a valid file_id, but that is a minor gap given openWorldHint=false and full schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with file_id ('数据文件 id') and study_design ('研究设计') both documented, so the baseline is 3. The description adds no new meaning about how study_design changes the profile output, leaving the schema to do all 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 concrete verb+resource ('first look at a data file') and enumerates the outputs: distributions, missingness, outliers, data quality. That is clearly distinguishable from neighbors like dataframe_parse (parsing) or dataset_columns (column listing), 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?
The 'USE WHEN: first look at a data file' trigger gives a clear entry condition, and the alias list further anchors the intent in both Chinese and English. It stops short of stating when NOT to use it or which sibling to prefer for deeper analysis, so it is strong context without explicit routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
DeLong test (compare two AUCs) / 两条 ROC 的 AUC 比较（DeLong） | USE WHEN: compare two ROC AUCs from the same subjects and test whether the difference is significant | ALIASES: DeLong, 两个AUC比较, 哪个指标更好, AUC差异, compare AUC, 曲线下面积比较 | RETURNS: 两 AUC 及差值 P 值
| Name | Required | Description | Default |
|---|---|---|---|
| labels | Yes | 真实标签 0/1 | |
| scores1 | Yes | 指标 1 的分数 | |
| scores2 | Yes | 指标 2 的分数 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly/closed-world/non-destructive, so the safety profile is covered. The description adds the substantive behavioral constraint that the two AUCs must come from the same subjects (paired design) and that the output is the test of a difference, which is the key thing an agent must get right before calling it. It omits assumptions such as binary labels being 0/1, minimum sample requirements, and error behavior, so it is not exhaustive.
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 labeled structure (USE WHEN / ALIASES / RETURNS) is front-loaded and easy to scan. However, the opening line duplicates the tool title verbatim in both English and Chinese, and the six-item alias list is keyword padding rather than information an agent needs to invoke the tool correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of explaining returns, and 'RETURNS: 两 AUC 及差值 P 值' covers only the bare minimum (two AUCs plus a difference p-value) — no direction of the difference, confidence interval, or per-AUC standard errors. For a simple three-array statistical tool this is adequate but thin, especially given the mixed-language phrasing that may slow parsing.
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 per-dimension field meaning is already documented (labels 0/1, scores for metric 1 and metric 2). The description goes beyond the schema by implying the three arrays must be subject-aligned and equal length, a constraint the schema never states. It still does not spell out that constraint explicitly or discuss score scale/ties.
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 named statistical test (DeLong) with its exact operation: comparing two ROC AUCs from the same subjects to test whether the difference is significant. This cleanly separates it from the sibling roc_auc (single-AUC estimation) and from generic metric tools, so an agent can identify it without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'USE WHEN' clause gives an explicit trigger condition: two AUCs measured on the same subjects, testing for a significant difference. It does not state when NOT to use it (e.g., independent/unpaired groups, where a different test would be needed) or name an alternative tool, so it falls short of a full routing rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Design gate rules / 方案设计闸门规则 | USE WHEN: explain why a design step is blocked, or what the platform requires for each step (hard gates G1/G2/G3) | ALIASES: 方案设计闸门, 为什么不让过, 硬性要求, gate rules, validation rules, why blocked | RETURNS: 每步是否有硬闸门、三道跨步闸门 G1/G2/G3 的原文规则
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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. The description adds value beyond those annotations by disclosing the shape of the payload: per-step hard-gate flags plus the verbatim G1/G2/G3 cross-step rules. This matters because there is no output schema. It does not mention any deterministic or caching behavior, but that omission is minor for a static rules lookup.
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 uses a labeled, front-loaded structure (USE WHEN / ALIASES / RETURNS) with no filler prose, so an agent can parse it quickly. The bilingual duplication and the long alias list add bulk, but those entries serve retrieval matching and are straightforward to justify.
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 the tool has no parameters, no output schema, and a read-only static payload, the description covers everything needed to call it correctly: the trigger, what comes back, and the gate identifiers G1/G2/G3. It could be stronger only by mentioning a sibling for step-state queries or noting that the output is static reference text, which is not a blocker.
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 schema is empty and there is nothing for the description to disambiguate. Under the baseline rule for 0-param tools, a 4 is the appropriate score. The description appropriately spends its words on scope and return content instead.
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 uses a concrete verb and resource: it explains why a design step is blocked and states what the platform requires per step, naming the hard gates G1/G2/G3. That makes the function clear, but the description never contrasts this tool with its closest siblings, such as design_step_context, act_design_next_step, or act_design_decision, so the agent must infer the boundary from the name 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 'USE WHEN' clause gives explicit trigger conditions: the agent needs to know why a step is blocked, or what each step requires. There is no 'when not to use' guidance and no named alternative for cases where the agent needs step state rather than gate rules, which keeps this from a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Design step context / 取某一步的上下文 | USE WHEN: load what the user already answered for a design step (PICO / design type / population) before drafting the next step | ALIASES: 方案设计上下文, 上一步内容, 已经填过的信息, design context, previous step, project context | RETURNS: 该步骤可用的前序上下文（pico / design_type / population / topic）
| Name | Required | Description | Default |
|---|---|---|---|
| step | Yes | 要看哪一步的上下文（数据编号 1-11） | |
| project_id | Yes | 课题 id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare this is read-only, closed-world, and non-destructive, so the safety profile is fully covered elsewhere. The only real addition is the RETURNS line listing pico / design_type / population / topic, which is useful given there is no output schema, but the description says nothing about what happens for an empty or unanswered step, an out-of-range step, or missing project.
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 pipe-delimited line with the trigger front-loaded in USE WHEN and the payload in RETURNS. The alias list is padding for a human reader, but since it doubles as search surface it earns partial keep; 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 read tool with no output schema, the description covers the trigger, the input meaning (via schema), and the shape of the return payload. The remaining gap is the meaning of the 1-11 step enumeration and empty-result behavior, which are minor for this complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: 'step' is documented as data index 1-11 and 'project_id' as the project id, so the schema already carries the parameter meaning. The description adds only that the returned context fields vary by step, without explaining what each step number corresponds to; 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: it loads what the user already answered for a design step (PICO / design type / population) and returns the prior context. 'Before drafting the next step' implicitly points away from the drafting siblings such as act_design_next_step or act_design_generate, but it never names an alternative explicitly, so the differentiation stays partial.
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 'USE WHEN' clause gives a clear trigger: fetch prior answers for a step before drafting the next one. It supplies no when-not conditions, no prerequisites, and no named alternative tools, so the guidance is solid but does not reach the explicit routing seen at the 5 level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Differential expression (limma-style) / 差异表达分析 | USE WHEN: differential genes from an expression matrix (with volcano plot input) | ALIASES: 差异表达, 差异基因, DEG, differential expression, 火山图, 表达矩阵, limma | RETURNS: 差异基因清单
| Name | Required | Description | Default |
|---|---|---|---|
| group_a | No | A 组样本表达（CSV） | |
| group_b | No | B 组样本表达（CSV） | |
| gene_names | No | 基因名列表 | |
| pval_threshold | No | P 阈值 | |
| log2fc_threshold | No | log2FC 阈值 |
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 and the description only needs to add context. It adds 'limma-style' (implying the statistical method) and names the returned artifact, but says nothing about required input shape, minimum sample counts, multiple-testing correction, or default threshold 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 pipe-delimited tag format is front-loaded and free of filler prose, which helps scanning. However, the title is repeated verbatim as the first token, the Chinese/English title duplicates the tool name, and the seven-term alias list is bulk rather than substance.
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 full responsibility for describing the return value, yet it says only '差异基因清单' without indicating fields such as logFC, P-value or adjusted P-value. It also leaves unexplained why all five parameters are optional for an analysis that logically requires two expression matrices.
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 five parameters (group_a, group_b, gene_names, pval_threshold, log2fc_threshold) are already documented in structured fields; baseline 3 applies. The description adds no extra meaning such as what happens when thresholds are omitted, even though every parameter is optional.
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 title and description state a specific analysis ('Differential expression (limma-style)') and a concrete output ('RETURNS: 差异基因清单'), so an agent knows this is a DEG computation over an expression matrix rather than a generic stats tool. It does not differentiate itself from the closely related sibling rnaseq_deg, which an agent would also plausibly pick for the same task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'USE WHEN: differential genes from an expression matrix (with volcano plot input)' gives a usable trigger condition, including the downstream volcano-plot use case. There is no when-not guidance and no explicit routing against alternatives such as rnaseq_deg or metabolite_volcano, so the agent must infer which DEG tool to call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
DNA → protein translation / 序列翻译 | USE WHEN: translate a nucleotide sequence into amino acids in all three frames | ALIASES: 序列翻译, 核酸转蛋白, 翻译, translate, DNA to protein, 氨基酸序列, ORF翻译 | RETURNS: 氨基酸序列
| Name | Required | Description | Default |
|---|---|---|---|
| sequence | Yes | 核酸序列 |
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 fully covered by structured data. The description adds only 'RETURNS: 氨基酸序列', which is useful because no output schema exists, but it does not disclose frame labeling, stop-codon representation, or handling of degenerate/ambiguous bases. That is adequate-but-thin for a tool with annotations carrying the main behavioral burden.
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 tag-style layout (purpose | USE WHEN | ALIASES | RETURNS) is front-loaded and scannable with no filler prose. The alias list is long and partially redundant with the title, which keeps it from a 5.
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 one-parameter, no-output-schema tool this covers the essentials: what it does, the frame scope, and the shape of the return value. Gaps remain around genetic code table selection and translation conventions, but they are small relative to the tool's simplicity.
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 the single required parameter, so the schema already documents 'sequence' as a nucleic acid sequence. The description adds no meaning beyond that — nothing about accepted alphabets, case sensitivity, FASTA headers, or length limits — so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource pair ('DNA → protein translation') and specifies scope ('in all three frames'), which rules out simple single-frame translation. It does not explicitly distinguish itself from nearby siblings like orf_find or protein_digest, 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 'USE WHEN' line gives a trigger condition (translate a nucleotide sequence into amino acids in all three frames), which implies when to call it. However, it never names an alternative or a when-not case — notably it gives no routing guidance versus orf_find, which also consumes nucleotide sequence and works in frames.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Drug-drug interaction check / 药物相互作用检查 | USE WHEN: can these two drugs be used together? interaction severity and mechanism | ALIASES: 药物相互作用, 能不能一起用, 配伍禁忌, DDI, drug interaction, 相互作用 | RETURNS: 相互作用等级与机制
| Name | Required | Description | Default |
|---|---|---|---|
| drug_a | Yes | 药物 A | |
| drug_b | Yes | 药物 B |
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 and closed-world scope are covered by structured fields. The description adds that the result contains severity and mechanism, which is useful, but it says nothing about behavior when a drug is unknown or ambiguous (no match, error, or empty result).
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 pipe-delimited layout is easy to scan, and the USE WHEN clause is front-loaded ahead of aliases and returns. The repeated bilingual title at the start is mildly redundant with the tool name and title fields, but nothing is verbose.
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-argument read tool with annotations and no output schema, the description covers purpose, trigger and return shape adequately. The notable omission is input expectations for drug naming, which materially affects a correct call, plus the handful of near-neighbor pharmacology tools it does not help disambiguate.
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%, but the field descriptions are only '药物 A' and '药物 B', so the schema itself adds little. The description does not specify whether names should be generic or brand names, Chinese or English, or what format is accepted, leaving the key semantic question unanswered.
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 ('Drug-drug interaction check') and states the scope ('interaction severity and mechanism'), which lets an agent distinguish it from neighbors like toxicity_predict, toxicology_assess or pk_pd_assess. It never explicitly names which sibling to use instead, so differentiation is implicit 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?
'USE WHEN: can these two drugs be used together?' gives a concrete triggering question, and the ALIASES list helps matching ambiguous user phrasing such as 配伍禁忌 or 能不能一起用. There are no exclusions or alternative-tool routing (e.g. when to prefer pk_pd_assess for dosing questions), which keeps it below a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dunn post-hoc test / 多组非参数两两比较（Dunn） | USE WHEN: pairwise comparisons after Kruskal-Wallis (nonparametric, multiple groups) | ALIASES: Dunn, 非参数两两比较, Kruskal-Wallis后续, post hoc, 多重比较 | RETURNS: 两两比较 P 值
| Name | Required | Description | Default |
|---|---|---|---|
| groups | Yes | {组名: [数值...]} |
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 and the description only needs to add statistical behavior. 'RETURNS: 两两比较 P 值' does signal the output is a pairwise P-value table, but the description never discloses the multiple-comparison correction method, which is the single most consequential behavioral detail for a Dunn implementation. Nothing contradicts 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 pipe-delimited, front-loaded structure (identity, USE WHEN, ALIASES, RETURNS) lets an agent parse intent in one pass with no rambling prose. The ALIASES segment is longer than strictly needed but serves discovery matching across Chinese and English phrasings. Nothing is redundant with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, no-output-schema tool the definition is nearly sufficient: it says when to call it and what comes back. The gaps are the post-hoc adjustment method and preconditions (>=3 groups, adequate per-group n, ties handling) that determine whether results are trustworthy. Adequate but not complete for a statistics 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 only one parameter, nested, with 100% schema description coverage ('{组名: [数值...]}'), so the schema already tells the agent to pass a mapping of group name to numeric vector. The description adds no constraint on minimum group count, minimum sample size per group, or handling of missing values. 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?
Names a specific statistical procedure (Dunn post-hoc) and states its scope: pairwise comparisons after Kruskal-Wallis for nonparametric multiple groups. The English/Chinese title plus 'RETURNS: 两两比较 P 值' makes the resource unambiguous. It stops short of naming the sibling it displaces (tukey_hsd, the parametric analogue), so differentiation is left implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'USE WHEN: pairwise comparisons after Kruskal-Wallis (nonparametric, multiple groups)' gives a clear triggering context that an agent can match against a study design. It also implicitly excludes the parametric case by flagging 'nonparametric'. No explicit when-not or named alternative (e.g., tukey_hsd / two_way_anova) appears, 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.
Egger's test (publication bias) / Meta 发表偏倚（Egger） | USE WHEN: test publication bias in a meta-analysis and get funnel-plot inputs | ALIASES: Egger, 发表偏倚, 漏斗图, publication bias, meta回归, funnel plot | RETURNS: Egger 检验 P 与截距
| Name | Required | Description | Default |
|---|---|---|---|
| log_or | Yes | 各研究 logOR | |
| se_log_or | Yes | 各研究 SE |
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 by structured data. The description adds only 'RETURNS: Egger 检验 P 与截距', which is useful since there is no output schema, but it omits material behavioral context such as the small-study-count reliability caveat and the assumption that effects/SEs are on a comparable scale.
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 pipe-delimited, front-loaded layout (purpose | USE WHEN | ALIASES | RETURNS) is easy to scan and contains no filler sentences. The alias list is long but earns its place for intent matching; the bilingual duplication of the title is mild 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 two-parameter, read-only statistical test with full schema coverage and an explicit RETURNS line standing in for a missing output schema, the definition gives an agent enough to call it correctly. The remaining gap is methodological preconditions (minimum number of studies, effect-size scale) that would prevent misuse.
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 log_or and se_log_or carry Chinese descriptions — so the baseline of 3 applies. The description adds nothing about parameter semantics: it never states that the arrays must be parallel, equal-length, or that SE must correspond to the same effect metric as the log OR.
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 test and its purpose ('Egger's test (publication bias)' plus 'test publication bias in a meta-analysis'), so an agent can immediately tell it is a bias-detection tool rather than a general meta-analysis or plotting tool like forest_plot. It does not explicitly contrast itself with any sibling, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'USE WHEN: test publication bias in a meta-analysis and get funnel-plot inputs' gives a clear triggering context, and the alias list ('publication bias', 'funnel plot', 'meta回归') helps intent matching. There is no when-not guidance, no minimum-study caveat, and no named alternative (e.g., trim-and-fill or funnel_plot) for when Egger's test is inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evidence follow-up Q&A / 证据追问（多轮） | USE WHEN: multi-turn follow-up on an evidence card (causal judgement) | ALIASES: 证据追问, 继续追问, 证据卡, evidence followup, 因果判断 | RETURNS: 追问答复
| Name | Required | Description | Default |
|---|---|---|---|
| round | No | 轮次 | |
| title | Yes | 标题 | |
| abstract | No | 摘要 | |
| question | Yes | 追问问题 |
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 only 'multi-turn' and 'RETURNS: 追问答复', leaving the key behavioral question unanswered: is conversation history held server-side by this tool, or must the caller replay the card via title/abstract/round on each turn? That ambiguity matters for a read-only multi-turn 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 pipe-delimited USE WHEN / ALIASES / RETURNS header is front-loaded and easy to scan, with no filler prose. It does duplicate the title string unnecessarily.
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 and a return value described only as '追问答复', plus no definition of what an evidence card is or how turns are chained, an agent cannot confidently construct a correct multi-turn call. For a stateful, 4-parameter tool this is a real gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. However, the schema labels are bare one-word glosses (轮次, 标题, 摘要, 追问问题) that convey almost no meaning, and the description does nothing to explain that title/abstract form the evidence-card context or what 'round' controls.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action (multi-turn follow-up Q&A) on a specific resource (an evidence card, scoped to causal judgement), which is more precise than the sibling names evidence_intake / evidence_report. It does not explicitly contrast itself with those siblings, 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 'USE WHEN: multi-turn follow-up on an evidence card' clause gives a real trigger condition, which is better than nothing. But it never says what to do first (presumably evidence_intake must have produced the card), what happens when there is no prior card, or when to prefer evidence_report instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Structured evidence intake / 文献证据分级录入 | USE WHEN: decompose a paper into a structured evidence card by evidence level (Decision OS) | ALIASES: 证据分级, 证据卡, 文献拆解, evidence level, GRADE, 证据录入 | RETURNS: 结构化证据卡
| Name | Required | Description | Default |
|---|---|---|---|
| doi | No | DOI | |
| title | Yes | 标题 | |
| abstract | No | 摘要 | |
| literature_type | No | 文献类型 |
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 only 'RETURNS: 结构化证据卡', which names the artifact without saying what the card contains, how evidence level is assigned, or whether the source text is stored or merely parsed. The alias list and bilingual title are metadata, not behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The pipe-delimited header front-loads the USE WHEN clause, which is good, but the entry is padded by a duplicated bilingual title, an ALIASES list of five alternative names, and a one-word RETURNS line. None of those extras help an agent decide or invoke, so several tokens do not earn their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, four-parameter intake tool with full schema coverage and no output schema, the definition covers the essentials: what it does, when to use it, and that it returns an evidence card. The remaining gap is that with no output schema the agent cannot predict the card's fields or grading scale, which the description could have sketched in a sentence.
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 doi, title, abstract, and literature_type are already documented in the schema. The description adds nothing about how these inputs affect grading or what happens when only title is supplied, 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 gives a specific verb and artifact: 'decompose a paper into a structured evidence card by evidence level (Decision OS)'. An agent knows this tool turns a paper into a graded evidence record, not a search or a report. It does not distinguish itself from close siblings such as evidence_report, evidence_followup, or act_lit_digest, 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 'USE WHEN' clause supplies one trigger condition, but it largely restates the purpose rather than giving real routing guidance. There are no when-not conditions and no named alternatives, even though the sibling list contains several adjacent evidence and literature tools an agent could easily confuse with this one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evidence report narrative / 证据报告叙述 | USE WHEN: turn evidence cards into a readable report | ALIASES: 证据报告, 证据综述, evidence report, 证据叙述 | RETURNS: 证据报告正文
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | 可选。报告语言：zh（默认，中文）或 en（英文）。其他值按 zh 处理。 | |
| result | Yes | 必填。上一次 act_decision_intake / act_decision_followup 返回的 result 对象，原样传入即可（内含 causality / drug_stage / evidence_chain 等字段）。实测缺此字段返回：缺少决策结果 result |
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 only 'RETURNS: 证据报告正文', which is useful but thin; it says nothing about failure behavior, whether the report overwrites prior output, or that the operation is a pure transformation of prior tool output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The pipe-delimited header is front-loaded and scannable, but the ALIASES segment (four near-duplicate Chinese/English labels) consumes space without helping an agent decide when to call the tool. The remaining content is a single trigger line and a terse return note, so it is compact but low in information density.
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 should supply more: the return value is described only as 'report body'. It also does not disclose the workflow dependency on a prior act_decision_intake / act_decision_followup call, and its term 'evidence cards' does not match the schema's 'result object', leaving a terminology gap an agent must reconcile.
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 (lang and the nested result object) are already documented in the schema, including the enum values and failure message. The description adds no parameter meaning beyond that, which is the expected baseline for a fully documented 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 clear action and output: turning evidence cards into a readable report narrative ('证据报告正文'). The verb/resource pair is specific enough to distinguish it from most sibling analysis tools, but it never names the closely related evidence_intake / evidence_followup tools it depends on, so an agent cannot tell the difference from the definition 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?
'USE WHEN: turn evidence cards into a readable report' is a trigger phrase, but it largely restates the purpose rather than giving a genuine selection condition. There is no when-not guidance, no mention of prerequisites (a result object from a prior decision tool), and no comparison to alternative narrative/report tools such as act_lit_digest or act_writing_one_click.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Liver fibrosis staging / 纤维化分期 | USE WHEN: map fibrosis scores to Ishak / METAVIR stage | ALIASES: 纤维化分期, Ishak, METAVIR, 肝纤维化, fibrosis stage, 病理分期 | RETURNS: 分期结论与解读
| Name | Required | Description | Default |
|---|---|---|---|
| stage | No | 分期数 | |
| method | No | 分期体系：ishak/metavir/nas |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description's only behavioral addition is 'RETURNS: 分期结论与解读', which hints at an interpretive result but gives no detail on the stage scale, ranges, or what happens with missing inputs. No contradiction with 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 pipe-delimited format is compact and front-loads the USE WHEN trigger ahead of aliases and return info. The ALIASES block is largely keyword padding for retrieval rather than information an agent needs to invoke the tool, keeping this just short of a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a small read-only lookup this is nearly sufficient, but with both parameters optional and no output schema, the description should say what stage scale is expected as input (raw Ishak score vs. already-assigned stage) and what the returned interpretation contains. Those gaps matter 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 'stage' and 'method' are already documented (including the ishak/metavir/nas values). The description adds no syntax, valid range, or mapping direction beyond that, so the baseline 3 applies. It notably omits 'nas', which the schema lists as a valid method.
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 operation and its target: mapping fibrosis scores to Ishak / METAVIR stages. This is distinguishable from every sibling (gleason_grade_group and similar grading tools cover other domains), though the extra Chinese label and alias list dilute the core statement slightly.
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 'USE WHEN: map fibrosis scores to Ishak / METAVIR stage' clause gives an explicit triggering condition, which is more than most siblings offer. It stops short of exclusions or pointing to an alternative when the user has, say, a NAS score or a non-liver grading task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Figure legend writer / 图注生成 | USE WHEN: write a figure legend for a given chart type | ALIASES: 图注, Figure legend, 图片说明, 图例, 写图注 | RETURNS: 图注文本
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | 图的背景与数据 | |
| chart_type | Yes | 图类型 |
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 the useful 'RETURNS: 图注文本' statement, which matters because there is no output schema. However, it says nothing about legend length, language, whether it cites statistics from the chart, or any limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A compact pipe-delimited format with the name and purpose first, then trigger, aliases, and return value. There is no filler text, though the ALIASES list is mostly redundant with the bilingual 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 small tool with two parameters and no output schema, this is close to complete: purpose, trigger, and a return-value hint are all present. What remains missing are the content expectations for the legend and the role of the optional context, so it falls short of fully 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?
Schema description coverage is 100%, so both parameters are already documented as 图的背景与数据 and 图类型. The description only echoes 'for a given chart type' and adds no format, length, or content guidance for either the required chart_type or the optional context. 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: writing a figure legend / 图注生成 for a given chart type. That resource is clearly distinct from the plotting or statistics siblings such as forest_plot or citation_format. It does not name a sibling to contrast with, but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'USE WHEN: write a figure legend for a given chart type' clause gives a trigger condition, but it largely restates the purpose. It never says when not to use this tool, what the alternatives are, or whether 'context' or the chart data must be supplied first. It provides implied usage, not selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Flow cytometry clustering / 流式细胞聚类 | USE WHEN: unsupervised clustering of flow cytometry data into cell populations | ALIASES: 流式聚类, 无监督分群, flow clustering, 细胞群, FlowSOM | RETURNS: 细胞群与比例
| Name | Required | Description | Default |
|---|---|---|---|
| events | No | 事件数据 | |
| grid_size | No | 网格大小 | |
| n_clusters | No | 聚类数 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a safe, closed-world read operation, so the safety burden is covered. The description adds a return-value hint ('RETURNS: 细胞群与比例'), which matters since there is no output schema, but says nothing about algorithmic behavior, determinism, or defaults for the optional grid_size/n_clusters.
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?
Pipe-delimited sections keep it compact and front-loaded: name, use condition, aliases, returns. The alias list is somewhat padded but serves real disambiguation value across bilingual queries.
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, all-optional tool with no output schema, the description covers purpose and rough output shape but leaves key call-correctness questions open: all parameters are optional yet `events` is clearly required for meaningful clustering, and no defaults are stated.
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. However the schema strings themselves are minimal ('网格大小', '聚类数') and the description adds no meaning about how grid_size relates to FlowSOM metaclusters or what happens when n_clusters 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+resource: unsupervised clustering of flow cytometry data into cell populations, with a clear domain qualifier (flow cytometry) and FlowSOM as an alias. It does not differentiate from nearby siblings such as scrna_cluster or flow_gate, so an agent must infer the boundary 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?
The 'USE WHEN: unsupervised clustering of flow cytometry data into cell populations' clause gives an explicit trigger condition. It stops short of the 5 bar because it names no alternatives or exclusions — nothing tells the agent when to prefer scrna_cluster or flow_gate instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Flow cytometry gating / 流式门控分析 | USE WHEN: gating / population percentages from flow cytometry data | ALIASES: 流式门控, 圈门, gating, 阳性比例, flow cytometry | RETURNS: 门控比例
| Name | Required | Description | Default |
|---|---|---|---|
| events | No | 事件数据 | |
| method | No | 门控方法 | |
| params | No | 门控参数 |
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 only 'RETURNS: 门控比例', which is useful output context given no output schema, but says nothing about whether events are raw intensities, how many events are expected, or how method choice alters the result.
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 pipe-delimited format is front-loaded and short, with USE WHEN and RETURNS separated into scannable slots. The bilingual duplication of the title and the ALIASES list (流式门控, 圈门, gating, 阳性比例) is keyword padding rather than information, but it is compact enough not to obscure the signal.
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 object parameter and no output schema, the definition leaves important questions open: what form the events array takes, which gating methods exist, and what keys 'params' accepts. The 'RETURNS: 门控比例' note is the only substantive addition, so an agent could select the tool but would likely have to guess at invocation details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is nominally 100%, but the labels are bare restatements ('事件数据', '门控方法', '门控参数') with no enum for method and no defined sub-properties for the nested params object. The description contributes nothing to disambiguate these three parameters, so it lands at the documented baseline for high coverage rather than above it.
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 (flow cytometry gating) and states the outcome obtained (population percentages / 门控比例), which is more than a restatement of the name. It does not explicitly distinguish itself from close siblings such as flow_cluster or mif_phenotype, so the agent must infer the boundary from the domain wording.
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 'USE WHEN: gating / population percentages from flow cytometry data' clause gives a clear triggering condition and is front-loaded. It stops short of saying when NOT to use it or pointing to an alternative sibling (e.g. flow_cluster for unsupervised clustering), so it is context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Forest plot / 森林图 | USE WHEN: forest plot from HR/OR/RR with confidence intervals | ALIASES: 森林图, forest plot, HR OR RR, 置信区间图, meta森林图 | RETURNS: 森林图（矢量）
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | 每项 {name, estimate, ci_lower, ci_upper} | |
| title | No | 图标题 | |
| x_label | No | X 轴标签 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered by structured data rather than prose. The description adds one genuinely useful behavioral fact beyond that: the return is a vector graphic (RETURNS: 森林图（矢量）). It says nothing about validation of the input array, minimum number of studies, or failure behavior for malformed rows — but with annotations present the bar is lower.
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 short and front-loaded, but a large share of the text is a bilingual alias list (森林图, 置信区间图, meta森林图) that is keyword filler rather than actionable guidance. The pipe-delimited format is scannable and nothing is buried, so it is efficient but not dense with 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?
For a 3-parameter, single-purpose plotting tool with no output schema, the definition covers purpose, trigger, and return type, which is enough to make a reasonable call. What is missing is anything about data expectations (minimum rows, required numeric fields) or how the returned vector figure is delivered for use.
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 each parameter, including the required 'data' array and its per-item {name, estimate, ci_lower, ci_upper} shape, is documented in the schema itself. The description contributes no additional parameter meaning such as value ranges, scale (log vs linear), or whether estimate is expected on a log scale. Baseline 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 names the concrete artifact (forest plot) and the required input form (HR/OR/RR with confidence intervals), which is specific enough to separate it from siblings like kaplan_meier, egger_bias_test, or nomogram. It never states an explicit verb (e.g. 'generate/render'), so the action is only implied by the title and the RETURNS line.
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 'USE WHEN' clause gives a real trigger condition: use when you have HR/OR/RR effect estimates with CIs. There are no exclusions and no named alternatives, so an agent must infer when a different plotting tool (e.g. kaplan_meier, roc_auc) is the better fit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gene information lookup / 基因信息检索 | USE WHEN: what a gene does: full name, aliases, function, location | ALIASES: 基因信息, 这个基因是干什么的, gene function, 别名, gene info, 基因全称 | RETURNS: 基因信息
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 基因名/关键词 |
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 essentially nothing beyond that: 'RETURNS: 基因信息' restates the title and the closed-world nature of the underlying source (which database, coverage, whether results can be empty for unknown symbols) is never disclosed.
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 front-loaded 'USE WHEN' and 'RETURNS' sections are scannable, but the pipe-delimited alias list (基因信息, 这个基因是干什么的, gene function, 别名...) is largely redundant with the trigger sentence and bloats the definition without adding selection signal.
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 one-parameter read-only lookup with no output schema, the field list in 'USE WHEN' effectively communicates what comes back (name, aliases, function, location). A note on source database or empty-result behavior would complete it, but nothing critical for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single query parameter is documented as '基因名/关键词'. The description's mention of aliases implies that alias strings are accepted as query input, which is a modest addition, but no format, case-sensitivity, or multi-gene behavior is clarified. 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 (gene) and enumerates exactly what information it returns: full name, aliases, function, and location. This clearly separates it from neighboring tools such as gene_pathway_disease or protein_enrichment, though the sibling distinction is implied by the field list rather than stated outright.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'USE WHEN: what a gene does' gives a clear trigger condition an agent can match against a user question. There is no explicit when-not clause and no named alternative tool (e.g., pointing to gene_pathway_disease when the question is about pathways or disease associations), which keeps it 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.
Gene → pathway → disease network / 基因-通路-疾病网络 | USE WHEN: from a gene list, find pathway / disease / drug associations and build a mechanism network | ALIASES: 基因通路, 机制网络, gene pathway, 疾病关联, 药物靶点, network, 通路疾病 | RETURNS: 通路/疾病/药物关联
| Name | Required | Description | Default |
|---|---|---|---|
| genes | Yes | 基因列表 |
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 and scope profile is covered without the description. The description adds only a brief RETURNS line (pathway/disease/drug associations) and the 'mechanism network' framing; it says nothing about data sources, association confidence, or whether openWorldHint=false means a bundled local knowledge base. Useful but thin 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?
Front-loaded with the purpose and a clear USE WHEN clause, then aliases and return summary, so an agent can skim it. The title is repeated verbatim in Chinese and the alias list is long and partly redundant (e.g. 'network', 'gene pathway'), which is mild padding rather than noise.
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 lookup with no output schema, the definition covers what it does, when to call it, and roughly what comes back. It is complete enough to invoke correctly, with only the return structure and knowledge-base scope left implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single required parameter, 'genes', documented at 100% schema coverage, so the schema carries the burden and the baseline is 3. The description reinforces the gene-list input but adds no detail on list size, gene ID format, species, or whether duplicates/unknown symbols are tolerated.
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 chain: from a gene list, find pathway/disease/drug associations and build a mechanism network. That is far more specific than the tool name alone, and the 'network' framing separates it from plain enrichment tools. It stops short of naming a specific sibling it is not (e.g. go_kegg_enrichment or ppi_network), so it lands at 4.
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 'USE WHEN: from a gene list...' clause states the trigger condition explicitly, which is exactly the kind of context an agent needs for routing. There are no exclusions, prerequisites, or named alternatives, 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.
GEO dataset pipeline / GEO 数据全流程 | USE WHEN: end-to-end on a GEO accession: DEG → enrichment → immune infiltration | ALIASES: GEO, GSE, 数据集分析, GEO编号, geo dataset, public data reanalysis | RETURNS: 差异基因、富集结果
| Name | Required | Description | Default |
|---|---|---|---|
| geo_id | Yes | GEO 数据集编号，如 GSE12345 | |
| species | No | 物种：human/mouse | |
| pval_cutoff | No | P 阈值 | |
| logfc_cutoff | No | logFC 阈值 |
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 non-destructive, non-network-bound profile is covered. The description adds only a partial return hint (差异基因、富集结果) and says nothing about runtime expectations, data download behavior, or whether intermediate results are persisted for a three-stage pipeline.
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 pipe-delimited USE WHEN / ALIASES / RETURNS layout is front-loaded and easy to scan, with no redundancy. The bilingual aliases block is somewhat noisy but serves retrieval, so the wording largely earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a composite three-stage pipeline with no output schema, the definition is thin: it does not say what artifacts come back beyond '差异基因、富集结果', omitting the immune infiltration output that the USE WHEN clause promises. An agent can invoke it but cannot predict runtime, intermediate files, or defaulted parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with geo_id, species, pval_cutoff and logfc_cutoff all documented inline, so the baseline of 3 applies. The description adds no semantics beyond the schema — no defaults for species or the cutoffs, and no statement that the cutoffs govern the DEG stage specifically.
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 (a GEO accession) and enumerates the pipeline stages: DEG → enrichment → immune infiltration, so an agent knows this is an end-to-end multi-step analysis rather than a single computation. However, it never distinguishes itself from related siblings such as differential_expression, rnaseq_deg, or go_kegg_enrichment, which perform individual stages of the same workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"USE WHEN: end-to-end on a GEO accession" gives a concrete selection condition that separates whole-pipeline runs from single-step tools. It stops short of stating when NOT to use it (e.g. when only DEGs are wanted, use differential_expression instead) and names no alternative sibling explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gleason grade group / Gleason 分级分组 | USE WHEN: Gleason score → Grade Group and risk stratum (prostate cancer) | ALIASES: Gleason, 前列腺癌分级, Grade Group, 格里森评分, 前列腺病理 | RETURNS: Grade Group 与风险分层
| Name | Required | Description | Default |
|---|---|---|---|
| primary_grade | Yes | 主要分级 1-5 | |
| secondary_grade | Yes | 次要分级 1-5 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish this as a safe, closed-world, side-effect-free read, so the description doesn't need to re-state safety. It adds that a risk stratum is produced alongside the Grade Group, but it does not disclose the mapping logic (e.g. how 3+4 vs 4+3 are grouped) or how ambiguous inputs such as grades outside 1–5 are handled — relevant for a scoring tool whose whole value is the rule it applies.
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 pipe-delimited USE WHEN / ALIASES / RETURNS layout is front-loaded and scans quickly, with zero filler sentences. The bilingual alias list is long but serves recall for Chinese-language queries, which is a legitimate use of space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a deterministic two-parameter calculator with no output schema, the description states the inputs and names both return values (Grade Group and risk stratum), which is enough to call it correctly. Only the grouping rules and input validation behaviour are left implicit, a minor gap given the tool's simplicity.
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%: both parameters are documented as 1–5 primary and secondary grades, so the schema carries the semantics. The description contributes nothing further about the parameters (no note on ordering, defaults, or whether a single composite score is accepted), which is the baseline case rather than an added-value case.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The 'USE WHEN' clause names the exact transformation: Gleason score in, Grade Group plus risk stratum out, scoped to prostate cancer. That is a specific input→output operation with a concrete domain, and it is unmistakably distinct from neighbouring pathology/statistics tools such as fibrosis_staging or ihc_hscore.
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 explicitly ('USE WHEN: Gleason score → Grade Group'), so an agent knows exactly which query routes here. It stops short of exclusions or naming an alternative tool (e.g. for whole-pathology staging), which is the only gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GO / KEGG enrichment / 通路富集（GO/KEGG） | USE WHEN: pathway enrichment for a gene list (GO biological process, KEGG) | ALIASES: 富集分析, GO, KEGG, 通路富集, enrichment, 通路, 功能注释 | RETURNS: 富集通路与 P 值
| Name | Required | Description | Default |
|---|---|---|---|
| db_filter | No | 数据库：GO_BP/GO_CC/GO_MF/KEGG | |
| gene_list | Yes | 基因列表 | |
| project_id | No | 项目 id |
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 by structured data. The description adds only a light return hint ('富集通路与 P 值'), and says nothing about the statistical procedure, multiple-testing correction, background gene set, or species assumptions, all of which materially affect interpretation of an enrichment result.
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 pipe-delimited layout is front-loaded with the actionable USE WHEN clause, which is good. However, the ALIASES line is keyword padding ('富集分析, 通路, 功能注释') that conveys no operational information, and the title is duplicated twice as the first segment and the title field.
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, single-required-parameter tool with no output schema, the description covers purpose and a rough return shape. It omits what an agent most needs before calling: expected gene identifier format (symbol vs. Entrez), organism scope, and how P values are adjusted, which are common failure points for enrichment 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%, and each of the three parameters (db_filter, gene_list, project_id) is already documented in the schema, including the GO_BP/GO_CC/GO_MF/KEGG vocabulary. The description mentions the gene list but adds no format or identifier-convention detail, 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 title line and the USE WHEN clause state a specific verb and resource: pathway enrichment (GO biological process / KEGG) over a supplied gene list. An agent can tell what it produces, but the description never distinguishes it from nearby siblings such as protein_enrichment, gene_pathway_disease, or metabolite_pathway, so the boundary is left to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'USE WHEN: pathway enrichment for a gene list' clause gives a clear triggering condition, which is the main routing cue an agent needs. It stops short of exclusions or named alternatives, so 5 is not warranted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
IC50 curve fitting / IC50 曲线拟合 | USE WHEN: fit a dose-response curve and report IC50 with 95% CI | ALIASES: IC50, 半数抑制浓度, 剂量效应曲线, dose response, 抑制率拟合, GI50 | RETURNS: IC50 值与 95%CI
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | 拟合模型：4PL/3PL | |
| direction | No | inhibition 或 activation | |
| responses | Yes | 响应/抑制率 | |
| concentrations | Yes | 浓度序列 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a read-only, non-destructive, closed-world computation, so the safety profile is covered. The description's main added value is stating the return payload (IC50 with 95% CI), but it says nothing about how the model choice affects results, default model behavior, or what happens with insufficient/degenerate data points.
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 pipe-delimited layout front-loads the purpose, then trigger, aliases, and return value in a compact block with no filler sentences. It is efficient, though the alias dump is longer than strictly needed for tool selection.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter computation tool with a fully documented schema and no output schema, the description correctly states the return value, which fills the main gap. It still omits practical requirements such as minimum number of concentration points, model defaulting, and how direction is inferred, which matter 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%, with every parameter (model, direction, responses, concentrations) documented in Chinese, so the baseline is 3. The description adds no syntax, default values, or constraints beyond the schema, and notably does not clarify what 'direction: inhibition vs activation' does to the fitted result.
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 combination ('fit a dose-response curve and report IC50 with 95% CI'), which tells an agent exactly what the tool produces. It stops short of distinguishing itself from nearby siblings such as calibration_curve or cell_assay_calc, so it is clear but not fully 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?
The explicit 'USE WHEN: fit a dose-response curve and report IC50 with 95% CI' gives a concrete trigger condition, and the ALIASES list clarifies the vocabulary users may bring (IC50, GI50, dose response, 抑制率拟合). No when-not-to-use or named alternative is offered, so it falls short of the top band.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
IHC scoring (H-score / Allred) / IHC 免疫组化评分 | USE WHEN: immunohistochemistry scoring from staining intensity percentages (H-score, Allred, positive rate) | ALIASES: 免疫组化评分, H-score, Allred, IHC, 阳性率, 染色评分, ER PR HER2 | RETURNS: H-score / Allred / 阳性率
| Name | Required | Description | Default |
|---|---|---|---|
| stain_type | Yes | 染色类型 | |
| intensity_0_pct | No | 0 级占比(%) | |
| intensity_1_pct | No | 1+ 占比(%) | |
| intensity_2_pct | No | 2+ 占比(%) | |
| intensity_3_pct | No | 3+ 占比(%) |
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 agent knows this is a closed-world, side-effect-free computation. The description adds that results are computed rather than looked up (RETURNS line naming the three derived scores), but says nothing about handling of percentages that do not sum to 100, validation failures, or which score applies to which stain_type. With annotations carrying the safety profile, this is adequate 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 definition is compact and pipe-delimited with front-loaded USE WHEN and RETURNS segments, which makes it easy to scan. It is also somewhat template-like: the header line repeats the title verbatim and the bilingual aliases pad the text without adding selection signal beyond the first few terms.
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 five-parameter, single-purpose calculator with full schema coverage and a read-only annotation set, the description covers what it computes and what it returns. The remaining gap is that the accepted stain_type values and the arithmetic constraint on the intensity percentages are unstated in both the description and the schema, which matters for a scoring 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% and the schema labels the parameters (stain_type, intensity_0_pct through intensity_3_pct) with units as percentages. The description adds real value by tying those intensity buckets to the named scoring systems (H-score, Allred, positive rate), so the agent understands why the 0/1+/2+/3+ split is required. It does not state whether percentages must sum to 100 or what stain_type values are accepted.
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 analytical operation (immunohistochemistry scoring) and enumerates the concrete outputs it produces (H-score, Allred, positive rate), which distinguishes it from nearby siblings like gleason_grade_group or mif_phenotype. It stops short of explicitly contrasting itself with those siblings, but the domain vocabulary is specific enough for an agent to pick it correctly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'USE WHEN: immunohistochemistry scoring from staining intensity percentages' gives an implied trigger condition tied to input data shape, which is more than a bare purpose statement. However, there is no when-not guidance and no mention of alternatives, so an agent facing borderline cases (e.g. a categorical stain readout or an image-based nuclei count) must infer the boundary itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
IPTW inverse probability weighting / IPTW 逆概率加权 | USE WHEN: propensity-score weighting (ATE/ATT) for observational comparisons | ALIASES: IPTW, 逆概率加权, 倾向评分加权, propensity weighting, 加权后效应, ATE | RETURNS: 权重与加权后效应
| Name | Required | Description | Default |
|---|---|---|---|
| treatment | Yes | 处理分组 0/1 | |
| propensity_scores | Yes | 倾向评分 |
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 only the return payload ('权重与加权后效应'), and says nothing about weight stabilization/trimming, handling of extreme or zero propensity scores, or whether propensity scores must be precomputed externally.
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?
Compact, front-loaded tag structure with no filler prose; purpose, trigger, aliases and return value come in that order. Minor redundancy: 'IPTW' and '逆概率加权' are repeated in the ALIASES block after already appearing in the title and first line.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter, non-destructive read tool with no output schema, the definition covers purpose, trigger and return shape. What is missing is the pipeline context — that propensity scores must already be estimated elsewhere — plus any statement of what the weighted-effect output contains beyond the one-word '权重与加权后效应'.
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 parameters are documented in the schema ('处理分组 0/1', '倾向评分'), so the baseline applies. The description adds no extra meaning about the required array alignment, length equality, or the coding of the treatment vector 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?
States a specific named method (IPTW inverse probability weighting) plus the effect estimands (ATE/ATT) and the analysis context (observational comparisons). An agent can distinguish it from the sibling propensity_score_matching by the 'weighting' vs 'matching' framing, though the sibling is never named.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'USE WHEN: propensity-score weighting (ATE/ATT) for observational comparisons' gives a clear triggering context, which is more than most siblings offer. However, it gives no when-not guidance and never names propensity_score_matching as the alternative to pick when matching is wanted instead of weighting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Journal recommendation / 智能选刊 V3 | USE WHEN: recommend target journals from title/abstract, in reach / match / safe tiers | ALIASES: 选刊, 投哪个期刊, 期刊推荐, journal, submission target, 冲稳保, 投稿建议 | RETURNS: 候选期刊与三档策略
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | 论文标题 | |
| design | No | 研究设计 | |
| abstract | No | 摘要 | |
| keywords | No | 关键词 | |
| sample_size | No | 样本量 | |
| target_tier | No | 目标档次 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered; the description adds value by disclosing the return shape ('候选期刊与三档策略') in the absence of an output schema. It does not mention limits, latency, or how tiers are computed, so it stops short of rich behavioral detail.
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 pipe-delimited layout is scannable and front-loads the usage condition before aliases and return info. The alias list is somewhat long but serves a real routing purpose for mixed-language queries; 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 read-only, 6-parameter tool with full schema coverage and no output schema, the description covers what it does, when to invoke it, and roughly what comes back. Only tier semantics and any input requirements beyond title remain unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all six parameters are already documented in the schema. The description only reinforces that title/abstract drive the recommendation, adding no syntax, format, or constraint detail beyond that. 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 (recommend target journals) and scopes the input to title/abstract, which distinguishes it from literature-oriented siblings like pubmed_search or citation_verify. The leading 'Journal recommendation / 智能选刊 V3' merely restates the name, but the USE WHEN clause carries the real specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'USE WHEN: recommend target journals from title/abstract' gives a clear triggering context, and the tier vocabulary (reach/match/safe) tells the agent what kind of output to expect. It does not name an alternative tool or state exclusions, which keeps it below a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Kaplan-Meier curve / Kaplan-Meier 曲线 | USE WHEN: KM curve and median survival only (no multivariable model) | ALIASES: KM曲线, Kaplan-Meier, 中位生存, 生存曲线, 生存率, log-rank | RETURNS: KM 曲线与中位生存
| Name | Required | Description | Default |
|---|---|---|---|
| times | Yes | 随访时间 | |
| events | Yes | 事件 0/1 | |
| groups | No | 分组 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered without the description's help. The description adds a RETURNS line naming the outputs (curve + median survival), which is useful, but says nothing about whether a plot is produced, what test accompanies group comparisons, or what happens when 'groups' is omitted. Listing 'log-rank' among the aliases hints at hypothesis testing without confirming it - mildly ambiguous rather than contradictory.
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 pipe-delimited USE WHEN / ALIASES / RETURNS layout is front-loaded and scannable, with the gating condition appearing before the keyword list. The bilingual title repetition and the long alias list are mild padding, but the alias list plausibly serves retrieval matching, so little is pure 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?
With no output schema, the RETURNS line is the only signal about results, and it is too terse for a statistics tool - it does not say whether a figure, a table of survival probabilities, or confidence intervals come back. For a three-parameter analysis tool whose 'groups' argument changes the analysis performed, the definition is adequate but leaves real gaps about the grouped/log-rank behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all three parameters documented (随访时间, 事件 0/1, 分组) plus a worked example, so the schema carries the semantics. The description adds no parameter-level meaning - notably it does not explain that supplying 'groups' triggers a between-group comparison or how event coding interacts with times - leaving 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 names a specific statistical resource (KM curve plus median survival) and the Chinese title/aliases reinforce the resource identity. It also distinguishes itself from the Cox/multivariable sibling by scoping to 'no multivariable model', though it never names the competing sibling tools (survival_cox, animal_survival_km) 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?
'USE WHEN: KM curve and median survival only (no multivariable model)' gives an explicit positive condition and an implicit exclusion boundary that steers agents toward the Cox model when adjustment is needed. It stops short of naming the alternative tool or covering the overlapping animal_survival_km sibling, so routing still requires inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Linear mixed model (repeated measures) / 线性混合模型（纵向/重复测量，公式模式） | USE WHEN: same subject measured repeatedly (pre/post, multiple follow-ups): compare trajectories over time, group×time interaction; modern replacement for repeated-measures ANOVA (handles missing, no sphericity assumption) | ALIASES: 混合模型, 重复测量, 纵向数据, LMM, mixed model, 交互作用, 多次随访, 每人测多次, repeated measures | RETURNS: 固定效应系数/SE/Wald z/P/95%CI（按真实变量名，不是 X1/X2）、各项整体检验 omnibus、交互项检验、primary_test、ICC、方差成分、n_subjects/n_obs、组间例数、缺失与收敛告警
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | 长格式数据：每行一次观测 [{受试者ID, 分组, 时点, 结局}, ...]；也接受列式 {列名: [值, ...]}。注意必须是**长表**（每行一次测量），不是每人一行多列 | |
| reml | No | 默认 true（REML） | |
| formula | Yes | R 风格公式，如 '收缩压 ~ 分组 * 时点'（组×时间交互）；左端=结局 | |
| subject | Yes | 受试者/病案号列名（随机截距的分组依据） | |
| reference | No | 参照水平，如 {"分组": "对照组"} —— 报告表里「与对照组相比」必须是它 | |
| re_formula | No | 随机效应，默认 '1'（随机截距）；随机斜率用 '1 + 时点' | |
| categorical | No | 显式声明哪些列按分类处理（如 ["分组"]）；数值编码的 0/1 分组必须声明，否则会被当连续变量 | |
| time_values | No | 把字符串时点映射成数值以估线性趋势，如 {"时点": {"基线":0,"4周":1,"12周":2}} |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish a safe read-only, closed-world computation, so the description's job is to add analytic behavior — and it does, enumerating fixed-effect coefficients/SE/Wald z/P/95%CI reported under real variable names, omnibus tests, interaction test, primary_test, ICC, variance components, n_subjects/n_obs, group counts, and warnings for missingness and convergence. It notably discloses that missing data are handled and flags convergence issues, which matters for interpreting results. It does not state assumptions beyond sphericity or describe failure modes/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 piped sections (USE WHEN / ALIASES / RETURNS) are front-loaded and scannable, with the highest-value routing information first. The bilingual duplication and the long ALIASES list are somewhat padded, but they serve retrieval matching rather than displacing substance.
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 8 parameters, nested objects, no enums, and no output schema, the description compensates by spelling out the return payload in detail, which is exactly what an agent needs to decide whether to call it and how to read results. Combined with rich schema descriptions for every parameter, only minor gaps remain (no explicit refusal/validation behavior, no note on minimum group sizes).
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 each of the 8 parameters already carries a substantive description (long-format requirement, formula syntax, reference levels, re_formula defaults, categorical declaration for 0/1-coded groups). The prose description adds essentially no parameter-level guidance beyond what the schema states, 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 method and analytic scope: a linear mixed model in formula mode for repeated measures/longitudinal data, with the explicit goal of comparing trajectories and group×time interaction. It also positions it against a named alternative class ('modern replacement for repeated-measures ANOVA'), so an agent can distinguish it from siblings like two_way_anova without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'USE WHEN' clause gives a clear triggering condition (same subject measured repeatedly: pre/post, multiple follow-ups) and the analytic goal (trajectory comparison, group×time interaction), plus the conditions favoring it over RM-ANOVA (missing data, no sphericity assumption). It stops short of naming concrete sibling tools (e.g., two_way_anova, dunn_posthoc) or stating when not to use it, so an agent still has to infer sibling routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Literature search (1.53M PMC full texts) / 文献检索（站内 153 万篇 PMC） | USE WHEN: search the in-house PMC corpus for literature / evidence / state of the art | ALIASES: 找文献, 文献检索, 检索文献, literature search, PMC, 证据, 研究现状, PubMed替代 | RETURNS: 文献列表（含 PMCID）
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | 检索词（英文效果更好） | |
| limit | No | 返回条数 |
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 and closed-corpus nature are covered. The description adds the corpus size and the return shape ('文献列表（含 PMCID）'), which is useful since no output schema exists, but it says nothing about relevance ranking, pagination, or defaults for limit.
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 pipe-delimited USE WHEN / ALIASES / RETURNS layout is front-loaded and scannable, with no filler sentences. The bilingual duplication of the title and aliases adds some redundancy without new meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter, read-only search tool whose annotations cover safety and whose schema is fully documented, the description covers purpose, trigger, and return shape. Only minor gaps remain: result ordering, the default for limit, and when to prefer the PubMed sibling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both 'q' and 'limit' described in the schema, so the baseline is 3. The description adds no syntax, default, or maximum-limit guidance beyond what the schema already supplies.
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 ('Literature search') plus concrete scope ('1.53M PMC full texts', in-house corpus), so an agent knows exactly what is searched. It stops short of naming the sibling pubmed_search; the alias 'PubMed替代' only hints at the distinction rather than drawing it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'USE WHEN: search the in-house PMC corpus for literature / evidence / state of the art' gives a clear triggering context. There is no explicit when-not or direct routing to pubmed_search, so the agent must infer the boundary between the two search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Metabolite heatmap / 代谢组热图 | USE WHEN: clustered heatmap of metabolites | ALIASES: 代谢热图, 聚类热图, heatmap, metabolite heatmap | RETURNS: 聚类热图
| Name | Required | Description | Default |
|---|---|---|---|
| data_json | Yes | 必填。数据对象（不是字符串）。矩阵形式：{"matrix": [[行1各列数值...], [行2...]], "rows": ["基因/特征名"], "cols": ["样本名"]}；组学结果另可带 {"groups": ["组A","组A","组B"...]}（与 cols 一一对应）、{"p_values": [...], "log2fc": [...]}（若已有差异结果）。实测缺此字段会被拒：Field required: data_json |
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 fully covered by structured data. The description adds nothing beyond that: 'RETURNS: 聚类热图' merely repeats the tool name, and it never says whether the result is an image, an HTML widget, or a JSON payload with cluster ordering, nor whether clustering method/distance is configurable or fixed. With annotations doing the heavy lifting, this is close to zero incremental behavioral value.
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 pipe-delimited tag format is compact and front-loaded, and an agent can parse the USE WHEN and ALIASES segments quickly. There is mild redundancy: the title is repeated in the first token and 'RETURNS: 聚类热图' duplicates the tool name, and the mixed English/Chinese duplication inflates length without adding meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with a fully documented schema and no output schema, the essentials for invocation are present. What is missing is the return contract — image versus data, and how cluster labels are surfaced — which an agent needs to decide whether to call this tool or a downstream plotting step, and no output schema exists to compensate.
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 data_json property description is unusually rich, spelling out the matrix/rows/cols shape, optional groups, p_values and log2fc arrays, and the exact validation error. The description mentions no parameters at all, so it contributes nothing beyond the schema; the baseline 3 applies because the schema itself 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 the resource ('metabolite' / '聚类热图') and adds the qualifier 'clustered', which is more informative than the bare title. However, there is no verb ('generates', 'renders', 'plots') and no hint at what the output artifact is, so the agent must infer that this produces a clustered heatmap figure rather than, say, clustering assignments. Siblings such as metabolite_pca, metabolite_plsda and metabolite_volcano are not referenced at all.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'USE WHEN: clustered heatmap of metabolites' restates the tool's own function instead of describing a scenario, so it gives no real selection signal. There are no exclusions and no routing to sibling metabolite tools (e.g. PCA for dimensionality reduction, volcano for differential results), which is a notable gap given the dense metabolite_* family.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Metabolite pathway enrichment / 代谢物通路富集 | USE WHEN: pathway enrichment for differential metabolites | ALIASES: 代谢物通路, 代谢富集, metabolite pathway, KEGG代谢, 差异代谢物 | RETURNS: 代谢通路富集
| Name | Required | Description | Default |
|---|---|---|---|
| metabolites | Yes | 代谢物列表 | |
| fdr_threshold | No | FDR 阈值 |
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. Beyond that the description adds nothing behavioral: the 'RETURNS: 代谢物通路富集' line just restates the tool name, and it never discloses the reference database, statistical model behind the FDR threshold, or required identifier format (no organism/ID-type parameter exists, which is a notable omission the description does not explain).
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 pipe-delimited template is front-loaded and scannable, so it is not verbose in absolute terms. However, the title is duplicated verbatim at the start, the ALIASES block is mostly search-bait, and the RETURNS field consumes space without conveying 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?
For a two-parameter, non-destructive analysis tool with full schema coverage and annotations, the agent can decide when to call it. What is still missing is input-format guidance for the metabolite list and any indication of what the enrichment result contains, which matters because there is no output schema to fall back on.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (代谢物列表, FDR 阈值) documented inline, so the schema carries the parameter burden and baseline 3 applies. The description adds no meaning beyond it — notably it never says what identifier system the metabolite list should use, which is the one thing the schema does not settle.
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: 'pathway enrichment' over 'metabolites', which distinguishes it from the protein and gene/KEGG enrichment siblings (protein_enrichment, go_kegg_enrichment) by analyte type. It does not explicitly name those siblings or state the contrast, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'USE WHEN: pathway enrichment for differential metabolites' gives a clear triggering context, and the alias list (差异代谢物, KEGG代谢) helps match user phrasing. There is no when-not guidance and no pointer to the neighboring metabolite tools (metabolite_volcano, metabolite_heatmap, metabolite_pca), which the agent must route between on its own.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Metabolite PCA / 代谢组 PCA | USE WHEN: sample separation / outliers in metabolomics (unsupervised) | ALIASES: 代谢组PCA, PCA, 样本分组趋势, 离群, unsupervised, 得分图 | RETURNS: PCA 得分与解释度
| Name | Required | Description | Default |
|---|---|---|---|
| groups | No | 分组标签 | |
| data_json | Yes | 代谢物矩阵 |
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 that results are PCA scores and explained variance, but says nothing about preprocessing/scaling assumptions, minimum sample requirements, or input orientation for the nested matrix.
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 compact, front-loaded metadata line with USE WHEN and RETURNS before the alias list; no filler prose. The ALIASES string is long and mostly redundant keyword padding, but it is placed last and does not obscure the actionable content.
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 statistical tool with annotations covering safety and no output schema, the description does cover the purpose and the return concept. It still leaves gaps an agent would want: expected matrix orientation, whether 'groups' is required for coloring only, and what happens with missing values or too few samples.
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 reported at 100%, so the baseline is 3 even though the description itself says nothing about 'data_json' or 'groups'. The schema labels are terse ('代谢物矩阵', '分组标签') and the nested object shape is undefined, so the description could have added real value here but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The name plus the USE WHEN clause conveys a specific analysis: unsupervised PCA on a metabolomics matrix, aimed at sample separation and outlier detection. The parenthetical '(unsupervised)' implicitly separates it from supervised siblings such as metabolite_plsda, 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?
USE WHEN gives a concrete triggering scenario ('sample separation / outliers in metabolomics') and a method qualifier ('unsupervised'), which is enough for an agent to prefer it over plsda or volcano-style tools. There is no explicit when-not guidance or named alternative, which keeps it out of the top band.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Metabolite PLS-DA / 代谢组 PLS-DA | USE WHEN: supervised discrimination and VIP for differential metabolites | ALIASES: PLS-DA, 有监督判别, VIP, 代谢组判别, 判别分析 | RETURNS: PLS-DA 模型与 VIP
| Name | Required | Description | Default |
|---|---|---|---|
| groups | No | 分组标签 | |
| data_json | Yes | 代谢物矩阵 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly=true, destructive=false, openWorld=false, so safety is covered. The description adds the return payload (model and VIP), but says nothing about input requirements such as needing ≥2 groups, group labels aligning with matrix columns, or whether the tool validates the design.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded pipe-delimited format with USE WHEN before RETURNS is easy to scan. The ALIASES segment lists six near-synonyms that add little selection value and consume space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the RETURNS line is necessary and useful. However, for a nested-object input with grouping semantics, the description omits the input contract entirely, leaving the agent to guess orientation and label alignment.
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 baseline 3 applies. The description contributes nothing about data_json structure (samples vs. metabolites orientation) or the relationship between groups and data_json columns, which is the main ambiguity in a two-parameter design tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific method and its discriminative outputs ("supervised discrimination and VIP"), plus a returns clause naming the model and VIP values. It does not explicitly contrast with the nearest sibling, metabolite_pca (unsupervised), so the agent must infer the supervised/unsupervised split from the word "supervised".
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 USE WHEN clause gives clear triggering conditions: supervised discrimination plus VIP extraction for differential metabolites. It offers no exclusions or named alternatives (e.g. 'use metabolite_pca for unsupervised structure'), which keeps it below a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Metabolite volcano plot / 代谢组火山图 | USE WHEN: volcano plot of differential metabolites | ALIASES: 代谢火山图, volcano, 差异代谢物火山图 | RETURNS: 火山图
| Name | Required | Description | Default |
|---|---|---|---|
| data_json | Yes | 必填。数据对象（不是字符串）。矩阵形式：{"matrix": [[行1各列数值...], [行2...]], "rows": ["基因/特征名"], "cols": ["样本名"]}；组学结果另可带 {"groups": ["组A","组A","组B"...]}（与 cols 一一对应）、{"p_values": [...], "log2fc": [...]}（若已有差异结果）。实测缺此字段会被拒：Field required: data_json |
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 description only needed to add context. Instead it offers just "RETURNS: 火山图," which does not clarify whether the output is an image, a file path, base64 data, or a plot specification — with no output schema, that gap matters.
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 short and pipe-delimited, but the ALIASES segment (代谢火山图, volcano, 差异代谢物火山图) consumes space without helping an agent decide or invoke. The content is front-loaded, yet the brevity comes from under-specification rather than tight editing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that takes a nested, structurally strict data object and produces a plot, the description says nothing about expected data shape, statistical requirements, or the return value. The rich schema compensates for input details, but the output side is undocumented anywhere, leaving the definition incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter exists and the schema describes it at 100% coverage, including matrix shape, rows/cols mapping, optional groups, and p_values/log2fc, plus the exact validation error for a missing field. The description adds no meaning beyond that, 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 does identify the operation as a volcano plot of differential metabolites, which distinguishes it from siblings such as metabolite_heatmap, metabolite_pca, and metabolite_plsda. However, most of the text restates the title and name, and the substantive scope (what input it accepts, what it computes) is left unstated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"USE WHEN: volcano plot of differential metabolites" is a bare trigger phrase that largely repeats the tool name. There is no mention of when NOT to use it, no prerequisites (e.g. need p-values and log2fc), and no routing to siblings like metabolite_heatmap or metabolite_pathway for adjacent analyses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Multiplex IF phenotyping / 多重免疫荧光表型 | USE WHEN: assign cell phenotypes and proportions from multiplex immunofluorescence markers | ALIASES: 多重免疫荧光, mIF, 细胞表型, phenotype, marker组合, 亚群比例 | RETURNS: 细胞亚群表型与比例
| Name | Required | Description | Default |
|---|---|---|---|
| cd3_pos | No | CD3+ 数 | |
| cd8_pos | No | CD8+ 数 | |
| foxp3_pos | No | FoxP3+ 数 | |
| pd_l1_pos | No | PD-L1+ 数 |
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 only that it returns cell-subset phenotypes and proportions; it does not say what happens with partial marker input, how proportions are computed, or what the result structure looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The pipe-delimited format is front-loaded and easy to scan: purpose, use condition, aliases, and return summary. The repeated bilingual title and the long alias list add some noise but do not obscure the key 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?
For a simple read-only tool with four clearly documented optional numeric parameters and no output schema, the definition is minimally adequate. However, it leaves open how the optional markers combine and what the returned phenotype/proportion object contains, which matters for correct invocation and interpretation.
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 each of the four marker-count parameters documented in the schema. The description adds no further meaning such as units, expected ranges, or whether any marker subset is required, 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 states a specific verb and resource: 'assign cell phenotypes and proportions from multiplex immunofluorescence markers.' An agent can tell this is a phenotyping/proportion calculator, though it does not name or contrast any sibling tool (e.g., flow_cluster, tumor_microenvironment, scrna_annotate) that could overlap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'USE WHEN' clause gives a clear trigger condition, but it largely restates the purpose rather than specifying exclusions or alternatives. There is no guidance on when to prefer this over related siblings such as flow_cluster or tumor_microenvironment, so an agent must infer the boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Multi-omics integration / 多组学整合 | USE WHEN: integrate mRNA / protein / metabolite layers and find cross-layer associations | ALIASES: 多组学, 整合分析, multi-omics, 转录组蛋白组代谢组, cross-omics | RETURNS: 多组学关联结果
| Name | Required | Description | Default |
|---|---|---|---|
| mrna | No | mRNA 列表 | |
| protein | No | 蛋白列表 | |
| metabolite | No | 代谢物列表 | |
| pathway_map | No | 通路映射方式 |
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 only offers 'RETURNS: 多组学关联结果', which gives no real information about output structure, statistical method, or what happens when only some layers are supplied. Almost nothing is added beyond structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The pipe-delimited metadata format keeps it short and the USE WHEN clause is front-loaded, but the bilingual title duplicates the tool title field and the ALIASES segment consumes space without helping tool selection. Signal-to-noise is mediocre rather than 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?
All four parameters are optional, there is no output schema, and the description never states minimum input requirements or what the association result contains. For a multi-layer analysis tool that can be invoked with zero arguments, that omission is the main completeness gap, though the fully documented schema mitigates it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3: each of mrna, protein, metabolite and pathway_map is documented in the schema. The description adds no meaning beyond those field labels — notably it does not explain accepted 'pathway_map' modes or whether at least two layers are required.
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 specific operation and domain: integrating mRNA/protein/metabolite layers to find cross-layer associations, which is more than a restatement of the name. It does not, however, distinguish itself from adjacent siblings such as metabolite_pathway, go_kegg_enrichment, ppi_network or protein_enrichment, so an agent must infer the boundary 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?
The 'USE WHEN' clause gives a usable trigger condition (multiple omics layers plus a cross-layer association goal), but it essentially paraphrases the purpose and offers no when-not guidance, no prerequisites, and no named alternative tools. The long alias list ('多组学, 整合分析, cross-omics') is matching noise rather than usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Nomogram / 列线图 Nomogram | USE WHEN: turn a logistic or Cox model into a nomogram figure for clinical use | ALIASES: 列线图, Nomogram, 评分图, nomogram, 风险评分图 | RETURNS: 列线图 SVG
| Name | Required | Description | Default |
|---|---|---|---|
| csv_data | No | CSV 文本 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish this as a non-destructive, read-only, closed-world operation, and the description correctly adds the output format ("RETURNS: 列线图 SVG"), which matters because there is no output schema. However, it never explains how the Cox/logistic model is meant to be supplied — the schema only offers a single CSV field — leaving a real behavioral gap for a figure-generation 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?
Pipe-delimited, front-loaded, and every segment conveys something (trigger, aliases, return type). The repeated tool name in the header and the four near-duplicate aliases are slightly redundant but serve search matching.
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 no output schema, stating the return type as SVG is genuinely useful and covers the output side. The input side is incomplete: for a single-CSV-parameter tool the description should indicate what that CSV must be for a model-to-nomogram conversion to succeed.
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% with a single optional parameter, so baseline 3 applies. The description adds nothing about what the CSV must contain (coefficients? training rows? column naming?), which is precisely the information the terse "CSV 文本" schema description does not supply.
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?
"Turn a logistic or Cox model into a nomogram figure for clinical use" is a specific verb + resource + scope statement, so the agent knows exactly what the tool produces. It stops short of naming a sibling (e.g. forest_plot, calibration_curve) that an agent might confuse it with, which keeps it out of 5 territory.
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 "USE WHEN" clause gives a clear triggering condition: when you already have a logistic or Cox model and want a clinical nomogram figure. There are no explicit exclusions or alternative-tool routing, so the agent must infer that model fitting itself belongs to survival_cox or stats_toolbox.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Nuclei segmentation & counting / 细胞核分割与计数 | USE WHEN: cell density / positive rate from a tissue section (nuclei segmentation) | ALIASES: 细胞核分割, 细胞计数, 密度, nuclei count, segmentation, 阳性细胞率 | RETURNS: 分割统计结果
| Name | Required | Description | Default |
|---|---|---|---|
| stain_type | No | 染色类型 | |
| cell_density | No | 细胞密度 | |
| positive_rate | No | 阳性率 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (read-only, non-destructive, closed-world), so the description only needs to add operational context. It adds 'RETURNS: 分割统计结果', which is vague boilerplate rather than a described output, and it never clarifies whether cell_density/positive_rate are inputs to be supplied or results this tool produces — a meaningful ambiguity for a counting tool. It does not contradict 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 pipe-delimited layout is front-loaded and scannable, with purpose first, then use-when, aliases, and returns. The bilingual duplication and a long alias list (including generic terms like 密度/segmentation) add some noise but the whole thing stays 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 three optional parameters, no output schema, and rich annotations, the definition is close to sufficient, but it omits the one thing an agent most needs here: what the tool actually consumes and what statistics come back. 'RETURNS: 分割统计结果' does not convey the return shape, and no prerequisite about image/section input is given.
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 and the schema already names all three parameters. The description adds no format, units, or valid-range guidance for stain_type, cell_density, or positive_rate, and leaves unresolved whether the numeric fields are inputs or expected outputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb+resource: 'Nuclei segmentation & counting', reinforced by the Chinese title and a use-case tagline about cell density / positive rate from a tissue section. It is distinguishable from most nearby siblings (ihc_hscore, mif_phenotype), though the overlap with quantitative-imaging tools is not explicitly addressed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'USE WHEN: cell density / positive rate from a tissue section' gives one concrete trigger condition, which is better than nothing. However, there are no exclusions and no named alternatives for closely related siblings like ihc_hscore, mif_phenotype, or tumor_microenvironment, so the agent must infer boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ORF prediction / ORF 预测 | USE WHEN: find open reading frames in a nucleotide sequence | ALIASES: ORF, 开放阅读框, 找编码区, open reading frame, 翻译起始 | RETURNS: ORF 列表与位置
| Name | Required | Description | Default |
|---|---|---|---|
| sequence | Yes | 核酸序列 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a read-only, non-destructive, closed-world operation. The description adds that it returns an ORF list with positions, but it does not disclose ORF criteria such as minimum length, genetic code, or strand handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose and structured using labeled sections. The bilingual aliases add some length but support matching and do not obscure the core usage condition.
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-only tool with no output schema, the description supplies the use case and states that results include ORF positions. It is sufficient for invocation, though it could be more complete about ORF detection defaults.
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 sole parameter is documented as a nucleic acid sequence. The description restates that the tool operates on a nucleotide sequence but adds no further parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: finding open reading frames in a nucleotide sequence. It distinguishes the task from related tools like dna_translate through the explicit ORF focus, though it does not name sibling alternatives directly.
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 'USE WHEN' clause gives a clear condition for invoking the tool: finding open reading frames in a nucleotide sequence. It lacks explicit when-not guidance or named alternatives, but the intended context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Organ coefficient / 脏器系数 | USE WHEN: organ weight / body weight ratio (脏器系数) | ALIASES: 脏器系数, 器官系数, organ coefficient, organ index, 脏器重量比 | RETURNS: 脏器系数
| Name | Required | Description | Default |
|---|---|---|---|
| label | No | 脏器名 | |
| body_weights | No | 体重 | |
| organ_weights | No | 脏器重 |
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 and the description is not expected to repeat it. What it should add — the formula (is the ratio multiplied by 100?), unit assumptions for body_weights vs organ_weights, and behavior when all-optional arrays are omitted — is entirely absent; 'RETURNS: 脏器系数' merely restates the tool 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?
The pipe-delimited, front-loaded format is easy to scan and the whole text is short. However, '脏器系数' appears three times (name, USE WHEN, RETURNS) and the RETURNS field conveys no information, so several tokens are pure repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With three parameters that are all optional and no output schema, the description must explain what a call with missing arrays does and what shape the result takes. It does neither — 'RETURNS: 脏器系数' does not tell the agent whether it receives a scalar, a list, or a labeled table — so an agent cannot confidently invoke it without 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 description coverage is 100%, with label/body_weights/organ_weights each documented in Chinese, so the baseline of 3 applies. The description contributes nothing extra — notably it does not clarify the expected array-length pairing between body_weights and organ_weights, which is the one semantic risk an agent would want resolved.
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 exact quantity computed — 'organ weight / body weight ratio (脏器系数)' — which is a specific, unambiguous resource distinct from every listed sibling (dose volume, tumor volume, organ-adjacent tools). It is not a generic restatement of the name, though it never contrasts itself with near neighbors like tumor_growth_inhibition.
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 'USE WHEN' clause supplies a trigger condition, but that condition ('organ weight / body weight ratio') is simply the definition of the tool, so it adds no real selection guidance. There are no when-not conditions, no prerequisite data requirements, and no named alternatives, leaving usage only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PCR primer design / PCR 引物设计 | USE WHEN: design PCR primer pairs from a DNA sequence or gene (Tm, GC, product size) | ALIASES: 引物设计, PCR引物, primer, 设计引物, 扩增引物, primer pair | RETURNS: 候选引物对与 Tm/GC
| Name | Required | Description | Default |
|---|---|---|---|
| gene | No | 基因名（无序列时用） | |
| sequence | No | 模板 DNA 序列 |
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 that it returns candidate primer pairs with Tm/GC, but it omits design defaults, constraints, and whether the 'gene' path performs an external lookup.
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 compact and front-loads the actionable 'USE WHEN' instruction. The bilingual title and alias list add some repetition, but they are short and useful for tool matching rather than wasteful 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 low-complexity, two-parameter read-only tool, the description covers purpose, trigger, and a basic return summary. It still leaves meaningful gaps around default primer-design parameters and the logical requirement to provide either a gene or a sequence.
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 schema explicitly documents both 'gene' and 'sequence', so the baseline is 3. The description groups them as alternative input sources but does not state what happens if both are supplied or that at least one is logically required despite the empty required 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?
The description gives a specific verb and resource ('design PCR primer pairs') and names the input sources ('DNA sequence or gene') plus relevant outputs ('Tm, GC, product size'). It is clear on its own, but it does not explicitly distinguish itself from nearby siblings such as primer_tm or qpcr_bayesian_design.
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 'USE WHEN' line gives a clear triggering condition: designing PCR primer pairs from a sequence or gene. It does not provide when-not guidance or name alternatives, so an agent must infer whether primer_tm would be more appropriate for Tm-only requests.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permutation test / 置换检验 | USE WHEN: exact/permutation test when t-test assumptions fail or n is tiny | ALIASES: 置换检验, 随机化检验, permutation, 精确检验, 小样本非参数, resampling | RETURNS: 置换 P 值
| Name | Required | Description | Default |
|---|---|---|---|
| group1 | Yes | 第一组数值 | |
| group2 | Yes | 第二组数值 | |
| n_perm | No | 置换次数，默认 10000 |
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 return value ('置换 P 值') in lieu of an output schema, which is useful, but it omits behavioral details that matter for a resampling procedure: whether the p-value is one- or two-sided, whether it is exact or Monte Carlo based, and there is no seed parameter or reproducibility note.
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 pipe-delimited label/USE WHEN/ALIASES/RETURNS layout is front-loaded and scannable with no filler prose. The ALIASES block is bulk for search matching rather than agent reasoning, which is slightly wasteful but standard for this family.
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, read-only statistics tool with full schema coverage and annotations, the definition covers purpose, trigger and return value adequately. However, with no output schema it should state what the result contains beyond a p-value (test statistic, group means, CI) and clarify one- vs two-sided behavior, both of which an agent needs to report results 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 group1, group2 and n_perm (default 10000) are already documented in the schema, and the provided example shows the expected shape. The description adds nothing about parameter semantics — not the sample-size limits, array-length constraints, or the cost implications of raising n_perm — 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 names a specific statistical procedure (permutation/exact test) and signals its role versus parametric alternatives via 'when t-test assumptions fail'. It does not explicitly say it is a two-group comparison, and it never names a concrete sibling (e.g. stats_toolbox or tukey_hsd) it should be chosen over, so it stops short of full 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 'USE WHEN' clause gives an explicit trigger: assumption violations in a t-test or very small n. There is no when-not guidance (e.g. for paired data, more than two groups, or when normality holds and a t-test is preferred) and no named alternative tool, so the routing guidance is clear but one-sided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PICO refinement / PICO 精炼 | USE WHEN: turn a vague clinical question into a structured PICO (Population / Intervention / Comparator / Outcome) | ALIASES: PICO, 把问题拆开, 研究问题怎么提, refine question, 结构化问题, PICO拆解 | RETURNS: 结构化 PICO
| Name | Required | Description | Default |
|---|---|---|---|
| pico | Yes | 结构化 PICO，如 {"P":"ICU 脓毒症患者","I":"乳酸清除率","C":"常规","O":"28天病死率"} |
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 little beyond that: 'RETURNS: 结构化 PICO' restates the obvious, and it does not say whether incomplete PICO elements are rejected or auto-filled, nor whether the input is echoed or expanded.
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 piped, label-driven layout front-loads the action and is scannable at a glance. The alias list is long relative to the payload, but it serves genuine matching purposes in a bilingual routing context rather than pure noise.
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 read-only transformation tool with one fully documented nested parameter, the definition is adequate but thin. It omits any statement about what the refined output contains or how partial PICO inputs are handled, which matters given there is no output schema to fall back on.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the nested object is documented with a concrete example, so the schema carries the load. The description's only addition is expanding the PICO acronym into Population/Intervention/Comparator/Outcome, which is mildly useful decoding but no deeper than the schema's own example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete transformation ('turn a vague clinical question into a structured PICO') with the resource and output form spelled out. It implicitly distinguishes itself from design-oriented siblings like study_design_advisor, but never names one, so the boundary must be inferred from the USE WHEN clause 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?
A 'USE WHEN' clause names the triggering condition (a vague clinical question needing PICO structure), which is actionable context. There is no when-not guidance and no named alternative for cases where the question is already structured or where study design help is actually wanted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Non-compartmental PK (NCA) / NCA 非房室药代分析 | USE WHEN: non-compartmental analysis of concentration-time data: AUC, Cmax, Tmax, t1/2, CL, Vd | ALIASES: NCA, 非房室分析, 药代参数, AUC Cmax T1/2, PK parameters, 血药浓度 | RETURNS: AUC/Cmax/Tmax/T1/2/CL/Vd
| Name | Required | Description | Default |
|---|---|---|---|
| dose | No | 给药剂量 | |
| dose_unit | No | 剂量单位，如 mg/kg | |
| time_points | Yes | 时间点 | |
| concentrations | Yes | 浓度 |
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 for free. The description adds the return parameter set but omits behaviorally important facts for this variant of the tool, notably that CL and Vd cannot be computed without the optional 'dose'/'dose_unit' inputs, and gives no hint about unit conventions or handling of sparse/irregular time points.
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 piped keyword format front-loads the tool identity, then USE WHEN, ALIASES and RETURNS, so an agent can skim it quickly. The bilingual duplication is slightly redundant for a reader but serves retrieval matching, and no sentence is pure filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only four inputs and no output schema, the RETURNS line usefully stands in for a missing output schema by listing the produced metrics. However, the description never states that dose is what unlocks clearance and volume terms, nor what the response shape looks like, leaving a real gap for a tool whose main parameters are conditionally available.
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 four parameters (dose, dose_unit, time_points, concentrations) are already documented in the schema and the baseline of 3 applies. The description adds no meaning beyond the schema — it does not explain the optionality of dose or its consequence for CL/Vd, nor any length-matching requirement between time_points and concentrations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource ('Non-compartmental PK (NCA)') and enumerates the exact outputs (AUC, Cmax, Tmax, t1/2, CL, Vd), which tells an agent precisely what computation this tool performs. It stops short of naming the nearest siblings (pk_pd_assess, pkpd_simulate, bioequivalence_compare) so the boundary against those is inferred only from 'non-compartmental' 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?
The 'USE WHEN' clause gives a clear trigger condition: non-compartmental analysis of concentration-time data producing the listed parameters. There is no when-not guidance and no explicit alternative for compartmental modeling or PK/PD simulation, leaving the sibling routing to the agent's inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PK/PD assessment / PK/PD 评估 | USE WHEN: pharmacokinetic/pharmacodynamic assessment and dose projection | ALIASES: PK/PD评估, 药代药效, 剂量推算, pkpd assess, 暴露量 | RETURNS: PK/PD 评估结果
| Name | Required | Description | Default |
|---|---|---|---|
| drug_name | Yes | 药物名称 | |
| pk_params | No | 药代参数 |
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 fully covered. The description adds only 'RETURNS: PK/PD 评估结果', which conveys no behavioral content — no indication of what analyses are run, what inputs are assumed, or what the result contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The content is a pipe-delimited keyword block with title, USE WHEN, ALIASES, and RETURNS fields. The ALIASES list is retrieval-oriented stuffing that does not help an agent decide or invoke, and the remaining prose is thinner than the boilerplate around it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool whose main parameter is a free-form nested object and which returns a report with no output schema, the description should indicate which PK parameters are expected (e.g., CL, V, dose, route) and what an assessment yields. Instead only a title/keyword header is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the two top-level parameters, so the baseline is 3. The description adds nothing beyond the schema, and notably the nested 'pk_params' object is an untyped bag with no inner property definitions — the description does not compensate for that opacity.
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 'USE WHEN' clause names a verb+domain ('pharmacokinetic/pharmacodynamic assessment and dose projection'), which advances slightly past the name, but it never says what an assessment produces or how it differs from closely related siblings such as pk_nca, pkpd_simulate, and species_dose_convert. 'PK/PD 评估' largely restates the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is an explicit when-to-use trigger ('pharmacokinetic/pharmacodynamic assessment and dose projection'), which is more than most definitions offer. But no exclusion or alternative routing is given, and in a toolset containing pk_nca, pkpd_simulate, and renal_dose_adjust an agent has no basis for choosing this one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PK/PD simulation / PK/PD 模拟 | USE WHEN: simulate concentration-effect time course for a dosing regimen | ALIASES: PK/PD模拟, 给药方案模拟, 浓度时间曲线, simulation, 剂量方案 | RETURNS: 模拟曲线与参数
| Name | Required | Description | Default |
|---|---|---|---|
| drug_name | Yes | 药物名 | |
| pd_params | No | 药效参数 | |
| pk_params | No | 药代参数 |
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 by structured data. The description adds the 'RETURNS: 模拟曲线与参数' line, which is useful given no output schema exists, but it says nothing about what model is used, what happens when pk_params or pd_params are omitted, or what units/format results carry.
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 pipe-delimited keyword block is front-loaded and scannable, and the alias list may aid retrieval. But it restates the title verbatim in the first segment and spends space on Chinese synonym aliases rather than on behavioral or parameter detail, so several clauses do not earn their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool taking two untyped nested objects and returning no output schema, the definition should explain what belongs in pk_params and pd_params and what the curves contain. The one-line 'RETURNS' hint and a single use case are thin relative to that complexity, leaving an agent likely to pass malformed nested payloads.
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, and the description adds no parameter detail beyond the schema's generic labels. This is notable because two of the three parameters are free-form nested objects (pk_params, pd_params) whose expected keys the description does not clarify.
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 'USE WHEN' clause gives a specific verb and resource: simulate a concentration-effect time course for a dosing regimen. That is clear enough to act on, but it never distinguishes this from close siblings such as pk_pd_assess, pk_nca, or renal_dose_adjust, so an agent facing a PK/PD request has to guess which one applies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'USE WHEN' line supplies a single positive trigger condition, which is more than most keyword blocks offer. However, there are no exclusions or named alternatives, and given the crowded PK/PD neighborhood (pk_pd_assess, pk_nca, species_dose_convert), the absence of routing guidance leaves a real ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Plasmid map / 质粒图谱 | USE WHEN: draw/describe a plasmid map from a sequence (features, orientation) | ALIASES: 质粒图谱, 载体结构, plasmid map, vector, 质粒构建图 | RETURNS: 质粒图谱
| Name | Required | Description | Default |
|---|---|---|---|
| sequence | Yes | 质粒序列 |
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 safety is covered. The description adds almost nothing beyond that: 'RETURNS: 质粒图谱' merely restates the tool name rather than disclosing the output form (image, SVG, feature table) or any constraints on input sequence length or format.
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 pipe-delimited layout is front-loaded and scannable, which is good. However, the long ALIASES list and the 'RETURNS: 质粒图谱' segment consume space without informing the agent, so the text is not fully economical.
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 read-only transformation tool with no output schema, so the description must explain what comes back. Instead the RETURNS field is a tautology, leaving the agent unable to tell whether the result is an image, a coordinate list, or an annotated sequence.
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 explains it and the baseline of 3 applies. The description adds no extra meaning, such as accepted sequence formats (FASTA vs raw) or whether annotation is automatic.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource: 'draw/describe a plasmid map from a sequence (features, orientation)'. That is enough to distinguish it from unrelated siblings, but it does not differentiate it from adjacent bioinformatics tools such as restriction_sites or cloning_design, 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 'USE WHEN' clause states an explicit trigger condition (you have a sequence and want a map with features/orientation). There is no when-not guidance and no named alternative for overlapping cases like restriction mapping or cloning design, so it is clear but incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Protein-protein interaction network / 蛋白互作网络 | USE WHEN: PPI network from a protein list, hub identification (STRING) | ALIASES: 蛋白互作, PPI, STRING, hub基因, 互作网络, network | RETURNS: 互作网络与 hub 蛋白
| Name | Required | Description | Default |
|---|---|---|---|
| species | No | 物种：human/mouse | |
| protein_list | Yes | 蛋白/基因列表 | |
| confidence_threshold | No | 置信度阈值 |
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 clear. The description adds useful behavioral context, namely the STRING data source and the fact that the output is a network plus hub proteins. There is a mild tension between the reference to STRING and openWorldHint=false, but it is not a direct contradiction. The description gives no guidance on defaults, rate limits, or how large a protein list can be before the STRING query fails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The pipe-delimited format is front-loaded and easy to scan, and the trigger condition comes before the aliases. The alias list is somewhat keyword-heavy and takes up space without adding much semantic value, but the overall entry remains 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?
For a three-parameter, read-only query tool, the description covers purpose and rough output, and there is no output schema to explain. It stops short of stating sensible defaults for confidence_threshold and species, or what the hub list contains, which an agent would need in order to call it correctly the first time.
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 all three parameters have descriptive labels in the schema. The description adds no extra meaning for protein_list, species, or confidence_threshold, so it does not compensate for what an agent would need in order to choose a sensible threshold. Baseline 3 applies because 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 action: build a PPI network from a protein list and identify hubs using STRING. That is concrete enough for an agent to distinguish it from neighboring analysis tools such as protein_enrichment or gene_pathway_disease. It does not explicitly name a sibling to avoid, so it falls just short of 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 'USE WHEN' clause gives a clear trigger condition, including the case of hub identification and the backing source (STRING). However, it does not say when NOT to use this tool or which alternatives exist, such as enrichment, pathway, or single-gene lookup tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Primer Tm & dimers / 引物 Tm 计算 | USE WHEN: Tm, GC% and self/cross dimer check for given primer sequences | ALIASES: Tm, 引物Tm, 退火温度, GC含量, 二聚体, primer dimer, melting temperature | RETURNS: Tm、GC、二聚体
| Name | Required | Description | Default |
|---|---|---|---|
| sequence | Yes | 引物序列 |
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 the return contents (Tm, GC, dimers), which matters because there is no output schema, but it says nothing about the Tm model/assumptions (salt, concentration, nearest-neighbor) or sequence-format constraints that would affect interpretation of results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Pipe-delimited and front-loaded with the tool's identity, followed by trigger and return summary; nothing is buried. The alias list is long and bilingual duplication adds bulk, but each section serves a retrieval or routing 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 one-parameter, non-destructive calculator with no output schema, the description supplies the trigger, the returned quantities, and alias coverage. Only the Tm computation assumptions are left unexplained, a minor gap for a tool this simple.
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 a single parameter and 100% schema description coverage, the schema already documents 'sequence'. The description only restates 'given primer sequences' and adds no format detail such as 5'->3' orientation, allowed characters, or length limits, 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 names a specific verb+resource: computing Tm, GC% and self/cross dimer status for supplied primer sequences. An agent can tell this is a calculation over an existing sequence rather than a design tool, though it never explicitly names the closest sibling (pcr_primer_design) to draw the contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'USE WHEN' clause gives a clear trigger condition: when you already have primer sequences and need Tm, GC% or dimer checks. It stops short of stating when NOT to use it (e.g. use pcr_primer_design to generate primers first), so the guidance is contextual but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PRISMA flow diagram / PRISMA 流程图 | USE WHEN: PRISMA literature screening flow for systematic reviews / meta-analyses | ALIASES: PRISMA, 文献筛选流程, 系统评价流程图, flow diagram, 检索流程图 | RETURNS: PRISMA 流程图
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | 研究题目 | |
| records_screened | No | 筛读记录数 | |
| studies_included | No | 最终纳入研究数 | |
| records_identified | No | 检索记录数 |
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 fully covered by structured data. The description adds essentially nothing beyond that — 'RETURNS: PRISMA 流程图' merely restates the tool name and gives no indication of output format (image, SVG, Mermaid, table) or whether a figure file is written.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is short and the use-case clause is front-loaded, which is good. However, the ALIASES block is keyword stuffing for search rather than guidance, and the bilingual duplication plus a content-free 'RETURNS' line adds characters 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?
For a figure-generating tool with four optional parameters and no output schema, the description leaves the key question unanswered: what the agent gets back and in what format. With zero required parameters, guidance on which counts produce a complete diagram versus a partial one would also matter.
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 (title, records_screened, studies_included, records_identified) are documented in the schema itself. The description contributes no additional semantics, such as how counts should relate or what happens when a field is omitted, 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 the concrete artifact (PRISMA flow diagram) and its domain (literature screening for systematic reviews / meta-analyses), which is enough to tell it apart from data-analysis siblings. It stops short of stating the verb (generate/build), so the action is inferred from the title 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?
The 'USE WHEN' clause gives an explicit triggering condition: PRISMA screening flow for systematic reviews or meta-analyses. It does not name an alternative or exclusion (e.g., consort_flowchart for trial reporting), so the agent must infer the boundary itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Propensity score matching (PSM) / 倾向性评分匹配 PSM | USE WHEN: match treated and control subjects on baseline covariates (1:1 nearest neighbour within caliper), then report SMD balance | ALIASES: PSM, 倾向性评分, 倾向评分匹配, propensity score, 1:1匹配, 基线可比, 混杂控制, 匹配后均衡 | RETURNS: 匹配后样本与均衡性
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | 样本表：每行一个受试者的字典，如 [{"treat":1,"age":62,"sex":0}, …]（也可改用 treatment/covariates 直接传数组） | |
| ratio | No | 匹配比例，默认 1 | |
| treatment | No | 处理变量（1=处理组，0=对照组）。传 data 时填列名 "treat"；也可直接传 0/1 数组 | |
| covariates | No | 协变量列名数组，如 ["age","sex"]（传 data 时）或二维数值矩阵 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish this as a read-only, non-destructive, closed-world operation. The description adds useful behavior beyond that: it specifies 1:1 nearest-neighbour matching within a caliper and says the tool reports SMD balance and returns the matched sample. It still does not describe data-quality requirements, missing-data handling, or output format 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?
The definition is compact and front-loaded with the method name and a clear 'USE WHEN' clause. The alias list is long and partly keyword-oriented, but the overall structure remains easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should carry more detail about returned values, but it only says '匹配后样本与均衡性' (matched sample and balance). The invocation-critical information is present, yet output structure and practical prerequisites remain underspecified for a statistical matching 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 all four parameters are already documented in the input schema. The description adds the caliper and 1:1 matching context but does not clarify the ratio parameter or how treatment/covariates may be passed as arrays, leaving parameter semantics largely to 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 method and resource: propensity score matching of treated and control subjects on baseline covariates using 1:1 nearest-neighbour matching within a caliper, plus SMD balance reporting. This is much clearer than the bare tool name, though it does not explicitly differentiate the method from sibling approaches such as iptw_weighting or smd_balance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'USE WHEN' clause gives a clear trigger: matching treated and control subjects on baseline covariates and then reporting SMD balance. It does not state when not to use PSM or point to alternatives such as IPTW weighting when matching is inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
In-silico protein digestion / 蛋白酶解模拟 | USE WHEN: choose protease and list peptides for mass-spec sample prep | ALIASES: 蛋白酶解, 质谱前处理, 酶解肽段, digest, trypsin, 肽段清单 | RETURNS: 肽段清单
| Name | Required | Description | Default |
|---|---|---|---|
| enzymes | No | 酶：Trypsin/Lys-C | |
| sequence | Yes | 蛋白序列 |
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 fully covered by structured data. The description adds only 'RETURNS: 肽段清单', which is useful since no output schema exists, but says nothing about cleavage rules, missed-cleavage defaults, how multiple enzymes combine, or what happens with invalid residues.
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 USE WHEN and RETURNS clauses are front-loaded and earn their place, but the six-item alias string (蛋白酶解, 质谱前处理, 酶解肽段, digest, trypsin, 肽段清单) is padding, and the bilingual title is repeated from the title field. The pipe-delimited metadata style is scannable but wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter read-only tool with full schema coverage and clear annotations, the minimal description is close to sufficient, and the RETURNS line partially compensates for the missing output schema. It is still thin on output shape (per-peptide fields, positions, masses) and on enzyme support, which an agent would need to interpret 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 coverage is 100% with only two parameters, each already documented ('酶：Trypsin/Lys-C', '蛋白序列'), so the schema does the heavy lifting and a 3 is the baseline. The description's 'choose protease' phrase hints that the enzymes array drives digestion, but it does not enumerate valid enzyme names or clarify whether multiple enzymes are applied in parallel or sequentially.
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 operation on a specific resource: in-silico protein digestion into a peptide list, with the use context 'mass-spec sample prep'. It does not explicitly differentiate from nearby siblings such as protein_physchem, protein_ptm, or protein_enrichment, so an agent must infer the boundary, but the verb+resource pairing is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'USE WHEN: choose protease and list peptides for mass-spec sample prep' clause gives a concrete triggering condition, which is more than most siblings provide. It offers no when-not guidance and names no alternative tool for adjacent tasks (e.g. physicochemical property calculation vs. digestion), and 'choose protease' slightly blurs whether the tool selects the enzyme or the caller does.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Protein enrichment / 蛋白富集分析 | USE WHEN: GO/KEGG enrichment for a protein list | ALIASES: 蛋白富集, protein enrichment, 蛋白GO, 蛋白通路 | RETURNS: 富集通路
| Name | Required | Description | Default |
|---|---|---|---|
| species | No | 物种 | |
| protein_list | Yes | 蛋白列表 | |
| enrichment_type | No | GO/KEGG/Reactome |
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 by structured data. The description adds only "RETURNS: 富集通路", which is vague and does not say what fields the enrichment table contains, how many pathways come back, or whether a background/universe is applied. Species handling and default enrichment_type are unaddressed.
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 pipe-delimited keyword block is front-loaded and compact, with the use case stated before the returns hint. The aliases line is redundancy for an English agent but plausibly aids matching of Chinese-language queries; nothing is verbose.
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 three-parameter, read-only analysis tool with full schema coverage and no output schema, the definition covers the essentials. It still omits the return shape and whether enrichment_type defaults to GO or KEGG, which matters when the caller leaves that parameter empty.
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 three parameters are already documented in the schema, and the description adds no syntax, format, or default information beyond it. Mentioning GO/KEGG loosely overlaps the enrichment_type parameter but adds no new 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 states a specific analysis (GO/KEGG enrichment) on a specific input (a protein list), which is enough for an agent to know what the tool produces. It does not differentiate from the closely related sibling go_kegg_enrichment, so an agent choosing between gene-level and protein-level enrichment gets no help.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"USE WHEN: GO/KEGG enrichment for a protein list" gives one positive trigger condition, which is better than nothing. There is no when-not guidance, no prerequisite (e.g. species requirement), and no mention of the sibling go_kegg_enrichment as the alternative for gene lists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Protein physicochemical properties / 蛋白理化性质 | USE WHEN: molecular weight, pI, GRAVY, instability index etc. from a protein sequence | ALIASES: 蛋白理化性质, 分子量, 等电点, pI, GRAVY, 疏水性, MW, protein properties | RETURNS: MW/pI/GRAVY 等
| Name | Required | Description | Default |
|---|---|---|---|
| sequence | Yes | 蛋白序列 | |
| protein_name | No | 蛋白名 |
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 only the output list and says nothing about sequence-length limits, which algorithm/constants are used for pI or instability, or the shape of the result set ('等' leaves it open). Useful but thin 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 piped USE WHEN / ALIASES / RETURNS layout is front-loaded and scannable, with the trigger condition first. The alias list is long and partly redundant with the title, which costs a bit of signal-to-noise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter, no-output-schema computation tool the description is adequate: it names inputs and outputs. It still leaves the agent unsure of accepted sequence format and the exact return shape, which matters because there is no output schema to fall back on.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are documented in the schema, albeit tersely ('蛋白序列', '蛋白名'). The description adds no format hints (FASTA vs raw residues, single-letter vs three-letter codes, whether protein_name is optional labelling) beyond what the schema already says, 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 names a concrete computation (molecular weight, pI, GRAVY, instability index) applied to a protein sequence, and the RETURNS line restates the key outputs. It is specific enough to distinguish this from neighbours like protein_digest or protein_ptm, though it never states the operation as a verb (e.g. 'computes').
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 explicit 'USE WHEN' clause gives a clear triggering condition (needing MW, pI, GRAVY, instability index from a sequence). There is no guidance on when not to use it and no named alternative among the protein-* siblings, 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.
Post-translational modification prediction / 翻译后修饰分析 | USE WHEN: predict phosphorylation / glycosylation and other PTM sites | ALIASES: 翻译后修饰, 磷酸化位点, 糖基化, PTM, phosphorylation, modification sites | RETURNS: 修饰位点预测
| Name | Required | Description | Default |
|---|---|---|---|
| sequence | Yes | 蛋白序列 | |
| modifications | No | 修饰类型：phosphorylation/glycosylation |
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 supplied structurally. The description's only behavioral addition is 'RETURNS: 修饰位点预测', which largely restates the tool's own purpose and says nothing about output fields, scoring, thresholds or how predictions should be interpreted.
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-loads purpose followed by USE WHEN, ALIASES and RETURNS, which is easy to scan. The ALIASES list is largely keyword padding for retrieval rather than information an agent needs in order to invoke the tool correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter, read-only prediction tool with full schema coverage this is close to sufficient, but with no output schema the vague 'RETURNS: 修饰位点预测' leaves the agent guessing what the result actually contains (site positions, confidence scores, supported modification types). A brief note on the result shape would close the 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%, with both 'sequence' and 'modifications' documented, so the schema carries the parameter burden and 3 is the baseline. The description adds nothing beyond the schema, since the phosphorylation/glycosylation examples it mentions already appear in the modifications field 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 title line names a specific verb+resource ('Post-translational modification prediction'), and 'USE WHEN: predict phosphorylation / glycosylation and other PTM sites' pins down the exact operation, which is distinguishable from sibling protein tools such as protein_physchem, protein_digest and protein_enrichment. It does not explicitly name a sibling it is not, 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 'USE WHEN' clause gives a clear trigger context (predicting PTM sites, with phosphorylation and glycosylation called out). There are no exclusions or pointers to alternative tools for adjacent tasks like physchem properties or enrichment, so it is clear context without when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PSI model stability / 模型稳定性 PSI | USE WHEN: population stability index between expected and observed score distributions | ALIASES: PSI, 模型稳定性, 群体稳定性, population stability, 漂移 | RETURNS: PSI 值与稳定性判断
| Name | Required | Description | Default |
|---|---|---|---|
| n_bins | No | 分箱数 | |
| expected_probs | Yes | 开发集概率 | |
| observed_probs | Yes | 验证集概率 |
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 description only needs to add context beyond that. It contributes the return shape ('PSI 值与稳定性判断'), which is genuinely useful given there is no output schema, but it says nothing about default binning, whether the judgment uses standard 0.1/0.25 thresholds, or any input constraints (equal-length arrays, probability sums).
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 pipe-delimited, front-loaded format puts the purpose first and quarantines aliases and return info into labeled segments, so nothing critical is buried. The alias list (PSI, 模型稳定性, 群体稳定性, population stability, 漂移) is somewhat padded for a tool-name-based selector, but it does not obstruct scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only, closed-world computation with a fully documented 3-parameter schema, the definition covers the essentials: what it computes, when to reach for it, and roughly what comes back. What is missing is interpretive guidance an agent would need to report results correctly — the meaning of the returned stability verdict and its thresholds — which matters because no output schema exists to explain it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — all three parameters carry inline Chinese descriptions (分箱数, 开发集概率, 验证集概率) — so the schema itself carries the parameter meaning. The description adds no additional semantics such as array-length matching or a default for n_bins, which is the expected baseline-3 outcome when the schema already documents everything.
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 definition names a specific statistical quantity (population stability index) and states the two inputs it compares (expected vs observed score distributions), so an agent knows exactly what it computes. It is clearly distinct from every sibling in the list (no other stability/PSI tool exists). It stops short of a full 5 because the verb is only implied via the 'USE WHEN:' clause rather than stated outright.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'USE WHEN:' clause gives a concrete triggering condition — comparing expected versus observed score distributions — which is enough for an agent to know when this tool applies. It offers no exclusions or named alternative (e.g. it does not say to compare against roc_auc or calibration_curve for discrimination/calibration rather than stability), so it falls short of the 5 tier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PubMed search / PubMed 检索 | USE WHEN: search PubMed for the latest literature (live NCBI E-utilities) | ALIASES: PubMed, 查pubmed, 最新文献, pubmed检索, NCBI, 最新研究 | RETURNS: PubMed 文献列表
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | 检索式（英文） | |
| year_start | No | 起始年份 | |
| max_results | No | 条数 |
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 that results come from live NCBI E-utilities (a real external dependency with implied latency and freshness) and that a literature list is returned. It says nothing about rate limits, retries, or how many results are actually live-fetched; note also that 'live NCBI E-utilities' sits in mild tension with openWorldHint=false, since a live third-party API call is arguably open-world.
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 compact, pipe-delimited block with the purpose and USE WHEN trigger front-loaded, followed by aliases and return type. Nothing is wasted; the alias list is genuinely functional since it maps colloquial and Chinese phrasings to this tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, full schema coverage, annotations, and the absence of an output schema, the definition supplies the essentials: what is searched, against which live source, and what is returned. Defaults for max_results and the effect of omitting year_start are the only meaningful gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter (q, year_start, max_results) is already documented in the schema. The description adds no syntax hints, such as MeSH terms, English-query requirement, defaults for max_results, or behavior when year_start is omitted, so it is a baseline 3.
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 ('search PubMed for the latest literature') and identifies the underlying data source ('live NCBI E-utilities'), so the agent can tell what the tool does. It does not explicitly differentiate itself from the sibling 'literature_search_pmc', which also performs literature search, 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 'USE WHEN' clause gives a clear activation trigger: searching PubMed for the latest literature. It does not name the alternative tool (literature_search_pmc) or state when NOT to use it, so the agent must infer the dividing line between PubMed and PMC search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
qPCR Bayesian design / 贝叶斯自适应设计（qPCR） | USE WHEN: design a qPCR experiment / digital-twin PCR simulation for a target | ALIASES: qPCR设计, 贝叶斯自适应, digital PCR, 实验设计, target, 扩增效率 | RETURNS: 实验设计方案
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | 目标基因/模板 | |
| constraints | No | 约束条件 |
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 carries no burden. Beyond that, the description normatively adds only 'RETURNS: 实验设计方案', which is a vague category label rather than actual behavioral context (what the design contains, whether it is deterministic, how expensive the simulation is).
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 consistently front-loaded: title, then USE WHEN, then aliases, then returns. No filler sentences, though the bilingual title and alias list are display metadata rather than guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 params, 1 required, no output schema), but 'RETURNS: 实验设计方案' does not tell the agent what a design plan includes or how to interpret it, and the 'constraints' parameter is never explained in the description. For an output-bearing analytic tool with no output schema, that leaves a real gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented (目标基因/模板 and 约束条件). The description only echoes 'for a target' and adds no format, range, or example detail, 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 'USE WHEN' line pairs a specific verb with a specific resource ('design a qPCR experiment... for a target'), but the compound framing 'Bayesian design / digital-twin PCR simulation' leaves it unclear whether the tool runs a simulation or only produces a design plan, and nothing distinguishes it from PCR-related siblings such as pcr_primer_design or qpcr_ddct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'USE WHEN: design a qPCR experiment... for a target' gives one positive triggering condition, which is more than nothing. However, it offers no exclusions, prerequisites, or pointers to alternatives, even though closely related tools (pcr_primer_design, qpcr_ddct, primer_tm) exist in the sibling list and the agent must guess which to pick.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
qPCR 2^-ddCt relative expression / qPCR 相对表达量（2^-ΔΔCt） | USE WHEN: compute dCt, ddCt and 2^-ddCt fold change from target and reference Ct values, with a group test (calibrated on the mean control dCt) | ALIASES: qPCR, 2^-ddCt, 相对表达量, 倍数, dCt, ddCt, fold change, 内参, Ct值, 基因表达 | RETURNS: fc（2^-ΔΔCt 相对倍数，已按对照组 ΔCt 均值校准）、fold_values、p_value、stat_method（welch_ttest_on_dct / student_ttest_on_dct …
| Name | Required | Description | Default |
|---|---|---|---|
| gene | No | 目的基因名，如 NLRP3 / TREM2 | |
| exp_ct | Yes | 处理组目的基因 Ct，逗号分隔，如 20.1,20.4,20.2 | |
| ctrl_ct | Yes | 对照组目的基因 Ct，逗号分隔，如 22.5,22.8,22.6 | |
| ref_gene | No | 内参基因名，默认 GAPDH | |
| exp_ref_ct | Yes | 处理组内参基因 Ct，逗号分隔，与 exp_ct 一一对应，如 18.2,18.5,18.3 | |
| ctrl_ref_ct | Yes | 对照组内参基因 Ct，逗号分隔，与 ctrl_ct 一一对应，如 18.3,18.1,18.4 |
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 a genuine behavioral detail the annotations cannot convey: calibration is against the mean control dCt, and the returned stat_method may be welch_ttest_on_dct or student_ttest_on_dct. However, that RETURNS block is truncated mid-token, and nothing is said about minimum replicate count or what happens with unequal group sizes.
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 lead segment repeats the title verbatim in both Chinese and English, which is pure redundancy with the title field, and the ALIASES list of eleven terms consumes a large share of a short description. The remaining USE WHEN / RETURNS structure is well front-loaded, but the trailing content is cut off, leaving the structure visibly incomplete.
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 is the only place return values can be explained, and it does list fc, fold_values and p_value, which is the right instinct. But the listing is truncated and missing key operational facts for a statistics tool: required minimum n per group, whether Ct inputs are technical replicate means, and the default significance test selection rule.
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 every parameter already carries a Chinese description with examples and pairing constraints (exp_ref_ct 与 exp_ct 一一对应). The description adds only the interpretive note that ctrl_ct/ctrl_ref_ct set the calibration baseline, which is marginal added meaning 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 USE WHEN clause names a specific verb chain and resource: 'compute dCt, ddCt and 2^-ddCt fold change from target and reference Ct values, with a group test'. That is precise enough to distinguish it from the nearest sibling, qpcr_bayesian_design, which is a design rather than a calculation 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?
The 'USE WHEN' clause gives a concrete triggering condition (target and reference Ct values available, group comparison with control-calibrated dCt), and the alias list helps with fuzzy matching from user phrasing. It stops short of naming alternatives or stating 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.
Randomization / allocation / 随机化分组 | USE WHEN: produce a reproducible randomization list: simple, block, stratified, or minimization, with a fixed seed | ALIASES: 随机分组, 随机数字表, 区组随机, 分层随机, 最小化法, randomization, random allocation, 分组名单, seed | RETURNS: 分组结果表
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | 随机种子（固定才可复现） | |
| groups | Yes | 分组名称数组，如 ["干预组","对照组"]（必须是数组，不是数字） | |
| method | No | simple 简单 / block 区组 / stratified 分层 / minimization 最小化 | |
| block_size | No | 区组长度（block 方法用） | |
| n_subjects | Yes | 总样本量，如 60 |
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 meaningful behavior beyond that: the output is an allocation result table and reproducibility depends on fixing the seed. It stops short of describing the table's columns or row count.
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 pipe-delimited layout is front-loaded: purpose, then use condition, then aliases, then return value. The long alias list (many near-duplicate Chinese and English keyword variants) is bulk that serves discoverability rather than comprehension, but the rest is 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?
With five parameters, no output schema, and a required groups/n_subjects pair, the description supplies the essential context: which designs exist, that a seed makes output reproducible, and that the result is an allocation table. A brief note on how minimization and stratified differ in required inputs would close the remaining 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 all five parameters including the method variants and block_size are already documented. The description reinforces the seed-as-reproducibility-control idea and mirrors the method list, but adds no syntax or constraint detail the schema lacks. 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 concrete verb and resource ('produce a reproducible randomization list') and enumerates the four supported designs (simple, block, stratified, minimization), so the agent knows exactly what the tool generates. It does not explicitly differentiate itself from the nearby sibling animal_randomization, 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 'USE WHEN' clause gives a clear triggering condition (need a reproducible allocation list with a fixed seed), which is strong guidance. However, it names no exclusions and no alternative sibling (e.g. animal_randomization or the sample-size tools) that an agent should prefer in other situations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Renal function & dose adjustment / 肾功能剂量调整 | USE WHEN: the user gives age / sex / weight / serum creatinine and asks for creatinine clearance, eGFR, CKD stage, or how to adjust a drug dose in renal impairment (vancomycin, meropenem, metformin, anticoagulants…) | ALIASES: 肾功能剂量, 肌酐清除率, CrCl, eGFR, 肾小球滤过率, 减量, 剂量调整, 肾功能不全, 万古霉素怎么减量, 按肌酐算剂量 | RETURNS: CrCl（Cockcroft-Gault）+ eGFR（CKD-EPI 2021）+ CKD 分期 + 该药的肾剂量分档（含依据与核对提示）
| Name | Required | Description | Default |
|---|---|---|---|
| age | Yes | 年龄（岁） | |
| sex | No | male / female（也接受 男 / 女） | |
| crrt | No | 是否 CRRT | |
| drug | No | 药名，中英文均可，如 vancomycin / 万古霉素 | |
| dialysis | No | 是否血液透析 | |
| height_cm | No | 身高 cm（用于理想体重与 BSA，建议给） | |
| scr_mg_dl | No | 血肌酐 mg/dL（与 scr_umol_l 二选一） | |
| weight_kg | Yes | 实际体重 kg | |
| scr_umol_l | No | 血肌酐 μmol/L（国内化验单常用单位，与 scr_mg_dl 二选一） |
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 description's job is to add operational context — and it does, via the RETURNS section naming the two formulas used and stating that dose bands come with rationale and verification prompts. It does not state assumptions or limits (for example, that a steady-state creatinine is needed or that dialysis/CRRT inputs change the calculation), which keeps it below a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is a single front-loaded line with clear pipe-delimited sections (identity, USE WHEN, ALIASES, RETURNS), so an agent can scan it quickly. The long bilingual alias list is retrieval-useful but is the one part that inflates length without adding behavioral meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters, no output schema, and full schema coverage, the description correctly focuses on stating what is returned (CrCl, eGFR, CKD stage, dose band) rather than re-documenting inputs. Some gaps remain for a clinical calculation tool: nothing is said about how dialysis and CRRT inputs alter the result or about clinical caveats.
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 one of the 9 parameters is already documented in the schema, including unit alternatives (scr_umol_l vs scr_mg_dl) and Chinese/English drug names. The description restates the input set at a high level and adds no syntax, defaults, or precedence rules beyond the schema. The baseline of 3 is therefore 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 (renal function) and the exact computations performed (CrCl by Cockcroft-Gault, eGFR by CKD-EPI 2021, CKD staging, drug-specific renal dose banding). It is clearly distinguishable from neighboring tools such as species_dose_convert, pk_nca, and animal_dose_volume, which handle other kinds of dosing or pharmacokinetics.
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 'USE WHEN' clause gives concrete triggering inputs (age, sex, weight, serum creatinine) and concrete requested outputs (CrCl, eGFR, CKD stage, dose adjustment), which is stronger guidance than most tools provide. It stops short of naming exclusions or pointing to sibling alternatives for adjacent cases, so it does not reach the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reporting guideline checklist / 报告规范清单核对 | USE WHEN: check a manuscript against CONSORT / STROBE / PRISMA / TRIPOD / ARRIVE / STARD | ALIASES: 报告规范, CONSORT, STROBE, PRISMA, TRIPOD, STARD, checklist, 投稿前检查, 规范核对 | RETURNS: 逐条核对结果
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | 论文正文 | |
| design_type | No | 研究设计类型 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the description need not repeat that. It adds only 'RETURNS: 逐条核对结果' — a bare item-by-item result claim with no information on how the checklist is selected, whether missing items are scored, or what a single result entry looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The pipe-delimited, front-loaded format makes the trigger easy to find and the text is short. However, a large share of it is keyword/alias padding and bilingual duplication ('报告规范, CONSORT, STROBE...' repeats the guideline names already in USE WHEN), and the RETURNS stub is in Chinese while the rest is English, adding noise rather than signal.
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 full schema coverage and no output schema, the description supplies the essential trigger and guideline scope. What remains missing is how the target guideline is determined (from design_type, from text inference, or from both) and any sense of result granularity, which matters because six distinct checklists are promised.
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 'text' and 'design_type' are documented in the schema. The description adds nothing about these parameters — in particular it never explains whether design_type steers guideline selection or is merely advisory, which is the one semantic an agent actually needs.
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 concrete verb ('check a manuscript') and a concrete resource set (CONSORT / STROBE / PRISMA / TRIPOD / ARRIVE / STARD), so an agent knows exactly what operation is performed. It does not explicitly distinguish itself from guideline-specific siblings such as arrive_checklist, consort_flowchart, or prisma_flowchart, which is the only gap.
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 'USE WHEN' clause gives a clear trigger condition (pre-submission checking of a manuscript against a named reporting guideline). It offers no exclusions or routing advice versus the sibling checklist/flowchart tools, so the agent must infer that overlap itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Restriction sites / 酶切位点分析 | USE WHEN: find restriction enzyme sites in a DNA sequence (can it be cut, which enzyme) | ALIASES: 酶切位点, 限制性内切酶, restriction enzyme, 能不能切开, cloning sites | RETURNS: 酶切位点清单
| Name | Required | Description | Default |
|---|---|---|---|
| sequence | Yes | 核酸序列 |
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 by structured data. The description adds only 'RETURNS: 酶切位点清单', which indicates a list output but says nothing about ordering, counts, or whether all enzymes or a default panel are scanned. Useful but thin 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 pipe-delimited layout front-loads the name and the USE WHEN trigger, so the key routing signal is immediately visible. The bilingual title and alias list add some bulk, but the aliases carry real matching value for Chinese-language queries.
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 analysis tool with no output schema, the definition covers trigger, aliases and return type, which is sufficient to call it correctly. The main residual gap is that the description never says which enzymes are considered or whether the caller can choose a panel.
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 with 100% schema coverage, so the schema already documents the required 'sequence' string. The description reinforces that the input is a DNA sequence but adds no format, length, or alphabet constraints of its own, which is the expected 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 names a specific verb and resource: 'find restriction enzyme sites in a DNA sequence', refined by 'can it be cut, which enzyme'. That is enough to separate it from neighbouring tools such as dna_translate, orf_find or plasmid_map, 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?
'USE WHEN: find restriction enzyme sites in a DNA sequence' gives a clear positive trigger, reinforced by colloquial triggers like '能不能切开'. There is no explicit when-not or named alternative such as cloning_design or plasmid_map, so routing against near neighbours 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.
Risk ratio / odds ratio / 相对危险度 RR | USE WHEN: RR, OR and 95% CI from a 2×2 table of counts | ALIASES: 相对危险度, RR, OR, 比值比, 四格表, risk ratio, odds ratio, 95%CI | RETURNS: RR、OR、95%CI
| Name | Required | Description | Default |
|---|---|---|---|
| exposed_total | Yes | 暴露组总数 | |
| exposed_events | Yes | 暴露组事件数 | |
| unexposed_total | Yes | 非暴露组总数 | |
| unexposed_events | Yes | 非暴露组事件数 |
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 listing the returned quantities (RR, OR, 95% CI) in the absence of an output schema, but says nothing about edge-case handling such as zero cells or continuity correction, which materially affects results for this 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?
The pipe-delimited format is front-loaded and scannable, with purpose, trigger, aliases and returns in order. The alias list is long and include search keywords rather than semantic guidance, which adds mild bulk but serves discoverability.
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 four-integer read-only calculator with full schema coverage and no output schema, the description covers what it does, when to use it, and what it returns. Only the handling of degenerate table cells is unaddressed, which is a modest gap for a tool of this simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the four integer parameters are already documented as counts for exposed/unexposed events and totals. The phrase '2x2 table of counts' reinforces that inputs are raw counts rather than rates or proportions, but no additional guidance (e.g., that totals must be >= events, or ordering conventions) 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 description names the specific measures (risk ratio, odds ratio) and the input form (a 2x2 table of counts), which is more precise than the bare tool name. It is identifiable against statistical siblings like stats_toolbox or roc_auc, though it never explicitly contrasts with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'USE WHEN: RR, OR and 95% CI from a 2x2 table of counts' clause gives a clear triggering condition, so an agent knows this is the right tool for count-based 2x2 analysis. It stops short of naming exclusions or alternatives (e.g., when to prefer a chi-square or Fisher test tool).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
RNA-seq differential analysis / RNA-seq 差异分析 | USE WHEN: differential genes from RNA-seq count matrix (negative binomial) | ALIASES: RNA-seq, 转录组差异, 差异基因, DESeq, count matrix, RNA测序 | RETURNS: 差异基因清单
| Name | Required | Description | Default |
|---|---|---|---|
| groups | No | 分组 | |
| log2fc | No | log2FC 阈值 | |
| data_json | Yes | 表达矩阵 | |
| fdr_threshold | No | FDR |
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 by structured data rather than the description. The description adds the negative-binomial method and states the return is a DEG list, but says nothing about default thresholds, multiple-testing correction conventions, or failure modes on malformed matrices — a modest increment over 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 pipe-delimited template is front-loaded with purpose and the USE WHEN clause, so the most important information comes first. The bilingual ALIASES block is largely keyword stuffing that consumes a meaningful share of a short description without adding decision-relevant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter read-only analysis tool with a simple contract, the description covers what it computes and what it returns at a high level, and no output schema is needed given the 'RETURNS: 差异基因清单' line. What is missing is the structural contract for the nested 'data_json' matrix (gene rows vs sample columns, group vector alignment) and any statement of default FDR/log2FC values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the four parameters are technically documented, and the description correctly implies a count matrix plus thresholds. However it adds no meaning beyond the schema — notably it never explains how 'groups' should align with matrix columns or the orientation of the nested 'data_json' object, which is the main ambiguity risk.
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 ('RNA-seq differential analysis') and scopes it with 'differential genes from RNA-seq count matrix (negative binomial)'. That is clear enough to act on, but it never distinguishes itself from the sibling tool 'differential_expression' (or 'atac_diff'), so an agent comparing the two must open both schemas to choose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'USE WHEN: differential genes from RNA-seq count matrix (negative binomial)' gives an implied input condition and hints at the statistical model, which is genuine guidance. However there are no exclusions, no prerequisites (e.g., raw counts vs normalized, minimum replicates), and no pointer to sibling alternatives, so routing is only partially supported.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ROC curve & AUC / ROC 曲线与 AUC | USE WHEN: the user has a binary gold standard and predicted scores/probabilities and wants AUC, ROC curve, discrimination, or the best cut-off | ALIASES: ROC, AUC, 曲线下面积, 诊断效能, 最佳阈值, cutoff, discrimination, 敏感度特异度, ROC曲线 | RETURNS: AUC、最优阈值、敏感度特异度
| Name | Required | Description | Default |
|---|---|---|---|
| labels | Yes | 真实标签 0/1 | |
| scores | Yes | 预测分数/概率 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, destructiveHint=false, so the safety profile is covered. The description adds real value with a RETURNS line (AUC, optimal threshold, sensitivity/specificity), which matters because there is no output schema. It stays silent on edge cases such as tied scores, minimum sample size, or what happens with a single-class label vector.
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 pipe-delimited USE WHEN / ALIASES / RETURNS layout is front-loaded and scannable, with no filler sentences. The opening repeats the title verbatim ('ROC curve & AUC / ROC 曲线与 AUC'), which is wasted tokens given the title field already carries it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter, annotation-covered, side-effect-free computation tool, the definition covers trigger condition, synonyms, and return values — essentially everything needed to call it. Only minor operational details (sample-size expectations, tie handling, output shape beyond field names) are absent, which is acceptable at this complexity.
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% (labels = true 0/1 labels, scores = predicted scores/probabilities), so the schema carries parameter meaning. The description only restates the same concepts in prose ('binary gold standard and predicted scores/probabilities') without adding format constraints such as equal-length arrays or score-range expectations. 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 computation (ROC curve & AUC) plus the exact output concept set — discrimination and best cut-off — and the required data shape (binary gold standard plus predicted scores/probabilities). An agent can distinguish this from sibling stats tools such as classification_metrics or delong_auc_compare without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'USE WHEN' clause gives a clear triggering condition: binary gold standard plus predicted scores and a desire for AUC/ROC/discrimination/cut-off. The alias list further widens matching (cutoff, 诊断效能, 敏感度特异度). It does not name a when-not condition or point to alternatives like delong_auc_compare for comparing two AUCs, 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.
Sample size & power / 样本量计算（设计口径） | USE WHEN: calculate how many subjects are needed (two means / two proportions / correlation / survival), or solve for power | ALIASES: 样本量, 要做多少例, 需要多少病人, sample size, power calculation, 把握度, 最少例数, n per group | RETURNS: 每组例数与合计
| Name | Required | Description | Default |
|---|---|---|---|
| sd | No | 标准差 | |
| alpha | No | 显著性水平，默认 0.05 | |
| power | No | 把握度，默认 0.8 | |
| effect | No | 预期效应量/差值 | |
| dropout | No | 脱落率 | |
| sample_type | No | 计算类型：两组均数/两组率/相关/生存 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly/openWorld=false/non-destructive, so the safety profile is covered. The description adds value beyond that by declaring the return shape ('每组例数与合计'), which matters since no output schema exists, and by framing results in design terms ('设计口径'). It does not state handedness of the returned numbers beyond the per-group/total split or whether dropout inflation is applied to the reported total.
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 labelled USE WHEN / ALIASES / RETURNS structure is front-loaded and scannable for an agent. The alias list is long but serves a real disambiguation purpose (Chinese and English phrasings), and no sentence is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter, zero-required computation tool with no output schema, the description supplies both the trigger conditions and the return format, which is the essential missing context. Minor gaps remain around default behavior when required-by-design fields are omitted and how dropout interacts with the reported n.
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 (sd, alpha, power, effect, dropout, sample_type) is already documented in the schema with defaults noted for alpha and power. The description only implicitly adds meaning by listing the four design types, which mirrors the sample_type description rather than adding semantics such as which parameters are ignored for a given design.
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 verb+resource (calculate sample size / power) and enumerates the four supported designs (two means, two proportions, correlation, survival), which matches the sample_type field. It is clearly distinguishable from siblings like animal_sample_size or qpcr_bayesian_design, which address different subject populations.
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 'USE WHEN' block gives explicit triggers, including the 'solve for power' variant, so an agent knows the tool is bidirectional. It stops short of naming alternatives or exclusions (e.g., when to prefer animal_sample_size or qpcr_bayesian_design), so routing between similar powered-design 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.
List every tool on this server as a compact catalogue (name / when-to-use / returns / required params / cost). 列出三域医研全部动作摘要。仅在不确定该用哪个工具时调用；已知工具名可直接调用对应工具。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already tells the agent this is a safe, non-mutating read, so the description only needs to add what is actually returned — and it does, by naming the five catalogue fields including "cost". It does not say how large the listing is or whether it is truncated/paginated across ~95 tools, which is the one behavioral detail still missing.
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 payload statement is front-loaded and the routing rule follows immediately, with zero filler. The one inefficiency is that the English and Chinese sentences carry the same two pieces of information, so the definition is roughly twice as long as its content requires.
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 carries the return-value burden itself — and listing the five fields per entry largely does that. What remains unspecified is output form and size (raw text vs. structured, and behavior with ~95 tools), which would matter for an agent planning to parse the 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?
The tool takes zero parameters, so the baseline is 4. The description implicitly confirms no input is required, and there is nothing beyond that for it to clarify against an 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?
"List every tool on this server as a compact catalogue" gives a specific verb (list) and resource (server tool catalogue), then enumerates exactly the fields returned (name / when-to-use / returns / required params / cost). No sibling does discovery, so an agent can distinguish it from the 90+ concrete analysis tools without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The Chinese sentence states both the trigger and the exclusion explicitly: call it only when unsure which tool to use, and call the specific tool directly if the name is already known. This is a complete when/when-not routing rule with the alternative named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reproducible SAS/R/Python code / 生成可复现 SAS/R 代码 | USE WHEN: generate the SAS / R / Python code that reproduces a given analysis | ALIASES: SAS代码, R代码, 复现代码, reproducible code, Python代码, 统计代码 | RETURNS: 推荐统计方法与代码
| Name | Required | Description | Default |
|---|---|---|---|
| design | Yes | 研究设计 | |
| n_groups | No | 组数 | |
| outcome_type | No | 结局类型 |
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 structurally. The description adds only 'RETURNS: 推荐统计方法与代码', which usefully signals that the tool also recommends a statistical method, not just code. It says nothing about whether the generated code is executed, validated, or version-pinned, which matters for a 'reproducible code' claim.
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 pipe-delimited USE WHEN / ALIASES / RETURNS layout is front-loaded and scannable, with the purpose stated first. It is somewhat keyword-stuffed (aliases in two languages, bilingual title repetition) but no sentence is truly 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 one-line RETURNS note is the only return-value signal and is vague — it does not say whether output is one script or three language variants. For a 3-parameter generation tool with full annotation coverage this is adequate but leaves real gaps around output shape and language selection.
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 'design', 'n_groups' and 'outcome_type' are already documented in the schema. The description adds no meaning beyond that — it never explains how design/outcome_type steer method or language 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 gives a specific verb and resource: 'generate the SAS / R / Python code that reproduces a given analysis', which is far clearer than the bare name 'sas_r_code' (which omits Python entirely). It does not, however, contrast itself with plausible siblings such as stats_toolbox or dataframe_parse, 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?
'USE WHEN: generate the SAS / R / Python code that reproduces a given analysis' is an explicit trigger condition, which is stronger than most siblings' implicit usage. It offers no when-not guidance and names no alternative tool for cases where the agent wants analysis results rather than code.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Single-cell type annotation / 单细胞细胞类型注释 | USE WHEN: automatically annotate cell types in single-cell clusters | ALIASES: 细胞类型注释, annotation, 单细胞注释, cell type, 自动注释 | RETURNS: 细胞类型注释
| Name | Required | Description | Default |
|---|---|---|---|
| data_json | Yes | 必填。数据对象（不是字符串）。矩阵形式：{"matrix": [[行1各列数值...], [行2...]], "rows": ["基因/特征名"], "cols": ["样本名"]}；组学结果另可带 {"groups": ["组A","组A","组B"...]}（与 cols 一一对应）、{"p_values": [...], "log2fc": [...]}（若已有差异结果）。实测缺此字段会被拒：Field required: data_json |
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 little behavioral context beyond saying 'automatically' and repeats the return label '细胞类型注释' without explaining the annotation method, limitations, or output structure.
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 usage condition, but it is formatted as keyword metadata rather than natural guidance. The ALIASES list and the redundant 'RETURNS: 细胞类型注释' add little 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?
For a single-cell annotation tool with no output schema, the description should clarify what the annotation result looks like or what method is used. Instead, 'RETURNS: 细胞类型注释' merely repeats the tool's purpose, leaving return semantics and method expectations underspecified.
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 input schema has 100% description coverage and thoroughly documents the single data_json parameter, including its required shape. The description adds no parameter semantics beyond what the schema already provides, 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 states a specific verb and resource: automatically annotate cell types in single-cell clusters. This is clear enough to distinguish it from general clustering or marker detection, though it does not explicitly name alternatives like scrna_cluster or scrna_markers.
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 'USE WHEN' clause gives a clear usage context: automatically annotating cell types in single-cell clusters. It does not provide when-not-to-use guidance or name alternative sibling tools, but the intended context is explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Single-cell clustering / 单细胞分析 | USE WHEN: cluster and embed single-cell data (UMAP) | ALIASES: 单细胞, scRNA, 聚类降维, UMAP, Seurat, single cell | RETURNS: 聚类结果与 UMAP
| Name | Required | Description | Default |
|---|---|---|---|
| n_pcs | No | 主成分数 | |
| data_json | Yes | 单细胞矩阵 | |
| min_genes | No | 最少基因数 | |
| max_mito_pct | No | 线粒体比例上限 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/non-destructive/closed-world, so the safety profile is covered. The description adds only the return contents ('聚类结果与 UMAP') and omits a meaningful behavior: min_genes and max_mito_pct mean this tool also performs QC filtering before clustering, which is a non-obvious side effect of a tool titled 'cluster'.
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?
Pipe-delimited fields front-load the purpose, trigger, aliases, and return value with no filler. It is slightly telegraphic, but every segment carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter tool taking a nested object matrix and returning no output schema, the definition covers purpose and rough returns, which is adequate. The gap is the data_json matrix format — its internal shape is unstated in both schema and description, leaving the required parameter underspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters and the baseline is 3. The description adds no interpretation of n_pcs, min_genes, or max_mito_pct beyond their schema text, and gives no hint about the expected structure of the nested data_json matrix.
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 operation ('cluster and embed single-cell data (UMAP)') on a concrete resource, which is clearly distinct from scrna_annotate, scrna_markers, and flow_cluster. It stops short of naming those siblings, so an agent must infer the boundary rather than being told it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'USE WHEN' clause gives an explicit trigger condition, which is more than most definitions offer. It does not say when to avoid this tool or route to scrna_annotate/scrna_markers instead, so the alternative-selection guidance is incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Single-cell marker genes / 单细胞 Marker 基因 | USE WHEN: find marker genes per cluster | ALIASES: marker基因, 各群marker, markers, 差异标记, cluster markers | RETURNS: 各群 marker
| Name | Required | Description | Default |
|---|---|---|---|
| data_json | Yes | 必填。数据对象（不是字符串）。矩阵形式：{"matrix": [[行1各列数值...], [行2...]], "rows": ["基因/特征名"], "cols": ["样本名"]}；组学结果另可带 {"groups": ["组A","组A","组B"...]}（与 cols 一一对应）、{"p_values": [...], "log2fc": [...]}（若已有差异结果）。实测缺此字段会被拒：Field required: data_json |
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 nothing beyond that: no mention of which statistical method is used, minimum cluster size, whether groups are auto-derived from cols, or any runtime expectation. 'RETURNS: 各群 marker' is a restatement, not behavioral detail.
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-loads the purpose and trigger, which is good. The ALIASES block is largely padding for an agent consumer, and the RETURNS line occupies space without conveying 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 and a nested-object input, the description should explain what comes back — a table of markers per cluster with p-values/log2FC columns, for example — but only says '各群 marker'. For a per-cluster marker computation whose result shape drives downstream use, this leaves a real gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single required parameter and schema description coverage is 100%, with the schema itself fully spelling out the matrix/rows/cols/groups/p_values structure. The description adds no additional meaning about data_json, 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 the resource (single-cell marker genes) and, via 'USE WHEN: find marker genes per cluster', a specific operation and scope, so an agent can tell it computes per-cluster markers. It does not distinguish itself from nearby siblings such as scrna_cluster, scrna_annotate, or differential_expression, which keeps it below a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'USE WHEN: find marker genes per cluster' supplies an explicit trigger condition, which is more than nothing. However, there are no exclusions and no named alternatives, so an agent choosing between this and differential_expression or scrna_annotate 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.
SHAP single-case explanation / SHAP 单样本解释 | USE WHEN: explain why one patient was predicted high risk (feature contributions) | ALIASES: SHAP, 解释预测, 为什么高风险, 特征贡献, explain prediction, 可解释性 | RETURNS: SHAP 贡献图
| Name | Required | Description | Default |
|---|---|---|---|
| csv_data | No | CSV 文本 | |
| model_type | No | 模型类型 | |
| sample_index | No | 样本序号 |
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 only 'RETURNS: SHAP 贡献图', which is a useful output hint but says nothing about compute cost, what happens with an invalid sample_index, or that all inputs are effectively mandatory despite being optional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The card format is front-loaded and structured: purpose, trigger, aliases, return value. The ALIASES block is keyword padding rather than explanation, but it is compact and does serve discovery, so waste is limited.
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 analytical tool with no output schema, the description covers the purpose and a one-line return format. It omits input requirements (all three parameters are marked optional yet functionally necessary) and any parameter detail on model_type, leaving a real gap 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% and all three parameters are documented in the schema, so the baseline of 3 applies. The description adds only the implied notion that sample_index selects a single case; it does not enumerate valid model_type values or CSV format expectations.
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 title and first sentence name a specific technique and scope: SHAP single-case explanation, i.e. per-sample feature contributions. The USE WHEN line adds a concrete example scenario, making it distinguishable from aggregate-model siblings, though no sibling is explicitly named as the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is an explicit USE WHEN scenario ('explain why one patient was predicted high risk'), which is more than most siblings offer. However, there is no when-not guidance, no mention of alternatives (e.g. global feature importance vs single-case), and no stated prerequisites such as needing a trained model plus CSV data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
SMD balance check / SMD 均衡性检查 | USE WHEN: standardized mean differences before/after PSM or IPTW (covariate balance) | ALIASES: SMD, 标准化均数差, 均衡性, balance, 匹配后均衡, 协变量平衡, love plot | RETURNS: 各协变量 SMD 与均衡判断
| Name | Required | Description | Default |
|---|---|---|---|
| treatment | Yes | 分组 0/1 | |
| covariates | Yes | 协变量矩阵：每行一个样本、每列一个变量 |
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 and the description needs only to add context. The 'RETURNS' line usefully discloses that per-covariate SMDs plus a balance decision come back, which matters without an output schema. However, it never states the balance threshold applied (e.g. 0.1) or how the judgement is derived, which is the one behavioral detail an agent would actually want.
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 piped metadata format front-loads the actionable 'USE WHEN' and 'RETURNS' fields, so the key facts are read first. The bilingual alias string is somewhat long but serves a real retrieval purpose for Chinese-language requests. No filler sentences, though the duplicated title is mild 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 two-parameter, read-only computation the definition covers the essentials: what it computes, when to reach for it, and what comes back. The gaps are minor — no output schema exists, and the description does not explain the balance-decision criterion, but the RETURNS line keeps it usable as-is.
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%: 'treatment' is documented as group labels 0/1 and 'covariates' as a sample-by-variable matrix, so the schema carries the parameter burden. The description adds no further semantics — no note on ordering alignment between the group vector and matrix rows, nor on handling of categorical covariates. 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 'USE WHEN' clause states the exact statistic and setting: standardized mean differences before/after PSM or IPTW for covariate balance. That is a specific analytic operation rather than a restatement of the name. It does not explicitly contrast itself with likely adjacent siblings such as propensity_score_matching or iptw_weighting, which supply the matched/weighted data this tool then checks.
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 triggering context (post-PSM or post-IPTW balance assessment) and the ALIASES list helps an agent recognize synonymous requests like 'love plot' or '协变量平衡'. It stops short of the 5 bar because it names no exclusions or explicit alternatives — an agent must infer that raw unmatched comparisons or the upstream matching itself belong to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Species dose conversion / 种属剂量换算 | USE WHEN: convert an animal dose to a human equivalent dose (mg/kg ↔ mg/m², FDA guidance) | ALIASES: 种属换算, 动物剂量换人, 剂量换算, species conversion, HED, mg/m2, 体表面积法 | RETURNS: 换算后剂量与依据
| Name | Required | Description | Default |
|---|---|---|---|
| source_dose | Yes | 来源剂量 | |
| source_species | Yes | 来源物种 | |
| target_species | Yes | 目标物种 |
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 real value by naming the conversion basis (body-surface-area method per FDA guidance) and stating the return content ('换算后剂量与依据'), but says nothing about supported species, input validation, or failure behavior for unrecognized species.
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?
Piped, front-loaded, and free of filler prose; the operative 'USE WHEN' clause appears before aliases and return info. The ALIASES block is slightly bulky but plausibly aids query matching rather than padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter read-only calculator with no output schema, the description covers purpose, method, and return content adequately. The main omission is any indication of valid species values or the unit expected for source_dose, which is a real gap given there are no enums and no nested structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description contributes unit context (mg/kg vs mg/m²) that the terse Chinese schema labels ('来源剂量') do not, but it never states which unit source_dose must be supplied in, and no species enum exists to constrain the free-text species fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('convert an animal dose to a human equivalent dose'), plus the exact unit transformation (mg/kg ↔ mg/m²) and the methodological standard (FDA guidance). This is clearly separable from nearby siblings such as animal_dose_volume or renal_dose_adjust.
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 'USE WHEN' clause gives an explicit triggering condition (animal → human equivalent dose), which is exactly the routing signal an agent needs. It does not name a when-not case or a specific alternative sibling, 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.
Statistics toolbox (97 tests) / 统计中心（97 个统计工具统一入口） | USE WHEN: any statistical test not covered by a dedicated tool: Kappa, ICC, Bland-Altman, VIF, PCA, cluster, Friedman, McNemar, runs test, sign test, trend chi-square, meta-analysis pieces — pass tool_id | ALIASES: 统计检验, Kappa, ICC, Bland-Altman, VIF, PCA, 聚类, Friedman, McNemar, 游程 | RETURNS: 该统计工具的完整结果（含统计量、P 值、95%CI、解读）
| Name | Required | Description | Default |
|---|---|---|---|
| payload | No | 该工具需要的数据字段（不要把数据包成字符串）。常见字段：group1/group2（两组数值数组）、groups（{组名:[数值]}）、values、x/y、time/event、gold/score、es/se（效应量与标准误）、m1/m2、r1/r2、row_var/col_var、features/label | |
| tool_id | Yes | 统计工具 id，必须是下列之一：比较差异[ttest,welch,mwu,wilcoxon,anova,welchAnova,kw,friedman,rmAnova,ancova,chi2,fisher,mcnemar,cochranQ,posthoc,multicorr,homogeneity,normality,brunner,signTest,runsTest,effectSize,pInverse]、找关系[pearson,spearman,kendall,linearReg,multiLinear,logistic,logisticModel,vif,regDiag,icc,blan |
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 the return contract (statistic, P value, 95% CI, interpretation) that annotations cannot express. It does not disclose failure behavior for an invalid or mismatched tool_id/payload combination, which for a 97-way dispatcher would be the most valuable added detail.
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 USE WHEN condition before aliases and returns, and each tag block carries distinct information. The multilingual ALIASES list is long relative to its value for an agent and adds bulk, but it is at least clearly delimited rather than woven into 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 2-parameter dispatcher with no output schema, the description covers what it does, when to call it, and the return shape. What is missing is guidance on composing the nested payload per selected tool and on behavior when tool_id and payload disagree, which matters given 97 possible parameter shapes.
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 payload property already enumerates the common field shapes (group1/group2, groups, values, x/y, es/se, features/label), so the schema does the heavy lifting. The description only echoes 'pass tool_id'. Baseline 3 applies since little meaning is added beyond the structured fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource (a bundle of 97 statistical tests behind a single tool_id) and gives concrete example families (Kappa, ICC, Bland-Altman, VIF, PCA, Friedman, McNemar, runs test). It explicitly positions itself relative to siblings with 'any statistical test not covered by a dedicated tool'. The boundary is still fuzzy, however: siblings like tukey_hsd, dunn_posthoc and two_way_anova overlap with tool_ids listed in the schema (posthoc, anova), so an agent cannot fully resolve routing 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?
A clear 'USE WHEN' clause states the selection condition: tests lacking a dedicated tool, with a concrete list of covered test families. This is more than implied usage. It stops short of explicit exclusions or a decision rule for the overlapping sibling tools (e.g., when to prefer tukey_hsd over this tool's posthoc id), which keeps it below a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Study design advisor / 研究设计向导 | USE WHEN: the user has a research question but does not know which study design to use (RCT / cohort / case-control / cross-sectional / diagnostic accuracy) | ALIASES: 研究设计选哪个, 设计向导, 用什么研究设计, study design, which design, 研究类型, 队列还是病例对照 | RETURNS: 推荐研究设计与理由
| Name | Required | Description | Default |
|---|---|---|---|
| pico | Yes | 研究问题/PICO 描述 | |
| feasibility | No | 可行性条件（病例量、周期、经费） |
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 by structured data. The description adds that it returns a recommended design plus rationale, which is useful, but says nothing about how it handles ambiguous questions, whether the recommendation is advisory-only, or how the optional feasibility input alters the output. With annotations doing the heavy lifting, this is adequate but 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?
The pipe-delimited USE WHEN / ALIASES / RETURNS structure is front-loaded and scannable, and every section serves tool selection or disambiguation. The alias block is long (eight phrases, bilingual), which is functional for matching but is the bulkiest part of the definition.
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 advisory tool with no output schema, the definition supplies the trigger condition, the design space, and the shape of the return value. What is missing is minor: how the optional feasibility input changes the recommendation and what to do when the question is under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both 'pico' and 'feasibility' are already documented in the schema. The description adds no syntax, format, or example guidance for either parameter and never mentions them directly, so the schema carries the full burden. 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 the specific resource (study design selection) and enumerates the candidate designs it chooses between (RCT / cohort / case-control / cross-sectional / diagnostic accuracy), which lets an agent distinguish it from analysis-oriented siblings like survival_cox or roc_auc. It does not explicitly differentiate from adjacent planning tools such as pico_refine or sample_size_calculator, keeping it short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'USE WHEN' clause gives a clear triggering condition: the user has a research question but no design chosen. That is actionable context, but there are no exclusions or named alternatives for the case where the design is already fixed (e.g., 'use sample_size_calculator once the design is decided').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Survival analysis (KM + Cox) / 生存分析（KM/Cox 全流程） | USE WHEN: follow-up time and event data: survival curves, median survival, hazard ratios, log-rank, multivariable Cox | ALIASES: 生存分析, Cox回归, HR, 风险比, log-rank, 中位生存, 随访, 生存率, hazard ratio | RETURNS: 生存曲线、中位生存、HR、log-rank P
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | 逐行数据，每行含时间/事件/分组/协变量 | |
| time_col | No | 随访时间列名 | |
| event_col | No | 结局事件列名（1=事件） | |
| group_col | No | 分组列名 | |
| analysis_type | No | km 或 cox | |
| covariate_cols | No | Cox 协变量列名 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the return payload (curves, median survival, HR, log-rank P), which is genuinely useful, but says nothing about modeling assumptions such as proportional hazards, censoring coding, or minimum sample 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?
The pipe-delimited layout is front-loaded and scannable: purpose, use condition, aliases, returns. The alias list is long but serves search/retrieval value in both languages; no sentence is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a six-parameter statistical modeling tool the definition covers what it does, when to use it, and what it returns, with no output schema needed for return values. It omits the conditional parameter relationships (cox requiring covariate_cols, group_col being optional for multivariable models) and any note about reference-group handling, which an agent must infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and each of the six parameters has a Chinese description covering time, event coding (1=event), group, analysis type (km/cox), and covariate columns. The description adds no guidance beyond the schema — notably it never explains which parameters are required under analysis_type='cox' versus 'km', though the baseline of 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 names a specific method set (KM curves plus multivariable Cox) and enumerates concrete outputs — survival curves, median survival, hazard ratios, log-rank P — so the resource is unambiguous. It does not, however, distinguish itself from the sibling kaplan_meier or animal_survival_km, which an agent could reasonably confuse with this 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?
The 'USE WHEN: follow-up time and event data' clause gives a clear triggering condition (time-to-event data with censoring, subgroup comparison, multivariable adjustment). It stops short of explicit exclusions or naming the simpler KM-only sibling as the alternative for single-curve cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Table 1 (baseline characteristics) / 生成 Table 1（基线特征表） | USE WHEN: build the paper's first table: baseline characteristics by group with P values | ALIASES: Table 1, 基线表, 基线特征表, 人口学表, 第一张表, baseline table, characteristics table, 组间比较表 | RETURNS: Table 1 表格 + 可选段落
| Name | Required | Description | Default |
|---|---|---|---|
| file_id | Yes | 数据文件 id（可不填，助手会自动用你最近上传的数据） | |
| test_method | No | auto/t/nonparametric/chi2 | |
| group_variable | Yes | 分组变量列名 | |
| generate_paragraph | No | 是否同时生成论文表述段落 | |
| variables_to_include | No | 纳入的变量列名 |
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 only the return shape ('Table 1 表格 + 可选段落') and nothing about test-method auto-selection behavior, variable-type handling, or what happens when file_id is omitted (that detail lives in the schema). Useful but thin given the annotations already carry the safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose, then usage, aliases, and returns in a compact pipe-delimited layout with no filler prose. The long alias list is somewhat bulky but serves retrieval matching rather than padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a five-parameter, two-required analytics tool with no output schema, the definition covers what it produces and when to call it, and the schema covers every parameter. The only missing piece is disambiguation from the subgroup sibling, which is not addressed.
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 five parameters (file_id, group_variable, test_method, variables_to_include, generate_paragraph) are already documented in the schema. The description adds no additional parameter meaning, 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 deliverable: 'build the paper's first table: baseline characteristics by group with P values', which is far more concrete than the tool name or title alone. It does not, however, distinguish itself explicitly from the sibling table_one_subgroup, leaving the agent to infer the baseline-vs-subgroup 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 'USE WHEN' clause gives a clear trigger condition (constructing the first manuscript table with group comparisons and P values). There are no explicit exclusions or named alternatives such as table_one_subgroup, but the usage context is unambiguous enough to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Subgroup Table 1 / 分组 Table 1（亚组表） | USE WHEN: baseline characteristics split by a subgroup variable (e.g. by sex, by centre) | ALIASES: 亚组基线表, 分层基线表, subgroup table, stratified baseline, 按某变量分层 | RETURNS: 亚组表
| Name | Required | Description | Default |
|---|---|---|---|
| file_id | Yes | 数据文件 id | |
| group_variable | Yes | 分组变量 | |
| subgroup_variable | Yes | 分层变量 | |
| variables_to_include | No | 纳入变量 |
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 fully covered without the description. The only added behavioral claim is the thin 'RETURNS: 亚组表', which restates the title rather than describing output shape, statistics computed, or table layout.
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 pipe-delimited structure is tightly front-loaded: purpose, use-when, aliases, returns. The alias list is long but serves retrieval matching across English and Chinese phrasings; no sentence is wasted, though 'RETURNS: 亚组表' is near-zero 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 and a returns note that merely echoes the title, the description leaves the agent unsure what the table contains or how it differs structurally from the baseline table. Parameter documentation is handled by the schema, so the remaining gap is output expectation, which is only minimally addressed.
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 (file_id, group_variable, subgroup_variable, variables_to_include) are already documented in the schema. The description's mention of stratification reinforces subgroup_variable but adds no syntax, format, or selection semantics beyond the schema, 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 gives a specific verb-equivalent and resource: baseline characteristics split by a subgroup variable, with concrete examples (by sex, by centre). It does not name the closest sibling table_one_baseline, so an agent must infer the distinction from the word 'subgroup' 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?
An explicit 'USE WHEN' clause states the triggering condition with two examples, which is more than most sibling tools offer. It stops short of exclusions, i.e. it never says to use table_one_baseline instead when no stratification is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Text overlap self-check / 文字重合度自查 | USE WHEN: compare a passage with the user's own previous papers (self-plagiarism check) | ALIASES: 查重, 文字重合度, 重复率, overlap, self plagiarism, 相似文献 | RETURNS: 重合度与相似文献
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | 待查文本 | |
| top_n | No | 返回条数 |
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 elsewhere. The description adds only "RETURNS: 重合度与相似文献", with no disclosure of corpus size, text length limits, matching thresholds, or latency. Useful but thin 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 pipe-delimited format is compact and front-loads the EN/ZH name ahead of the routing keyword. The ALIASES block is keyword-heavy but serves retrieval, and no sentence is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only two parameters and no output schema, the definition is nearly sufficient, but the "RETURNS" line does not describe the shape of the result and the source of the comparison corpus (the user's own prior papers) is left unexplained. That ambiguity matters 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% and both parameters are already documented in the schema (text, top_n). The description adds no meaning about what top_n bounds or what form the overlap score takes, 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?
"Text overlap self-check" plus the USE WHEN clause states a specific resource (a passage vs. the user's own prior papers) and a specific operation (self-plagiarism comparison), which separates it from literature_search_pmc, pubmed_search, and citation_verify. It stops short of naming a sibling as the alternative, so an agent must infer the boundary rather than being told it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The USE WHEN clause gives a concrete triggering context: comparing a passage against the user's own previously published work. No when-not conditions or explicit alternatives are given, and the description never says whether the user's prior papers must already be indexed/uploaded for the check to work.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Toxicity prediction (hERG / DILI) / 毒性预测（hERG/DILI） | USE WHEN: cardiac (hERG) and liver (DILI) toxicity risk from a SMILES string | ALIASES: 毒性预测, hERG, DILI, 心脏毒性, 肝毒性, toxicity, SMILES | RETURNS: 毒性风险分级
| Name | Required | Description | Default |
|---|---|---|---|
| smiles | Yes | 化合物 SMILES | |
| endpoints | No | 终点：hERG/DILI/Ames |
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 fully covered and the description does not need to restate it. The description adds one piece of behavioral context, "RETURNS: 毒性风险分级" (graded toxicity risk), which is useful given there is no output schema. Beyond that it says nothing about the underlying model, how grades are defined, or whether endpoints are batched — hence a 3, not higher.
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 pipe-delimited layout is front-loaded and scannable, with USE WHEN placed before ALIASES. However, the alias block is largely padding — 毒性预测, hERG, DILI, toxicity and SMILES simply restate the title and the input, and the bilingual duplication of the title at the start consumes tokens without adding selection 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?
For a two-parameter, read-only, closed-world tool with no output schema, an agent has enough to call it: what it predicts, what input it needs, and roughly what comes back. It is still missing the interpretation of the risk grades and any mention of the Ames endpoint exposed in the schema, which an agent would need to use results 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 both parameters are already documented (smiles = compound SMILES; endpoints = hERG/DILI/Ames). The description adds no meaning beyond the schema and never mentions the endpoints parameter or the Ames option at all. 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 verb-and-resource pair: predicting cardiac (hERG) and liver (DILI) toxicity risk from a SMILES string. This is concrete enough to separate it from neighbors such as protein_physchem or drug_interaction_check. It does not explicitly contrast itself with the closest sibling, toxicology_assess, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"USE WHEN: cardiac (hERG) and liver (DILI) toxicity risk from a SMILES string" gives an explicit trigger condition and required input. There is no when-not guidance and no named alternative (e.g., when to prefer toxicology_assess over this endpoint-level predictor), which is the only missing piece.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Toxicology assessment / 毒理评估 | USE WHEN: nonclinical toxicology risk: hERG / DILI / genotoxicity, overall risk level | ALIASES: 毒理评估, 毒性风险, 遗传毒, toxicology, nonclinical safety, 安全评价 | RETURNS: 毒性风险分级
| Name | Required | Description | Default |
|---|---|---|---|
| logP | No | logP | |
| hERG_IC50_nM | No | hERG IC50 (nM) | |
| daily_dose_mg | No | 日剂量 (mg) | |
| expected_Cmax_nM | No | 预期 Cmax (nM) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety profile is covered by structured data. The description only adds 'RETURNS: 毒性风险分级', which conveys that output is a risk tier, but says nothing about how risk is graded, thresholds, or what happens when optional inputs are omitted. That is a modest addition beyond annotations, fitting a 3.
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 pipe-delimited format is front-loaded with the purpose and use case, and fits in one line with no filler prose. The ALIASES segment is largely redundant noise and the bilingual duplication adds length without new meaning, keeping it short of a 5.
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, no-output-schema assessment tool, the description covers purpose, trigger, and a rough return concept. It is still incomplete on two points an agent would want: how the risk tier is determined (e.g., dependency on Cmax/IC50 ratio or dose) and differentiation from toxicity_predict. Adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the four parameters (logP, hERG_IC50_nM, daily_dose_mg, expected_Cmax_nM) are already documented. The description mentions hERG in the use case but adds no syntax, units, or interaction guidance beyond the schema, 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 names a concrete assessment domain (nonclinical toxicology risk covering hERG, DILI, genotoxicity) and the output concept (overall risk level / 毒性风险分级), so an agent can tell what the tool does without opening the schema. It does not, however, distinguish itself from the sibling toxicity_predict, leaving genuine ambiguity between two closely named risk tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'USE WHEN' clause gives a clear triggering context: nonclinical toxicology risk with hERG/DILI/genotoxicity endpoints. There is no guidance on when NOT to use it, and no mention of toxicity_predict or pk_pd_assess as alternatives, so the routing guidance is incomplete for a crowded sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tukey HSD post-hoc / 多组两两比较（Tukey HSD） | USE WHEN: pairwise comparisons after one-way ANOVA with family-wise error control | ALIASES: Tukey, HSD, ANOVA后续, 两两比较, post hoc, 多重比较 | RETURNS: 两两比较 P 值
| Name | Required | Description | Default |
|---|---|---|---|
| groups | Yes | {组名: [数值...]} |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnly/non-destructive/closed-world annotations already establish that this is a safe, local computation, so the description need not cover safety. 'RETURNS: 两两比较 P 值' adds a small amount of information about the output, but it does not say whether the P values are adjusted, whether confidence intervals are included, or whether model assumptions are checked.
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 uses a piped and labeled layout (USE WHEN / ALIASES / RETURNS); it front-loads the purpose and contains no filler. The ALIASES segment is keyword-heavy but serves a genuine discovery function for Chinese and English phrasings.
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, single-parameter, read-only statistical tool, and the description covers the intent and the rough return type. Still, it leaves out statistical assumptions (normality, homogeneity of variance) and the shape of the result, which matter for using the tool correctly in a pipeline.
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 one parameter at 100% schema coverage, and the schema documents it as '{组名: [数值...]}' with a worked example, so the baseline is 3. The description adds nothing about constraints such as the minimum number of groups, unequal group sizes, or missing values.
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 (Tukey HSD post-hoc) and resource (pairwise comparisons across groups), so the purpose is unambiguous. It does not separate itself from the sibling dunn_posthoc, which is the non-parametric counterpart, so an agent must know the difference between the two 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?
'USE WHEN: pairwise comparisons after one-way ANOVA with family-wise error control' states the antecedent condition for calling this tool clearly. However, it gives no exclusion rule (e.g., use dunn_posthoc for non-normal data, or two_way_anova when there are two factors), which would have routed the agent decisively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tumour growth inhibition (TGI) / 抑瘤率 TGI | USE WHEN: compute TGI (%) from control vs treated tumour volumes, with a group comparison | ALIASES: 抑瘤率, TGI, 肿瘤抑制率, tumour growth inhibition, 抑瘤实验, 药效评价 | RETURNS: TGI 与统计检验
| Name | Required | Description | Default |
|---|---|---|---|
| ctrl_volumes | Yes | 对照组体积 | |
| treat_volumes | Yes | 给药组体积 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, non-destructive and closed-world, so the safety profile is covered. The description adds that the tool also performs a group comparison and returns statistical testing, which is useful behavioral context beyond the annotations, but it does not say which test or how results are shaped.
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 pipe-delimited line with the purpose first, then usage, aliases, and return summary — front-loaded and scannable. The long bilingual alias list earns its place for query matching but is the bulkiest 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 two-parameter calculation tool with full schema coverage, the definition covers purpose, inputs, and a rough return note. With no output schema, the vague 'returns TGI and statistical testing' leaves the agent unable to anticipate output fields or which test is applied.
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 (control-group volumes, treated-group volumes) are already documented in the schema. The description only restates that mapping; it adds no detail on units, whether array entries are per-animal measurements, or minimum sample sizes, which the schema leaves 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 states a specific verb and output ('compute TGI (%)') on a specific resource ('control vs treated tumour volumes'), so an agent can tell this apart from a summary/plotting tool like tumor_volume_curve. It does not name that sibling explicitly, so differentiation is inferred rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'USE WHEN' clause gives a clear triggering condition: compute TGI from control vs treated volumes with a group comparison. No when-not conditions or named alternatives are given, so the agent must infer boundaries against tumor_volume_curve or stats_toolbox.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tumour microenvironment / 肿瘤微环境分析 | USE WHEN: assess tumour immune microenvironment from TILs / CD8 / PD-L1 data (typing + prognosis hint) | ALIASES: 肿瘤微环境, TME, 免疫浸润, TIL, PD-L1, CD8, immune microenvironment | RETURNS: 微环境分型与预后提示
| Name | Required | Description | Default |
|---|---|---|---|
| tils_pct | No | TILs 占比 | |
| cd8_count | No | CD8+ 细胞数 | |
| pd_l1_pos | No | PD-L1 阳性率 | |
| cancer_type | No | 癌种 |
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 fully covered. The description adds only the 'RETURNS: 微环境分型与预后提示' line, which is useful given there is no output schema, but it is terse and does not explain how the typing is derived or what the prognosis hint consists of.
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?
Pipe-delimited sections with USE WHEN, ALIASES and RETURNS are front-loaded and scannable, with no filler sentences. The alias list is somewhat long but serves retrieval, which is a legitimate cost.
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 four-parameter analytic tool with no output schema, the description explains what goes in and roughly what comes out, but leaves the return structure and the meaning of 'prognosis hint' undefined. An agent could call it correctly but could not predict the response shape.
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 (tils_pct, cd8_count, pd_l1_pos, cancer_type) are already documented in the schema. The description names three of the inputs but adds no units, ranges, or guidance on which combination is needed; 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 analytic action (assess tumour immune microenvironment) plus the concrete inputs it works from (TILs / CD8 / PD-L1) and the output it produces (typing + prognosis hint). An agent can distinguish it from adjacent tools like ihc_hscore or mif_phenotype, though the description never explicitly contrasts 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?
The 'USE WHEN' clause gives an explicit trigger condition with the required data types, which is the right level of guidance for a computation tool. There are no when-not conditions and no named alternative sibling, 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.
Tumour volume & growth curve / 肿瘤体积计算 | USE WHEN: tumour volume from caliper length/width and the growth curve over days | ALIASES: 肿瘤体积, 长短径算体积, 生长曲线, tumor volume, caliper, 生长抑制曲线 | RETURNS: 体积与生长曲线
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | 天数 | |
| widths | No | 短径 | |
| lengths | No | 长径 | |
| group_name | No | 组名 |
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 by structured data. The description adds only 'RETURNS: 体积与生长曲线', and it omits units (mm vs cm, mm³) and the volume formula, which materially affect a calculation tool with no output 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 piped layout front-loads the 'USE WHEN' trigger and the return summary, and no sentence is wasted. The bilingual alias run is somewhat noisy padding, but it is confined to a single labelled segment.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter statistics tool with no required fields and no output schema, the definition should say what happens with empty or mismatched-length arrays and what units to supply. It declares the return type, which partially compensates, but unit and validation behavior 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 description coverage is 100% and the Chinese item descriptions (天数, 短径, 长径, 组名) document each field, so the baseline of 3 applies. The description adds the linking idea that lengths/widths are caliper measurements, but contributes no unit conventions or array-length-matching rules beyond what the schema implies.
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 operation and inputs ('tumour volume from caliper length/width and the growth curve over days'), and the alias list reinforces the caliper-based volume computation. It does not, however, distinguish itself from the sibling 'tumor_growth_inhibition', which an agent could plausibly confuse it with when a growth-curve request arrives.
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 'USE WHEN' clause gives an explicit trigger: caliper length/width measurements plus a day series. There are no exclusions or named alternatives, so an agent still has to infer that 'tumor_growth_inhibition' is the right tool when percent inhibition rather than raw volume is wanted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Two-way ANOVA / 双因素方差分析 | USE WHEN: two factors: main effects and interaction | ALIASES: 双因素方差分析, two-way ANOVA, 交互作用, 主效应, 两个因素 | RETURNS: 主效应与交互
| Name | Required | Description | Default |
|---|---|---|---|
| values | No | 观测值 | |
| group_a | Yes | 因素 A 水平 | |
| group_b | Yes | 因素 B 水平 |
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 only 'RETURNS: 主效应与交互', which is a thin output hint with no mention of assumptions (balanced design, normality), error behavior, or result structure.
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 piped label format is scannable and front-loads the method name, but the repeated bilingual title plus an ALIASES list containing overlapping English/Chinese variants of the same term consumes space without adding selection 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?
For a three-parameter statistical tool with no output schema, the definition covers what the method is and roughly what it returns. It omits design requirements and result shape, which leaves meaningful gaps for an agent that needs to prepare inputs 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 each parameter (values, group_a, group_b) is already documented in the schema, and the baseline of 3 applies. The description adds nothing about how the factor-level arrays must align with the values array, which is the main ambiguity an agent would face.
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 statistical method in both English and Chinese ('Two-way ANOVA / 双因素方差分析') and names the object of analysis (two factors, main effects, interaction). That distinguishes it from one-way or post-hoc siblings such as tukey_hsd and dunn_posthoc, though it never explicitly contrasts with linear_mixed_model.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'USE WHEN: two factors: main effects and interaction' clause gives a usable precondition for selection. However, it offers no exclusions or alternatives — nothing tells the agent when to prefer linear_mixed_model, a post-hoc test, or a one-way ANOVA instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
act_cover_letteract_decision_arbitrationact_deep_reviewact_design_decisionact_design_exportact_design_export_checkact_design_generateact_design_next_stepact_design_pico_refineact_experiment_planact_idea_igniteact_lit_digestact_lit_systematic_reviewact_literature_compareact_material_mermaidact_nsfc_analysisact_paper_reviewact_pdf_local_compareact_pdf_picoact_pdf_review_outlineact_polishact_pre_reviewact_predict_successact_proposal_reviewact_results_paragraphact_revision_trackact_roadmapact_top_journal_miningact_topic_feasibilityact_topic_gapsact_topic_generateact_topic_lit_reviewact_topic_noveltyact_topic_pptact_topic_prominenceact_topic_research_planact_write_chapteract_writing_one_clickact_writing_outlineact_animal_arrive_checkact_animal_dosingact_animal_organ_coefact_animal_randomizeact_animal_sample_sizeact_animal_survivalact_animal_tgiact_animal_tumor_volumeact_atac_diffact_bayesian_designact_be_compareact_bridge_convertact_calibrationact_cell_toolact_checklist_checkact_chip_peakact_citation_formatact_classification_reportact_cloning_designact_consort_flowact_crf_validateact_data_quick_statsact_ddi_checkact_decision_followupact_decision_intakeact_decision_reportact_deg_analyzeact_delongact_design_contextact_design_gate_rulesact_design_guideact_design_sample_sizeact_dose_convert_pharmact_dunnact_enrichact_fcs_clusteract_fcs_gateact_fibrosis_stageact_figure_legendact_file_columnsact_forest_chartact_gene_pathwayact_gene_searchact_geo_pipelineact_gleasonact_ic50_fitact_ihc_scoreact_iptwact_journal_recommend_v3act_km_curveact_lit_searchact_lit_verify_citationsact_literature_overlapact_lmm_formulaact_meta_eggeract_metabo_enrichmentact_metabo_heatmapact_metabo_pcaact_metabo_plsdaact_metabo_volcanoact_mif_phenotypeact_ml_nomogramact_ml_parseact_ml_psiact_ml_shapact_nca_analyzeact_nuclei_segmentact_omics_integrateact_permutation_testact_pico_refineact_pkpd_evalact_pkpd_simulateact_ppi_networkact_primer_designact_primer_tmact_prisma_flowact_protein_digestact_protein_enrichmentact_protein_physchemact_protein_ptmact_psm_matchact_pubmed_searchact_qpcr_ddctact_randomizeact_risk_ratioact_rnaseq_degact_rocact_sas_r_codeact_scrna_analyzeact_scrna_celltypeact_scrna_markersact_sequence_enzymeact_sequence_orfact_sequence_plasmidact_sequence_translateact_smd_balanceact_stat_centeract_survival_analyzeact_table_oneact_table_one_subgroupact_tme_analyzeact_tox_evalact_tox_predictact_tukey_hsdact_two_way_anovaanimal_dose_volumeanimal_randomizationanimal_sample_sizeanimal_survival_kmarrive_checklistatac_diffbioequivalence_comparecalibration_curvecell_assay_calcchip_peak_callingcitation_formatcitation_verifyclassification_metricsclinical_basic_bridgecloning_designconsort_flowchartcrf_sdtm_validatedataframe_parsedataset_columnsdataset_profiledelong_auc_comparedesign_gate_rulesdesign_step_contextdifferential_expressiondna_translatedrug_interaction_checkdunn_posthocegger_bias_testevidence_followupevidence_intakeevidence_reportfibrosis_stagingfigure_legendflow_clusterflow_gateforest_plotgene_info_lookupgene_pathway_diseasegeo_dataset_pipelinegleason_grade_groupgo_kegg_enrichmentic50_fitihc_hscoreiptw_weightingjournal_recommendkaplan_meierlinear_mixed_modelliterature_search_pmcmetabolite_heatmapmetabolite_pathwaymetabolite_pcametabolite_plsdametabolite_volcanomif_phenotypemulti_omics_integratenomogramnuclei_countorf_findorgan_coefficientpcr_primer_designpermutation_testpico_refinepk_ncapk_pd_assesspkpd_simulateplasmid_mapppi_networkprimer_tmprisma_flowchartpropensity_score_matchingprotein_digestprotein_enrichmentprotein_physchemprotein_ptmpsi_stabilitypubmed_searchqpcr_bayesian_designqpcr_ddctrandomization_allocaterenal_dose_adjustreporting_checklistrestriction_sitesrisk_ratio_orrnaseq_degroc_aucsample_size_calculatorsas_r_codescrna_annotatescrna_clusterscrna_markersshap_explainsmd_balancespecies_dose_convertstats_toolboxstudy_design_advisorsurvival_coxtable_one_baselinetable_one_subgrouptext_overlap_checktoxicity_predicttoxicology_assesstukey_hsdtumor_growth_inhibitiontumor_microenvironmenttumor_volume_curvetwo_way_anovaact_distribution_fitact_table_one1 field changedInput schema / requiredPrevious value: -[
- "group_variable"
-]New value: +[
+ "file_id",
+ "group_variable"
+]act_table_one_subgroup1 field changedInput schema / requiredPrevious value: -[
- "group_variable",
- "subgroup_variable"
-]New value: +[
+ "file_id",
+ "group_variable",
+ "subgroup_variable"
+]act_animal_arrive_checkact_animal_dosingact_animal_organ_coefact_animal_randomizeact_animal_sample_sizeact_animal_survivalact_animal_tgiact_animal_tumor_volumeact_atac_diffact_bayesian_designact_be_compareact_bridge_convertact_calibrationact_cell_toolact_checklist_checkact_chip_peakact_citation_formatact_classification_reportact_cloning_designact_consort_flowact_crf_validateact_data_quick_statsact_ddi_checkact_decision_followupact_decision_intakeact_decision_reportact_deg_analyzeact_delongact_design_contextact_design_gate_rulesact_design_guideact_design_sample_sizeact_distribution_fitact_dose_convert_pharmact_dunnact_enrichact_fcs_clusteract_fcs_gateact_fibrosis_stageact_figure_legendact_file_columnsact_forest_chartact_gene_pathwayact_gene_searchact_geo_pipelineact_gleasonact_ic50_fitact_ihc_scoreact_iptwact_journal_recommend_v3act_km_curveact_lit_searchact_lit_verify_citationsact_literature_overlapact_lmm_formulaact_meta_eggeract_metabo_enrichmentact_metabo_heatmapact_metabo_pcaact_metabo_plsdaact_metabo_volcanoact_mif_phenotypeact_ml_nomogramact_ml_parseact_ml_psiact_ml_shapact_nca_analyzeact_nuclei_segmentact_omics_integrateact_permutation_testact_pico_refineact_pkpd_evalact_pkpd_simulateact_ppi_networkact_primer_designact_primer_tmact_prisma_flowact_protein_digestact_protein_enrichmentact_protein_physchemact_protein_ptmact_psm_matchact_pubmed_searchact_qpcr_ddctact_randomizeact_risk_ratioact_rnaseq_degact_rocact_sas_r_codeact_scrna_analyzeact_scrna_celltypeact_scrna_markersact_sequence_enzymeact_sequence_orfact_sequence_plasmidact_sequence_translateact_smd_balanceact_stat_centeract_survival_analyzeact_table_oneact_table_one_subgroupact_tme_analyzeact_tox_evalact_tox_predictact_tukey_hsdact_two_way_anovasanyu_list_actions
Add one secure layer between your agents and this server.