This server provides read access to the Frappe framework documentation via MCP, enabling AI clients to search and fetch pages as clean markdown.
Search: Use search_frappe_docs with a query (and optional limit 1–50, default 10). Every token must match in the title or path, so adding terms narrows results. Returns matching page titles and paths.
Fetch: Use get_frappe_doc with a path (e.g., en/tutorial). The server extracts only the article body from the HTML, converts it to markdown, stripping navigation, reducing size drastically (e.g., from ~960 KB to a few KB). Truncates if content exceeds FRAPPE_DOCS_MAX_BYTES.
Caching: In-memory caching of pages and catalogue for a configurable duration (FRAPPE_DOCS_CACHE_TTL_MS). Concurrent requests for the same page share one fetch.
Integration: Compatible with any stdio-capable MCP client (VS Code, Claude Desktop, etc.).
Provides tools for searching and fetching documentation pages from the Frappe framework documentation.
Click on "Install 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., "@Frappe Docs MCP Server search Frappe docs for creating a doctype"
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.
A Model Context Protocol server that gives an MCP client read access to the Frappe framework documentation.
It speaks MCP over stdio using the official
@modelcontextprotocol/sdk,
so any stdio-capable client (VS Code, Claude Desktop, Claude Code) can run it.
search_frappe_docsFinds documentation pages by keyword. Start here when you do not already know a page's exact path.
Parameter | Type | Description |
| string | Keywords, e.g. |
| number | Optional, 1-50, default 10 |
Every docs page embeds the full navigation tree, so one fetch yields a catalogue of all ~215 pages. Every query token must match somewhere in a result's title or path, so adding a word narrows the results rather than widening them.
1 page matched "create doctype":
- **Create a DocType** — `en/tutorial/create-a-doctype`get_frappe_docFetches a documentation page and returns its readable content as markdown.
Parameter | Type | Description |
| string | Path relative to the docs root, e.g. |
Paths always resolve under https://docs.frappe.io/framework/user. A leading
framework/user is stripped if you include it, .. segments are rejected rather
than resolved, and each segment is percent-encoded, so a path cannot escape that
prefix or smuggle in a query string.
A raw docs page is roughly 960 KB of HTML, most of it navigation. Only the article body is kept and converted to markdown, which brings a typical page down to a few KB.
Related MCP server: CHECK-MODULE MCP Server
Both settings are optional. A malformed value is reported on stderr and the default is used, so a typo degrades rather than killing the server.
Variable | Default | Meaning |
|
| Ceiling on one response, in UTF-8 bytes. |
|
| How long fetched pages and the catalogue stay fresh (15 minutes). |
Pages and the catalogue are cached in memory, so repeated lookups within a session do not re-fetch. Concurrent requests for the same page share a single fetch.
Node.js 20 or newer. There is no node-fetch dependency; the server uses the
global fetch built into Node 20.
git clone https://github.com/muthanii/frappe_docs_mcp.git
cd frappe_docs_mcp
npm install
npm run build
npm testThe server reads JSON-RPC from stdin and writes it to stdout, so it must be
launched directly rather than through npm run start (npm prints its own banner
to stdout, which corrupts the protocol stream).
VS Code — .vscode/mcp.json is already set up:
{
"servers": {
"frappe-docs-mcp": {
"type": "stdio",
"command": "node",
"args": ["${workspaceFolder}/dist/server.js"]
}
}
}Claude Desktop / Claude Code — point at the built entry point:
{
"mcpServers": {
"frappe-docs-mcp": {
"command": "node",
"args": ["/absolute/path/to/frappe_docs_mcp/dist/server.js"]
}
}
}Run npm run build after any source change so dist/ stays current.
docker compose run --rm -T frappe-docs-mcpThe image publishes no port. This is a stdio server, not an HTTP service, so it must be run attached with a client owning stdin and stdout.
File | Role |
| URL construction and path sanitising |
| Navigation-tree parsing and keyword search |
| Article extraction, markdown conversion, truncation |
| TTL cache with request coalescing |
| Tool registration and the stdio transport |
|
|
Logic is kept out of server.ts so it can be tested without spawning a process.
npm run build uses tsconfig.build.json, which excludes *.test.ts so tests
do not ship in the image. npm test compiles everything, including the tests.
package-lock.json is committed and the Docker build uses npm ci, so image
builds are reproducible.
Diagnostics must go to stderr. Anything written to stdout is interpreted as a protocol frame; CI asserts that the server writes nothing to stdout before a client speaks.
MIT
Fetch a page from the Frappe framework user documentation at https://docs.frappe.io/framework/user and return its readable content as markdown. Paths are relative to that prefix and start with a language segment, e.g. "en/tutorial" or "en/basics/doctypes". Use search_frappe_docs to discover paths.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Documentation path relative to the docs root, e.g. "en/tutorial" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool fetches a page, returns readable content as markdown, and explains the URL structure. It does not specify error handling or side effects, but for a simple retrieval tool the key behavioral expectations are covered.
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?
The description is two sentences with no wasted words. It front-loads the main purpose and output format, then gives essential path details and a pointer to the sibling tool. Every sentence adds value.
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 tool with no output schema, the description is complete: it states the return format (markdown), defines the path structure, provides examples, and names the sibling tool for discovery. No critical information is missing for correct invocation.
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 input schema already documents the single parameter well (100% coverage). The description adds meaningful context beyond the schema by explaining the URL prefix, language segment requirement, and giving examples, which helps the agent construct valid paths.
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 uses a specific verb 'Fetch' and clearly identifies the resource: pages from the Frappe framework user documentation at a defined URL prefix. It differentiates from the sibling search_frappe_docs by stating that this tool fetches a direct page rather than discovering paths.
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 explicitly instructs to use search_frappe_docs for discovering paths, establishing a clear when-to-use vs alternative scenario. It also clarifies that paths must be relative to the prefix and start with a language segment, providing concrete usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find Frappe framework documentation pages by keyword. Returns page titles with the paths to pass to get_frappe_doc. Use this first when you do not already know the exact path of the page you want.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results to return (default 10) | |
| query | Yes | Keywords to search for, e.g. "create doctype" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It adds useful behavioral context by explaining the return shape (page titles and paths) and the integration with get_frappe_doc. However, it doesn't explicitly state read-only behavior, describe failure modes, or address edge cases like empty results, so it's adequately but not richly transparent.
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?
Two tight sentences, each serving a purpose: first states the core action, second explains the output and usage priority. No redundant content, perfectly front-loaded.
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 simple two-parameter search tool with sibling tool and no output schema, the description covers the essential context: what it does, what it returns, and how it fits into the workflow. It lacks only minor details like explicit read-only confirmation or error handling, which are arguably not necessary for a well-scoped search tool.
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% (both `query` and `limit` are well-described), so the baseline is 3. The description adds no additional parameter-level semantics beyond the schema, but it does contextually relate the output to the `query` parameter. That doesn't push it above 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?
The description clearly states it 'Find Frappe framework documentation pages by keyword', specifying the verb and resource. It also differentiates itself from the sibling get_frappe_doc by noting it returns paths to pass to that tool, establishing its role as the search entry point.
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?
Explicitly instructs 'Use this first when you do not already know the exact path of the page you want,' giving a clear when-to-use directive and implying the alternative (get_frappe_doc) when the path is known.
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. Dates show when Glama detected each change.
v0.2.0get_frappe_docsearch_frappe_docsThe two tools have clearly distinct purposes: one discovers documentation paths via keyword search, the other retrieves content by path. There is no overlap or ambiguity between them.
Both tool names follow a consistent verb_noun pattern: search_frappe_docs and get_frappe_doc. The naming is predictable and matches the actions they perform.
With only two tools, the set feels slightly thin but is appropriate for a documentation-focused server. The search-then-fetch workflow is minimal yet coherent, and adding more tools might be unnecessary.
For the stated purpose of accessing Frappe documentation, the pair covers the full lifecycle: discovery (search) and retrieval (get). No write operations are relevant, and there are no obvious gaps in the read-only documentation use case.
Query any docs site via MCP. Submit a URL, ask questions, get cited answers.
MCP server for querying Forkast documentation
Team docs served to AI agents over MCP - search, Markdown reads, version pinning, read audit.
Read-only MCP server for the OrchestKit docs: full-text search + Markdown fetch. No auth.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/muthanii/frappe_docs_mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
