ProductNow

fetch_folder

Read-onlyIdempotent

List a folder you already have an id for, or the warehouse root. Pass folderId to list that folder's name, an optional parentFolderId to fetch and go up, and its direct contents. Each child folder and document includes its id, name, updatedAt, createdBy, and isPrivate. Each folder also includes contentCount, its direct documents plus subfolders, and subfolderCount, its direct child folders. Each document also includes its status: DRAFT, REVIEW, or PUBLISHED. A child folder also includes parentFolderId when it is nested, including a shared folder that shows up in the root listing but lives somewhere else; parentFolderId is omitted for a true top-level folder. Pass deep true with a folderId to return that folder and every nested folder as a tree, up to 15 levels, with each folder's documents inside it. deep is rejected for the warehouse root. Omit folderId to list the root one level: the top-level folders plus shared folders this user can see, not the whole warehouse and not other people's private folders. Not a search — use search to find a folder by name. Not a document read — use fetch to read a document.

Input Schema

Name	Required	Description	Default
`deep`	No	With folderId, return that folder and every nested folder as a tree of names and ids, up to 15 levels. Omit or pass false to list only direct children. Rejected when listing the warehouse root.
`folderId`	No	The folder to list. Pass deep true to return this folder and every nested folder. Omit deep to list only direct children. Omit to list the warehouse root one level.

Output Schema

Name	Required	Description
`name`	No	The folder name. Omitted when listing the root.
`folders`	Yes	Child folders. Without deep, each entry is identity plus updatedAt, createdBy, isPrivate, and parentFolderId when nested. With deep, each entry also nests its own documents and folders.
`folderId`	No	The folder you fetched. Omitted when listing the root.
`documents`	Yes
`resultType`	Yes
`parentFolderId`	No	The parent folder. Fetch it to go up. Omitted at the root and for a top-level folder.

Schema Changelog

Changes observed during successful MCP inspections.

AddedSep 28, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description is free to add operational context instead of repeating it. It does: the 15-level depth cap, that deep is rejected for the root, and that parentFolderId is omitted for true top-level folders while appearing for nested/shared ones. This is genuine behavioral disclosure beyond the annotations.

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?

The listing semantics are front-loaded, then the return-field inventory, then the exclusions. It is long, and the enumeration of child fields (id, name, updatedAt, createdBy, isPrivate, contentCount, status, etc.) partly duplicates the output schema, but each sentence still carries usable scoping 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?

An output schema exists, so return values need not be re-explained, yet the description still clarifies field semantics (contentCount = direct docs + subfolders, status enum values, parentFolderId nesting behavior). Root vs folder vs deep modes are all covered, and sibling routing is handled.

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% and both parameters are already documented in the schema, so the baseline is 3. The description restates the folderId/deep interaction ('Pass deep true with a folderId', 'deep is rejected for the warehouse root') which is largely duplicative of the schema descriptions rather than adding new syntax or edge-case detail.

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 opens with a specific verb+resource ('List a folder') and immediately scopes it ('you already have an id for, or the warehouse root'). It also explicitly distinguishes itself from two siblings ('Not a search — use search', 'Not a document read — use fetch'), so an agent can route correctly without opening any schema.

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

Usage Guidelines5/5

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

Explicit when-to-use is given for each mode: pass folderId to list a folder, omit it to list the root, add deep=true for a recursive tree. Explicit when-not-to-use is stated via the search and fetch exclusions, plus the constraint that deep is rejected for the warehouse root.

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

All ProductNow tools Inspect

Try in Browser

Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.