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., "@mcp-wiki-server search the docs for how to set up 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.
A minimal, agent-agnostic MCP server that exposes search over local markdown documentation. Any MCP-compatible client (Claude Code, Claude Desktop, or a custom agent built on any model) can connect to it — the server has no knowledge of which agent or LLM is calling it.
search_docs(query, limit?) — keyword search across docs/*.md, returns matching files with a snippet.
read_doc(path) — read the full contents of a doc by its relative path.
Related MCP server: docubridge
npm install
npm run buildnpm run inspectThis launches the MCP Inspector, a web UI for calling your tools directly without needing a full LLM client.
claude mcp add wiki-search -- node /absolute/path/to/mcp-wiki-server/dist/index.jsAdd to claude_desktop_config.json:
{
"mcpServers": {
"wiki-search": {
"command": "node",
"args": ["/absolute/path/to/mcp-wiki-server/dist/index.js"]
}
}
}Any other MCP client follows the same pattern: point it at node dist/index.js as a subprocess command.
Drop .md files into docs/ (subfolders supported). No re-deploy needed — search_docs reads from disk on every call.
Swap StdioServerTransport for the Streamable HTTP transport in src/index.ts.
Point docs/ at a real source (Confluence/Notion/Drive) instead of local files.
Containerize and deploy to Cloud Run.
Add auth (OAuth2/OIDC or Cloud Run IAM) in front of the HTTP endpoint.
Read the full contents of a specific markdown doc by its relative path (as returned by search_docs).
Inputs: path (required).
Search internal markdown documentation for a keyword or phrase. Returns matching files with a short snippet of surrounding context.
Inputs: query (required), limit.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Scored across 2 tools
The two tools serve clearly distinct purposes: search_docs finds documents by keyword, while read_doc retrieves the full content of a known document by path. There is no overlap or ambiguity between them.
Both tools use a verb_noun pattern (search_docs, read_doc), making the pattern predictable. There is a minor inconsistency in pluralization—search_docs is plural while read_doc is singular—but it does not cause confusion.
With only two tools, the server feels minimally scoped. This is appropriate for a simple read-only wiki, but it is on the thin side and offers no additional utility beyond search and read.
For a read-only documentation server, the search-and-read lifecycle is complete. The only notable gap is the lack of a way to list or browse all documents without a search query, which could be a minor workaround in some cases.
Read-only MCP server for the OrchestKit docs: full-text search + Markdown fetch. No auth.
Read-only search and Markdown pages from the OpenPlanr docs, for coding agents.
Political Comms documentation MCP server: search docs, query the docs filesystem. No auth.
Team docs served to AI agents over MCP - search, Markdown reads, version pinning, read audit.
