Search project docs
search_project_docsFIND A DOCUMENTATION PAGE — start here, and this is the FIRST call for any question about these docs. Searches the project's documentation by MEANING (embeddings over a pre-built vector index), which finds the right page far more often than literal keyword matching: 'how do I reset a password' lands on a page titled 'Recovering account access', which a word search misses entirely. A LONG query is welcome, and usually better than a short one: paste the user's whole request, several questions at once included. It is split into its parts, each part searched on its own and the results merged, so a request that asks about four things returns a page for each instead of one blurred average of all four. Cheap and repeatable: the index is built once, ahead of time, so a call here is one lookup against vectors that already exist. Always answers: a project with no vector index yet is searched by full text instead, and mode ('semantic' | 'lexical') says which engine replied — no plan is required either way. Returns hits {n, title, headingPath, url, path}, best first — each with a similarity score (semantic) or a snippet (lexical); call the matching read-page tool on path for the whole page — read_project_doc on the signed-in server, the read tool this same tools/list names on the public one. Prefer search_docs only when you need a LITERAL string — an error message, a CLI flag, a regex, a file path.
- Use it for any natural-language question — «где написано про…», 'where do we explain X', 'which page covers Y' — and before writing anything, so you edit the page that exists instead of adding a second one about the same thing.
- Do NOT start by listing the outline, grepping or globbing files, or opening pages one by one to look for the answer: that downloads and reads the whole site, takes many times longer and answers worse than one call here.
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "search_project_docs",
"arguments": {
"query": "<query>"
}
}
}