List all available CDISC products, including SDTM, ADaM, CDASH and IG series, with version paths and types. Call this first to confirm which versions of a standard exist.
获取所有 CDISC 产品列表，包括 SDTM、ADaM、CDASH 等标准及各 IG 系列。 返回产品名称、版本路径（refs）、类型等信息。 无需参数，可直接调用。不确定某标准的可用版本时，先调这个。
| Name | Required | Description | Default |
|---|---|---|---|
| raw | No | true 时返回未经瘦身的原始 API 载荷（含 _links 等超媒体元数据）；默认 false，返回已瘦身、更省 token 的响应 |
Changes observed during successful MCP inspections.
v0.1.0Does 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.