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

With readOnlyHint already covering safety, the description adds real behavioral context beyond annotations: default summary view, multi-MB payload risk for the full diff, truncation flagging when rows exceed max_rows, and the notable behavior that reversed old/new version arguments are auto-swapped with an explanatory note in the response. That auto-swap disclosure is exactly the kind of non-obvious behavior an agent needs.

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?

Well front-loaded: the default behavior and its rationale come first, then the drill-down instruction, then a parameter list and two concrete examples. Some redundancy with the schema (repeating '3-3'/'3.3'/'latest' and the default of 200) costs it the top score.

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

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

For a 6-parameter, no-output-schema tool, the description covers the return shape (section names plus per-section row counts plus Info section content), the drill-down workflow, and the cost profile of the heavy mode. Nothing an agent needs in order to call it correctly is missing.

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

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

Schema coverage is 100%, so baseline is 3; the description still earns above baseline by explaining that section names must come from the summary's sections index and that passing new_version before old_version is tolerated via auto-swap. The version-format and max_rows-default restatements duplicate the schema but the extra semantics are genuine.

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 opening line states a specific verb+resource+scope: comparing two versions of the same standard. It is immediately distinguishable from every sibling tool (all of which are single-entity get_* lookups) and identifies the three required inputs implicitly.

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 operating procedure: default summary first, then drill into a section by name from the summary's sections index, with max_rows capping output. It also effectively says when NOT to use the full payload (raw is tens of MB). It stops short of explicitly comparing itself to any sibling tool, but none of the siblings compete for this job.

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?

readOnlyHint=true already declares this as a safe read, so the description's burden is lower. It adds the word 'all', implying no pagination or partial results, which is useful. It does not mention the 'raw' flag's effect, output shape, or error behavior for invalid standard/version combinations.

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

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

Three short sentences, front-loaded with the purpose, then examples of return values, then a usage example. Nothing is padded, though the example line duplicates information already in the schema descriptions.

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

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

For a simple read-only list tool with full schema coverage and no output schema, the description is largely sufficient: it states the input concept and gives a sample of what the class list contains. Minor gaps remain around where this fits in the larger standard/class/dataset hierarchy.

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

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

Schema coverage is 100%, so all three parameters are already documented, including the raw flag and the 'latest' version value. The description's only added value is a concrete example pairing ('sdtmig', '3-4'), which confirms the two required parameters must be used together but adds no new semantics. 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 and resource: retrieve the list of all classes contained in a given standard, and names concrete class examples (Events, Findings, Interventions, SpecialPurpose). This is distinguishable from siblings like get_datasets or get_datastructures, though the description never explicitly contrasts itself with them.

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

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

Usage is implied by the example invocation (standard='sdtmig', version='3-4'), which shows the tool is the entry point for enumerating classes. However, there is no explicit when-to-use/when-not guidance and no mention of how this differs from get_datastructures or get_datastructure_varsets in the 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?

Although the annotations provide the readOnlyHint, the description adds specific behavioral context by mentioning what details will be returned (definition, extensibility). This provides the AI with a better idea of the output content than the schema alone.

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

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

The definition is highly efficient. It front-loads the most important routing advice and uses a concrete example immediately afterward, making it highly digestible and 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?

Given the complexity of the CT framework (package names, codelist formats, multiple related tools), this definition is exceptionally complete. It covers how to find the inputs (package/codelist) and what the resulting data structure entails (raw vs. slim response).

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?

Since schema coverage is 100%, the description must add context. It excels here by adding vital constraints on required parameters—specifically defining the format of the codelist ID, suggesting fallback tools (get_variable, get_codelists) if the ID is unknown, and explaining the practical difference between 'raw' and 'slim' responses.

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 explicitly states the function is to retrieve detailed information about a specific codelist. Crucially, it distinguishes this tool from its siblings by providing clear routing instructions: use get_codelist_terms for all terms and get_codelist_submission_values for submission values.

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 definition provides comprehensive usage guidance by not only suggesting alternative tools based on the user's specific need (e.g., terms vs. submissions) but also by warning against using the tool incorrectly (i.e., guessing the codelist 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?

readOnlyHint=true already tells the agent this is a safe read, so the description's burden is reduced. It adds that the result covers the entire package (all codelists, not one), which is meaningful scope information, but says nothing about response size, pagination, or how the list relates to get_codelist terms.

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 sentence plus a one-line example, with the scope stated first and nothing redundant. It is lean to the point of being slightly bare, but every element present 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 simple read-only list tool with fully documented parameters and an annotation covering the safety profile, nothing essential is missing; the example supplies the one piece of call-format guidance an agent needs. The absence of an output schema is irrelevant here since the tool returns a list whose shape is implied by the name.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema, including the case-insensitivity note and the pointer to get_ct_packages. The description only repeats an example value for 'package' and never mentions the 'raw' parameter, so it adds no meaning beyond the schema. Baseline 3 applies.

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

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

The description gives a specific verb and resource ('获取...所有编码列表（Codelist）') scoped to a named CT package, which distinguishes it from the singular get_codelist sibling by virtue of the 'all' aggregation. It stops short of naming those siblings explicitly, so an agent must infer the distinction from the plural form alone.

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

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

Usage is only implied: the example ('package=sdtmct-2024-03-29') shows the expected input but no when-to-use or when-not guidance. The useful routing hint ('use get_ct_packages if you don't know the package names') lives only in the schema for the package parameter, not in the description, and there is no mention of when get_codelist (singular) would be the better choice.

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

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

The annotations only declare readOnlyHint=true, so the description carries most of the behavioral burden and does so: payload-based resolution, a termsResolvedByDetailRequest count reporting fallback terms, total/hasMore paging signals, a 2000-per-page clamp (limitRequested echo), and a concrete scale note that LBTESTCD's 2397 terms need two pages. It doesn't discuss auth or failure modes for an invalid codelist ID, which keeps it off a 5.

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

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

The key point — don't call get_term per term — is front-loaded before mechanics and the example, and every line carries operational content (cost comparison, projection, paging, ID pitfalls). It is dense and runs long, with the closing 'use get_term for single-term detail' partially restating an earlier line, so it falls short of a 5.

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

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

For a six-parameter read tool with no output schema, the description supplies the return shape (three columns plus an example row), page-size and total/hasMore semantics, and the fallback-count field, which is everything an agent needs to call it and interpret the result. The scale warning about two-page codelists closes the remaining gap.

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

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

Schema coverage is already 100%, so the baseline would be 3, but the description adds real semantic guidance on top: fields can be narrowed to 'name,submissionValue' (or extended with definition/synonyms), pagination is driven by total/hasMore rather than blind looping, and the codelist ID has documented traps (C667 does not exist; C141657 is not LBTESTCD).

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 precise verb and resource (paginated retrieval of a codelist's terms and their submissionValue) and fixes the output shape as three columns (code / name / submissionValue). It explicitly sets itself apart from the sibling get_term and shows a concrete example (package='sdtmct-2024-03-29', codelist='C66731' → [{code: C16576, ...}]).

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 says when NOT to use the per-term path: reading the package payload covers the whole table in 1–2 calls versus roughly 150s / 260 calls to get_term, with a fallback to per-term detail only for terms missing from the payload. It also routes to get_ct_packages when the package is unknown and to get_variable / get_codelists when the codelist ID is uncertain, and reserves get_term for full single-term detail.

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?

Goes well beyond the readOnlyHint annotation: it discloses the exact response shape (refs map of term name -> href, with the C code as the href's last segment), explicitly documents a negative behavior (submissionValue is never returned, even with raw=true, by API design), and quantifies a real risk (responses up to ~260k characters for large codelists). This is exactly the kind of operational context an agent cannot get from structured fields.

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

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

The key constraint (no per-term submissionValue, use the sibling instead) is front-loaded and the example anchors it at the end. It is dense with useful caveats, though the emphasis markers and the large-table warning could be tightened slightly.

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

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

With no output schema and three parameters, the description does the heavy lifting well: return shape, omitted fields, and size limits are all covered. The one shortfall is that after flagging 260k-character responses it names no concrete pagination approach, leaving the agent without a next step for the worst case.

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 schema carries the baseline. The description still adds value by clarifying that raw=true does not unlock submissionValue and by giving a concrete package/codelist example pair, which helps an agent form valid arguments.

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 ('获取指定编码列表中的所有术语'), defines what a term is ('可选的标准化值'), and distinguishes itself from get_codelist_submission_values. An agent can tell exactly what this returns 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?

Explicitly routes to get_codelist_submission_values when the three-column view (name + C code + submission value) is needed, and warns that large codelists such as LBTESTCD should use a paginated tool instead. The paginated alternative is referenced only vaguely as '新工具分页' without being named, which is a minor gap given the sibling list.

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?

readOnlyHint already marks this as a safe read, and the description goes well beyond that: it discloses the response shape (package metadata plus codelist index with termCount), the deliberate omission of inline terms, concrete payload size (1106 tables / 13 MB for sdtmct), and the client-timeout risk of raw=true. That is exactly the operational context annotations cannot supply.

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

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

Front-loaded with the core purpose and the default-vs-raw decision, followed by an example; nothing is filler. The 13 MB figure appears twice (once in the payload explanation, once in the raw warning), which is mild redundancy, though it reinforces the key risk.

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

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

There is no output schema, so the description carries the return-value burden and does so: it names the returned sections, mentions hasMore/limit clamping behavior, and warns about the oversized raw mode. For a read-only, 4-parameter tool this leaves no decision-relevant 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 the baseline is 3, but the description adds real meaning on top: raw is framed by its 13 MB/timeout consequence rather than just 'untrimmed payload', and the package parameter is given concrete naming syntax and a pointer to get_ct_packages. Limit/offset semantics are left entirely to the schema, which is acceptable at full coverage.

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

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

States a concrete verb and resource: returns package metadata plus a paginated codelist index that includes a termCount per table. It also draws the boundary against two siblings by name, get_ct_packages (for discovering package names) and get_codelist_submission_values (for per-table terms), so an agent can pick the right tool without inspecting 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 says what happens by default (index only, no inline terms), what raw=true does (pushes the 13 MB payload and will hit a 60s client timeout), and names the alternative tool to use instead. It also routes to get_ct_packages when the package name is unknown, so the when/when-not conditions are all covered.

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

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

The readOnlyHint=true annotation already establishes that this is a safe read, so the description only needs to add context beyond it. It does disclose the shape of the return data (package names and effective dates), which helps the agent know this is an enumeration call rather than a detail fetch. It does not mention pagination or response size, and it does not mention that the optional raw flag can change the shape of the response, so behavioral coverage stops short of full.

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

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

Three short lines with the resource and return content front-loaded; nothing is padded. The final line about not needing parameters is the weakest of the three: it restates the empty required list from the schema and omits the optional raw flag, so it uses space without adding information. It is mildly misleading rather than merely verbose.

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

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

This is a simple, parameter-light, read-only list tool with no output schema, and the description covers its purpose and rough return content. Because the annotations already carry the safety profile and get_ct_package covers the per-package detail case, the remaining gaps are minor. It does not discuss response size or the effect of raw, but an agent can call it correctly from what is given.

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

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

Schema description coverage is 100%, and the single raw parameter is fully documented in the schema, so the baseline of 3 applies. The description does not mention raw at all; saying "无需参数" (no parameters needed) is technically true because the parameter is optional, but it could lead an agent to overlook the option to receive the unsimplified payload. No additional meaning is added beyond the schema.

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

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

The description uses a specific verb and resource: "获取所有 CDISC 控制术语（Controlled Terminology）包列表" (get the list of all CDISC CT packages), and it names the fields returned (package name, effective date). This clearly separates it from sibling tools such as get_codelists and get_standard. However, it does not explicitly contrast with the singular sibling get_ct_package, so an agent cannot immediately infer the list-versus-detail split from the description alone.

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

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

"无需参数，可直接调用" (no parameters needed, can be called directly) tells the agent the call is unconditional and cheap, which is useful call-readiness guidance. It gives no explicit when-to-use versus when-not-to-use guidance, and it never routes the agent to get_ct_package for details on a single package or to get_codelists for drilling into one package's contents.

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?

readOnlyHint=true already tells the agent this is a safe read, so the description does not need to re-establish safety. It does add beyond the annotations by disclosing the payload's conceptual contents and a token-cost trade-off versus get_dataset_variables. It stops short of covering size/scope of the response or whether the variable list is embedded in the metadata, which matters given there is no output schema.

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

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

Three short lines with clear front-loading: what it returns, then sibling routing, then scope, then a runnable example. No sentence is redundant and the alternative-tool pointers are load-bearing rather than filler.

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

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

With no output schema, the description carries responsibility for explaining returns, and it does list the metadata facets (description, class, structure, purpose). Combined with explicit sibling routing and scope limits, an agent can select and call this correctly. Slightly incomplete in that it never says whether variables are included or how large the response is, which the token-cost remark hints at but does not resolve.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns above that by supplying a concrete invocation example (standard='sdtmig', version='3-4', dataset='DM') that demonstrates how the three required parameters combine in practice. The scope restriction to SDTM/SEND/CDASH further constrains which standard values are meaningful, which the schema alone does not signal.

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 ("获取指定数据集的元数据") and enumerates the payload contents (description, class, structure notes, purpose), so an agent knows exactly what comes back. It also names the sibling tools it is *not* (get_dataset_variables, get_variable, get_datastructure), making it unambiguous within a very crowded sibling set.

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?

Explicit routing is given: use get_dataset_variables when only the variable list is needed (cheaper on tokens), get_variable for a single variable, and get_datastructure for ADaM structures. This is exactly the when-to-use/when-not-to-use/alternative pattern. A minor caveat: the schema enum accepts 'adam'/'adamig' as standards while the text steers ADaM work elsewhere, but 'data structure' vs 'dataset' is a defensible distinction.

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?

readOnlyHint=true already declares the safety profile, and the description adds the genuinely useful behavioral constraint that certain standard values have no backing endpoint and will not work. It does not discuss response size/pagination or what slimmed-vs-raw output implies operationally, leaving some context 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?

Three short lines with zero filler: purpose first, then the critical exclusion, then a call example. Every sentence earns its place and the constraint is front-loaded before the example.

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

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

For a three-parameter read-only list tool with a fully documented schema and no output schema, the description covers purpose, applicability, alternative routing, and a usage example. The only gap is that it doesn't hint at what a dataset entry contains, which is minor given how the sibling get_dataset/get_dataset_variables tools split that concern.

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 parameter meaning is already fully documented, including version formats ('3-4'/'3.4'/'latest') and the raw toggle. The description's example demonstrates a valid standard/version pairing but adds no semantics 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+resource ('获取指定标准下的所有数据集列表') scoped by standard, and explicitly separates itself from get_datastructures for the adam/adamig family. An agent can distinguish it from the ~20 sibling get_* tools 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 an explicit when-NOT-to-use rule ('仅适用于 SDTM/SEND/CDASH 系列；adam / adamig 没有 datasets 端点，请改用 get_datastructures'), naming the alternative and the condition that selects it. The concrete example anchors the calling pattern.

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?

readOnlyHint=true is consistent with a pure lookup, and the description reinforces this by describing a read-only variable listing with its returned field set. It also discloses the important scope constraint (SDTM/SEND/CDASH only, not ADaM). It does not discuss the slimmed-vs-raw payload tradeoff or response size, but the schema's `raw` parameter already documents that difference.

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

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

Front-loaded with the core action, followed by sibling routing, scope limit, and a concrete example — each sentence carries distinct information and nothing is repeated from the name or schema. The parenthetical field list is dense but earns its place by previewing the return shape.

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 naming the fields returned (name, label, core attributes, role). For a 4-parameter read-only lookup it covers purpose, scope, alternatives, and return content — nothing an agent needs in order to call it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the worked example (standard='sdtmig', version='3-4', dataset='DM') adds real value by demonstrating which standard/version/dataset combination is valid and clarifying the dashed version format in context. It does not add anything about the `raw` flag beyond the schema, keeping this short of a 5.

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: retrieve the complete variable list for a given dataset, and enumerates what each entry contains (name, label, core attributes Req/Exp/Perm, role). It explicitly distinguishes itself from get_dataset (dataset-level metadata) and from get_datastructure/get_datastructure_variables (ADaM variables). An agent can differentiate it from all 20 siblings from the text alone.

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

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

Explicitly declares itself the preferred tool for pulling all variable definitions of a domain, names the alternative for dataset metadata (get_dataset), and gives a hard exclusion with the redirect for ADaM (e.g. ADSL → get_datastructure or get_datastructure_variables). When-to-use, when-not-to-use, and alternatives are all present.

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?

readOnlyHint=true already tells the agent this is a safe read. The description adds real value beyond the annotation: the default response strips each variable's description to save tokens, and the raw payload is large and should be requested only on need, which is a cost/size disclosure the annotation does not carry. It does not discuss ordering, error behavior when a datastructure name is invalid, or whether the returned table is complete for the version.

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

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

Front-loaded purpose sentence, followed by the default-vs-raw behavioral note and a compact example, with no filler. The repeated emphasis on 'only source with core and type' is close to redundancy with the purpose sentence but still earns its place as differentiation.

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

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

With no output schema, the description carries the return-shape burden and does so: grouping by variable set, per-row fields, and what the compact mode removes. For a simple 4-parameter read tool this is nearly complete, leaving only failure modes and version-availability edge cases 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 coverage is 100%, so the baseline is 3, but the description adds practical meaning for raw: the compact default is the token-efficient choice, and the full payload is bulky, which the schema only describes neutrally. The worked example (standard='adamig', version='latest', datastructure='ADSL') also shows how the three required parameters combine in a real call.

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

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

The description gives a concrete verb, resource, and payload shape: fetch the full variable table for one analysis data structure, grouped by variable set, one row per variable with name/label/core/datatype. It also explicitly states a uniqueness claim ('the only full-table source that includes core and type'), which separates it from the get_datastructure_variables and get_datastructure_varsets siblings without opening a schema.

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

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

It supplies a concrete trigger question ('what variables does ADSL have, including Required/Permissible?') and the rule that raw=true should be passed only when genuinely needed. What's missing is an explicit named competitor such as get_datastructure_variables for row-level lookups; the differentiation is only implied by 'the only full-table source'.

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

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

The readOnlyHint annotation already identifies this as a safe read, and the description usefully adds the behavioral fact that get_datasets returns 404 on the ADaM side. However, it says nothing about the response shape, how the list is ordered, or pagination; so beyond the annotation, the added value is real but thin.

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

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

The purpose is front-loaded, and the 404 caveat follows immediately with no filler. The trailing example line is genuinely useful, though it slightly echoes the schema's 'latest' description.

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

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

For a read-only list tool with a fully documented schema and no output schema, this description is nearly complete. One gap remains: the standard enum also allows sdtm, sdtmig, sendig, cdash, and cdashig, but the description talks only about ADaM products. It is therefore unclear whether the tool applies to those standards or only to ADaM.

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 schema covers all three parameters at 100%, including the 'latest' version convention and the enum of standards. The example (standard='adamig', version='latest') illustrates typical values but adds no meaning beyond what the schema already documents; the baseline of 3 is therefore appropriate.

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

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

The description states a specific verb and resource: it retrieves the list of analysis data structures (ADSL, BDS, etc.) for an ADaM product. It also names the concrete distinguishing difference from the sibling get_datasets, so an agent can identify the right tool without reading 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?

The description explicitly says when to use this tool: on the adam/adamig side, use this tool first to see which data structures exist. It also explains why the alternative fails: get_datasets will always return 404 for these standards. It also includes a worked parameter example, leaving little 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?

readOnlyHint=true already covers the safety profile, but the description goes further and discloses the returned field set (core, data type, description, var-set in refs) plus the case-insensitive auto-matching behavior against mixed-case API spellings like SITEGRy/APHASEw. That is real behavioral context an agent would not get from annotations, though the token-saving 'raw' behavior is only described 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?

Two short blocks, front-loaded with the return-field summary, then the casing caveat, then a compact example. The case-insensitivity point is repeated in both the description and the schema property, which is minor redundancy rather than bloat.

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

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

A read-only single-record lookup with full schema coverage and no output schema needs to say what it returns and how to form the call; the description does both via the field list and the example. The main remaining gap is not routing the agent away from similarly named siblings.

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

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

Schema coverage is 100%, so all five parameters are already documented with descriptions and the standard enum. The description's case-insensitivity note and worked example add marginal value but largely restate what the schema already says for 'variable' and 'datastructure'. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

States a specific verb+resource: fetch the details of one variable inside an analysis data structure, and enumerates what comes back (core, data type, description, var-set membership via refs). The singular 'single variable' implicitly contrasts with the plural listing sibling, but no sibling is named explicitly.

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

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

Usage is only implied: the example shows a concrete call shape (standard='adamig', version='latest', datastructure='ADSL', variable='AGE'), which helps an agent pattern-match. There is no explicit statement of when to prefer this over get_variable, get_datastructure_variables, or get_dataset_variables, and the 'call get_datastructures first if unsure' advice lives in the schema, not the description.

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?

Beyond readOnlyHint=true, the description discloses the negative behavior that matters most: this endpoint omits core and data types, so an agent that needs them is redirected. It also advertises token efficiency and the hrefTemplate field. It does not describe pagination or the exact response shape, which keeps it just short of a 5 given there is no output schema.

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

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

The purpose and the token-saving claim are front-loaded, with the exclusion note and example following. Three sentences plus an example, all earning their place, though the 'most token-efficient' phrasing slightly overlaps the raw-flag documentation in the schema.

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

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

Read-only list tool with 4 fully documented parameters and no output schema; the description still names the returned fields and, critically, states what is not returned. Nothing an agent needs in order to call this correctly or to pick a sibling is missing.

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

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

Schema coverage is already 100%, so the baseline is 3, and the description adds a concrete worked example (standard='adamig', version='latest', datastructure='ADSL') that shows how the parameters combine in practice. It does not add semantics for the raw flag, but that is fully documented in 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 and resource — returning the variable-name list (names + labels, plus hrefTemplate) for an analysis data structure — and explicitly differentiates itself from get_datastructure (full table) and get_datastructure_variable (single variable). An agent can distinguish it from the nearest siblings without opening a 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?

Explicit routing is given: use this for the cheapest exhaustive name list, use get_datastructure when core and data types are needed, use get_datastructure_variable for a single variable's definition. The schema's datastructure field also tells the agent to call get_datastructures first when the name is unknown. When-to-use and when-not-to-use are both covered.

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?

readOnlyHint=true already tells the agent this is a safe read, so the description's main added value is the varset name-resolution behavior: slugs or display names, case/space/hyphen insensitive. It adds nothing about response size, truncation, or error behavior when a name doesn't resolve, which leaves a gap beyond the 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?

Front-loaded with the purpose, then name-resolution rules, then a compact end-to-end example — each element earns its place. The parenthetical examples are slightly verbose but serve a concrete disambiguation purpose.

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

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

With 5 parameters (4 required, all schema-documented) and no output schema, the description covers the essential call shape plus the one behavioral quirk (naming) that would otherwise cause a failed lookup. It doesn't address what a returned varset contains beyond 'variables with descriptions', but that is a minor gap for a read-only drill-down tool.

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

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

Schema coverage is 100% (baseline 3), and the description still adds real meaning: it explains that varset accepts either a slug or a display name and that matching ignores case, spaces and hyphens — a detail the schema does not state. The worked example (standard='adamig', version='latest', datastructure='ADSL', varset='PopulationIndicator') further disambiguates how the four required params combine.

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

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

The description opens with a specific verb+resource ('获取单个变量集的内容'), and notes it also returns each variable's description, which distinguishes it from the listing sibling get_datastructure_varsets. It stops short of naming that sibling explicitly, but the scope line ('适合按集下钻而不要拉整包') makes the boundary clear enough to choose correctly.

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

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

It gives a clear usage context — drill down per varset rather than pulling a whole package — which implicitly routes to the listing tool when the set name is unknown. The schema also tells the agent to call get_datastructure_varsets first for the applicable list, though the description itself doesn't repeat that prerequisite or state explicit exclusions.

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

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

readOnlyHint=true already covers the safety profile. The description adds the behavioral note that names are unstable across versions, but does not describe the result shape beyond the examples, nor whether the list is paginated or how raw=true affects the payload (that 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?

Front-loaded purpose, then a workflow caveat, then a compact example invocation. Three short lines with no filler, though the example line could arguably be redundant given 100% schema coverage.

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 lookup with full schema coverage and no output schema, it covers what is needed: verb, target resource, key fields of the response, and a worked example. It falls short of 5 because it does not clarify the distinct roles of get_datastructure_varset (singular) vs this list tool.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds real value by prescribing an example combination and warning that names vary by version, reinforcing the need for the correct 'version' and 'datastructure'. The nested 'datastructure' schema already points to get_datastructures, so the description adds only modest extra context.

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

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

The description names a specific verb (获取) and resource (变量集清单 for an analysis datastructure), with examples of varset kinds (Identifier / Treatment / Trial Experience). It is distinguishable from siblings like get_datastructure_variables and get_datastructure, though it does not explicitly contrast them in words.

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 states a usage rule: var-noiset names are unstable across versions, so come here first to get the version-specific available names before drilling down. That is implied guidance for a workflow, but there is no explicit when-not guidance and no mention of the sibling naming ambiguity (varset vs variables).

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, so the safety profile is covered by structured data. The description adds useful return-shape context (product name, version paths, type) and the fact that it is callable with no required input, but it does not mention response size, pagination, or the existence of the heavier `raw` mode. Modest added value beyond annotations.

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

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

Four short sentences: purpose, returned fields, callability, and the routing tip — front-loaded and free of filler. The '无需参数，可直接调用' line mildly restates the schema's empty required list, but it still serves the agent as a quick confidence signal.

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

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

This is a simple read-only list tool with a fully documented single parameter and no output schema, so the description carries most of the burden it needs to: what it returns, that it needs no input, and when to reach for it. Only the raw/degraded-payload tradeoff and any notion of result volume are left 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?

With one parameter at 100% schema description coverage, the schema fully documents `raw` and its token-cost tradeoff, so the baseline of 3 applies. The description contributes nothing about that parameter and even says '无需参数', which describes required inputs but does not mention the optional raw flag at all.

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

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

The description names a specific verb and resource ('获取所有 CDISC 产品列表'), enumerates the standard families covered (SDTM, ADaM, CDASH, IG series), and states the returned fields (名称、refs、类型). This clearly distinguishes it from the deeper lookups in the sibling set (get_standard, get_classes, get_datasets), though it never names a sibling explicitly.

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

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

It gives explicit when-to-use guidance: '不确定某标准的可用版本时，先调这个' plus '无需参数，可直接调用', telling the agent this is the entry point to the hierarchy. It stops short of stating when NOT to use it or naming a concrete alternative (e.g. use get_standard once the version is known), so it is clear but not exhaustive.

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 readOnlyHint=true already covering the safety profile, the description adds a real behavioral constraint: version and standard must be compatible (sdtmig uses 3-x, sdtm uses 1-x/2-x), which prevents failed calls. It says nothing about error behavior on mismatch or about what 'raw' changes beyond what the schema already states, so it adds only modest value over annotations.

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

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

Three tight lines: purpose and return contents first, then a worked example, then the caveat. No redundancy with the schema and nothing extraneous — every sentence either scopes the tool or prevents a misuse.

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

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

For a simple read tool with 3 fully documented parameters and an existing readOnlyHint, the description covers purpose, returned content, and the main failure mode (version mismatch). It lacks only an explicit sibling routing statement, which is a minor omission given the rich sibling list.

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 goes beyond it by supplying concrete example values (standard='sdtmig', version='3-4' or '3.4' or 'latest') and the cross-parameter validity rule that a schema cannot express. That materially reduces the chance of a mismatched pair being sent.

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

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

The description gives a specific verb and resource (获取指定标准的基本信息 / get basic information for a specified standard) and names the returned fields — 描述、生效日期、包含的类列表 — so an agent knows this is the metadata entry point rather than a listing tool like get_classes. It does not explicitly contrast itself with those siblings, keeping it just short of a 5.

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

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

Usage guidance is limited to a matching rule (standard and version must correspond) and a fallback ('latest' when unsure), which is really parameter guidance rather than when-to-use-this-vs-alternatives. There is no statement about when to call get_standard versus get_classes or get_datasets, so the agent must infer that from the returned-field list.

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 readOnlyHint=true already covering the safety profile, the description adds genuine behavioral detail: case-insensitive name matching, automatic resolution to a C code scoped to the supplied codelist, and a graceful fallback returning similar candidate names when no match exists. It does not discuss error conditions beyond that, which is minor for a read-only lookup.

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

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

Purpose is front-loaded in the first sentence, followed by a numbered list of accepted term forms and a worked example. The example slightly restates the parameter rules already given in the numbered list, but overall it is compact and easy to scan.

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

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

For a 4-parameter read-only lookup with no output schema, the description covers what is returned (definition, submissionValue), how the loose term input is interpreted, and what happens on a miss. It stops short of describing the overall response shape or how multiple candidate matches are ordered, which would be the last gap for an agent to call it confidently.

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 goes beyond the schema by spelling out the two accepted term forms with concrete examples and the case-insensitive resolution semantics plus failure behavior. The raw parameter's slim-vs-full payload behavior is left entirely to the schema.

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

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

The description uses a specific verb+resource (获取指定术语的详细信息) and names the payload fields returned (定义、submissionValue). It hints at its distinct role by describing name-to-code resolution inside a codelist, which separates it from list-style siblings, but it never explicitly contrasts itself with get_codelist_terms or get_codelist_submission_values.

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 conveyed only by example ('package=..., codelist=..., term=...') and by the note that a term name resolves within the codelist, with nearby candidates returned on failure. There is no explicit when-to-use vs. when-not-to-use guidance and no routing to get_codelist_terms for enumeration or get_codelist_submission_values for bulk submission values; the codelist-ID discovery advice lives in the schema, not the description.

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?

readOnlyHint=true already tells the agent this is a safe read, and the description adds real value on top by disclosing the shape of the returned record (attributes, role, codelist refs under refs). It does not mention failure behavior for unknown variables/datasets, but for a read-only lookup that is a minor omission.

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

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

Three short lines: what it returns, the scope restriction plus alternative tool, then a concrete example. The scope restriction and the redirect are front-loaded, and no sentence is filler.

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

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

With no output schema, the description correctly compensates by listing the returned fields, and the example demonstrates a valid invocation across all four required parameters. Remaining gaps are small: it does not say what happens when a variable name is not found, nor how the raw flag changes the returned payload beyond the schema's own note.

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 schema already carries the meaning of all five parameters, including the raw toggle and the 'latest' version sentinel – the description adds nothing to those. The worked example does reinforce value formats ('3-4', uppercase DM/USUBJID), which is a marginal gain over a fully documented schema and lands at baseline.

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

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

The description names a specific verb+resource ('获取指定变量的详细信息') and enumerates the payload an agent will get back: data type, core attributes (Req/Exp/Perm), role, and CT codelist references in refs. It also explicitly marks the boundary against the sibling 'get_datastructure_variable', so the tool is distinguishable 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?

It states the applicable standards (SDTM/SEND/CDASH) and names the alternative tool for ADaM variables, which is exactly the routing decision an agent needs. However, the input schema's enum still accepts 'adam'/'adamig', creating a residual ambiguity the description does not reconcile (e.g. whether those values error or are silently resolved).

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

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

Annotations already cover the read-only safety profile, and the description adds genuinely non-obvious behavior: results are relevance-sorted, responses are cached client-side for 24h, and limit/offset are applied client-side rather than server-side. The 24h cache is an important staleness fact an agent would not otherwise know. It does not describe the shape of a hit, but that is partly a return-value concern.

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

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

Front-loaded with purpose, then a compact bulleted parameter list and a worked example — easy to scan. The examples in the bullets duplicate the schema's own examples, so a sentence of the content is not strictly earning 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?

There is no output schema, so the description carries the burden of explaining what a result looks like, yet it never says what fields a hit exposes or how hits are typed. Caching, sorting, and client-side pagination/truncation are well covered, but the return-side gap keeps it at minimum viable.

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 is already documented, and the description's parameter notes largely restate the schema (query examples, type filter, paging math). It adds the clarification that type matching is case-insensitive and that paging is client-side, but says nothing about 'raw', which is the largest-token-impact parameter.

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

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

Opens with a specific verb+resource pair ('全局搜索 CDISC Library') and enumerates what is searchable (标准、数据集、变量、术语). It is clearly distinguishable from the get_* siblings, which are direct-lookup tools, though that contrast is only implicit rather than stated.

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

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

Usage is conveyed only through examples ('query=AVAL, type=Analysis Variable, limit=10'); there is no explicit statement of when to prefer search over get_variable/get_dataset or when the tool should not be used. An agent can infer the intent from context but the guidance is not spelled out.

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