docmost-mcp-local

Name: docmost-mcp-local
Author: wisflux

by wisflux

Overview Schema Source Related Servers Discussions Admin

Rust

Local

@wisflux/docmost-local-mcp

npm version npm downloads license

MCP server for Docmost that is built for self-hosted instances, especially deployments that do not have an enterprise license but still want reliable MCP access from local IDEs and AI tools.

The package is launched with npx, while the actual server is a Rust binary downloaded from GitHub Releases during install. That binary handles stdio MCP traffic, local authentication UX, session storage, and Docmost API access.

The main reason this project exists: bring MCP access to self-hosted Docmost setups without making an enterprise license a prerequisite.

Why This Project

Many MCP integrations are designed around hosted or enterprise assumptions. This project is intentionally optimized for self-hosted Docmost:

Works against your own Docmost base URL
Uses Docmost email/password authentication
Stores session state locally for reuse
Opens a local auth flow instead of requiring a separate hosted control plane
Ships as a simple npx entrypoint for easy IDE integration

If you run your own Docmost and want it available inside Cursor, Claude Desktop, or another MCP client, this package is the straightforward path.

Related MCP server: Outline knowledge base MCP Server

Highlights

Strong fit for self-hosted Docmost instances without enterprise licensing
Rust server core with a small Node launcher for predictable local installs
Native auth window on supported platforms, with browser fallback
Explicit Docmost instance selection via startup config
Session reuse with JWT expiry checks and automatic re-login
OS keychain credential storage on supported platforms
Clean tool surface for spaces, pages, comments, members, and current user context

Available Tools

list_spaces: list available Docmost spaces
get_space: fetch details for a specific space
search_docs: search documentation, optionally scoped to a space
search_pages: backward-compatible alias for search_docs
get_page: fetch a page and return its content as Markdown
list_pages: list recent pages in a space
list_child_pages: list child pages for a parent page ID
get_comments: list comments for a page
list_workspace_members: list workspace members
get_current_user: fetch the authenticated user and workspace context
create_page: create a new page in a space from Markdown content
update_page: update an existing page's title and/or Markdown content
duplicate_page: duplicate a page (and its sub-pages) within its space
copy_page_to_space: copy a page (and its sub-pages) into a different space
move_page: move a page under a new parent page, or to the space root
move_page_to_space: move a page (and its sub-pages) to a different space
create_space: create a new space with a name and URL slug
update_space: update a space's name, slug, and/or description
create_comment: add a page-level comment to a page from Markdown
update_comment: replace an existing comment's body with new Markdown

Roadmap

All planned read and write tools are now implemented. create_comment adds page-level comments; comments anchored to a specific text selection (inline comments) require the collaborative editor's cursor positions and are out of scope for this REST-based server.

Compatibility

Targets Docmost from roughly the last year of releases (v0.22+); older servers work best-effort. The server detects the Docmost version (via POST /api/version) once per session and adapts where behaviour differs:

Page body edits: update_page can only change an existing page's body on Docmost v0.70.0+. On older servers the body lives in the collaborative editor and a REST body update is ignored — update_page says so explicitly and suggests create_page (which persists bodies on every version via the import endpoint). Title updates work everywhere.

Content support

Page and comment bodies are written in Markdown (headings, bold/italic/strike, inline code, links, lists, task lists, blockquotes, code blocks; pages also support tables and external-URL images). Comments support a smaller set — no tables, task lists, or images.

Mentions (@tagging): in any Markdown body, a link with a user: or page: URL becomes a mention — [Display Name](user:USER_UUID) tags a user (find the UUID with list_workspace_members) and [Page Title](page:PAGE_UUID) links a page. Tagged users are notified by Docmost.

Attaching uploaded files/images (as opposed to referencing an image URL) is not supported.

Requirements

Node.js 18 or newer for npx
A reachable Docmost instance
Email/password authentication enabled in that Docmost instance

Quick Start

Run the server directly with npx:

npx -y @wisflux/docmost-local-mcp --base-url=https://docs.example.com

You can also provide the base URL with an environment variable:

DOCMOST_BASE_URL=https://docs.example.com npx -y @wisflux/docmost-local-mcp

MCP Client Configuration

Most MCP clients launch the server directly with npx. Add this to your client's MCP config, replacing the base URL with your own Docmost instance:

{
  "mcpServers": {
    "docmost": {
      "command": "npx",
      "args": ["-y", "@wisflux/docmost-local-mcp", "--base-url=https://docs.example.com"]
    }
  }
}

Where that config lives, per client:

Claude Desktop — claude_desktop_config.json (Settings → Developer → Edit Config)
Cursor — ~/.cursor/mcp.json (global) or .cursor/mcp.json (per project)

Claude Code — one command, no file editing:

claude mcp add docmost -- npx -y @wisflux/docmost-local-mcp --base-url=https://docs.example.com

VS Code (GitHub Copilot) — .vscode/mcp.json, using a top-level servers key instead of mcpServers:

{
  "servers": {
    "docmost": {
      "command": "npx",
      "args": ["-y", "@wisflux/docmost-local-mcp", "--base-url=https://docs.example.com"]
    }
  }
}

This setup works well when you want a fixed Docmost instance per client configuration. If --base-url or DOCMOST_BASE_URL is set, the login page shows that URL prefilled and locks the field. If no base URL is configured, the login flow asks for it during interactive sign-in.

Example Prompts

Once connected, ask your AI client things like:

"Search the Engineering space in Docmost for our on-call runbook and summarize it."
"Create a new page in the Product space titled 'Q3 Planning' from these notes: …"
"Turn this meeting transcript into a structured Docmost page under the Team space."
"Find every page in Docmost that mentions the old API endpoint and list them."
"Read the 'Onboarding' page and draft a shorter checklist as a new sub-page."
"Add a comment on the release-notes page flagging the missing migration step."

Authentication Flow

Your MCP client launches the server over stdio.
On the first authenticated tool call, the server starts a local HTTP login page on 127.0.0.1.
The server opens a native auth window when available, or falls back to the system browser.
You enter your email and password there. If --base-url or DOCMOST_BASE_URL is set, the Docmost URL is prefilled and locked.
The server signs in through /api/auth/login, extracts the authToken cookie, stores the session, and optionally stores credentials for automatic re-login.
Future requests reuse the saved token until it is close to expiry or rejected by Docmost.

Local State And Credential Storage

The server stores local state in:

~/.docmost-local-mcp/

Files used there:

config.json: last base URL and email
session.json: saved auth token and expiry

Credentials are stored in the OS keychain when available, which is the preferred path on supported platforms.

If secure OS credential storage is unavailable, the server falls back to encrypted local credential storage so it can still support login reuse without writing plain-text credentials. That fallback is intentionally secondary to keychain-backed storage.

Platform Notes

The native auth window uses the system webview on each platform:

macOS: WKWebView
Windows: WebView2
Linux: WebKitGTK

Important caveats:

Windows needs the WebView2 runtime available
Linux desktop environments need WebKitGTK packages installed
When the binary is built without the native-webview feature, browser fallback is always used

Tool Reference

`list_spaces`

Returns Docmost space names, slugs, and IDs.

`search_docs`

Inputs:

query: required search text
space_id: optional Docmost space ID

`search_pages`

Inputs:

query: required search text
space_id: optional Docmost space ID

This is a backward-compatible alias for page search. search_docs remains available.

`get_space`

Inputs:

space_id: required Docmost space ID

`get_page`

Inputs:

slug_id: the page slug ID returned by search_docs

`list_pages`

Inputs:

space_id: required Docmost space ID
limit: optional page count limit
cursor: optional pagination cursor

`list_child_pages`

Inputs:

page_id: required parent page ID
limit: optional page count limit
cursor: optional pagination cursor

`get_comments`

Inputs:

page_id: required page ID
limit: optional comment count limit
cursor: optional pagination cursor

`list_workspace_members`

Inputs:

limit: optional member count limit
cursor: optional pagination cursor
query: optional member search text
admin_view: optional admin visibility flag

`get_current_user`

Inputs:

none

`create_page`

Inputs:

space_id: required Docmost space ID (UUID) to create the page in
title: required page title
markdown: optional page body as Markdown
parent_page_id: optional parent page ID to nest under (title-only pages only)

When markdown is provided, the page body is sent through Docmost's import endpoint (POST /api/pages/import), which is the only mechanism that reliably persists page body content across Docmost versions (including older self-hosted servers). Pages created with a body land at the space root — parent_page_id is honored only for title-only pages.

`update_page`

Inputs:

page_id: required Docmost page ID or slug ID
title: optional new title (omit to leave unchanged)
markdown: optional new body as Markdown; replaces the existing content (omit to leave unchanged)

Updating a page title works on all Docmost versions. Updating an existing page's body via REST works only on newer Docmost; on older self-hosted servers (e.g. v0.25.x) the body is edited solely through the collaborative editor and a REST body update is not applied. To set body content reliably there, create a new page with create_page instead.

For the full design, Markdown→ProseMirror conversion details, verified Docmost API fields, and version caveats, see docs/write-tools.md.

Development

For maintainer and contributor workflow details, see CONTRIBUTING.md.

License

MIT

Available Tools

20 tools

copy_page_to_spaceA

Copy a Docmost page (with its sub-pages) into a different space.

ParametersJSON Schema

Name	Required	Description	Default
`page_id`	Yes	The Docmost page ID or slug ID to copy.
`space_id`	Yes	The target space ID (UUID) to copy the page into.

TDQS

A3.6/5.0

Behavior3/5

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

Annotations indicate non-destructive, non-read-only, non-idempotent. The description adds that sub-pages are copied. However, it does not disclose additional behavioral traits like asynchronicity, permission handling, or what gets created. With annotations present, the bar is lower; the description adds some value but not extensive context.

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 a single, concise sentence that efficiently communicates the tool's core functionality with no redundant words or structure.

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?

The description is complete enough for a simple copy operation: it specifies the source (page with sub-pages) and destination (different space). No output schema exists, but return values are straightforward. Minor omission: does not explain if the copy is recursive or how conflicts are handled, but overall adequate.

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?

Both parameters are fully described in the input schema (100% coverage). The description merely repeats their names, adding no extra meaning beyond what the schema provides. Baseline of 3 is appropriate.

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 description clearly states the action: copying a page along with its sub-pages into a different space. It uses specific verbs and resources, and distinguishes from sibling tools like move_page_to_space (move vs copy) and duplicate_page (same space vs different space).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives such as move_page_to_space or duplicate_page. The sibling list shows similar tools, but no explicit context or exclusion criteria are given.

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

create_commentA

Add a page-level comment to a Docmost page, written in Markdown.

ParametersJSON Schema

Name	Required	Description	Default
`page_id`	Yes	The Docmost page ID (UUID) to comment on.
`markdown`	Yes	Comment body as Markdown. Creates a page-level comment (not anchored to a text selection). To tag a user, write a link with a `user:` URL: `[Display Name](user:USER_UUID)` (get USER_UUID from list_workspace_members); `[Title](page:PAGE_UUID)` mentions a page. Tables, images, and task lists are not supported inside comments.

TDQS

A4/5.0

Behavior4/5

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

Annotations already indicate a write operation (readOnlyHint false) with no destructive or idempotent behavior. The description adds that the comment is page-level (not anchored to text selection), which is valuable behavioral context beyond the annotations. However, it does not disclose success/error details or permission requirements, which are minor given the simplicity.

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 a single sentence of 12 words, front-loaded with the verb 'Add'. It contains no unnecessary words and every element contributes to the purpose.

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?

For a simple create tool with 2 well-described parameters and no output schema, the description is largely complete. It explains what the tool does and that comments are page-level. A minor gap is that it does not mention the return value, but this is acceptable given the tool's simplicity and the convention of creation tools returning the created resource.

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%, with both parameters (page_id, markdown) fully described in the schema. The main description does not add additional meaning beyond what the schema provides, so baseline score of 3 is appropriate.

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 description clearly states the verb 'Add', the resource 'page-level comment', the context 'to a Docmost page', and the format 'written in Markdown'. This distinguishes it from siblings like update_comment (modify) and get_comments (read).

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?

The description implies that this tool is for creating new page-level comments, but it does not explicitly state when to use it versus alternatives (e.g., update_comment for editing, get_comments for reading). No exclusions or prerequisites are mentioned.

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

create_pageA

Create a new Docmost page in a space from Markdown content.

ParametersJSON Schema

Name	Required	Description
`title`	Yes	Page title.
`markdown`	No	Page body as Markdown; converted to ProseMirror JSON before sending.
`space_id`	Yes	The Docmost space ID (UUID) to create the page in.
`parent_page_id`	No	Optional parent page ID to nest this page under (must be in the same space).

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already indicate non-read-only and non-destructive behavior. The description adds the conversion detail ('converted to ProseMirror JSON') but does not disclose other behavioral traits like rate limits, authentication needs, or side effects. No contradiction with 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?

Single 11-word sentence. No fluff, every word earns its place. Front-loaded with the action and resource.

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

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description should explain return values or what happens after creation. It does not. Also omits mention of required prerequisites (e.g., space must exist). For a creation tool with 4 parameters, this is incomplete.

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?

Input schema covers all 4 parameters with descriptions (100% coverage). The description's 'from Markdown content' loosely relates to the markdown parameter but adds no meaningful information beyond the schema. Baseline 3 is appropriate given high schema coverage.

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 description clearly states the verb 'create', the resource 'Docmost page', and the context 'in a space from Markdown content'. This distinguishes it from sibling tools like 'duplicate_page' (copy existing) and 'update_page' (modify existing).

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?

The description implies when to use (creating a new page) but provides no explicit guidance on when not to use or alternatives. With 19 sibling tools, more exclusions or comparisons would help, but the context is clear enough for basic use.

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

create_spaceB

Create a new Docmost space with a name and URL slug.

ParametersJSON Schema

Name	Required	Description
`name`	Yes	Space name (2-100 characters).
`slug`	Yes	URL slug: letters and numbers only (2-100 characters). Some Docmost versions also allow hyphens and underscores, but letters/numbers work everywhere.
`description`	No	Optional space description.

TDQS

B3.2/5.0

Behavior2/5

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

While annotations indicate a write operation (readOnlyHint=false) and non-destructive, the description adds no behavioral details beyond creation. It does not disclose return value, permissions, or side effects.

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 a single, well-formed sentence with no unnecessary words. It is front-loaded with the main action.

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

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema is provided, and the description does not mention what the tool returns (e.g., the created space object). Given 20 sibling tools, more context would help differentiate usage.

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%, so the schema already describes each parameter. The description adds no extra semantic value beyond what is in the schema.

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 description clearly states the action ('Create') and the resource ('a new Docmost space'), and specifies required inputs (name and URL slug). It distinguishes from sibling tools like update_space or list_spaces.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives (e.g., when to use update_space instead). The description does not mention prerequisites or when not to use it.

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

duplicate_pageA

Duplicate a Docmost page (with its sub-pages) within its space.

ParametersJSON Schema

Name	Required	Description	Default
`page_id`	Yes	The Docmost page ID or slug ID to duplicate within its space.

TDQS

A3.8/5.0

Behavior3/5

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

Annotations declare destructiveHint=false and readOnlyHint=false, indicating a mutation but not destructive. Description adds that sub-pages are included, but omits details like duplicate naming conventions, permission inheritance, or return value.

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?

Single sentence, front-loaded with the key information. Every word is meaningful, no wasted text.

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?

For a simple tool with one parameter and no output schema, the description covers the basic functionality. However, it lacks information about the return value (e.g., success indicator or new page ID).

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% for the single parameter page_id. The description repeats 'within its space' which is already in the schema, adding no new semantic value.

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?

Description clearly states the action (Duplicate), the resource (Docmost page), and scope (with sub-pages within its space). This distinguishes it from sibling tools like copy_page_to_space (which copies to another space) and move_page.

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?

The description implies usage for duplicating a page in the same space but does not explicitly state when to use this tool versus alternatives like copy_page_to_space or move_page.

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

get_commentsB

Read-only

List Docmost comments for a page ID.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Optional number of comments to return.
`cursor`	No	Optional cursor returned by a previous list call.
`page_id`	Yes	The Docmost page ID to list comments for.

TDQS

B3.3/5.0

Behavior3/5

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

Annotations already indicate readOnlyHint=true, so the agent knows this is a read operation. The description adds that it lists comments for a page ID, which is consistent. However, it does not disclose pagination behavior even though the schema includes cursor and limit parameters, nor does it mention potential errors or rate limits. This is adequate but not enriched.

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?

The description is a single sentence, concise and front-loaded with the core action. However, it lacks any additional structure such as examples or notes, but it does not contain any fluff. It earns a 4 because it is efficient but minimally informative.

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

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Without an output schema, the description should clarify what is returned, but it does not. It also fails to explain pagination despite the presence of cursor and limit parameters. Given the complexity of 3 parameters and no output schema, the description is incomplete for an agent to fully understand the tool's 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?

The schema already provides descriptions for all three parameters (100% coverage), so the description does not add new semantic meaning beyond restating the resource. According to the rules, with high schema coverage the baseline is 3, and the description does not exceed that.

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 description uses a specific verb 'List' with a clear resource 'Docmost comments' and scope 'for a page ID', which distinguishes it from sibling tools like create_comment or update_comment that perform different actions. The purpose is immediately obvious.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. For example, it does not mention that this tool should be used to retrieve comments, while create_comment is for adding new ones. This omission forces the agent to infer usage from the tool name alone.

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

get_current_userA

Read-only

Fetch the current Docmost user and workspace context.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

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

The annotations already declare readOnlyHint=true, and the description adds 'Fetch' which aligns. However, no additional behavioral details (e.g., auth requirements, rate limits) are provided beyond 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?

The description is a single, front-loaded sentence that conveys exactly what the tool does without unnecessary words.

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?

For a simple getter with no parameters and no output schema, the description provides sufficient context about what is returned (user and workspace context). It could mention that authentication is required, but that is likely inherent.

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?

There are no parameters, so the description does not need to add parameter details. The schema coverage is 100%, and the description is concise.

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 description clearly states the verb 'Fetch' and the resource 'current Docmost user and workspace context,' which is specific and distinguishes it from sibling tools that manipulate pages, spaces, or comments.

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?

The description implies the tool is used to get context about the current user, but it does not explicitly state when to use it (e.g., before performing other operations) or mention alternatives.

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

get_pageA

Read-only

Fetch a Docmost page by slug ID and return its content as Markdown.

ParametersJSON Schema

Name	Required	Description	Default
`slug_id`	Yes	The page slug ID returned from search_docs.

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true. The description adds the behavioral trait that it returns Markdown content. No contradictions. Could mention error handling or rate limits but acceptable given 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?

Single sentence, no wasted words. Front-loads the action 'Fetch'. Perfectly concise.

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?

For a simple one-parameter tool with no output schema, the description covers the main action and return format. Missing details on error behavior but acceptable for a read-only fetch.

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% with one parameter fully described. The description's 'by slug ID' adds minimal extra meaning beyond the schema's description. 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?

The description clearly states the verb 'Fetch', the resource 'Docmost page', the method 'by slug ID', and the output format 'as Markdown'. This distinguishes it from siblings like search_docs which returns a list of pages, not content.

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?

Implied usage: the slug ID comes from search_docs, but no explicit guidance on when to use this tool versus alternatives like get_comments or list_child_pages. No when-not-to-use or exclusion criteria.

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

get_spaceA

Read-only

Fetch Docmost space details by space ID, including membership context for the current user.

ParametersJSON Schema

Name	Required	Description	Default
`space_id`	Yes	The Docmost space ID.

TDQS

A4/5.0

Behavior4/5

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

Annotations already mark the tool as readOnlyHint=true, so safety is clear. The description adds value by specifying that the response includes membership context, which is beyond the basic read behavior. No contradictions.

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 a single, concise sentence that front-loads the action and resource, with no redundant or wasteful language.

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?

Given the tool is simple (one parameter, read-only, no output schema), the description sufficiently explains what the tool returns (space details and membership context). It could optionally mention that the space_id is required, but that is already in the schema. Overall adequate.

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?

The single parameter space_id is already fully described in the input schema (100% coverage). The description adds no additional semantic information about the parameter, so baseline score of 3 is appropriate.

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?

Description clearly specifies the action (fetch), resource (space details), and key differentiator (including membership context for the current user). This distinguishes it from sibling tools like list_spaces (which lists all spaces) or update_space (which modifies).

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?

The description implies usage when you have a specific space ID, but does not explicitly state when to use this tool vs alternatives like list_spaces, nor does it provide any exclusion criteria or prerequisites.

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

list_child_pagesB

Read-only

List child pages for a Docmost page ID.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Optional number of child pages to return.
`cursor`	No	Optional cursor returned by a previous list call.
`page_id`	Yes	The parent Docmost page ID.

TDQS

B3.3/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=true. Description adds no additional behavioral traits, such as pagination behavior or hierarchy depth.

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?

Single sentence with no unnecessary words. Efficient and front-loaded.

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?

Minimally adequate for a simple list tool, but lacks explanation of pagination or child page concept, and has no output schema.

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%, so baseline is 3. Description merely restates page_id context without adding meaning for limit or cursor parameters.

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 description precisely states the tool lists child pages for a given page ID, clearly distinguishing it from sibling tools like get_page or list_pages.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. Siblings include other list and search tools, but no context is provided for selection.

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

list_pagesB

Read-only

List recent Docmost pages in a space by space ID.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Optional number of pages to return.
`cursor`	No	Optional cursor returned by a previous list call.
`space_id`	Yes	The Docmost space ID to list pages from.

TDQS

B3.3/5.0

Behavior3/5

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

Annotations already indicate readOnlyHint=true. Description adds that it lists 'recent' pages, but does not define 'recent' criteria (e.g., last updated). No mention of ordering or draft status. With annotations covering safety, bar is lower, but description lacks deeper behavioral context.

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?

Single sentence of 8 words, efficient and front-loaded. However, it may be too concise, missing context on pagination and return values, but still effective for the core purpose.

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

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite simple tool, no output schema and minimal description. Lacks explanation of return format, pagination behavior (cursor, limit), or what 'recent' means. Agent cannot fully understand output without additional info.

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%, with clear descriptions for each parameter. Description adds the qualifier 'recent' but does not enhance parameter semantics beyond schema. 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?

Clearly states it lists recent pages in a space by space ID, distinguishing from siblings like get_page (single page), search_pages (search), and list_child_pages (child pages).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives like search_pages or list_child_pages. Does not mention prerequisites or context for pagination (cursor).

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

list_spacesA

Read-only

List all available documentation spaces in Docmost, including names, slugs, and IDs.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already indicate readOnlyHint=true, so the description adds value by specifying that it returns names, slugs, and IDs. No contradictions. However, there is no mention of potential limits or ordering.

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?

One sentence with no fluff. Every word adds value. Front-loaded with the core action and resource.

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?

For a list tool with no parameters, the description is complete: it specifies the output fields. Lacks mention of pagination or sorting, but these are not critical for basic usage. Combined with annotations, it is sufficient.

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?

The tool has no parameters, and schema coverage is 100%. The description adds no parameter info because none is needed. Baseline 4 is appropriate.

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 description clearly states the action (list), resource (all available documentation spaces), and included data (names, slugs, IDs). It distinguishes from siblings like get_space (single space) and create_space.

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?

Usage is implied by the tool name and description: use when you need an overview of all spaces. No explicit when-not-to-use or alternatives are provided, but the context of sibling tools makes it clear.

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

list_workspace_membersA

Read-only

List Docmost workspace members visible to the current user.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Optional number of members to return.
`query`	No	Optional text filter for member names or emails.
`cursor`	No	Optional cursor returned by a previous list call.
`admin_view`	No	Optional admin view flag, when supported by the workspace.

TDQS

A4/5.0

Behavior3/5

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

Annotations already indicate readOnlyHint=true, so the description doesn't need to cover safety. It adds context by mentioning 'visible to the current user', but does not elaborate on pagination or other behaviors beyond what the schema implies.

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 a single clear sentence with no extraneous words. It efficiently conveys the tool's purpose.

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?

For a simple listing tool with no output schema, the description adequately covers functionality. It could mention pagination or result structure, but the schema parameters hint at this, so it is largely complete.

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 schema fully documents the four optional parameters. The description adds no additional meaning beyond the schema, so it meets the baseline.

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 description clearly states the verb 'List', the resource 'workspace members', and the scope 'visible to the current user'. It is specific and distinguishes itself from sibling tools, as no other tool lists members.

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?

The description implicitly defines its use case by specifying 'workspace members visible to the current user'. Since there are no alternative member-listing tools among siblings, explicit when-to-use guidance is less critical.

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

move_pageA

Idempotent

Move a Docmost page under a new parent page, or to the space root. The page is appended after the target parent's existing children.

ParametersJSON Schema

Name	Required	Description	Default
`page_id`	Yes	The Docmost page ID or slug ID to move.
`parent_page_id`	No	Optional new parent page ID within the same space. Omit to move the page to the space root. The page is appended after the parent's existing children.

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already provide readOnlyHint=false, idempotentHint=true, destructiveHint=false. Description adds behavioral detail about ordering (appended after existing children) and scope (within same space). No contradictions, adds value beyond 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?

Two sentences, front-loaded with action and resource, then additional detail. Every word earns its place. No fluff.

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?

Tool is simple with 2 params, no output schema, and annotations cover mutation and idempotency. Description covers the two use cases and ordering behavior completely. No missing critical information.

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 baseline is 3. Tool description doesn't add new parameter semantics beyond what schema already provides for both page_id and parent_page_id. No additional value.

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?

Clearly states the action (move) and resource (Docmost page), specifies two destinations (new parent page or space root), and distinguishes from sibling tools like copy_page_to_space and move_page_to_space by focusing on parent changes within the same space.

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?

Explicitly describes when to use: moving a page under a new parent or to space root. Implicitly excludes cross-space moves (use move_page_to_space), but lacks explicit alternative naming. Clear context for appropriate use.

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

move_page_to_spaceB

Idempotent

Move a Docmost page (with its sub-pages) to a different space.

ParametersJSON Schema

Name	Required	Description	Default
`page_id`	Yes	The Docmost page ID or slug ID to move.
`space_id`	Yes	The target space ID (UUID) to move the page (and its sub-pages) into.

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already indicate readOnlyHint=false, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds that sub-pages are moved along with the page, which provides some behavioral context beyond annotations. However, it does not explain permissions, side effects, or what happens to the original location (since destructiveHint=false, it implies source is not destroyed, but that is already clear from annotations). The description does not contradict 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?

The description is a single sentence that is front-loaded and contains no unnecessary words. Every part contributes to understanding the tool's core function. It is appropriately concise for a tool with two well-described parameters.

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

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Without an output schema, the description should disclose what the tool returns (e.g., success indicator, moved page object). It does not. Additionally, for a mutation tool, it lacks context on prerequisites (e.g., user permissions, page not locked) and potential side effects. Sibling tools like 'get_page' have output schemas, making this one feel incomplete.

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%, with clear descriptions for both parameters: page_id is described as 'The Docmost page ID or slug ID to move' and space_id as 'The target space ID (UUID) to move the page (and its sub-pages) into.' The tool description adds no additional meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.

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 description clearly states the action ('move'), the resource ('a Docmost page with its sub-pages'), and the target ('to a different space'). This distinguishes it from sibling tools like 'copy_page_to_space' (copy vs move) and 'move_page' (which likely moves within a space). The purpose is specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. The sibling list includes 'move_page' (ambiguously named) and 'copy_page_to_space', but the description does not clarify the difference or suggest contexts for each. Users are left to infer usage scenarios.

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

search_docsA

Read-only

Search Docmost documentation and optionally filter results by a space ID from list_spaces.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Full-text query to search for.
`space_id`	No	Optional Docmost space ID to scope the search.

TDQS

A3.7/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, so the agent knows this is a read operation. The description repeats 'search' but adds no new behavioral context beyond that. It is adequate but not enhanced.

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 a single sentence that is front-loaded with the main action and concise, leaving no room for unnecessary words. It effectively communicates the essential 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?

Given no output schema, the description could mention the return format (e.g., list of docs). It is missing this detail but overall adequate for a simple search tool with two parameters.

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% with clear descriptions for both parameters. The description merely restates the optional filter, adding no new meaning beyond the schema. Baseline score of 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?

The description clearly states the verb 'search' and the resource 'Docmost documentation', and mentions optional filtering by space ID. This distinguishes it from sibling tools like 'search_pages', making the purpose specific and unambiguous.

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?

The description provides implicit guidance by mentioning optional space ID filtering from list_spaces, but it does not explicitly state when to use this tool versus alternatives like 'search_pages'. No exclusions or when-not-to-use advice is given.

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

search_pagesA

Read-only

Search Docmost pages and optionally filter results by a space ID from list_spaces.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Full-text query to search for.
`space_id`	No	Optional Docmost space ID to scope the search.

TDQS

A4.1/5.0

Behavior3/5

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

Annotations already provide readOnlyHint=true. Description adds optional filtering context but no other behavioral details (e.g., pagination, limits).

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?

Single sentence with no wasted words, effectively conveying purpose and optional behavior.

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?

Missing output description (e.g., result format) and search behavior details (e.g., case sensitivity, pagination). Adequate but not comprehensive.

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%, but description adds practical guidance: where to obtain space_id ('from list_spaces') and clarifies the tool's scope.

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?

Clearly states verb 'Search' and resource 'Docmost pages', with optional filter by space ID. Distinguishes from siblings like search_docs by specifying pages.

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?

Indicates when to use optional space_id filter (from list_spaces), but does not explicitly contrast with siblings or state when not to use.

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

update_commentA

Destructive

Replace an existing Docmost comment's body with new Markdown content.

ParametersJSON Schema

Name	Required	Description	Default
`markdown`	Yes	New comment body as Markdown; replaces the existing content. Tag users with `[Display Name](user:USER_UUID)` (see list_workspace_members).
`comment_id`	Yes	The comment ID (UUID) to update.

TDQS

A4/5.0

Behavior3/5

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

Annotations already indicate destructive and non-read-only behavior. Description adds no extra behavioral context (e.g., notifications, permissions). Minimal additional value.

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?

Single sentence, front-loaded with action, no unnecessary words.

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?

Sufficient for a simple update with 2 required parameters and no output schema. Could mention error cases or required permissions, but adequate.

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 provides 100% coverage with descriptions for both parameters. Description does not add new meaning beyond what schema already conveys.

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?

Description uses specific verb 'Replace' and clearly identifies resource 'existing Docmost comment's body', distinguishing it from create_comment (creation) and get_comments (reading).

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?

Implies usage for updating existing comments, but no explicit when-not or alternatives mentioned. However, context from sibling tools makes it clear.

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

update_pageA

Destructive

Update an existing Docmost page's title and/or Markdown content.

ParametersJSON Schema

Name	Required	Description
`title`	No	Optional new page title. Omit to leave the title unchanged.
`page_id`	Yes	The Docmost page ID or slug ID to update.
`markdown`	No	Optional new page body as Markdown; replaces the existing content. Omit to leave content unchanged.

TDQS

A4/5.0

Behavior3/5

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

Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds minimal extra behavioral context beyond the parameter descriptions in the schema. It does not disclose side effects, authentication needs, or rate limits, but the core safety profile is covered by 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?

The description is a single, front-loaded sentence with no wasted words. Every word contributes to the purpose, making it highly concise and well-structured.

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?

For a simple update tool with no output schema, the description covers the essential purpose and constraints. It could mention the return value (e.g., the updated page) but the tool's behavior is clear enough for an agent to understand and invoke correctly.

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%, with all three parameters clearly described in the schema. The tool description does not add new meaning beyond what is already stated in the parameter descriptions, achieving the baseline score.

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 description clearly states the verb 'update', the resource 'existing Docmost page', and the specific fields that can be updated (title and/or Markdown content). It effectively distinguishes this tool from siblings such as create_page, copy_page_to_space, and move_page.

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?

The description implies that the tool should be used only for existing pages ('update an existing...'). It provides clear context for when to use, but does not explicitly mention when not to use or compare with alternatives like create_page for new pages.

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

update_spaceA

Idempotent

Update a Docmost space's name, slug, and/or description.

ParametersJSON Schema

Name	Required	Description
`name`	No	Optional new name (2-100 characters). Omit to leave unchanged.
`slug`	No	Optional new URL slug. Omit to leave unchanged.
`space_id`	Yes	The space ID (UUID) to update.
`description`	No	Optional new description. Omit to leave unchanged.

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already provide idempotentHint=true and destructiveHint=false. Description specifies the updatable fields, adding context. No mention of authorization or error states, but overall aligns well with 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?

Single sentence, front-loaded with key information, no redundancy. Every word earns its place.

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?

Adequate for a simple update tool, but fails to mention return behavior (e.g., returns updated space) or error conditions. Given no output schema, description could be more complete.

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% with detailed descriptions per parameter. The description merely lists the fields without adding new meaning beyond the schema.

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?

Description clearly states verb 'update' and resource 'Docmost space's name, slug, and/or description.', distinguishing it from create, get, and other page/comment tools among siblings.

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?

No explicit when-to-use or when-not-to-use guidance, but the update action is self-explanatory given sibling tools like create_space and get_space. Implied usage only.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

20 tool updatesv0.1.0Jul 12, 2026
- First observedcopy_page_to_space
- First observedcreate_comment
- First observedcreate_page
- First observedcreate_space
- First observedduplicate_page
- First observedget_comments
- First observedget_current_user
- First observedget_page
- First observedget_space
- First observedlist_child_pages
- First observedlist_pages
- First observedlist_spaces
- First observedlist_workspace_members
- First observedmove_page
- First observedmove_page_to_space
- First observedsearch_docs
- First observedsearch_pages
- First observedupdate_comment
- First observedupdate_page
- First observedupdate_space

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0

Scored 2026-07-12 03:25 across 20 tools

Disambiguation3/5

Most tools have distinct purposes, but search_docs and search_pages are nearly identical, both searching and filtering by space ID, creating ambiguity for an agent. move_page and move_page_to_space are distinct but could be confused.

Naming Consistency5/5

All tools follow a consistent verb_noun (with preposition) snake_case pattern, e.g., create_page, list_spaces, get_comments, move_page_to_space. No mixing of styles.

Tool Count4/5

20 tools is slightly above the typical well-scoped range but still reasonable for a wiki server covering pages, spaces, comments, search, and user info. Each tool serves a clear purpose.

Completeness2/5

Missing essential delete operations: no delete_page, delete_comment, or delete_space. This is a significant gap for lifecycle management, causing dead ends for agents.

Maintenance

ActivitySlowing

ResponsivenessUnresponsive

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

hjarni AOAuth
com.hjarni
Markdown-based note-taking with a hosted MCP server. Your notes serve you and your AI.
Note Taking Workplace & Productivity
383
Remote Desktop CommanderOAuth
app.desktopcommander
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Shell Access OS Automation
219
Mirror Memory MCP Server
io.github.Tr1ckyMag1ca1
Personal knowledge base MCP server with semantic search, auto-categorization, metadata extraction
Knowledge & Memory Search Note Taking
2
docbaseOAuth
io.github.krayinc
DocBase MCP server for AI agents
Documentation Access Search Developer Tools
2

Related MCP Servers

Jotdown
Developer Tools Content Management Systems
Harry-027
A
license
Not graded
quality
D
maintenance
An MCP Server in Rust for creating Notion pages & mdBooks with LLMs 🦀
Updated 7 months ago (2026-02-24 02:35 UTC)
23
MIT
Outline knowledge base MCP
Knowledge & Memory Content Management Systems
nizovtsevnv
A
license
Not graded
quality
C
maintenance
MCP server for Outline knowledge base implemented on Rust as one statically linked executable file for Linux/MacOS/Windows.
Updated 7 months ago (2026-02-26 08:40 UTC)
7
MIT
MindOS
Knowledge & Memory Note Taking File Systems
GeminiLight
A
license
Not graded
quality
A
maintenance
Local-first knowledge base MCP server. Lets AI agents (Claude Code, Cursor, etc.) read and write your personal knowledge base through 20 MCP tools. Zero cloud dependency — all files stay on your machine.
Updated a day ago (2026-09-10 21:11 UTC)
1,758
667
MIT
knowledgine
Knowledge & Memory Note Taking
3062-in-zamud
A
license
Not graded
quality
D
maintenance
Local-first MCP server that extracts structured knowledge from markdown notes into SQLite with full-text search, enabling AI coding tools to retrieve relevant context offline at zero cost.
Updated 2 months ago (2026-07-24 09:06 UTC)
3
MIT