A multi-source document knowledge assistant driven by a self-reflective LangGraph agent. It ingests PDF + Markdown + web pages into one vector store, then answers questions through an agent that grades its own retrieval and verifies its own answer for grounding — retrying with a rewritten query when either check fails, and refusing to fabricate when it can't ground an answer. Traced with Langfuse, quality-tested with DeepEval, and exposed over MCP.
Built to showcase agentic development: LangGraph · LiteLLM · ChromaDB · MCP · Langfuse · DeepEval.
Агент представляет собой корректирующий / саморефлексивный RAG-цикл, а не линейную
цепочку retrieve → generate:
question
│
▼
route ──chitchat/out_of_scope──▶ generate ──▶ END
│ kb
▼
retrieve ──▶ grade_docs ──irrelevant (rewrite query, retry)──▶ retrieve
│ relevant
▼
generate ──▶ self_check ──ungrounded (retry)──▶ retrieve
│ grounded / budget spent
▼
answer + citations (or an honest "I don't know")route — пропускает поиск при светской беседе / вопросах вне области.
grade_docs — LLM-шлюз релевантности; при неудаче переписывает запрос и повторяет попытку.
self_check — проверяет, что черновой ответ вытекает из полученного контекста; если нет, повторяет попытку или уклоняется, а не галлюцинирует.
Общий бюджет повторных попыток (max_retries, по умолчанию 2) ограничивает оба цикла.
Память — чекпойнтер SQLite сохраняет состояние многоходового диалога для каждого thread_id.
Related MCP server: PDF MCP Server
# 1. Install (Python 3.11+, uv)
uv sync
# 2. Configure — only ANTHROPIC_API_KEY is required
cp .env.example .env # then edit .env
# 3. Ingest the sample corpus (2 Markdown + 1 PDF + 1 Wikipedia article)
uv run skai ingest # -> builds ./.chroma (local MiniLM embeddings, no API)
# 4. Ask (defaults to Haiku 4.5; switch per-call with --model)
uv run skai ask "What do orcas eat?"
uv run skai ask "How do orcas communicate?" --source md
uv run skai ask "Summarize orca threats" --model sonnet # haiku | sonnet (Opus blocked)
# 5. Multi-turn chat (remembers the conversation)
uv run skai chat
# 6. Web UI (chat + feedback + live data ingestion)
uv run skai ui # http://localhost:7860
# 7. Serve over MCP (stdio) for Claude Desktop / an IDE
uv run skai mcpskai ui запускает приложение Gradio с функциями, необходимыми для живого демо:
Чат с памятью на сессию; каждый ответ показывает источники, маршрут и модель.
Обратная связь после каждого ответа — 👍/👎 + необязательный комментарий, сохраняется в SQLite
(.skai/feedback.sqlite) и отправляется как оценка Langfuse в трассировке этого хода,
когда трассировка включена. Это замкнутый цикл: реальное использование становится сигналом для оценки.
Примеры запросов для направления первого взаимодействия.
Расширяйте базу знаний вживую — загрузите .md/.txt/.pdf или вставьте URL, и он будет
немедленно добавлен в Chroma, так что демо не ограничено исходным корпусом.
Селекторы модели (haiku/sonnet) и фильтра источников (all/pdf/md/web).
Обратная связь экспортируется в JSONL-файл для оценки через skai.feedback.export_jsonl.
Команда | Что делает |
| Загрузить → разбить на чанки → эмбеддинг → сохранить в Chroma |
| Разовый вопрос с цитатами |
| Интерактивный многоходовой чат с памятью |
| Веб-интерфейс Gradio: чат, обратная связь, живое добавление |
| Запуск MCP-сервера, предоставляющего |
| Запуск набора проверок качества DeepEval (требуется |
Сервер предоставляет два инструмента — search_kb(query, source_type?) (прямой поиск) и
ask(question) (полный агент). Укажите на него MCP-клиенту:
{
"mcpServers": {
"solid-knowledge-ai": {
"command": "uv",
"args": ["run", "skai", "mcp"],
"cwd": "/absolute/path/to/solid-knowledge-ai"
}
}
}По умолчанию используется Haiku 4.5 (быстрый, дешёвый — хорошо подходит для цикла
маршрутизатор+оценщик+генератор вопросов и ответов). Переключайте на каждый вызов с помощью
--model или глобально через SKAI_MODEL в .env:
Значение | Разрешается в |
|
|
|
|
любой идентификатор LiteLLM | передаётся как есть (например, |
Opus намеренно заблокирован (resolve_model вызывает исключение), чтобы ассистента нельзя
было случайно направить на самый дорогой уровень.
Установите LANGFUSE_PUBLIC_KEY / LANGFUSE_SECRET_KEY (и опционально LANGFUSE_HOST) в
.env. Каждый запуск графа тогда создаёт одну трассировку с спаном на каждый узел и каждый
вызов LLM. Без ключей трассировка — чистая заглушка, ничего больше не меняется.
uv sync --group eval
export ANTHROPIC_API_KEY=...
uv run skai ingest
uv run --group eval pytest evals -v # or: skai evalСудья — Claude через LiteLLM, поэтому ключ OpenAI не нужен. Метрики: точность, релевантность ответа, релевантность контекста — плюс дешёвый ключевой фильтр.
uv run pytest # 39 tests, fully offline: no network, no API keysLLM внедряется через зависимости, поэтому весь граф в тестах работает с детерминированным заглушкой, а Chroma использует детерминированную встроенную функцию эмбеддинга.
src/skai/
config.py settings (.env) agent/llm.py ChatLiteLLM -> Claude
models.py Document/Chunk/AgentState agent/nodes.py route/retrieve/grade/generate/self_check
ingest/loaders.py pdf | md | web -> Document agent/prompts.py node prompts
ingest/chunk.py source-aware splitting agent/graph.py StateGraph + SQLite memory
ingest/store.py Chroma add/query observability.py Langfuse handler (or no-op)
cli.py ingest|ask|chat|mcp|eval mcp_server.py search_kb / ask as MCP tools
evals/ DeepEval suite tests/ offline unit + graph testsГраф агента и диаграммы компонентов (Mermaid): см. docs/ARCHITECTURE.md.
Обоснование дизайна и технические компромиссы: см. docs/DECISIONS.md.
Проверено: uv run skai ingest загружает все три типа источников (2 md + 1 pdf + 1 web →
170 чанков), и реальный семантический поиск возвращает релевантные отрывки. 39 офлайн-тестов
проходят. ask/chat/eval требуют ANTHROPIC_API_KEY.
Ask the self-reflective knowledge agent. Returns a grounded, cited answer.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavior disclosure; it does say outputs are grounded and cited, a meaningful trait. However, it does not mention limitations, confidence, citation format, or whether the agent can refuse/ask follow-ups, leaving the behavioral profile thin.
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 short sentences, with the core instruction and return behavior front-loaded. No filler or redundant restatement of the schema.
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?
For a one-parameter tool with an output schema, the description covers the key behavior and return characteristic. It is mostly complete, though the lack of sibling differentiation and parameter detail keeps it from being fully self-sufficient.
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 a single required `question` string with no field description, and the description does not elaborate on expected question format, length, or scope. The parameter name is self-explanatory, but the description adds no semantic detail to compensate for 0% schema coverage.
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?
States a specific action ('Ask') on a distinct resource ('self-reflective knowledge agent') and its output ('grounded, cited answer'). It does not explicitly compare itself to search_kb, but the resource and output type give enough differentiation for a general sense.
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 explicit guidance on when to ask versus using search_kb, nor any exclusions or conditions. The name and description imply Q&A usage, but the agent is not told when to choose this tool over the sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Semantic search over the ingested documents. Optional source_type: pdf|md|web.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| source_type | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of disclosing behavior. It reveals that the tool searches over ingested documents and accepts an optional source_type, but it does not disclose result limits, relevance behavior, authentication needs, or any side effects. For a read/search tool this is a notable but not severe gap.
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 tight sentence followed by a compact optional-parameter note. It is front-loaded with the core action and resource, and every word adds information. No filler or redundancy.
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?
For a simple two-parameter search tool, the description covers the essential invocation surface, and an output schema likely documents return values. However, it omits any comparison with 'ask' and does not explain result behavior or limitations, leaving the agent to infer when this tool is appropriate.
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 description coverage is 0%, so the description must compensate. It does add meaning to source_type by enumerating allowed values ('pdf|md|web'), but it leaves the main 'query' parameter semantically undefined beyond the schema's bare type declaration. The compensation is only partial.
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 a specific action ('Semantic search') on a clear resource ('ingested documents') and lists the optional source_type filter. It does not explicitly name the sibling tool 'ask' as the alternative, so some differentiation is left to inference, but the operation is unmistakable.
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 provides no guidance on when to prefer search_kb over the sibling tool 'ask', nor any exclusions or prerequisites. Usage context is only implied by the phrase 'semantic search', which is not enough to route an agent reliably.
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. Dates show when Glama detected each change.
v0.1.0asksearch_kbThe two tools are distinct in purpose: search_kb returns semantic search results over sources, while ask provides a grounded, cited answer through an agent. There is some overlap in that both retrieve information from the same knowledge base, but the descriptions clearly differentiate a low-level search from a high-level Q&A interaction, making misselection unlikely.
Both tool names use lowercase snake_case and are verb-based. 'search_kb' follows a verb_noun pattern while 'ask' is a bare verb, creating a minor inconsistency, but the pattern is still simple and predictable given the small set.
With only two tools, the server feels thin but not unreasonable. Search and ask cover the core knowledge-access functions, though additional tools like listing sources or managing documents might be expected in a fuller knowledge-management server.
The tool surface covers the core domain of querying an ingested knowledge base: search_kb for retrieval and ask for synthesized answers. Minor gaps exist, such as no way to enumerate available sources or inspect document metadata, but these are not critical for the stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Ingest, manage, and retrieve documents for RAG-powered AI applications
Governed, auditable knowledge your team curates for its AI assistants, self-hostable
Persistent memory and knowledge management for AI agents with semantic search and 50+ tools.
Your company's brain for AI agents. Cited, permission-aware knowledge across every system.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/hailampy123/solid-knowledge-ai'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
