Skip to main content
Glama

Get Orphan Documents

get_orphan_docs
Read-onlyIdempotent

Find documents with no parent or incoming links in an AFFiNE workspace to identify orphaned docs for cleanup and workspace hygiene.

Instructions

Find all documents that have no parent (not linked from any other doc via embed_linked_doc / embed_synced_doc blocks or inline LinkedPage references). Useful for workspace hygiene. Note: scans all docs — O(n). Each doc includes an inTrash flag.

Input Schema

NameRequiredDescriptionDefault
workspaceIdNo

Output Schema

NameRequiredDescriptionDefault
okNo
codeNo
countNo
errorNo
detailsNo
orphansNo
causeCodeNo
retryableNo
recoveryGuidanceNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv3.10.2

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already cover read-only, idempotent, and non-destructive, so the bar is lower. The description still adds real value: it discloses the O(n) full-scan cost, the reference types scanned, and that each result carries an inTrash flag — none of which are in 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.

Conciseness5/5

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

Three sentences, front-loaded with the core definition, then caveat, then result detail. No filler and each sentence contributes distinct information.

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

Completeness3/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 needn't be described, and the inTrash flag is helpfully surfaced. However, for a tool whose only input is a workspace selector, leaving workspaceId's meaning and default scope undocumented is a real gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the sole parameter workspaceId is never mentioned in the description; its optionality (0 required) and default scope are left unexplained. Only the vague phrase 'scans all docs' hints at scope, which does not compensate for the coverage gap.

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?

States a specific verb (find) and resource (documents with no parent) and operationally defines 'orphan' by naming the exact reference types (embed_linked_doc, embed_synced_doc, LinkedPage). This clearly separates it from siblings like list_docs or list_workspace_tree.

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?

Gives a motivation ('useful for workspace hygiene') which implies when to reach for it, but names no alternatives and sets no exclusions — an agent must infer that list_workspace_tree is the structural alternative. Usage is implied rather than specified.

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