Skip to main content
Glama

List a directory

list_directory
Read-onlyIdempotent

A directory of a tree: its index.md (when it has one), its subdirectories, and the concepts directly in it. Omit the path for the tree's root; omit the tree to list the trees.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_directory"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathNoDirectory, e.g. `product`; omit for the root.
treeNoThe tree's slug, as list_trees gives it (not its name). The tree to list; omit to list the trees.

Output Schema

NameRequiredDescriptionDefault
urlNoThe directory's page in OKForest.
pathNoThe directory listed; empty for the root.
treeNoThe tree, and the commit it was read at.
indexNoThe directory's `index.md`, when it has one.
treesNoWithout `tree`: the account's trees.
accountNoWithout `tree`: the account whose Forest this is.
conceptsNoThe concepts directly in it.
directoriesNoIts subdirectories.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare read-only, idempotent, closed-world behavior, so the safety profile is covered. The description adds the content shape of the result (index.md, subdirectories, concepts) and the degenerate no-tree case, but says nothing about depth/recursion, ordering, or size limits.

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?

Two compact sentences, the result composition front-loaded and the omission cases second. The opening fragment 'A directory of a tree' is slightly awkward but not wasteful.

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?

With an output schema present, the description doesn't need to document return values, and the two-parameter surface is fully mapped. Only traversal behavior (recursive vs immediate) and ordering remain unspecified, which are minor for a listing tool.

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?

Schema coverage is 100%, so both parameters are already documented, including the 'omit for root' and 'omit to list the trees' semantics. The description restates those omission rules without adding format or value details beyond the schema, so baseline 3 applies.

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 enumerates exactly what a listing contains (index.md when present, subdirectories, direct concepts), which is more specific than the name alone. It doesn't explicitly contrast with siblings like list_trees or get_concept, but the composition of the result makes the tool's role distinguishable.

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?

It explains the two omission cases: omit path for the tree root, omit tree to get the tree list. That is parameter usage guidance rather than tool-selection guidance — nothing tells the agent when to call this versus list_trees, search_concepts, or get_concept.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources