MCP server

Connect an AI agent to your documentation over the Model Context Protocol.

Every Versidify site is an MCP server. An agent that connects to it can search your documentation, read a page in full, and list what exists, using the same retrieval the site's own search uses.

Nothing needs provisioning. The server is already running; it needs an API key to know which documentation you mean.

Connect

Create an API key under API keys in your organisation, then point your client at the endpoint.

{
  "mcpServers": {
    "versidify": {
      "url": "https://versidify.com/api/mcp",
      "headers": { "Authorization": "Bearer YOUR_API_KEY" }
    }
  }
}

The endpoint is the same for every customer. It does not vary by site or by custom domain, because the key alone decides which documentation is returned: the server never looks at the hostname the request arrived on.

The key is shown once, when it is created. Only a hash is stored, so a lost key is replaced rather than recovered.

What the agent can do

Tool	Arguments	Returns
`search_docs`	`query`, optional `limit`	The most relevant sections, each with a URL that links to the exact heading
`read_page`	`path`	One page in full. An empty path reads the site root
`list_pages`	optional `limit`, `offset`	Every page, with titles and URLs

Results are chunked per heading rather than per page, so a citation points at the section that answered rather than at the top of a long document.

Which site the key reads

A key scoped to one site reads that site.

A key scoped to the whole organisation reads its documentation while the organisation has a single site. With more than one, the server cannot tell which you meant, and says so rather than picking one. Scope the key to a site when the organisation has several.

What the server will not do

It reads. There is no tool that writes a page, changes a setting, or touches anything outside the documentation the key covers.

A key cannot reach another organisation's content. The tenant is resolved from the key itself, never from anything the caller says about itself, so there is no parameter to set wrongly and no header to forge.

Answers are not part of this. search_docs returns your documentation and lets the agent reason over it, which is what an agent is for. The hosted answer endpoint, which spends your plan's monthly allowance, is a separate thing.

Transport

JSON-RPC 2.0 over HTTP, the Streamable HTTP transport.

POST carries requests and answers as JSON, or as an event stream when the client asks for one. initialize negotiates the protocol version against what the client offers.

GET and DELETE answer 405. That is deliberate rather than missing: GET exists for messages a server starts on its own, and this server starts none, so an open stream would be a connection that never speaks. No session id is issued either, because there is no per-connection state to keep: the key is the whole of it, and every request carries one.

Rate limits

Shared with the read API, per key. A client that exceeds them gets a 429 with the real HTTP status rather than a JSON-RPC error, so an ordinary HTTP client still behaves sensibly. Everything else is reported as HTTP 200 with a JSON-RPC error in the body, which is what a JSON-RPC client reads.