Skip to main content
Glama
Sign In
wasabi

wasabi

by creep-ltx
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Remote

List a directory

amiga_ls
Read-onlyIdempotent

Lists files and drawers in an Amiga directory, showing type, size, protection bits, date, time, and name; omit the path to list mounted volumes.

Instructions

List the files and subdirectories ('drawers') in one Amiga directory, drawers first then by name. One line per entry: 'd' for a drawer or '-' for a file, the size in bytes ('(dir)' for drawers), the protection bits as List shows them (hsparwed), the date and time, the name. Amiga paths start with a volume or assign and a colon, e.g. 'SYS:', 'Work:Projects', 'RAM:'; '/' is the parent, not the root. With no path it lists the mounted volumes (on Zenix, '/'). Not recursive. Read-only.

Input Schema

NameRequiredDescriptionDefault
pathNothe directory, e.g. 'SYS:C' or 'Work:'; empty lists the volumes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.1
    • changedInput schema / properties / path / description
      Previous value: -"e.g. 'SYS:C'"New value: +"the directory, e.g. 'SYS:C' or 'Work:'; empty lists the volumes"
  2. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the description correctly spends its words elsewhere: sort order (drawers first, then by name), the exact output line layout including protection bits and '(dir)' markers, and the fact that it is not recursive. It leaves error behaviour (nonexistent volume, access denied) unstated, which keeps it from 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.

Conciseness4/5

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

Front-loaded with purpose and ordering, then output format, then path semantics, then defaults — a logical progression. It is dense with semicolons and slightly run-on, but essentially every clause carries operational information.

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?

With no output schema, the description takes on the burden of describing return shape and does so precisely (one line per entry, type flag, size, protection bits, date/time, name). Combined with the annotations covering safety, an agent has 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.

Parameters4/5

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

Schema coverage is 100% and the schema already says empty lists volumes, but the description adds real meaning beyond it: the volume/assign colon syntax ('SYS:', 'Work:Projects', 'RAM:') and the non-obvious rule that '/' is the parent rather than the root. Those are exactly the semantics an agent would otherwise get wrong.

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

Purpose5/5

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

States a specific verb and resource ('List the files and subdirectories in one Amiga directory') and immediately scopes it as non-recursive and read-only, which cleanly separates it from amiga_read_file, amiga_text, and other content tools in the sibling list.

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

Usage Guidelines4/5

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

Gives a clear operating context: path is optional, and with no path it lists mounted volumes (on Zenix, '/'). It also rules out recursion and clarifies the Amiga path grammar. It does not explicitly name a sibling alternative for reading file contents, so it falls short of a full when-to-use/when-not-to-use routing statement.

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

Deploy Server

Other Tools