Skip to main content
Glama

List Organize Nodes

list_organize_nodes
Read-onlyIdempotent

Lists AFFiNE sidebar organize folder and link nodes from the workspace DB so you can review them before moving or deleting any organize node.

Instructions

Experimental: list AFFiNE sidebar organize folder and link nodes from the folders workspace DB. Use this before moving or deleting organize nodes.

Input Schema

NameRequiredDescriptionDefault
workspaceIdNoAFFiNE workspace id. Omit only when AFFINE_WORKSPACE_ID is configured.

Output Schema

NameRequiredDescriptionDefault
okNo
codeNo
errorNo
nodesNo
detailsNo
causeCodeNo
retryableNo
workspaceIdNo
storageDocIdNo
recoveryGuidanceNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv3.10.2

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so safety is fully covered structurally. The description adds the 'Experimental' stability caveat and the fact that results come from the folders workspace DB, but says nothing about permissions, result shape, or volume/pagination. With rich annotations, a 3 is warranted.

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?

Two sentences, zero waste, with the scope statement and data source front-loaded ahead of the usage hint. The 'Experimental' marker earns its place as a stability signal.

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?

A read-only list tool with a documented single optional parameter, full annotations, and an output schema, so return values need not be explained. What remains missing is minor: whether both folders and links are always returned together and any ordering/paging behavior.

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?

Only one parameter (workspaceId) and schema description coverage is 100%, so the schema already explains the omission rule tied to AFFINE_WORKSPACE_ID. The description adds nothing about the parameter, which is acceptable at full coverage but not above baseline.

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?

States a specific verb (list) and a specific resource (AFFiNE sidebar organize folder and link nodes) plus the data source (folders workspace DB), which distinguishes it from siblings like list_workspace_tree or list_collections. The 'Experimental' prefix also flags the tool's maturity, though it slightly muddies the core statement.

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?

'Use this before moving or deleting organize nodes' gives a concrete trigger and implicitly points to move_organize_node and delete_organize_link. It stops short of naming those siblings or stating when not to use it (e.g., when reading a full doc tree), so it is clear but not exhaustive.

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

Deploy Server

Other Tools