Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@docmost-mcp search the wiki for the onboarding checklist"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server for self-hosted Docmost. Read, search, create and update wiki pages in Markdown from Claude Code, Claude Desktop, Cursor or any other MCP client.
Docmost's official MCP server and API keys are part of its paid Enterprise edition. This server needs neither. It logs in with a normal Docmost account and calls the same API the Docmost web app uses. Since Docmost v0.70 that API accepts and returns Markdown, and the server converts it to and from its editor format.
Tool | What it does |
| Lists the spaces the account can see, with their ids |
| Lists the root pages of a space, or the children of a page |
| Full-text search, optionally within one space |
| Returns a page as Markdown, with its id, space, parent and URL |
| Creates a page from Markdown, at a space root or under a parent page |
| Replaces, appends to or prepends to a page body; can rename it or change its icon |
Every tool that takes a page accepts a page id, a slug id, or the page URL copied from the browser.
Content updates go through Docmost's real-time collaboration layer, so if someone has the page open while it is updated, their editor picks up the change instead of overwriting it.
Related MCP server: Docmost Community Bridge
Node.js 20.12 or newer
Docmost v0.70 or newer
A Docmost account without MFA. Edits are attributed to this account in page history, so each person should use their own.
There is nothing to clone. Register the server with your MCP client and pass your Docmost login as environment variables. npx downloads and runs it.
claude mcp add docmost --scope user \
-e DOCMOST_URL=https://docs.example.com \
-e DOCMOST_EMAIL=you@example.com \
-e DOCMOST_PASSWORD='your-password' \
-- npx -y @punyamsingh/docmost-mcpAdd the following to the client's MCP config (claude_desktop_config.json, ~/.cursor/mcp.json, …):
{
"mcpServers": {
"docmost": {
"command": "npx",
"args": ["-y", "@punyamsingh/docmost-mcp"],
"env": {
"DOCMOST_URL": "https://docs.example.com",
"DOCMOST_EMAIL": "you@example.com",
"DOCMOST_PASSWORD": "your-password"
}
}
}
}To run the latest code on GitHub instead of the npm release, replace @punyamsingh/docmost-mcp with github:punyamsingh/docmost-mcp. The first start is slower because it builds from source.
The client stores these values in its own config file in plain text, the same as a .env file would, so use a config file only you can read.
After the first login the session token is cached in ~/.cache/docmost-mcp/ (or $XDG_CACHE_HOME/docmost-mcp/), with file mode 600. Restarting the client therefore does not open a new Docmost session each time. A new login happens automatically when the token expires or is revoked.
git clone https://github.com/punyamsingh/docmost-mcp.git
cd docmost-mcp
npm install # also builds into build/
cp .env.example .env # then fill in DOCMOST_URL, DOCMOST_EMAIL, DOCMOST_PASSWORD
claude mcp add docmost --scope user -- node "$PWD/build/index.js".env is git-ignored. Variables set in the client's config take precedence over it.
Uploading local image files is not supported yet; reference images that are already hosted somewhere by URL.
No tools for deleting or moving pages, comments, or permissions.
Accounts with MFA cannot log in, because the server has no way to complete the second factor.
MIT
Creates a page from Markdown at the root of a space or under a parent page, and returns its URL.
| Name | Required | Description | Default |
|---|---|---|---|
| icon | No | Optional emoji shown next to the title. | |
| title | Yes | Page title. | |
| spaceId | No | Space id from list_spaces; optional when parentPageId is given. | |
| markdown | Yes | Page body in Markdown; do not repeat the title as a leading # heading. | |
| parentPageId | No | Create the page under this page instead of at the space root. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full behavioral burden. It discloses that the operation returns the new page's URL, which is genuinely useful with no output schema, but it omits permission requirements, error/failure behavior, and any title-collision constraints for a mutation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with zero filler; the action, the two source locations, and the return value are all packed into one clause chain with no redundant restatement of the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter create tool with no annotations and no output schema, the description covers the essential invocation facts and uniquely supplies the return value. It would be complete with a hint about required permissions or the spaceId/parentPageId dependency, but nothing critical for calling it is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents icon, title, spaceId, markdown and parentPageId with placement semantics. The description only echoes 'from Markdown' and adds no syntax, format, or size guidance beyond the schema, which is the baseline 3 case.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Creates a page from Markdown') and specifies the two placement modes (space root or under a parent page). The create verb inherently separates it from update_page/get_page/list_pages, though it never names a sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 siblings like update_page, and no prerequisites (e.g. needing a valid spaceId from list_spaces) are stated. Placement context is only implicit, and the agent is left to infer conditions entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a page as Markdown along with its id, space, parent and URL.
| Name | Required | Description | Default |
|---|---|---|---|
| pageId | Yes | Page id, slug id, or the full page URL copied from the browser. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses the return payload (Markdown plus id, space, parent, URL), which matters since there is no output schema, but it stays silent on permissions, behavior when the page is missing, and any 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence with the return content front-loaded and no filler. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool with a fully documented schema, the description covers what is returned even though no output schema exists. It omits only edge-case behavior, which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already explains that pageId accepts an id, slug id, or full URL. The description adds nothing about the parameter, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (returns/reads) and resource (a page) plus the return format (Markdown). The singular 'a page' implicitly distinguishes it from list_pages and search_pages, but it never names an alternative explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance and no alternatives named. It doesn't say to use this instead of search_pages when the id is already known, nor describe any prerequisites or failure conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the top-level pages of a space, or the direct children of a page when parentPageId is given.
| Name | Required | Description | Default |
|---|---|---|---|
| spaceId | No | Space id from list_spaces; lists the root pages of that space. | |
| parentPageId | No | Lists the direct children of this page instead. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the parentPageId branching, but that behavior is already documented in the schema, and the description says nothing about read-only safety, ordering, or pagination limits for a list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no waste. It could be marginally tighter but is efficient and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity list tool with full schema coverage, the description is adequate but omits pagination/ordering behavior and read-only confirmation, which matter for a listing endpoint with no annotations or output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already well documented. The description only restates the parentPageId behavior already present in the schema, adding no new semantic detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Lists') and resource ('pages') and clarifies the two modes of operation (top-level space pages vs. direct children). It does not explicitly distinguish itself from siblings like search_pages or get_page, so it falls just short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage via the parentPageId conditional, but gives no explicit guidance on when to prefer this over search_pages or get_page, nor any prerequisites. Usage must be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the Docmost spaces this account can see, with the space ids the other tools take.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the permission-based scope ('this account can see') and implicitly a read-only list operation, but says nothing about pagination, result ordering, or size, which matters for a listing endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence with the resource and its practical payoff front-loaded. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with no output schema, the description covers what is returned at a high level (spaces and their ids) but omits pagination and whether the list is filtered. Adequate, with a small remaining gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. It correctly adds no fabricated parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Lists the Docmost spaces') plus a scope qualifier ('this account can see') and what the result carries (space ids). It is clearly distinguishable from the page-oriented siblings, though it doesn't explicitly name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'the space ids the other tools take' implies this should be called first to obtain identifiers other tools require, but it never states that directly or names which tools or when-not to use it. Usage is implied rather than prescribed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text searches page titles and bodies, optionally within one space.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results to return; defaults to 20. | |
| query | Yes | Words to search for. | |
| spaceId | No | Restrict the search to this space id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does not state that this is a read-only operation, how results are ordered or ranked, whether snippets/highlights are returned, or how the 100-result cap interacts with the default of 20. It does disclose the search scope (titles and bodies), which is the only behavioral substance present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; the scope (titles and bodies) precedes the optional constraint, so the most important information arrives first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no annotations and no output schema, the description is minimally viable: the core scope and the three parameters are covered. However, it omits read-only confirmation, result shape, and ordering behavior that an agent would want before invoking a search.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains query, limit, and spaceId fully. The description only echoes the spaceId constraint ('within one space') and adds no syntax, matching, or ranking semantics beyond what the schema provides — the baseline 3 for full coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb ('full-text searches') and an explicit scope ('page titles and bodies'), which clearly separates it from list_pages and get_page by behavior. It stops short of naming those siblings as alternatives, so it lands at 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Optionally within one space' hints at the spaceId scoping case but gives no guidance on when to search versus listing or fetching pages directly. No exclusions, prerequisites, or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Replaces, appends to or prepends to a page body in Markdown, and can rename it or change its icon.
| Name | Required | Description | Default |
|---|---|---|---|
| icon | No | New emoji icon. | |
| title | No | New page title. | |
| pageId | Yes | Page id, slug id, or the full page URL copied from the browser. | |
| markdown | No | New Markdown content; omit to change only the title or icon. | |
| operation | No | How markdown is applied to the existing body; defaults to replace. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does communicate that the body can be overwritten (a destructive behavior) and that title/icon are optional modifications, but it says nothing about permissions, reversibility, versioning of overwritten content, or failure modes. The operation semantics it implies largely duplicate the schema enum.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence that front-loads the primary action (body modification) and tacks on secondary capabilities. Efficient, with only mild redundancy against the schema's operation enumeration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter mutation tool with no annotations and no output schema, the description covers the main capabilities adequately but omits auth/permission requirements, confirmation of what is returned, and any warning about losing existing content on replace. It is minimally sufficient rather than complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so every parameter is already documented in the schema, including pageId accepting slug/URL, the operation enum, and the ability to omit markdown. The description adds no format or constraint detail beyond that baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb set (replaces, appends, prepends) and resource (page body), plus ancillary actions (rename, change icon). It is clearly an update tool and distinct from create_page/get_page by its mutating framing, though it never names a sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says what can be changed but never states when to use this tool versus create_page or get_page, nor any prerequisites such as needing an existing pageId. Usage is only implied by the word 'update'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0create_pageget_pagelist_pageslist_spacessearch_pagesupdate_pageScored across 6 tools
Each tool targets a distinct operation: browsing spaces, browsing page hierarchy, full-text search, single-page fetch, page creation, and page editing. list_pages (hierarchical browsing) and search_pages (full-text lookup) have clearly separate intents, and get_page vs list_pages vs search_pages are easy to tell apart by their outputs.
All six tools follow a clean verb_noun snake_case pattern (list_spaces, list_pages, search_pages, get_page, create_page, update_page). Verbs are used consistently for their action type and no naming style is mixed.
Six tools is well-scoped for a wiki/docs service, covering the natural read/browse/search/create/edit verbs without redundancy. Each tool clearly earns its place in the set.
Create, read (get/list/search), and update are all covered with Markdown fidelity, which handles the core lifecycle. However, there is no delete or archive operation and no explicit page-move/reparent tool, leaving a minor lifecycle gap agents cannot work around.
Shared project wiki for AI agents: read and write pages, next actions, and activity logs over MCP.
Hosted markdown project wikis your team's AI assistants read, search, and update over MCP.
Read and write your team's shared, AI-readable wiki from any MCP client.
Read-only MCP for the Eco game wiki: search, Markdown pages, and wiki_* lookups. No keys, no writes.
