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

Annotations only tell the agent it is a non-readOnly, open-world, non-idempotent, non-destructive call. The description goes well beyond them by disclosing concrete side effects: writes into downloads/, records a SHA-256 manifest, deliberately skips extraction, and caps download size at 8 GiB. It omits what happens when the target file already exists, leaving the overwrite parameter's effect 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?

Two tight sentences: the first gives the action and its side effects, the second gives the hard limits. No filler, and the most decision-relevant facts (no extraction, size cap) are up front.

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

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

An output schema exists so the manifest result needs no prose, and the destructive/size behavior is covered. Still, for a 4-parameter, 3-enum tool with zero schema documentation, an agent cannot tell what 'complete' vs 'core' costs in size or what overwrite=true does, which the description should fill in.

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

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

Schema description coverage is 0% and the description offers no parameter guidance at all beyond hinting that selection is per manifest item. Vocabulary like dataset=core vs complete, the ten file_category values, and the non-idempotent overwrite flag are left entirely to inference from bare enum members.

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

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

Specific verb (下载) plus a precisely scoped resource: a .7z file from RegNetwork's official download page, written to downloads/ without extraction. An agent knows exactly what the call produces. It does not name a sibling (export_network, get_database_status) to contrast against, so it stops 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 description implies when the tool applies (pulling official published datasets rather than querying the live graph), and it adds a real usage constraint: one official manifest item per call, max 8 GiB. It never states when not to use it, nor points to a sibling for the alternative path of getting interaction data.

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

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

注解已声明非只读、幂等、非破坏和封闭世界；描述额外说明会生成可复算文件与校验清单并返回 MCP resource URI，补充了产物形态和返回方式。未说明覆盖已有文件的策略或权限要求，但幂等注解已部分覆盖重复调用语义。

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

Is the description appropriately sized, front-loaded, and free of 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?

有输出 schema 和注解，描述覆盖了产物与返回 URI；但参数语义完全缺失，format 选项和 subnetwork_id 作用未说明，对正确选择格式调用仍不够完整。

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

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

描述完全未提及 subnetwork_id 或 format 参数；在 schema 描述覆盖率为 0% 的情况下，没有补偿 subnetwork_id 的含义，也没有说明 tsv/json/graphml 三种格式如何选择。

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

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

明确使用动词“创建”并说明产出为可复算网络文件及校验清单，还指出返回 MCP resource URI，资源与结果清晰。但没有显式与 extract_subnetwork、download_official_file 等兄弟工具区分，导出与提取的边界需要靠名称推断。

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

描述只说明工具做什么，没有说明何时应使用本工具而不是 extract_subnetwork 或 download_official_file，也没有前置条件、排除场景或替代方案提示。

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

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

Annotations only declare readOnlyHint and openWorldHint; the description adds real behavioral context by disclosing that the response contains a subnetwork_id, an input status, and at most 30 preview edges, with full edges reserved for export. That truncation behavior is exactly what an agent needs before deciding whether to chain a second call. It does not explain the refresh/max_edges interaction or whether the returned subnetwork_id persists server-side.

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

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

A single front-loaded sentence: action, then return shape, then export caveat. No filler, no restatement of the tool 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?

Reduced to 4: with an output schema present, return values need not be explained, yet the description spends most of its length on them while leaving all five inputs undocumented at 0% schema coverage. For a tool with two enum choices and a caching flag, an agent is left guessing about required inputs.

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

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

Schema description coverage is 0% across five parameters, so the description carries the full burden and largely fails: it only alludes to symbols ('输入名称集合'). Nothing explains species, the core vs complete dataset enum, refresh, or max_edges (capped at 5000), nor why the preview cap is 30 when max_edges defaults to 5000 — a genuine ambiguity left unresolved.

Input schemas describe structure but not intent. Descriptions should explain 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: extracts the directed network induced by a set of input names. It also distinguishes itself from the export path by noting the result is a capped preview, so an agent can tell it apart from export_network without opening the schema. It stops short of naming sibling tools explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied: call this when you have a set of entity names and want the internal subnetwork. The clause '完整边用于导出' hints that full edges require a follow-up export, which is a partial routing cue, but there is no explicit when-to-use vs when-not versus summarize_network, get_neighbors, or search_interactions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description is consistent with a read-only diagnostic that touches external systems. It adds value by naming the subsystems checked, but says nothing about the cost or side effects of a refresh (does it re-query the external statistics endpoint? how long does it take?). Given openWorldHint, that omission is notable.

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

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

A single front-loaded sentence with the verb first and no filler. It is appropriately short, though the enumerated list is dense enough that the actual purpose ('health check') is only implied rather than stated.

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

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

An output schema exists, so return values need not be explained, and annotations cover the safety profile. What remains missing is the semantics of the only parameter and any guidance on interpretation or when the check should be run — leaving the definition minimally adequate for a single-parameter diagnostic 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 one parameter, 'refresh', with 0% schema description coverage, and the description never mentions it. An agent cannot tell from either source whether refresh forces a live re-fetch, clears a cache, or simply returns cached data — a meaningful distinction for a diagnostics call that hits external systems.

Input schemas describe structure but not intent. Descriptions should explain 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 specific verb (检查/check) and enumerates the concrete subsystems examined: the online statistics endpoint, cache, source-statistics consistency, and current tool capabilities. It is clearly a diagnostics/health tool, which distinguishes it implicitly from the sibling graph-manipulation tools. Minor mismatch: the name says 'database_status' while the description talks about statistics interfaces and tool capabilities, which could make an agent unsure of scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to call this versus alternatives, no prerequisites, and no mention of when a status check is warranted (e.g., before or after other operations). The single sentence is purely descriptive, leaving usage entirely to inference.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds genuinely non-derivable behavior: missing values are never promoted to evidence ('不把缺失值变成证据'), which warns the agent that sparse results are expected and should not be interpreted as findings. It does not disclose the max_references truncation behavior.

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

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

A single compact sentence pair with the positive behavior front-loaded and the two exclusions trailing. No filler, and every clause carries distinct information.

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

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

An output schema exists, so return values need no explanation, and the read-only profile is covered by annotations. However, with 0% parameter coverage the description should at minimum explain what interaction_id must be and that max_references bounds the reference list; those omissions leave real gaps for a two-parameter tool.

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

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

Schema description coverage is 0%, so the description carries the full burden for both parameters — yet neither interaction_id nor max_references is mentioned. The agent gets no guidance on ID format, where interaction_id comes from, or that max_references caps citation retrieval (default 20, max 100).

Input schemas describe structure but not intent. Descriptions should explain 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: reads source annotations and PMIDs for an interaction, drawn from prior query/mapping results. It also carves out a scope boundary (no full-text retrieval), which separates it from search_interactions and download_official_file. The link to interaction_id is implied only via '此前查询/映射', so it is not fully self-contained.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

'此前查询/映射取得的' tells the agent this is a follow-up call after discovery, not a search entry point. '不抓取论文全文' explicitly rules out the full-text use case that would otherwise tempt an agent. No sibling tool is named as an alternative, so routing is implied rather than explicit.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the description does not need to restate safety. It adds useful behavioral context by noting that results preserve direction, source/provenance, and truncation; it does not describe pagination behavior, though limit/offset exist in the schema.

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

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

A single compact sentence with the core scope and the ID-resolution caveat front-loaded. No filler or redundancy.

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

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

Output schema covers return values and annotations cover safety, so the description need not explain response format. However, for an 8-parameter interface with no schema descriptions, it leaves important invocation details like dataset choice, refresh behavior, and pagination unexplained.

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

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

Schema description coverage is 0%, so the description must compensate for 8 undocumented parameters. It only alludes to direction, raw IDs, and truncation; species, dataset, symbol, entity_id, refresh, limit, and offset are left to bare schema 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: querying one-hop upstream/downstream neighbors, with directional scope called out. It implies a narrower scope than broader subnetwork or interaction-search siblings, though it does not explicitly name them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear prerequisite: unfamiliar raw IDs must first be resolved by name, which effectively routes the agent to resolve_entities. It does not explicitly state when to prefer extract_subnetwork or search_interactions instead.

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

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

Annotations already cover read-only and open-world. The description adds a genuinely non-obvious behavioral trait: ambiguous and incomplete candidates are kept rather than resolved away, so the agent knows to handle multiple/no hits. It does not explain what the 'refresh' flag does, which is the main remaining gap.

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

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

A single compact sentence that front-loads the lookup and matching rule, then the result-handling caveat and the downstream-ID note. No filler.

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

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

An output schema exists, so return values need no explanation, and the ambiguity caveat covers result handling. However, for a four-parameter tool with no schema descriptions, the meaning of 'dataset' and 'refresh' is missing, so the definition is only just 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 0% across four parameters, so the description must carry the load, yet it only implies that 'symbols' are matched by full name. The 'dataset' enum ('core' vs 'complete'), 'species', the 'refresh' flag and the 50-item cap are left entirely unexplained.

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

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

The description states a specific verb and resource: query source entity candidates by full name, and notes the returned IDs feed later queries. It is clear enough to contrast with the interaction/network siblings, though it never names an alternative tool or states the identity-resolution role 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 workflow hint ('returned IDs can be used in subsequent queries') implies this is a first step before other lookups, and 'preserve ambiguity and incomplete results' implies it shouldn't be treated as authoritative filtering. There is no explicit when/when-not guidance or named alternative.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered externally. The description adds a genuinely useful caveat that alias coverage is not exhaustive and completeness is bounded to the current name candidates, but says nothing about pagination (limit/offset), the effect of refresh, or what dataset=complete costs.

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

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

Two dense clauses with no filler, and the anchoring requirement is front-loaded ahead of the completeness caveat. Brevity is close to over-terse given the parameter surface, but there is no wasted 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?

An output schema and annotations exist, so return shape and safety need not be restated, but for a 13-parameter search tool with zero schema descriptions the definition is far too thin — an agent cannot tell what confidence, min_score, dataset, or the type filters do.

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

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

Schema description coverage is 0% across 13 parameters, so the description carries the full burden and largely fails: it only gestures at the symbol/entity_id pair while dataset, confidence, min_score, target_type, regulator_type, refresh, limit, and offset remain unexplained anywhere.

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

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

The description states that it performs a precise query anchored on a start or end point (i.e., regulator or target), and that at least one end must be supplied by name or resolved ID. However, it uses generic '起点/终点' phrasing rather than the schema's regulator/target vocabulary, and it does not differentiate itself from siblings like get_interaction_evidence or get_neighbors.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a clear precondition (at least one of the two ends must be specified by symbol or resolved ID), which implies usage context. It offers no explicit when-not guidance and never names an alternative tool for the cases this one does not cover.

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

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

Annotations already declare this is a read-only, non-open-world operation, so the safety profile is covered. The description adds the calculated metrics and an interpretive caution that structural position is not disease driverness, but it does not explain how include_self_loops affects behavior or how invalid subnetwork_id values are handled.

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

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

The description is a single compact sentence that front-loads the computation targets and adds a useful interpretive caveat with no wasted text. Every part contributes to purpose or interpretation.

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

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

The output schema exists, so the description need not enumerate return fields, and the annotations cover read-only behavior. However, with 0% schema description coverage, the definition remains incomplete on parameter behavior and explicit usage sequencing.

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

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

Schema description coverage is 0%, so the description should compensate for both parameters. It only hints at self-loops via '自环' and says nothing about the required subnetwork_id or how include_self_loops changes the computation, leaving parameter meaning largely undocumented.

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

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

The description uses a clear verb-resource combination: it computes degree, role composition, self-loops, and connectivity for an already extracted subnetwork. It distinguishes itself from extraction/export siblings by emphasizing summarization of an existing subnetwork, though it does not explicitly name those 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 phrase '已提取子网络' implies this should be used after a subnetwork has been extracted, but it never explicitly says to use extract_subnetwork first or when not to use this tool. Usage is therefore implied rather than clearly guided.

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