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

Annotations already declare readOnly/non-destructive/closed-world, so safety is covered. The description adds real behavioral detail not in the annotations: results are sorted by n descending, labels are auto-applied by default, and the denominator rule changes with include_missing. It does not mention the row cap behavior beyond limit, but that is 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?

Three short, front-loaded lines: what it computes, how output is shaped, and how denominators work. No filler; the only redundancy is restating label application that also appears 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?

With 6 params at 100% schema coverage, an output schema, and read-only annotations, the description covers the remaining interpretive gaps (ordering, label decoding, denominator). Nothing an agent needs to call it correctly is missing, though sibling disambiguation would complete it.

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

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

Schema coverage is 100%, so baseline would be 3. The description earns more by explaining the consequence of include_missing on the percentage denominator ('total row count when True, otherwise non-missing'), which is a semantic effect the schema text does not spell out.

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 pair (单变量频数表 – univariate frequency table) and states what is produced (n and percentage per distinct value). It implicitly separates itself from summarize_dataset/query_dataset by being single-column distribution counting, but 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?

The usage context is implied by the label '单变量频数表' and the limits on value count, but there is no explicit guidance on when to choose this over summarize_dataset or query_dataset, nor any stated prerequisites (e.g. that a dataset path under SAS_DATA_ROOT is required).

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 already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds a contents inventory (label/type/format, creation time), which helps set expectations, but it discloses nothing about failure behavior for missing paths or dataset size limits. With annotations carrying the safety burden, a 3 is appropriate.

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

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

It is a single compact sentence that lands the resource first and then lists return contents; every clause earns its place with zero filler.

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

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

An output schema exists, so return structure need not be explained, and the one required parameter is fully documented. The only missing piece for a complete definition is guidance on when to prefer this over summarize_dataset.

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 path parameter is fully documented in the schema with a relative/absolute example. The description adds nothing about the path argument, 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?

It gives a specific verb+resource ("获取数据集元数据") and enumerates exactly what metadata is returned (row count, per-variable label/type/format, file label, creation time). This distinguishes it in substance from list_datasets and read_dataset, 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?

There is no statement of when to use this tool versus read_dataset or summarize_dataset, and no prerequisites, such as whether the dataset must exist or whether a path prefix is required. Usage must be inferred entirely from the contents 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds only that the result is a label mapping used for decoding; it leaves open whether the mapping covers the whole dataset or only selected variables, and gives no cost/size 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?

One short sentence with no filler, and the core purpose is front-loaded. It is however extremely terse given the ambiguity about mapping scope, so it sits slightly below ideal.

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

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

An output schema exists, so return-value shape needn't be explained, and annotations cover safety. The remaining gap is scope: whether labels are returned for every variable in the dataset or filtered somehow, which matters for an agent deciding whether to call this per dataset.

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 single `path` parameter (relative to SAS_DATA_ROOT or absolute) is fully documented in the schema. The description adds nothing about the parameter, so the baseline 3 applies.

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

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

States a specific verb and resource: it returns SAS format value-label mappings. The parenthetical adds a concrete purpose (decoding coded values during QC), which distinguishes it from generic readers like read_dataset. It does not explicitly name a sibling to differentiate from, so it stops short of 5.

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

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

The phrase 'QC 时解码 coded 值用' implies when to reach for it (data-quality checks on coded values), which is more than nothing. However, no alternative is named (e.g., get_dataset_metadata for variable metadata) and no exclusion or prerequisite is 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?

Annotations already declare this a safe, non-destructive, closed-world read, so the description only needs to add context. It contributes the scope (SAS_DATA_ROOT) and the file-type filter, but says nothing about whether subdirectories are traversed, how results are ordered, or what happens when `limit` truncates the listing — the behaviors that actually matter for a directory scan.

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 front-loaded sentence with the scope first and the accepted extensions last; nothing is wasted. It is arguably under-specified rather than bloated, but as a structure it is clean.

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

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

An output schema exists, so return values need not be described, and annotations cover the safety profile and closed-world scope. Combined with a fully documented 2-parameter schema, the description supplies everything needed to call this correctly.

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

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

Schema description coverage is 100%, with both `limit` and `pattern` documented inline (default 500, case-insensitive substring match), so the schema carries parameter meaning. The description adds no syntax or matching details beyond that, making baseline 3 correct.

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

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

States a specific verb (列出/list) and resource (SAS 数据集文件), and names the root scope SAS_DATA_ROOT plus the accepted extensions (.sas7bdat / .xpt / .sas7bcat), which no sibling does. It does not explicitly distinguish itself from read_dataset or get_dataset_metadata, but the 'list files' framing is distinct enough that an agent will not confuse 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 only implied: an agent can infer this is the discovery step before read_dataset or get_dataset_metadata, but the description never says so nor mentions any exclusion or prerequisite. No alternative is named, so guidance stops at the obvious.

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/openWorldHint/destructiveHint=false, and the description is consistent with them, adding the important enforcement detail that only SELECT/WITH statements are accepted. It also discloses the extra_paths table-registration and collision fallback behavior (dataset2/dataset3), which the agent could not infer otherwise. It does not discuss error behavior or result-size truncation, keeping it below a 5.

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

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

Front-loads the core action and constraint in the first sentence, then adds the table-naming rule and a worked example, each of which earns its place. Dense but not padded; a short pointer to the paging parameters is the only missing piece.

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

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

An output schema exists, so return values needn't be spelled out, and the description still helpfully notes that the response includes a tables name->path map. Combined with the SELECT/WITH restriction and extra_paths naming rules, an agent has enough to call it correctly; only truncation/paging behavior at the row cap 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?

With 100% schema coverage the baseline is 3, and the description genuinely adds semantics beyond the schema: how extra_paths entries map to table names (filename stem, e.g. lb.sas7bdat -> lb) and how name conflicts resolve. The remaining parameters (limit, offset, apply_labels) are 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?

Names a specific verb (execute DuckDB SQL) and resource (dataset), pins the main table name as `dataset`, and restricts the dialect to SELECT/WITH. That level of specificity cleanly separates it from read_dataset, summarize_dataset, and frequency.

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 states the intended scenario — cross-dataset comparison via extra_paths — and backs it with a concrete FULL JOIN example. It stops short of saying when to prefer the simpler siblings (read_dataset/summarize_dataset) instead, so it is clear context without 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?

Annotations already cover the safety profile (readOnly, non-destructive, closed-world). The description adds real value beyond them: records are returned as JSON, NaN becomes null, dates are ISO strings. It omits row-cap/limit enforcement behavior, but the schema's limit field documents the SAS_LOCAL_MCP_MAX_ROWS cap.

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, front-loaded with the pagination purpose and followed by a compact parenthetical on serialization quirks. Nothing is wasted and no filler precedes the core statement.

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

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

An output schema exists, so return values need not be explained, and serialization behavior is covered. The missing piece is tool selection guidance versus the other read/query siblings, which matters for a six-parameter read tool in a crowded family.

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

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

Schema description coverage is 100%, so all six parameters are already documented, including the rationale for offset sampling and the where-expression syntax. The description only echoes offset/limit pagination, adding no syntax or edge-case detail 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?

States a specific verb (读取/read) and resource (records from a dataset) and mentions pagination via offset/limit. It does not differentiate itself from siblings like query_dataset or summarize_dataset, so an agent cannot tell from the description alone which read tool to pick.

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

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

No statement of when to use this versus query_dataset, summarize_dataset, or frequency. Pagination is implied as the purpose, but there are no exclusions or alternative-routing guidance anywhere in 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?

Annotations already declare readOnlyHint/openWorldHint=false, so safety is covered; the description adds genuinely new behavior: only metadata is read, no data rows are loaded, and corrupted files are collected in errors without aborting the search. That error-tolerance disclosure is exactly the kind of context annotations cannot carry.

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

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

Three short sentences, front-loaded with the scope constraint, then the use case, then the read-only and error behavior. Nothing repeats the tool name or the schema, and every sentence 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?

With an output schema present and full parameter documentation, the description only needs to cover purpose, read-only semantics, and failure behavior, which it does. The only gap is guidance on choosing among siblings such as list_datasets versus this tool, which would make it 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%, so the schema already explains variable, pattern, contains, limit, and max_datasets. The description only restates that a variable name is supplied and adds no format, matching, or scoping 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 (search datasets containing a given variable) plus its scope (under SAS_DATA_ROOT), which is distinct from every sibling. It also explicitly names the sibling it replaces, get_dataset_metadata trial-and-error, so the agent can tell them apart 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?

Gives two concrete motivating questions ("which dataset has USUBJID", "which tables have AEDECOD") and names the alternative it avoids (iterating get_dataset_metadata). It lacks explicit when-not-to-use guidance, e.g. when list_datasets or read_dataset is preferable, so it falls short of a 5.

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

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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), and the description goes further by enumerating exactly which per-variable metrics are produced and how metrics vary by column type. That is genuine behavioral context beyond the annotations, though it omits practical traits such as cost or handling of very wide tables.

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 'entry point' claim are front-loaded in the first clause, followed by a structured enumeration of returned metrics. The per-type metric list is dense but each line carries information an agent needs; only slightly longer than necessary.

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 an output schema present, return values need not be explained, yet the description still documents them at a semantic level, and annotations plus full schema coverage handle safety and parameters. The only gap is guidance relative to the other read-oriented siblings, which a user of this complex a tool family would benefit from.

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 path, columns and apply_labels are already fully documented in the schema. The description adds no syntax, default or format detail for those parameters — the mention of value labels only implies what apply_labels touches. Baseline 3 is appropriate.

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

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

The description opens with a specific verb+resource (per-variable summary statistics) and states the tool's role explicitly as the preferred entry point for understanding a table. It also names the sibling it defers to (frequency) for labelled variables, so an agent can distinguish it from alternatives 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?

It gives a clear usage condition — use this first to understand a table without writing SQL — and an explicit exclusion: when has_value_labels is true, use frequency to see decoded distributions. It does not, however, position itself against read_dataset, get_dataset_metadata or query_dataset, so the routing picture is only partial.

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