List open datasets and connections in the current session, or close one by alias to free memory. Use 'list' to view them or 'close' with an alias to remove a source.
List the datasets and connections open in this session, or close one to free memory. action is 'list' or 'close'.
| Name | Required | Description | Default |
|---|---|---|---|
| alias | No | ||
| action | No | list |
| 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?
Annotations are all false, so the description carries the behavioral disclosure burden. It usefully states that closing frees memory, implying a non-destructive operation, but it does not explain idempotency, permissions, or what happens after close beyond memory release.
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 description is a single, front-loaded sentence with no filler. It conveys the operation, resource, motivation, and action values efficiently.
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?
The output schema likely covers return values, so not describing them is acceptable. However, the alias parameter remains ambiguous and no guidance explains when alias is needed for a close action, leaving a meaningful gap for an agent.
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 0%, so the description must compensate. It does define the action parameter values ('list' or 'close'), but the alias parameter's role is left implicit - an agent cannot tell from the description alone that alias likely identifies which source to close.
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 specific actions ('List', 'close') and the exact resource ('datasets and connections open in this session'). This clearly distinguishes the tool from its sibling load_dataset, which is about loading new data rather than managing already-open session resources.
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 provides clear context: use this tool to see what is open in the session or close something to free memory. It does not explicitly mention load_dataset as the alternative for bringing in new sources, but the intended usage is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.