How do I use Doccler MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Doccler MCP Server search my documentation for authentication" 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.

Doccler MCP Server

by doccler-app

Overview Schema Source Related Servers Discussions Admin

JavaScript

Doccler MCP Server

🚀 Connect your IDE to Doccler - Use AI-powered documentation directly from your development environment.

npm version

What is MCP?

The Model Context Protocol (MCP) is an open standard that allows AI assistants (like Claude, Cursor, VS Code with AI extensions) to connect to external tools and data sources. Doccler's MCP server enables you to:

Query your documentation as a single source of truth
Create documentation directly from your IDE
Search documentation with semantic search
Generate documentation from code using AI
Publish/unpublish documents
Organize documents into spaces

Related MCP server: Unified Docs Hub

Quick Start

1. Get Your Doccler API Key

Log in to Doccler
Go to Settings → API Keys
Click Create New API Key
Copy the key (it's only shown once!)

2. Configure Your IDE

Choose your IDE and add the configuration:

Cursor (`~/.cursor/mcp.json`)

{
  "mcpServers": {
    "doccler": {
      "command": "npx",
      "args": ["-y", "@doccler/mcp-server@latest"],
      "env": {
        "DOCCLER_API_KEY": "doccler_xxxxxxxx_yyyyyyyyyyyyyyyyyyyy"
      }
    }
  }
}

Claude Desktop

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "doccler": {
      "command": "npx",
      "args": ["-y", "@doccler/mcp-server@latest"],
      "env": {
        "DOCCLER_API_KEY": "doccler_xxxxxxxx_yyyyyyyyyyyyyyyyyyyy"
      }
    }
  }
}

VS Code / Antigravity

Add to your MCP settings:

{
  "mcp": {
    "servers": {
      "doccler": {
        "command": "npx",
        "args": ["-y", "@doccler/mcp-server@latest"],
        "env": {
          "DOCCLER_API_KEY": "doccler_xxxxxxxx_yyyyyyyyyyyyyyyyyyyy"
        }
      }
    }
  }
}

3. Restart Your IDE

After adding the configuration, restart your IDE. The Doccler MCP server will be downloaded and started automatically.

Alternative: Global Installation

If you prefer to install globally instead of using npx:

npm install -g @doccler/mcp-server

Then configure your IDE with:

{
  "mcpServers": {
    "doccler": {
      "command": "doccler-mcp",
      "env": {
        "DOCCLER_API_KEY": "doccler_xxxxxxxx_yyyyyyyyyyyyyyyyyyyy"
      }
    }
  }
}

Available Tools

Tool	Description
`hello_doccler`	Verify your connection to Doccler
`search_docs`	Search your documentation (keyword + semantic)
`create_doc`	Create new documentation with optional space
`generate_doc`	Generate documentation from code using AI
`publish_doc`	Publish or unpublish a document
`get_doc`	Get the content of a specific document
`list_spaces`	List all available spaces

Usage Examples

Search Documentation

"Search my documentation for authentication"
"Find docs about API endpoints"

Create Documentation

"Create documentation titled 'Getting Started' about how to install the app"
"Create a doc in the API space explaining the user endpoint"

Generate from Code

"Generate documentation for this code: [paste your code]"
"Document this function with examples"

Publish/Unpublish

"Publish the document with slug 'getting-started'"
"Unpublish my-api-guide"

Environment Variables

Variable	Description	Default
`DOCCLER_API_KEY`	Your Doccler API key	(required)
`DOCCLER_API_URL`	API URL (for self-hosted)	`https://doccler.app/api`

Note: DOCCLER_API_URL is only needed for self-hosted instances or development. Production users can omit it.

Troubleshooting

"API Key not configured"

Make sure DOCCLER_API_KEY is set in your IDE's MCP configuration.

"Unauthorized" errors

Check that your API key is valid
Go to Settings → API Keys in Doccler to verify
Create a new key if needed

Server not starting

Ensure Node.js 18+ is installed
Try running manually: npx @doccler/mcp-server
Check your IDE's MCP logs

Support

Documentation: doccler.app/en/docs
Email: help@doccler.app

License

MIT © Doccler

Available Tools

7 tools

create_docB

Create new documentation in Doccler. Use list_spaces first to see available spaces.

ParametersJSON Schema

Name	Required	Description
`space`	No	Space/category to organize the doc (e.g., "API", "Guides", "Setup"). Leave empty for uncategorized.
`title`	Yes	Title of the documentation
`content`	Yes	Content in Markdown format
`published`	No	Whether to publish immediately

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description bears full responsibility. It describes a mutation (create) but does not disclose any behavioral details such as idempotency, side effects, authorization requirements, or what happens if the document already exists. The lack of such information limits transparency.

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 extremely concise with only two sentences, front-loading the purpose and immediately providing a useful prerequisite. Every sentence earns its place with no wasted words.

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 and 4 parameters, the description covers basic functionality and a prerequisite. However, it lacks details about return values, error handling, or required permissions, which would be helpful for an agent to invoke the tool 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?

Input schema covers all 4 parameters with descriptions (100% coverage). The description adds context for the 'space' parameter by recommending list_spaces, but does not significantly enhance understanding of other parameters. Baseline 3 is appropriate as schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/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 resource (documentation in Doccler). It also mentions a prerequisite, making the purpose clear. However, it does not explicitly differentiate from sibling tools like generate_doc or publish_doc.

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 one usage guideline: use list_spaces first. This is a precondition, but there is no guidance on when to use this tool versus alternatives like publish_doc or generate_doc. The usage is implied but not elaborated.

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

generate_docB

Analyze code and generate documentation using AI

ParametersJSON Schema

Name	Required	Description	Default
`code`	Yes	The code to analyze and document
`style`	No	Documentation style	technical
`language`	No	Programming language of the code

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It only says 'analyze code and generate documentation', but does not disclose whether this is a read-only operation, if it stores the result, or any side effects. Lacks details on input limits or required permissions.

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 fluff. Front-loaded with key action. Every word earns its place.

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, and description doesn't state what the generated documentation looks like (e.g., returns string, creates file). With siblings like 'create_doc' and 'publish_doc', it's unclear if this tool persists or only generates. Incomplete for a 3-parameter tool.

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 descriptions for all three parameters. The description adds no extra information beyond what the schema already provides, so baseline 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 states 'Analyze code and generate documentation using AI', which specifies the verb (generate) and resource (documentation from code). This distinguishes it from siblings like 'create_doc' (create from scratch) and 'search_docs' (search existing).

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 siblings such as 'create_doc' or 'publish_doc'. The description only explains what it does, not the context or prerequisites.

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

get_docB

Get the content of a specific Doccler document

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes	The slug (URL identifier) of the document

TDQS

B3.3/5.0

Behavior2/5

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

Without annotations, the description must disclose behavioral traits. It only says 'get the content', but does not specify what content includes (full text, metadata, formatting) or any side effects. The tool is likely idempotent but this is unstated.

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 with no extraneous information. It is front-loaded and efficient, earning 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?

Given the simplicity (1 parameter, no output schema, no annotations), the description is minimally adequate but lacks details on return format or content structure. It could be more complete by mentioning what 'content' encompasses.

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 covers 100% of parameters (slug) with a description. The tool description does not add additional meaning beyond the schema. Baseline score of 3 is appropriate as no extra value is provided.

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 it retrieves the content of a specific document using the verb 'Get' and resource 'Doccler document'. It distinguishes from sibling tools like search_docs (searching) and create_doc (creation).

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 search_docs for finding documents or hello_doccler for greetings. No context on prerequisites or preferred use cases.

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

hello_docclerA

Say hello to Doccler and verify the connection is working

ParametersJSON Schema

Name	Required	Description	Default
`name`	No	Optional name to personalize the greeting

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It indicates a read-only health check, but lacks details on auth, rate limits, or side effects; adequate for a simple tool.

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?

A single sentence, zero waste; perfectly concise for the tool's complexity.

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 low complexity (one optional param, no output schema), the description is sufficient. It explains purpose and connection verification, though return value is not specified but expected to be simple.

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 input schema covers the single optional parameter with a description. The tool description adds the context of personalization ('personalize the greeting'), but does not add significant 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?

The description clearly states the action ('Say hello to Doccler') and the goal ('verify the connection is working'), distinguishing it from sibling tools that focus on document operations.

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 use for connectivity testing, but does not explicitly state when to use it vs. alternatives or any exclusions, though the context 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_spacesA

List all available spaces (document categories) in Doccler

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.9/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It implies a read-only operation but doesn't explicitly disclose side effects, authentication needs, or limitations. Adequate for a simple list tool.

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

Conciseness5/5

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

Single sentence, front-loaded with verb and resource. No wasted words.

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?

Given the tool's simplicity (no parameters, no output schema), the description fully captures its purpose and scope. No gaps.

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?

With zero parameters and full schema coverage (100%), the description correctly indicates the scope ('all available spaces'). No additional parameter detail needed.

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 'spaces', and the context 'Doccler'. It is distinct from sibling tools like 'create_doc' or 'search_docs'.

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 provided on when to use this tool versus alternatives. The description only states what it does, not when to choose it over other tools.

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

publish_docB

Publish or unpublish a Doccler document

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes	The slug (URL identifier) of the document
`publish`	Yes	true to publish, false to unpublish

TDQS

B3.3/5.0

Behavior2/5

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

No annotations exist, so description must carry full burden. Only states that it publishes or unpublishes; no mention of side effects, permissions, or state changes.

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?

Extremely concise (6 words, one sentence). No wasted words; front-loaded with the key action and resource.

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 tool with 2 parameters and no output schema, but lacks details on error handling, return values, or permissions.

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. Description adds no extra meaning beyond the schema; does not elaborate on parameter behavior or usage hints.

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 (publish/unpublish) and the resource (Doccler document), providing a specific verb+resource pair. It distinguishes itself from sibling tools like search_docs or create_doc.

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. Does not specify prerequisites or scenarios where other tools might be more appropriate.

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

search_docsB

Search your Doccler documentation by keyword or semantic query

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum number of results to return
`query`	Yes	Search query to find relevant documentation

TDQS

B3.4/5.0

Behavior2/5

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

No annotations provided, and the description lacks key behaviors such as whether it is read-only, what it returns, pagination, or authentication requirements. Minimal transparency for a search operation.

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 verb and resource, 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.

Completeness2/5

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

Despite simple structure, the description fails to specify result format, search scope (titles vs. content), or how to refine queries, leaving critical gaps for effective use.

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 having descriptions. The tool description adds no additional meaning beyond the schema, meeting 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 tool searches Doccler documentation using keyword or semantic query, distinguishing it from sibling tools like create_doc, get_doc, etc.

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 finding relevant docs but does not explicitly state when to use search vs. alternatives like get_doc or list_spaces, leaving the decision to the agent.

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.

7 tool updatesv1.0.5Jul 28, 2026
- First observedcreate_doc
- First observedgenerate_doc
- First observedget_doc
- First observedhello_doccler
- First observedlist_spaces
- First observedpublish_doc
- First observedsearch_docs

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.8/5.0

Scored 2026-07-28 11:55 across 7 tools

Disambiguation5/5

All tools have clear, distinct purposes. The health check, search, CRUD for docs, spaces listing, and publishing are each unique and non-overlapping.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern (e.g., search_docs, create_doc, list_spaces), making them predictable and easy to navigate.

Tool Count5/5

With 7 tools covering health check, search, CRUD, AI generation, and space management, the count is well-scoped for a documentation server without being excessive or sparse.

Completeness4/5

The tool set covers most core documentation operations but is missing explicit update and delete tools, which are minor but notable gaps that an agent would need to work around.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

llmref A
org.llmref
Versioned documentation registry and semantic search for AI tools and coding assistants.
Documentation Access Search Developer Tools
42
docfork-mcpOAuth
ai.smithery
@latest documentation and code examples to 9000+ libraries for LLMs and AI code editors in a singl…
Documentation Access Developer Tools Code Analysis
2488
docuwriter AOAuth
ai.docuwriter
Generate, search, and manage codebase documentation on DocuWriter.ai. 72 tools incl. Autopilot.
AI & Machine Learning Developer Tools Documentation Access
723
ref-tools-ref-tools-mcpOAuth
ai.smithery
Provide your AI coding tools with token-efficient access to up-to-date technical documentation for…
Documentation Access Developer Tools Code Analysis
21,173

Related MCP Servers

RAG Documentation MCP Server
RAG Systems Documentation Access Vector Databases
rahulretnan
A
license
Not graded
quality
F
maintenance
Enables AI assistants to enhance their responses with relevant documentation through a semantic vector search, offering tools for managing and processing documentation efficiently.
Updated a year ago (2025-06-26 01:40 UTC)
6 npm
64
MIT
Unified Docs Hub
Documentation Access Search Developer Tools
boodrow
A
license
Not graded
quality
D
maintenance
Provides AI assistants with searchable access to documentation from 170+ curated repositories and 1000+ popular GitHub projects across 20+ categories including trading, AI/ML, DevOps, and web development.
Updated a year ago (2025-06-19 12:46 UTC)
3
MIT
Docmost MCP Server
Content Management Systems Note Taking Documentation Access
MrMartiniMo
A
license
Not graded
quality
D
maintenance
Enables AI agents to search, create, modify, and organize documentation pages and spaces in Docmost.
Updated 8 months ago (2026-02-01 03:24 UTC)
8 npm
30
MIT
SourceTap
RAG Systems Web Scraping Documentation Access
maxvoltage
F
license
B
quality
D
maintenance
Enables AI assistants to query and search library documentation from GitHub repositories or web pages using RAG and web scraping.
Updated 8 months ago (2026-01-16 22:06 UTC)
2
-

Doccler MCP Server

What is MCP?

Quick Start

1. Get Your Doccler API Key

2. Configure Your IDE

Cursor (~/.cursor/mcp.json)

Claude Desktop

VS Code / Antigravity

3. Restart Your IDE

Alternative: Global Installation

Available Tools

Usage Examples

Search Documentation

Create Documentation

Generate from Code

Publish/Unpublish

Environment Variables

Troubleshooting

"API Key not configured"

"Unauthorized" errors

Server not starting

Support

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Cursor (`~/.cursor/mcp.json`)