This lightweight knowledge base (RAG) MCP server enables agents to query, search, and retrieve content from one or more static sites, complementing a static site generator. Key capabilities:
List configured sites (list_sites): View loaded sites, body-cache statistics, and Orama search engine status (mode, embeddings, snapshot).
Summarize the knowledge base (catalog_summary): Get document counts by site, category, language, and top tags, filterable by visibility (public, protected, all).
Full-text search (search_content): Perform BM25 searches (optional hybrid/vector if embeddings enabled) across titles, descriptions, tags, and full markdown body. Filter by site, category, language, tags, and visibility. Paginate with limit and offset.
Retrieve document metadata (get_entry): Fetch full metadata for a document by its stable ID (e.g., know:devops/es/Keycloak).
Read full document (read_document): Get the complete markdown body (without frontmatter) from cache/disk, with configurable truncation up to 100,000 characters.
List series (list_series): List documents in a category ordered by filename for sequential reading (e.g., chapters, dream logs).
Reload catalog (reload_catalog): Re-read index and markdown files from disk and rebuild the Orama index, respecting snapshot settings.
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., "@OnMind-RAG Search for 'markdown indexing' in the knowledge base"
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 complementary and independent project from OnMind-PUB: a lightweight knowledge base (light RAG) that exposes an MCP server so an agent (MCP client) can query the content of one or more sites.
It is not part of the init → index → build → publish workflow. It only reads the _index.json already generated by a site and, on demand, the markdown.
On startup, the server loads docs/public/_index.json from each configured site.
Normalizes in memory (stable IDs, clean tags, visibility, path to .md).
Body cache: reads each .md once, stores bodyText (no frontmatter) and logs time/size to stderr.
Search engine: Orama BM25 full-text by default; hybrid/vector modes opt-in with embeddings.
Exposes compact MCP tools: summary → search (meta + body) → document reading.
No _catalog.json is written. If the site re-indexes externally, use the reload_catalog tool.
Related MCP server: Lexomni MCP
Node.js ≥ 18 (or Bun with Node compatibility)
At least one site with docs/public/_index.json (e.g. sites/know from OnMind-PUB)
cd rag
cp .env.example .env # optional; you can also export vars
bun install # or: npm installVariables (see .env.example):
Variable | Meaning |
| Paths to site roots, comma-separated (required) |
| Optional labels (same order) |
|
|
| Max chars returned by |
|
|
|
|
|
|
| Vector dimensions (default 384) |
|
|
| Snapshot path (default |
Example:
export RAG_SITES=../sites/know
# or multiple:
# export RAG_SITES=../sites/know,../sites/andreyRAG_SITES=../sites/know bun run smokeWith embeddings + hybrid:
RAG_SITES=../sites/know RAG_EMBEDDINGS=1 RAG_SEARCH_MODE=hybrid bun run smokeWith snapshot (2nd load ~100 ms):
RAG_SITES=../sites/know RAG_SNAPSHOT=1 bun run smoke # first: saved
RAG_SITES=../sites/know RAG_SNAPSHOT=1 bun run smoke # second: loadedRAG_SITES=../sites/know bun run mcp{
"mcpServers": {
"onmind-rag": {
"command": "bun",
"args": ["/absolute/path/to/pub/rag/src/server.js"],
"env": {
"RAG_SITES": "/absolute/path/to/pub/sites/know",
"RAG_VISIBILITY": "public",
"RAG_SEARCH_MODE": "fulltext",
"RAG_EMBEDDINGS": "0",
"RAG_SNAPSHOT": "0"
}
}
}
}You can also use
nodeinstead ofbun
{
"command": "node",
"args": ["/absolute/path/to/pub/rag/src/server.js"],
"env": { "RAG_SITES": "/absolute/path/to/pub/sites/know" }
}Tool | Purpose |
| Loaded sites, body-cache stats, search-engine status (Orama, embeddings, snapshot) |
| Stats by category / language / tags (orientation) |
| Full-text Orama (BM25) by default on title/description/tags/body. |
| One record by |
| Markdown body (preferably from cache; truncatable) |
| Series ordered by |
| Re-reads |
Typical agent flow:
catalog_summary → search_content → get_entry / list_series → read_documentOnMind-PUB | onmind-rag |
Generates | Only consumes it |
Publish workflow | Outside that flow |
Lives in monorepo for convenience | Movable: just point |
In stderr you'll see something like:
[onmind-rag] index: 289 entries from 1 site(s) in 3ms at ...
[onmind-rag] body cache: 289 docs, 3533.3 KiB in 59ms (missing path=0, read errors=0)
[onmind-rag] search engine: orama · mode=fulltext · embeddings=off · 289 docs · 450msWith RAG_CACHE_BODY=1 (default): Orama indexes the body field → search_content performs full-text BM25 over the entire markdown. read_document answers from memory (fromCache: true).
With RAG_CACHE_BODY=0: Orama only indexes metadata (title, description, tags) → search_content does not find matches in the document body. read_document falls back to disk reads.
Disable only if RAM is very tight or corpus > 50 MB and you accept metadata-only search.
Mode | What it does |
| BM25 with stemming, typo tolerance, field boosting. Fast, no external deps. |
| BM25 + vector (cosine) — needs |
| Vector similarity only — needs |
RAG_EMBEDDINGS=1 uses local feature-hashing (no TensorFlow, no API keys) — a portable baseline to exercise the vector/hybrid path. Not a SOTA semantic model. For real quality, replace embed.js with a provider (OpenAI, Xenova/transformers.js, etc.) keeping the embedText(text, { dims }) interface.
RAG_SNAPSHOT=1 serializes the Orama index to disk (data/orama-snapshot.json + .meta.json). On subsequent starts, if the corpus fingerprint (ids, titles, body length, hide, embeddings flag/dims) matches, it loads the snapshot in ~100 ms instead of re-indexing (~450 ms).
Lexical/BM25 retrieval + hash vectors (no SOTA embeddings unless you plug them in).
No knowledge graph / neighbors yet (next step: markdown links).
Designed as a useful, portable base — not a managed vector engine.
The corpus is predominantly Spanish (~80%). Orama's default English tokenizer treats short technical codes like "XDB", "IAM", "UCDM" as stop-words/noise. Setting language: 'spanish' in the tokenizer indexes them correctly.
Based on onmind-rag v0.2.0 — MCP server for knowledge retrieval with Orama BM25 + opt-in hybrid/vector + snapshot
Resumen de la base de conocimiento OnMind. Úsalo ANTES de buscar para orientarte: cuenta docs por sitio, categoría, idioma y tags top. Te dice qué hay disponible sin hacer búsqueda.
| Name | Required | Description | Default |
|---|---|---|---|
| visibility | No | public (default) | protected | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It explains that the tool counts documents by site, category, language, and top tags, and that it does not perform a search. However, it does not mention any required permissions, rate limits, or whether it returns aggregated counts or detailed lists. This is adequate but not fully 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?
The description is two sentences long, front-loading the purpose and then immediately providing usage guidance. Every word adds value, and there is no redundancy. It is appropriately concise for a simple tool.
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?
Given the tool's simplicity (one optional parameter, no output schema), the description provides a good overview of what the tool returns: counts by site, category, language, and top tags. It covers the essential information an AI agent needs to understand the tool's output and use it correctly, though it could mention whether the counts are absolute or relative.
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 has one optional parameter 'visibility' with clear enum values and a description in the schema. The tool description does not mention the parameter, but the schema coverage is 100%, so the schema already provides full meaning. The description adds little beyond the schema, so a baseline score of 3 is appropriate.
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 the tool provides a summary of the OnMind knowledge base, counting documents by site, category, language, and top tags. It distinguishes itself from sibling tools like search_content (which performs searches) and get_entry (which retrieves specific entries) by emphasizing that it is an orientation tool used before searching.
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 it BEFORE searching to orient oneself, indicating the primary use case. It also says what it does without searching, implying it is not for detailed retrieval. However, it does not explicitly mention when not to use it or list alternative tools beyond this implicit contrast.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Obtiene la ficha completa de un documento OnMind por ID estable (site:url). Úsalo tras search_content para ver metadatos antes de leer el cuerpo.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Entry id from search results, e.g. know:devops/es/Keycloak |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It implies a read operation ('gets') and adds context about stable ID format, but does not explicitly state safety, permissions, or side effects. Lacks some behavioral detail.
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 sentences only: first states purpose, second gives usage guideline. Concise, front-loaded, no wasted words.
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?
Given a simple single-parameter tool with no output schema, the description is fairly complete. It explains what it does, when to use it, and the ID format. Could be slightly more specific about what metadata is returned, but the second sentence clarifies it returns metadata.
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 coverage is 100% with a clear description and example for the 'id' parameter. The tool description reinforces the format ('ID estable (site:url)') and adds context about stability, adding value beyond the schema.
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?
Clearly states the tool gets the complete record ('ficha completa') of an OnMind document by stable ID. Distinguishes from siblings by specifying usage after search_content and before read_document.
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 advises 'Úsalo tras search_content para ver metadatos antes de leer el cuerpo' (use it after search_content to view metadata before reading the body), providing a clear workflow and when to use this tool vs alternatives like read_document.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista documentos de una serie/categoría OnMind ordenados por filename (libros, sueños, capítulos). Útil para leer en secuencia: abridgetothemiracles, thoseaccordsyoudontremember, dreams, etc.
| Name | Required | Description | Default |
|---|---|---|---|
| site | No | ||
| category | Yes | Category name, e.g. dreams, abridgetothemiracles, devops | |
| language | No | ||
| visibility | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only mentions sorting by filename and examples, lacking details on authorization, rate limits, or other behavioral traits beyond the basic listing.
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 redundancy, efficiently conveying the tool's purpose and typical usage.
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?
With 4 parameters and no output schema or annotations, the description only explains the category and ordering. It omits details on how site, language, and visibility parameters behave, leaving gaps for correct usage.
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 coverage is only 25% (only category has description). The description adds examples of valid category values, but does not explain site, language, or visibility parameters, nor their effect on results.
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 lists documents from a series/category, ordered by filename, with specific examples like dreams and abridgetothemiracles. It distinguishes from sibling tools like search_content or read_document by focusing on sequential reading.
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 implies a use case (reading in sequence) and provides examples, but does not explicitly state when to avoid using this tool or suggest alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List configured knowledge sites, body-cache stats, and search-engine status (Orama, embeddings, snapshot).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It states what is listed (sites, cache stats, search-engine status), implying a read-only operation, but lacks details on performance, authentication, or side effects. The description is moderately transparent but incomplete.
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 a single sentence that efficiently conveys the core function. It is front-loaded with 'list' and includes key details without wasted words.
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?
Given the simplicity of the tool (no parameters, no output schema), the description adequately covers what is listed. However, it does not describe the output format or structure, which would help an agent interpret the result. This is a minor gap.
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 tool has zero parameters, and the schema coverage is 100%, so the baseline is 4. The description does not need to add parameter information, and it correctly omits any, aligning with the schema.
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 the tool lists configured knowledge sites, body-cache stats, and search-engine status, specifying what is returned. However, it does not explicitly differentiate from sibling tools like 'catalog_summary' or 'search_content', leaving some ambiguity about what distinguishes this tool from others.
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?
No guidance is provided on when to use this tool versus alternatives, such as when to list sites versus searching content or getting a catalog summary. The description does not mention prerequisites or limitations, leaving the agent without context for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lee el cuerpo markdown COMPLETO de un documento OnMind (sin frontmatter). Úsalo tras search_content/get_entry cuando necesites el contenido técnico completo. El cuerpo puede truncarse (máx 12k chars por defecto).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Entry id, e.g. know:devops/es/Keycloak | |
| maxBody | No | Max characters of body to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It discloses truncation at 12k chars default and that frontmatter is removed. It does not mention error handling, rate limits, or auth requirements, but for a read tool this is acceptable.
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 sentences: first states purpose, second provides usage context and a key behavioral note. Every sentence is essential, no fluff.
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?
Covers main points: what it returns (body without frontmatter), truncation, and usage context. No output schema but return type is clear. Could briefly mention error handling or response format but not essential for this 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 coverage is 100% with descriptions for both parameters. The description adds value by specifying the default truncation limit (12k chars) when maxBody is not set, which is not in the schema.
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 states it reads the full markdown body of an OnMind document without frontmatter, and distinguishes itself from siblings like search_content and get_entry by noting it is used after those for full technical content.
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?
It explicitly says to use it after search_content/get_entry when needing full technical content, and mentions truncation behavior. However, it does not provide when-not-to-use cases or list alternatives beyond the two named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recarga el índice OnMind desde disco (_index.json + markdown) y reconstruye el índice Orama. Úsalo tras cambios en la fuente (re-index externo). Respeta RAG_SNAPSHOT.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses that the tool reloads from disk and rebuilds the index, and respects RAG_SNAPSHOT. Could be more explicit about potential side effects (e.g., overwrites previous index).
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 sentences in Spanish, efficient, front-loaded with action. No wasted words.
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?
With no parameters or output schema, the description fully covers what the tool does, when to use it, and a key behavior (RAG_SNAPSHOT). Complete for this simple operation.
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?
No parameters exist, so description adds no parameter info. Baseline 4 for zero-parameter tools is appropriate.
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 the action (reload index from disk, rebuild Orama index) and specifies the resources (_index.json + markdown). It is distinct from sibling tools like list_sites and search_content.
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 indicates when to use: after external index changes (re-index externo). Does not state when not to use or provide alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
BÚSQUEDA PRIMARIA en la base de conocimiento OnMind. Úsala PRIMERA para cualquier pregunta sobre: OnMind-PUB, OnMind-XDB, OnMind-CMS, OnMind-WDB, OnMind-ARK, OnMind-EPI, OnMind-DAI, Método OnMind, ABCode, CloudOps, DevOps, código, arquitectura, productos OnMind. Busca en título, descripción, tags y cuerpo completo (BM25 Orama). Devuelve cards con score y snippet. NO uses búsqueda web hasta agotar esta herramienta.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Free-text query (Orama full-text / hybrid) | |
| mode | No | Override search mode for this call: fulltext | hybrid | vector (hybrid/vector need RAG_EMBEDDINGS=1) | |
| site | No | Limit to one site name | |
| tags | No | All of these tags must match | |
| limit | No | Max results (default 20) | |
| inBody | No | Also search markdown body (default true) | |
| offset | No | Pagination offset | |
| notable | No | Only notable entries when true | |
| category | No | Category facet (e.g. devops, dreams) | |
| language | No | Language code, e.g. es or en | |
| visibility | No | public (default) | protected | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions the search algorithm (BM25 Orama) and return format (cards with score and snippet), but lacks details on auth, rate limits, or side effects. It is adequate but not rich.
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 concise with three sentences in Spanish, front-loaded with purpose. Every sentence adds value: primary usage, content scope, and search behavior.
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?
Given 11 parameters and no output schema, the description could provide more detail on result pagination or structure. It briefly mentions cards with score and snippet but omits default modes or ordering. Adequate but not fully complete.
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 schema has 100% parameter description coverage, so the description adds little beyond stating the search scope. It does not explain parameter interactions or syntax, meeting the baseline expectation.
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 the tool is for primary search in the OnMind knowledge base, listing specific topics (OnMind-PUB, etc.) and search fields (title, description, tags, full body). This distinguishes it from sibling tools like list_sites or get_entry.
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 this tool first for any OnMind question and not to resort to web search until this tool is exhausted. This provides clear when-to-use and when-not-to-use guidance.
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.
v0.2.0catalog_summaryget_entrylist_serieslist_sitesread_documentreload_catalogsearch_contentScored across 7 tools
Each tool has a clearly distinct purpose: listing sites, summarizing catalog, fetching entry details, reloading index, searching, reading full documents, and listing series. No two tools overlap in functionality, making selection unambiguous.
Tool names mostly follow a verb_noun pattern (list_sites, get_entry, reload_catalog, search_content, read_document, list_series). The exception is catalog_summary, which is a noun phrase, but still descriptive and consistent in style.
Seven tools is well-scoped for a RAG knowledge base system, covering all necessary operations: overview, search, retrieval of details, admin reload, and series browsing. No tool feels redundant or missing.
The tool set provides complete coverage for a knowledge retrieval workflow: overview (catalog_summary), search (search_content), entry details (get_entry), full content (read_document), and navigation (list_series, list_sites). No obvious gaps for the intended purpose.
Read-only MCP server for the OrchestKit docs: full-text search + Markdown fetch. No auth.
Serve a folder of Markdown notes as an MCP server: hybrid search, reading, and sourced answers.
MCP server for querying Forkast documentation
