Skip to main content
Glama
yenchieh

DiagramZu

by yenchieh
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

list_pages

List the workspace's Markdown pages, most recently edited first. Returns each page's id, title, revision, last-edit time, who edited it, and a short snippet — never the full body; call get_page for that.

Instructions

List the workspace's Markdown pages, most recently edited first. Returns each page's id, title, revision, last-edit time, who edited it, and a short snippet — never the full body; call get_page for that. Filter with q, a case-insensitive substring over title and body that works in Chinese and Japanese too, and pass sort: 'relevance' with it so a title hit ranks first. Call this BEFORE create_page to see whether a page on the topic already exists — prefer update_page over writing a second one.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNoCase-insensitive substring search over title and body. Works for CJK text; a query of one or two Chinese characters is slower because the trigram index cannot help it.
sortNoSort order. 'updated' (the default) = newest edit first; 'created' = newest page first; 'title' = alphabetical; 'relevance' = title hits before body hits, and only meaningful with `q`.
ownerNoFilter to pages created by this user id. Rarely needed; omit unless the caller already has the id.
spaceNoWhich workspace to act in: its id, its slug, or its exact name (case-insensitive). Omit to use this token's default workspace. Call list_spaces to see what this token can reach. A name that matches more than one workspace is refused — pass the id or slug instead.
folderIdNoOptional UUID — narrow to pages in this folder. Use list_folders to look up folder ids. Omit to see every folder (the default).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.0.8

TDQS

A4.3/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden, and it discharges most of it: it enumerates the returned fields, explicitly denies body content, documents the default sort, warns that CJK two-character queries are slower due to the trigram index, and notes that an ambiguous workspace name is refused. The notable gap is that it says nothing about result limits or pagination for a list endpoint.

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?

Dense but front-loaded: purpose and result shape come first, then filtering, then the create/update workflow guidance. Every sentence carries distinct information, though the paragraph is on the longer side for a list tool and could be split for scanability.

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 no output schema and no annotations, the description must supply return format and safety context, and it does describe the returned fields and that bodies are excluded. For a 5-parameter list tool the one meaningful omission is pagination/limit behavior, which leaves a small but real gap.

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 description coverage is 100%, so the parameters are already well documented in the schema itself. The description's added value is modest: the q plus sort:'relevance' combination is already stated in the schema ('only meaningful with q'), so the description largely reinforces rather than extends parameter meaning, warranting the baseline 3.

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 and resource ('List the workspace's Markdown pages') plus the default ordering ('most recently edited first') and immediately contrasts with get_page by stating it returns snippets, never the full body. An agent can distinguish it from list_folders, list_diagrams, and get_page without opening a 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?

Gives explicit workflow routing: call this BEFORE create_page to check for duplicates, prefer update_page over creating a second page, and call get_page for the full body. It also specifies the q + sort:'relevance' pairing, so both when-to-use and how-to-configure are covered.

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