docmost-mcp-oss

Overview Schema Source Related Servers Discussions Admin

Get Workspace Overview

get_workspace_overview

Lists all spaces and pages in the workspace, including nested pages, with optional activity dates and summary statistics to assess content and find what to read first.

Instructions

Start here. Lists everything in the workspace: every space and every page.

Use this to answer questions like "what do I have in Docmost?", to take an inventory, or to find a page by title before reading it with get_page. Unlike list_child_pages, it walks the whole page tree, so nested pages are included.

Each page carries id, slug_id, title, parent_page_id and depth, which is enough to rebuild the tree or to list everything flat.

With an activity level above "none" each page also carries updated_at and updated_by, and the result includes recently_updated: the most recently touched pages, newest first. Use it to decide what is worth reading first instead of walking the inventory blindly.

It also returns a summary with counts per space, tree shape (roots, containers, leaves, max depth), date ranges and recency buckets, pages never edited after creation, top editors and any orphaned pages. Every figure comes from data already gathered, so it costs nothing extra; summary.date_coverage states how much of the workspace the date-based numbers actually cover.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`activity`	No	How much activity data to gather: `"recent"` (default) reads the recent-pages window, so pages touched recently get dates; `"full"` additionally fetches each page to date all of them, which costs one request per page and is slow on large workspaces; `"none"` skips activity entirely.	recent
`space_id`	No	UUID of a single space to limit the listing (optional). Without it, every space the user can access is included.
`max_pages`	No	Safety cap on the total number of pages returned.
`check_empty`	No	When True, downloads each page to measure its body and flag the empty ones. Nothing cheaper exposes page size, so this costs one request per page — leave it off unless you specifically need it.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.6.0Sep 23, 2026

TDQS

A4.9/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden, and it delivers: it spells out what each activity level costs, warns that full activity and check_empty cost one request per page, explains that the summary adds no extra cost, and documents the exact per-page fields returned. This gives an agent an accurate mental model of both behavior and performance trade-offs.

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?

The description is front-loaded with the single most important instruction ("Start here"), and every subsequent sentence adds distinct information: scope, sibling differentiation, output shape, cost model, and summary semantics. It is long only because the tool has meaningful behavioral nuance, with no filler or repetition of schema fields.

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?

For a complex listing tool with no annotations, the description covers purpose, alternatives, output shape, cost behavior, and even a caveat about date coverage. Since an output schema exists, return-value details do not need to be duplicated, and the description fills the remaining gaps an agent would need to call it correctly.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine value beyond the schema: it connects activity levels to the returned recently_updated and per-page date fields, characterizes max_pages as a safety cap, and explains why check_empty is expensive. This helps an agent choose parameter values rather than just knowing their types.

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 opening line "Start here. Lists everything in the workspace: every space and every page" states a specific verb, a clear resource, and the full scope. It also explicitly contrasts itself with list_child_pages by noting it walks the whole page tree, so an agent can distinguish it from the closest sibling 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?

The description gives concrete use cases: answering 'what do I have?', taking an inventory, and finding a page by title before reading it with get_page. It also names the relevant sibling (list_child_pages) and explains the difference in tree traversal, making the selection condition explicit.

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