Skip to main content
Glama

List Datasets

list_datasets
Read-only

List SAS dataset files (.sas7bdat, .xpt, .sas7bcat) under SAS_DATA_ROOT, with optional case-insensitive filename filtering and a result limit.

Instructions

列出 SAS_DATA_ROOT 下所有 SAS 数据集文件(.sas7bdat / .xpt / .sas7bcat)。

Input Schema

NameRequiredDescriptionDefault
limitNo最多返回条数(默认 500)。
patternNo可选,文件名子串过滤(不区分大小写),如 "ae" 或 "14.1"。

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.6/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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.