Connect an AI assistant (MCP)

Every public Dewstack docs site serves an MCP endpoint at /mcp. Point Claude, ChatGPT or Cursor at it and the assistant can search and read your documentation directly, instead of guessing from whatever it saw during training.

MCP – the Model Context Protocol – is the standard way an AI assistant connects to an outside source of information. Dewstack implements the server half; the assistant is the client.

https://docs.acme.com/mcp

Use your custom domain if you have one, otherwise your *.dewstack.com subdomain. The exact URL for each workspace is on the API & Agents page, under Endpoints, with a copy button.

Connect Claude

Claude will list four tools once connected. Ask it something your docs answer and it will call them rather than improvising.

Connect ChatGPT

In ChatGPT, go to Settings → Connectors → Add custom connector – or add it to a custom GPT – paste the same URL, and choose No authentication.

ChatGPT's connector and Deep Research features expect a server to expose tools named exactly search and fetch. Dewstack does, so it works without any adapter.

Connect Cursor

Add the server to .cursor/mcp.json in your project:

{
  "mcpServers": {
    "acme-docs": {
      "url": "https://docs.acme.com/mcp"
    }
  }
}

The API & Agents page renders this snippet for you with the server name and URL already filled in – copy it straight out.

What the assistant can do

All four are read-only and cover published pages only – drafts stay private. Reading through MCP does not consume SmartDocs message credits, so an assistant can browse your whole corpus at no cost.

Five more tools exist behind write access on the /mcp-rw endpoint: create_collection, create_article and update_article (which operate on drafts only – an agent can never publish, unpublish, or edit a live page), plus list_content_gaps and list_stale_pages, which let the agent read the same content-gap signals your dashboard shows. How to grant them is covered in Let an agent write drafts.

Technical details

If you are wiring up a client by hand rather than using one of the three above:

• Transport is streamable HTTP. POST your JSON-RPC 2.0 request, get one JSON response back. There is no SSE – a client configured for sse transport will not connect. A GET to /mcp returns 405 with a JSON hint, which is correct for a server that never initiates a stream.
• /mcp needs no authentication. The workspace is identified by the hostname you connect to. The write endpoint /mcp-rw is different: unauthenticated requests get a 401 with a WWW-Authenticate challenge, and OAuth discovery documents are served at /.well-known/oauth-protected-resource and /.well-known/oauth-authorization-server for clients that connect that way.
• Supported methods: initialize, ping, tools/list, tools/call. There are no MCP resources or prompts.
• Batched requests are rejected. Send one request per POST. Clients that batch initialize with notifications/initialized will fail on connect.
• Protocol versions 2024-11-05, 2025-03-26 and 2025-06-18 are echoed back; anything else negotiates down to 2025-03-26.
• Tool failures come back as tool results carrying an error, not as JSON-RPC protocol errors, so the assistant can read and recover from them.

Limits and plan requirements

• Up to 500 published pages are exposed.
• search is a plain substring match with no relevance ranking. An empty query returns everything.
• The API & Agents page – where the URLs and the Cursor snippet live – is hidden if you have no subscription and no active trial, and for members without the Manage SmartDocs permission. The /mcp endpoint itself stays available on any public workspace.

Related