Returns the current dataset state summary, including sample names and roles for differential group selection; load a dataset first to avoid a missing-state response.
現在の DatasetState の概要を返す。
samples に name/role の TSV が入る。dataset_differential の
group_a / group_b はここに出る名前をそのまま使う。
dataset_load を先に実行しておくこと。 未実行の場合は missing_state エンベロープを返す。
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.0Does 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 non-obvious behavior beyond the annotation: the prerequisite ordering and the missing_state envelope returned on misuse, which is exactly the kind of context annotations can't convey. It stops short of describing the full DatasetState overview payload, so a 4 rather than 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?
Four short lines, each earning its place: purpose, output key, downstream consumer, and prerequisite. The prerequisite is placed where an agent will see it before calling.
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 bears return-value disclosure. It covers the `samples` field and the missing_state envelope, which is the operationally critical part, but leaves the rest of the 'overview' fields unnamed. Adequate for a zero-parameter status tool, with a small 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?
Zero parameters, so there is nothing to disambiguate and baseline is 4. The description correctly spends no words on parameters and instead documents the output shape (`samples` TSV of name/role).
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 ('現在の DatasetState の概要を返す') and links to a sibling (dataset_differential) that consumes its output. It doesn't explicitly negate other sibling tools like dataset_statistic or dataset_build_matrix, but the resource (DatasetState) is distinctive enough to separate it from the cluster.
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 prerequisite: 'dataset_load を先に実行しておくこと', plus the failure mode (missing_state envelope) when the prerequisite is unmet. It also tells the agent exactly how to use the output in dataset_differential (group_a/group_b take names as-is). This is close to ideal when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.