Skip to main content
Glama
QuantumFabricIndustries

phantom-snare

list_files

List files in a directory, optionally filtered by a glob pattern, to quickly identify matching files for inspection or further processing.

Instructions

List files matching a path or pattern.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathNoDirectory path to list..
patternNoOptional glob pattern to filter results.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

C2.8/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action and filter, but does not mention whether the listing includes directories, whether it is recursive, what the return format is, or any side effects. This is minimal disclosure for a tool that could have significant behavioral nuances.

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

Conciseness3/5

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

The description is a single short sentence, which is concise and front-loaded. However, it is so brief that it omits useful context that could be added without bloating the description, such as the difference from 'list_directory' or the output format. It is concise but under-informative.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of the tool and full schema coverage, the description is minimally adequate, but it lacks critical context such as whether it lists only files or also directories, whether it is recursive, and how it differs from the sibling 'list_directory'. With no annotations and no output schema, the description should carry more weight to ensure correct usage.

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?

The input schema fully describes both parameters ('path' and 'pattern') with clear descriptions and a default for 'path'. The description merely restates the schema's concepts ('path or pattern') without adding extra meaning such as syntax, constraints, or examples, so it adds no value beyond the schema.

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?

The description states a clear verb ('List') and resource ('files') with a filtering condition ('matching a path or pattern'). It is concise and unambiguous about the tool's function, though it does not explicitly differentiate from the sibling tool 'list_directory', which may overlap in function.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like 'list_directory' or 'read_file'. There are no stated exclusions or conditions that would help an agent choose this tool over its siblings.

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