Skip to main content
Glama

List documents that outlived their use

folio_stale
Read-onlyIdempotent

Lists documents that likely outlived their use—unchanged for a year, never read, or unlinked—and explains why, so you can suggest what to archive without moving or deleting files.

Instructions

List documents that have probably outlived their use - by default unchanged for a year, never read and linked from nowhere, or what the folder's declared stale query names - each with when its file last changed and why; with path, only that document or those under that folder. Use it to suggest what to archive; Folio only lists them and never moves or deletes anything. For documents the reader should catch up on use folio_changes instead, and for everything wrong in the folder folio_health. It reveals which documents the reader never read. While the reader pauses sharing in Folio, it answers only {paused: true, message}. Answers {ready, documents: [{path, changed: ISO time, why}], version: the same while the list is}; ready false, with no documents, while Folio still reads the folder. A list cut to fit one answer adds omitted, the entries each list left out, and narrow, how to ask for less.

Input Schema

NameRequiredDescriptionDefault
pathNoA document, relative to the served folder or absolute under it, such as notes/plan.md, or a folder, such as notes/; omit for the whole folder

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already establish read-only, non-destructive, idempotent behavior, and the description adds real context beyond that: Folio never moves or deletes anything, the paused response shape {paused: true, message}, the not-ready state with empty documents while the folder is being read, version stability, and truncation metadata (omitted, narrow). That is unusually complete behavioral disclosure for a list tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

The purpose is front-loaded and every sentence carries information, but the text is a dense run-on chain of clauses with some restatement, e.g. 'It reveals which documents the reader never read' largely repeats 'never read' from the opening sentence. It would read better broken into shorter, ordered sentences.

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?

With no output schema, the description carries the full burden of describing returns, and it does: the document object fields (path, changed, why), the version field, the ready flag, the paused short-circuit, and the omitted/narrow truncation fields. An agent has enough to call it and interpret every expected response.

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 the path description already explains document vs folder vs omit. The description only echoes that split ('only that document or those under that folder') without adding syntax or edge-case meaning, so the baseline 3 applies.

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?

Names a specific verb and resource ('List documents that have probably outlived their use') and spells out the criteria (unchanged for a year, never read, linked from nowhere, or folder's declared stale query). It also explicitly separates itself from folio_changes and folio_health, 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?

States the intended use ('Use it to suggest what to archive') and names two alternatives with the conditions that select them: folio_changes for documents to catch up on, folio_health for everything wrong in the folder. The scope of the path parameter is also framed as a usage rule ('only that document or those under that folder').

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