MedicineData MCP

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

No annotations are provided, so the description carries the full burden. It does disclose two useful non-schema behaviors: content varies by source, and long text is truncated at 4000 characters. However it says nothing about error behavior, missing-id handling, or the shape of the response beyond the content summary.

Agents need to know what a tool does to the 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 sentences, zero filler. The core operation (fetch by trial_id + source) is front-loaded, followed by the per-source content contract and the truncation caveat.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 compensates by describing the returned content per source and the 4000-character truncation. For a two-parameter read tool with full schema coverage this is nearly complete; only error/edge-case behavior is unaddressed.

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

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

Schema description coverage is 100%, so the baseline is 3. The description goes beyond the schema by explaining the semantic consequence of the 'source' parameter — which fields each database returns — rather than just repeating 'cn or global, default cn'.

Input schemas describe structure but not intent. Descriptions should explain 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 ('取试验详情' / fetch trial detail) keyed by trial_id + source, and further specifies what the returned content is per source (cn: enrollment count, evaluation metrics, AI summary; global: eligibility criteria and outcome measures). This lets an agent distinguish it from search_clinical_trials without opening either schema.

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

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

Usage is only implied: the schema's trial_id description points to ids returned by search_clinical_trials, so the search-then-detail flow is inferable. There is no explicit statement of when to use this versus alternatives, nor any prerequisite or exclusion guidance.

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

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

With no annotations, the description carries real weight here and delivers a non-obvious behavioral trait: partial-failure semantics where a timed-out count is surfaced in count_errors instead of being silently reported as 0. That is exactly the kind of context an agent cannot infer from schema. It still omits latency/cost expectations and confirmation that no mutation occurs.

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

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

Two short clauses, zero filler, with the primary action front-loaded and the caveat about count_errors placed after the returns. Nothing could be cut 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 read tool with no output schema, the description covers what is returned (detail plus three counts) and the failure mode. It does not say what fields the 'detail' itself contains, but the core calling information is present.

Complex tools with many parameters or behaviors need more documentation. 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, and the schema already documents it at 100% coverage with the same 'search_companies 返回的 id' provenance. The description adds no syntax or format detail 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?

States a specific verb and resource ('按 company_id 取公司详情') and enumerates the payload (pipeline drug count, BD deal count, financing event count), which clearly distinguishes it from the search_* siblings that only return ids. No sibling is named explicitly, 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 'company_id = id returned by search_companies' hint implies the workflow (search first, then fetch detail), but the description never states when to use this tool versus the search tools or any prerequisites. Usage is implied rather than stated.

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

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

No annotations are provided, so the description carries the behavioral burden alone. It does disclose the read nature ('取') and enumerates the returned fields, which is valuable given there is no output schema, but it says nothing about permissions, rate limits, or behavior for an unknown/invalid deal_id.

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

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

A single tight sentence with the key action and the returned payload front-loaded; nothing is padded or redundant.

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

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

For a one-parameter read tool with full schema coverage and no output schema, the description partially compensates by naming the returned fields. It is nearly sufficient, missing only id provenance and error 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?

With a single parameter and 100% schema description coverage, the schema already documents that deal_id is 'search_deals 返回的 id'. The description adds no syntax, format, or type nuance 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 states a specific verb (取/fetch) and resource (交易/deal) plus the shape of the returned record (amount structure, license type, counterparty company ids). It is clearly distinct from the search_* siblings by the word 'detail' and '完整记录', though it never names search_deals as the id source inside the description itself.

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

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

Usage is only implied: an agent infers it is called with a deal_id obtained elsewhere (the id provenance is mentioned only in the schema). There is no explicit when-to-use, when-not, or named alternative such as search_deals vs. this tool.

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?

No annotations are provided, so the description carries the burden. It usefully discloses the return payload fields, but says nothing about failure behavior for an unknown drug_id, whether results are cached/live, or any auth requirements. For a simple read-by-id lookup the risk is low, so partial coverage is acceptable.

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

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

One tight sentence with no filler, and the key input (drug_id) is front-loaded. It is efficient, though the terseness leaves no room for routing or precondition context.

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

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

For a one-parameter lookup with no output schema and no annotations, enumerating the returned fields compensates reasonably well for the missing output schema. Only the absence of source/routing guidance keeps it from being fully complete.

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

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

Schema description coverage is 100% and the single parameter's meaning ('id returned by search_drugs') is already documented there. The description repeats the identifier name but adds no syntax, format, or type nuance beyond it, so baseline 3 applies.

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

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

States a specific verb and resource ('按 drug_id 取单条药品完整记录') and enumerates the returned content (indication codes, targets, approval date, company, links), which distinguishes it from the other entity-detail siblings at a glance. It does not explicitly name a sibling, but the resource noun carries the 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?

No when-to-use or when-not-to-use guidance. The only hint that this is the detail counterpart to search_drugs appears in the schema ('search_drugs 返回的 id'), not in the description. An agent must infer the search-then-detail workflow.

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?

No annotations are provided, so the description carries the full burden. It usefully discloses what the response contains (hierarchy chain, children, aggregate drug and trial counts), which is real behavioral context, but says nothing about permissions, errors, or whether missing ids 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?

One dense line, front-loaded with the look-up key followed by the returned content. No filler sentences; every clause carries information.

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

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

For a low-risk read tool with one documented parameter and no output schema, the description adequately enumerates what comes back, compensating for the absent output schema. Minor gaps are auth/error behavior, which are unlikely to block correct invocation.

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

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

Schema coverage is 100% and the single parameter is documented as taking an id produced by search_indications. The description adds no syntax, uniqueness, or format detail beyond that, so it matches the baseline for full-coverage schemas.

Input schemas describe structure but not intent. Descriptions should explain 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 (取适应症 by indication_id) and enumerates the response payload (parent chain, children, drug count, trial count). It follows the get_*_detail sibling pattern but never explicitly contrasts itself with search_indications, so differentiation is only implied by naming convention.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 explicit when-to-use statement, but the parameter description ('search_indications 返回的 id') implies the intended flow: search first, then fetch detail by id. Boundaries with siblings remain for the agent to infer.

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?

With no annotations, the description carries the full burden and does meaningful work: it discloses that the response is a meta object containing author and body abstract, that long text is truncated at 4000 characters, and that an original-source link is included. This is genuine behavioral context an agent needs to avoid misreading truncated output as complete. It does not cover failure modes or permissions.

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

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

One dense, front-loaded sentence with the primary action first and payload details in a trailing parenthetical. Nothing is wasted, though the closing '+ 原文链接' fragment is terse enough to feel like an afterthought.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 tool with no output schema and no annotations, the description is nearly sufficient: it characterizes the returned payload, the truncation behavior, and the supplementary link. Only error/empty-result behavior and any access requirements are absent.

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

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

Schema description coverage is 100% and there is a single required parameter, so the schema already documents the id fully. The description's '按 report_id' adds no format, range, or provenance detail beyond what the schema states, so the baseline 3 applies.

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

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

States a specific verb and resource: fetch the detail record for a meeting summary keyed by report_id, and names the two payload components (meta with author and abstract, plus the source link). It reads clearly as the single-item counterpart to search_meeting_reports, though it never says so explicitly in the description text 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 description implies a detail-fetch pattern, and the parameter schema explicitly ties the id back to 'search_meeting_reports 返回的 id', which routes the agent correctly. However, neither text states when to call this versus re-querying search_meeting_reports, nor what to do if the id is unknown or stale.

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?

No annotations are provided, so the description carries the full burden. It usefully discloses a behavioral limit (linked_drugs capped at a maximum of 20), but is silent on read-only semantics (merely implied by 'get'), error/not-found behavior, and 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?

A single compact sentence, front-loaded with the id-based lookup and then the extra returned data. 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?

For a one-parameter read tool with no output schema, the description summarizes both the primary result (patent details) and a key nested return (linked_drugs, max 20). It could say more about the full detail payload, but is adequate for correct invocation.

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

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

Schema coverage is 100% and there is a single parameter whose description already explains it is the id returned by search_patents. The description adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

The description states a specific verb+resource: fetch patent details by patent_id, plus linked drugs/ingredients. It is clearly distinct from the other get_*_detail siblings by resource, but it never explicitly contrasts itself with search_patents, so it falls short of full sibling differentiation.

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

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

No when-to-use, when-not, or alternative is stated in the description. The only usage hint (the id comes from search_patents) lives in the schema's parameter description, not in the tool description itself.

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?

No annotations are provided, so the description carries the full burden. It usefully discloses the shape of what is returned (upstream ancestor chain, downstream children, associated drug count), but says nothing about read-only nature, error behavior for a missing/invalid id, or response size.

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

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

A single dense sentence, front-loaded with the identifier and the action, followed by the returned fields. Nothing is wasted and nothing is buried.

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

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

With no output schema, the description correctly compensates by enumerating the returned elements (ancestors, children, drug_count), which is the key information for an agent deciding whether to call it. It is adequate for a simple one-parameter read tool, with only error/edge behavior 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?

Only one parameter and schema description coverage is 100% — the schema already documents target_id as 'the id returned by search_targets'. The description restates that the id selects the target but adds no format, type, or edge-case detail beyond the schema, 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 and resource in Chinese (按 target_id 取靶点 = fetch a target by target_id) and even previews the payload (ancestor chain, child targets, drug count). It is clearly distinguishable from the search_* siblings by being the id-based detail fetch, though it does not explicitly name an alternative tool.

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

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

Usage is only implied: the phrase 'by target_id' plus the schema note that the id comes from search_targets signals this is the follow-up call to a search, but the description itself never says when to use this versus search_targets or what happens for an unknown id.

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?

No annotations are provided, so the description carries the full burden. It usefully discloses cost behavior ('不计费' / not billed) and enumerates the categories of returned information (tools, capability domains, quotas, plans), but says nothing about rate limits, auth requirements, or caching — leaving the operational profile only partially covered.

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

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

Two short sentences with no filler. The most decision-relevant fact (what it lists) comes first, and the actionable instruction (call it on connect) is front-loaded at the end where it is easy to act on.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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, no annotations, and no parameters, the description is nearly complete for a discovery tool: it says what is returned and that it costs nothing. It could be marginally stronger by indicating that its output should drive subsequent tool selection, but nothing essential is missing.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. The description correctly implies a parameterless, self-contained call, and there is nothing further a parameter section could add.

Input schemas describe structure but not intent. Descriptions should explain 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 (列出/list) and resource (本 MCP 的全部工具、能力域、限额与套餐), which no sibling tool does — every sibling is a domain-specific search or get. An agent can instantly tell this is the meta/discovery tool rather than a data-retrieval 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?

Explicitly prescribes the calling context: '接入后第一件事就是调它' (call it first thing after connecting), which is strong, actionable when-to-use guidance. It stops short of naming when not to use it or pointing to alternatives, but for a zero-param meta tool the alternative space is just 'anything else', so the gap is minor.

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?

With no annotations, the description carries the full burden and discloses a genuinely non-obvious quirk: the cn source's status column is empirically always 1 with no semantics and returns null. It also notes status filtering only works on source=global and that a few Chinese status values are matchable by fuzzy words, which prevents real misuse.

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

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

A single dense paragraph, front-loaded with the core purpose before source-specific caveats. Every clause earns its place, though the packing of source differences, the status quirk, and the field list into one block makes it slightly heavy 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?

No output schema exists, and the description compensates by listing the shared return fields (trial_no/title/drug/target/indication/phase/status/sponsor). Combined with the source and enum caveats, it covers what an agent needs to call correctly, with only minor gaps around keyword-matching 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 coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: phase uses the std_phase Chinese enum on cn (e.g. III期 / Phase 3), and status is exact-match for English enums yet fuzzy-match for Chinese terms. This clarifies parameter behavior beyond the schema text.

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

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

States a specific verb+resource (检索临床试验 / search clinical trials) and crisply splits the tool into two sources with their record counts. It names the exact return field set, so an agent can distinguish it from the sibling get_clinical_trial_detail without opening any schema.

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

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

Gives clear conditions for choosing source=cn vs source=global (database size, filterable fields, status semantics), which is exactly the decision the caller must make. It stops short of explicitly naming the alternative detail tool or stating when NOT to use this search, so it is strong context rather than full routing guidance.

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

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

No annotations are provided, so the description carries the full behavioral burden. It adds the row count (5.1 万行) as a scale hint, but says nothing about permissions, whether pagination caps apply, or what the results look like. For an unannotated search tool this is a thin disclosure.

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

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

A single sentence that front-loads the core purpose and then lists the facets; no filler. It is efficient, though the trailing field list is somewhat terse and could be more actionable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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-param search with full schema coverage and no output schema, the description is minimally adequate: purpose and queryable fields are covered. It falls short on usage context (when to pick this over get_company_detail) and any behavioral expectations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. 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 (limit, fields, offset, country, keyword) are already documented in the schema. The description names overlapping facets (keyword→公司名, country→注册地) but adds no syntax beyond what the schema states, so baseline 3 is appropriate.

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

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

States a specific verb (检索) and resource (公司与机构), plus the backing table (rs_company) and dataset scale (5.1 万行). It even enumerates the searchable facets (中英文名、注册地、上市类型、母公司), so an agent knows what it can query. It does not, however, distinguish itself from sibling get_company_detail.

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

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

There is no when-to-use guidance and no mention of alternatives. The obvious sibling get_company_detail (single-company lookup vs. this bulk search) is never referenced, leaving the agent to infer the routing decision on its own.

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?

With no annotations, the description carries the behavioral burden. It usefully discloses the corpus size and that trade_type is a semicolon-joined string with example values, which is real behavioral context. However it omits the schema-level pagination caps (limit hard cap of 20, offset+limit ≤1000) from the prose and says nothing about permissions, read-only nature, or result shape – understandable gaps for a search tool but not fully compensating for zero annotation coverage.

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

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

Two tight sentences, front-loaded with what the tool does and the data it exposes, then the key filtering caveat. The parenthetical table/count is minor implementation detail but earns its place as scale context with no filler.

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

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

For an 8-param, all-optional search tool with full schema coverage, no annotations, and no output schema, the description supplies the domain scope and the one non-obvious parameter (trade_type semantics). It is reasonably complete; only pagination/return-shape behavior is left to the schema.

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

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

Schema coverage is already 100%, so the baseline is 3. The description exceeds the baseline by explaining that trade_type is a semicolon-combined string and enumerating concrete values (授权/许可、投资;期权;合作、并购), which meaningfully extends the bare schema text '交易类型关键词' and warns the agent about multi-value semantics.

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

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

States a specific verb+resource (检索 BD 交易) and enriches it with the underlying table (fa_drug_trade), the corpus size (~4k), and the domains covered (license-in/out, upfront, total amount, milestones, counterparties). This clearly identifies the tool and differentiates it from sibling detail getters like get_deal_detail, though it never names a sibling 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?

No explicit when-to-use guidance and no comparison with overlapping siblings such as search_investments, search_companies, or get_deal_detail. The trade_type note hints at how to filter but not when this tool is the right choice over alternatives.

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

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

There are no annotations, so the description carries the full burden. It usefully discloses the data source and size (rs_medical, 76k rows) and that only summary columns are returned versus full records elsewhere. It does not mention read-only behavior, rate limits, or pagination caps (the latter is left to 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?

It is front-loaded with the search purpose, followed by the enum list and a return-scope note. The enumeration is long but earns its place by supplying values the schema omits. No filler sentences.

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

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

For an 8-parameter search tool with no output schema, the description adequately covers purpose and return scope (summary columns). However, the fields parameter refers to '返回列名' (returned column names) that are never defined anywhere, and it ignores the by_indication/by_target search siblings, leaving a modest completeness 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 coverage is 100%, so baseline would be 3, but the description adds real value by listing the full stage enum (临床前/临床I期/.../已撤市) that the stage_china and stage_global schema entries reference only as '精确匹配枚举值' without enumerating. This directly enriches two parameters 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 (检索/search) and resource (药品/drugs) and enumerates the searchable dimensions: drug name/English name/alias, drug type, global or domestic stage, and company. It is distinct from get_drug_detail by noting it returns summary columns. It does not differentiate from the search_drugs_by_indication or search_drugs_by_target siblings, keeping 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?

It gives an explicit routing rule: for full records use get_drug_detail, and states this tool returns summary columns. That is clear when-to-use context, but it omits the two other drug-search siblings (by_indication, by_target), which are natural alternatives an agent should weigh.

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?

No annotations are provided, so the description carries the full burden. It does disclose the matching mechanism (encoded 阶段|适应症名|适应症id string) and an extra return field (indication_matched), which is useful behavioral context. However, it omits that this is a read-only search, how pagination limits interact, and any scope constraints beyond what the schema already documents.

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

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

Two compact sentences with the core purpose front-loaded, followed by the matching and return detail. No filler, though the parenthetical encoding string is dense and would benefit from a touch more structure.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 return-value explanation; it partially does by describing the indication_matched field but does not describe the overall result shape (drug rows) or field-selection behavior. Adequate for a filtered-search tool but with visible 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 schema already documents all five parameters, including the default/hard cap on limit and the offset+limit<=1000 constraint. The description adds only marginal meaning by clarifying what the indication keyword is matched against, so the baseline 3 is appropriate.

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

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

States a specific verb+resource ('按适应症找药品' = find drugs by indication) and names the exact field being matched (rs_medical.indication), which makes its role distinguishable from search_drugs and search_drugs_by_target. It stops short of explicitly naming those sibling alternatives, so it is clear but not sibling-differentiating.

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

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

There is no guidance on when to use this tool versus search_drugs, search_drugs_by_target, or search_indications. No prerequisites, exclusions, or context conditions are stated; the agent must infer the selection logic from the tool name alone.

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

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

No annotations are provided, so the description must carry behavioral disclosure. It usefully reveals the underlying match field and the returned value format (e.g. 'ADRB(批准上市);GR(批准上市)'), but says nothing about permissions, result ranking, or what happens when a target matches nothing. Pagination caps are handled by the schema, not the description.

Agents need to know what a tool does to the 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 core purpose first and the technical detail confined to a parenthetical. No wasted clauses, though the parenthetical format sample is slightly dense.

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

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

With no output schema, the description usefully sketches the return shape (target strings annotated with approval status), and the schema covers all four parameters including pagination limits. It is nearly complete for a simple filtered search; only the absence of alternative-routing guidance and empty-result behavior keeps it short of full.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. 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 limit/offset/fields/target are all documented in the schema itself; the baseline of 3 applies. The description only adds that matching occurs against rs_medical.target with status-annotated values, which is modest value beyond the schema's own 'target name' 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?

States a specific verb+resource ('find drugs by target') plus the exact field matched (rs_medical.target) and the drug-status scope (in-development/marketed). This distinguishes it from search_drugs and search_drugs_by_indication without opening their schemas, 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 purpose sentence implies the usage context (locate drugs when you have a target), but there is no explicit when-to-use, when-not-to-use, or routing to the sibling search_drugs_by_indication for indication-based lookups. Usage is only inferable.

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?

With no annotations, the description still adds some behavioral context: it identifies the underlying table (rs_indication), dataset size (8.7k rows), and the kinds of entity fields involved (names, aliases, hierarchy). However, it does not describe matching behavior, return format, read-only semantics, or limits beyond what the schema already covers.

Agents need to know what a tool does to the 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 with no filler. The resource is front-loaded and the dataset identity and field scope follow immediately.

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

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

The description covers the dataset and broad field scope, and the schema is well documented, but with no output schema and no annotations the agent still lacks explicit return-shape and usage-vs-detail guidance. It is minimally adequate for a simple search tool but leaves clear gaps.

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

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

Schema description coverage is 100%, so the schema already documents keyword, limit, fields, and offset. The description adds context that the tree covers Chinese/English names, aliases, and parent/root nodes, but it does not clarify whether keyword matching applies to all of those fields or how results are 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 states a specific verb and resource: searching the indication tree (rs_indication, 8.7k rows), and names the searchable/returned fields (Chinese/English names, aliases, parent/root nodes). It is clear what the tool does, though it does not explicitly contrast itself with the sibling get_indication_detail.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 explicit guidance on when to use this tool versus alternatives such as get_indication_detail or search_drugs_by_indication. Usage is only implied by the tool name and the word 'search'.

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?

No annotations are provided, so the description carries the entire behavioral burden. It reveals nothing about pagination limits, the hard 20-row cap, the 1000 offset ceiling, matching semantics (e.g. prefix vs fuzzy), or result ordering — all critical for a search tool, though some of this is only 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, front-loaded with the verb and resource. It wastes nothing, though the brevity comes at the cost of the missing usage and behavioral detail.

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

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

For a read-only search tool with full schema coverage and no output schema, the description is minimally adequate: it conveys scope and returned dimensions. It lacks sibling differentiation and any behavioral/operational context, which is the main gap.

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

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

Schema description coverage is 100%, so the schema already documents all 9 parameters, including the limit cap and offset constraint. The description lists field names that overlap with the filters but adds no syntax or format meaning beyond the schema, 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 (检索) and resource (投融资事件), and enumerates the returned fields (轮次、金额、领投方、跟投方、时间) plus the source table and record count. It does not, however, differentiate itself from siblings like search_investors (which sounds adjacent) or search_deals, leaving some ambiguity about which sibling covers which data.

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

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

There is no guidance on when to use this tool versus search_investors or search_deals, no stated prerequisites, and no exclusions. The description only says what data is covered, leaving the agent to infer selection.

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?

No annotations are provided, so the description carries the full burden. It does disclose a real behavioral trait: a commonly expected field (participation count) is deliberately omitted for cost reasons, which prevents an agent from wasting calls hunting for it. However, it says nothing about read-only semantics, permissions, or result characteristics beyond what the schema already covers.

Agents need to know what a tool does to the 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 tightly packed sentences: purpose and scope first, then the exclusion and the redirect. The parenthetical giving record count and the cost rationale are informative rather than filler. Slightly dense but nothing 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 search tool with no output schema, the description covers purpose, scope, a notable data limitation, and the sibling alternative. Pagination and field selection are fully handled by the schema, so no gaps an agent would trip on remain, though return-shape context is absent.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters including the limit cap and offset bounds. The description's mention of dimensions (类型、总部、关注阶段、关注赛道) loosely maps to the fields/focus_stage params but adds no syntax or format detail beyond what the schema 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?

States a specific verb (检索) and resource (投资机构 / fa_investor), gives the dataset size (2.5万家) and enumerates the dimensions covered (类型、总部、关注阶段、关注赛道). Crucially it distinguishes itself from the sibling search_investments by declaring what it does NOT return, so an agent can choose between the two without opening schemas.

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

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

Explicitly gives a when-not condition (参投次数 is not provided, because counting the whole table by institution name is cost-prohibitive) and names the alternative (use search_investments' investor parameter to query by event). This is concrete routing guidance, though it only addresses that one case rather than the broader when-to-use context.

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?

With no annotations, the description carries the full burden and does well: it discloses data coverage (2016–2024), per-channel row counts (46万/133万/36万), merge behavior for 'all', and a required-filter constraint. It omits return format, pagination interaction, and any auth/rate-limit context.

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

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

Front-loads purpose, then packs channel semantics and the ⚠️ critical constraint into minimal text with zero filler. Every clause earns its place.

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

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

Covers purpose, scope, channels, and the key filter constraint for a 9-param tool with no output schema. Return shape and limit/offset interplay are left to the schema, which is acceptable, but the description could say a bit more about result semantics.

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

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

Schema coverage is 100%, so baseline is 3; the description earns above that by explaining what each channel value actually contains (aggregate vs hospital vs online e-commerce, with row counts) and by stating the drug/company requirement, which the schema does not encode.

Input schemas describe structure but not intent. Descriptions should explain 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 (检索药品销量) with an explicit date scope (2016–2024). No sibling tool covers market sales, so it is unambiguously distinguishable from search_drugs/search_companies and the rest.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 hard usage prerequisite (必须带 drug 或 company) and an explicit when-not boundary (库内没有线下连锁药店动销), plus channel selection guidance. It stops short of naming an alternative tool to use instead, so it falls just under 5.

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

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

No annotations, so the description carries the burden and does add genuine behavioral context: dataset size (~450k), the fact that the PubMed domain is empty in practice, and the created_year semantics gotcha. Pagination caps and default limits are covered only by the schema, not the description, leaving some behavior to be inferred.

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

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

Two compact sentences, front-loaded with purpose and dataset scale, followed by the two highest-value caveats. No filler text; every clause earns its place.

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

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

For a search tool with full schema parameter coverage and no output schema, the description covers scope, size, and the key year caveat. It could mention the detail sibling (get_meeting_report_detail) for full records, but overall it is sufficient for correct invocation.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema by clarifying that created_year (bound to year_from/year_to) is the ingestion year rather than publication year. This directly improves correct parameter interpretation.

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

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

States a specific verb (检索/search) plus resource (医学会议摘要, 45万条, ASCO/ESMO/SABCS), and explicitly distinguishes its domain from the PubMed sibling by noting rs_pubmed is empty. An agent can identify the resource and scope without opening the schema.

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

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

Provides clear usage context: what the domain contains (only conference abstracts, no PubMed) and a critical semantic caveat that created_year is ingestion year, not publication year. However, it does not name an explicit alternative when the agent needs full records or PubMed data, so the routing guidance is incomplete.

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?

With no annotations at all, the description carries the full behavioral burden. It usefully discloses the dataset size (~27,000 records) and a non-obvious semantic that year_from/year_to filter on expiry year rather than filing year, but says nothing about result limits, pagination behavior, or access 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?

Two compact sentences with the resource and source-table context front-loaded; no padding or redundancy. It is appropriately sized for what it attempts.

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

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

No output schema or annotations exist, so the description is the sole context carrier, and for a 9-param all-optional search returning a known field set it is reasonably complete. The main omission is routing the agent to get_patent_detail for full records.

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

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

Schema description coverage is 100%, so the baseline is 3. The description restates the field list and the expiry-year comparison, which the schema already conveys in each parameter's own description, so it adds little beyond structured data.

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

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

States a specific verb (检索/search) and resource (药品专利/drug patents), and names the underlying source table and record volume (rs_drug_patents, 2.7万条) plus the returned fields. The search-vs-detail distinction against get_patent_detail is implied by the name but never stated explicitly.

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

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

No guidance on when to use this tool versus alternatives such as get_patent_detail, nor on prerequisites or sensible query combinations. The description only lists what fields exist, leaving selection 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?

With no annotations, the description carries the full burden, and it does add real context: the dataset size (9.5k 行) and the tree/hierarchy nature including parent nodes. However it says nothing about return shape, the hard 20-row cap, or the 1000 offset ceiling that the schema enforces, so the behavioral picture is only partial.

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

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

A single compact sentence that front-loads the resource and the searchable fields with no filler. It is efficient, though the terseness borders on under-specification for a tool with pagination constraints.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 search with 100% schema coverage and no output schema, the definition is minimally sufficient. It omits the practical limits (20-row hard cap, 1000 offset ceiling) and any signal distinguishing it from get_target_detail, leaving the agent to infer routing.

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

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

Schema description coverage is 100%, so every parameter (limit, fields, offset, keyword) is already documented in the schema, including the hard cap and pagination ceiling. The description's mention of name/alias/parent node overlaps with the keyword parameter description and adds no syntax or format detail 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?

States a specific verb (检索/search) and resource (靶点树/target tree) and names the searchable fields (靶点名、别名、父节点), so the agent knows exactly what this returns rows from. It does not distinguish itself from siblings such as get_target_detail or search_drugs_by_target, which share the target domain.

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

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

There is no explicit guidance on when to use this search versus get_target_detail for a single target, nor when to prefer search_drugs_by_target. Usage is only implied by the word 检索 and the listed searchable fields.

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