Skip to main content
Glama

scan_directory

Scans a directory to find files already linked to vault nodes and lists unregistered files with suggested types, subtypes, and titles for review.

Instructions

Scan a directory for files and identify which already have vault nodes.

For each file found, checks whether any vault node has a has_asset location with scheme: local pointing to that file (by resolved absolute path).

Returns: { directory: str, total_files: int, unregistered: [{path, filename, format, suggested_type, suggested_subtype, suggested_title}, ...], registered: [{path, filename, format, node_uid}, ...], }

suggested_type is asset (with suggested_subtype book) for ebook formats and document otherwise; suggested_title is the humanized filename. Both come from the filename alone — confirm with the user when they look wrong.

Args: path: Absolute path to the directory to scan. recursive: Scan subdirectories recursively (default false).

Input Schema

NameRequiredDescriptionDefault
pathYes
recursiveNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.7.0

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does well: it discloses the exact matching rule (a has_asset location with scheme: local pointing at the resolved absolute path) and warns that suggested_type and suggested_title derive from the filename alone and may be wrong. It does not cover error behavior for missing/unreadable paths, symlink handling, or depth of recursion, which keeps it below 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 the purpose, then the matching rule, then a structured return shape, then args; each block is scannable. The suggested_type/subtype paragraph is slightly verbose for what it conveys but earns its place as a caution about derived values.

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

Completeness4/5

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

There is no output schema and no annotations, yet the description supplies a full return shape (directory, total_files, unregistered, registered with field lists), which is exactly what an agent needs to consume results. Remaining gaps are edge-case behavior on bad paths and recursion limits, minor for a read-only scanning tool.

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 0%, so the description must compensate, and it does for both parameters: path is specified as an absolute directory path and recursive is explained as scanning subdirectories, including its default. The absolute-path requirement and subdirectory semantics are genuine additions the schema does not provide.

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 opening line gives a specific verb and resource (scan a directory for files) plus the distinguishing outcome (identify which already have vault nodes). It is clear on its own, but among siblings such as find_unregistered_assets and scan_inbox there is no explicit statement of how this differs from those overlapping tools.

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

Usage Guidelines3/5

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

Usage is implied: you scan a directory to find unregistered files before saving them as assets, and the description advises confirming suggested_type/suggested_title with the user when they look wrong. However, it never names an alternative (e.g. find_unregistered_assets, scan_inbox) or states when not to use this tool, leaving the agent to infer selection.

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