Skip to main content
Glama

Layven

by io.layven

list

Read-only

List files and folders under a path. Non-recursive by default: folders are synthesized from file paths. Pass recursive to list an entire subtree. Pass q to find files by name anywhere under path (case-insensitive substring of the full path; implies recursive). Omit workspace to search every workspace this token can reach. Always returns one result block per workspace searched, each with its own entries and next_cursor; limit applies per workspace. To page, call again with that block's workspace and next_cursor.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNoFind files whose full path contains this text, case-insensitive. Implies recursive.
pathNoFolder to list, relative to the workspace root. Empty string lists the root.
limitNoMax entries to return per workspace.
cursorNonext_cursor from a previous call, to fetch the next page. Requires an explicit workspace.
recursiveNoList the whole subtree under path instead of one level.
workspaceNoWorkspace slug. Optional, defaults to "temp".
include_deletedNoInclude deleted files, each flagged with deleted: true.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, but the description adds substantial behavioral detail beyond this: non-recursive default, folder synthesis from paths, per-workspace result blocks and next_cursor, and pagination requirements. This is valuable context for an AI agent.

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

Conciseness5/5

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

The description is a single focused paragraph with no redundant content. The first sentence states the core purpose, and subsequent sentences efficiently cover mode changes, multi-workspace behavior, and pagination. Every sentence earns its place.

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 7 parameters and no output schema, the description covers essential operational details: response structure (result blocks, entries, next_cursor), pagination, workspace behavior, and filter modes. It sufficiently explains the tool's behavior for an agent to use it 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%, so the baseline is 3. The description adds extra meaning by explaining implications of 'q' (implies recursive, case-insensitive full-path substring), 'cursor' requiring explicit workspace, and per-workspace limit semantics, which are not fully captured in the schema.

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?

The description specifies a clear verb+resource ('List files and folders under a path') and differentiates from siblings by explaining the file-name search mode (q) that distinguishes it from grep, and the path-based listing vs read's content-focused behavior.

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?

Provides explicit guidance on using recursive, q, workspace omission, and paging behavior. It doesn't explicitly name alternative tools (e.g., 'use grep for content search'), but the parameter explanations clearly define when to use this tool for listing/name-filtering tasks.

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

All Layven toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0
Disambiguation5/5

Each tool targets a distinct operation: file CRUD (write, read, edit, delete), versioning (history, restore), search (grep, list with q), locking (lock, unlock), uploads (request_upload, finalize_upload), and activity tracking. Even similar tools like request_upload and finalize_upload are complementary rather than overlapping.

Naming Consistency4/5

Tool names are lowercase and action-oriented, with single-word verbs (read, write, delete) and two compound verbs (request_upload, finalize_upload) following a verb_noun pattern. This is consistent enough to be predictable, though the mix of single words and compound words is a minor deviation.

Tool Count5/5

14 tools is well-scoped for a versioned file management server. Each tool covers a necessary aspect of the domain—file operations, version control, search, locking, uploads, and activity—without unnecessary bloat or missing critical functionality.

Completeness5/5

The tool set covers the full lifecycle of file management: create/write, read, edit, delete, restore, list, search, lock, unlock, upload/download (via request_upload/finalize_upload and read's download URL). The only potential gap is a copy operation, but that can be achieved with read+write. All workflows have no dead ends.

Resources