de en es ja ko ru zh

mcp-astgl-knowledge

Name: mcp-astgl-knowledge
Author: Jmeg8r

by Jmeg8r

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

mcp-astgl-knowledge

MCP-сервер, который позволяет ИИ-ассистентам искать и цитировать контент с сайта As The Geek Learns, охватывающий MCP-серверы, локальный ИИ, автоматизацию ИИ и документацию проектов ASTGL.

Когда ИИ-ассистент подключается к этому серверу, он получает доступ к 49 индексированным записям (статьям, руководствам, сравнениям, гайдам и документации по проектам). Каждый ответ включает исходные URL-адреса на astgl.ai.

Быстрый старт

Claude Desktop

Добавьте в ваш claude_desktop_config.json:

{
  "mcpServers": {
    "astgl-knowledge": {
      "command": "npx",
      "args": ["-y", "mcp-astgl-knowledge"]
    }
  }
}

Claude Code

Добавьте в файл .mcp.json вашего проекта:

{
  "mcpServers": {
    "astgl-knowledge": {
      "command": "npx",
      "args": ["-y", "mcp-astgl-knowledge"]
    }
  }
}

Cursor / Универсальный MCP-клиент

{
  "mcpServers": {
    "astgl-knowledge": {
      "command": "npx",
      "args": ["-y", "mcp-astgl-knowledge"]
    }
  }
}

С регистрацией (500 запросов в день)

Зарегистрируйтесь через инструмент register, чтобы получить API-ключ, а затем добавьте его в свою конфигурацию:

{
  "mcpServers": {
    "astgl-knowledge": {
      "command": "npx",
      "args": ["-y", "mcp-astgl-knowledge"],
      "env": {
        "ASTGL_API_KEY": "astgl_your_api_key_here"
      }
    }
  }
}

Related MCP server: moss-brain

Инструменты

`search_articles`

Поиск по базе знаний на основе запроса. Возвращает ранжированные результаты с оценками релевантности и исходными URL-адресами.

Параметр	Тип	Обязательный	Описание
`query`	string	Да	Поисковый запрос (например, "how to build an MCP server")
`limit`	number	Нет	Макс. количество результатов, 1-20 (по умолчанию: 5)
`content_type`	string	Нет	Фильтр по типу: article, tutorial, faq, comparison, guide, newsletter, project

`get_answer`

Получение прямого ответа на конкретный вопрос. Предпочтение отдается записям FAQ для кратких ответов.

Параметр	Тип	Обязательный	Описание
`question`	string	Да	Конкретный вопрос (например, "What is an MCP server?")
`content_type`	string	Нет	Фильтр по типу контента

`get_tutorial`

Получение пошаговых инструкций из учебных материалов и руководств.

Параметр	Тип	Обязательный	Описание
`query`	string	Да	Что вы хотите изучить (например, "setup Ollama on Mac")

`compare_topics`

Сравнение двух тем бок о бок.

Параметр	Тип	Обязательный	Описание
`topic_a`	string	Да	Первая тема
`topic_b`	string	Да	Вторая тема

`get_latest`

Получение самого последнего добавленного контента.

Параметр	Тип	Обязательный	Описание
`limit`	number	Нет	Макс. количество результатов, 1-20 (по умолчанию: 5)

`list_topics`

Просмотр всех тем в базе знаний с типами контента и заголовками разделов.

`register`

Зарегистрируйте свой email, чтобы разблокировать 500 запросов в день (вместо 50).

Параметр	Тип	Обязательный	Описание
`email`	string	Да	Ваш адрес электронной почты

Типы контента

Тип	Количество	Описание
article	29	Информационный контент об MCP, локальном ИИ, автоматизации
project	9	Документация проектов ASTGL (KlockThingy, Revri, Cortex и др.)
tutorial	8	Пошаговые руководства
comparison	2	Сравнительный анализ тем
guide	1	Исчерпывающий справочный материал
newsletter	—	Личные обновления и анонсы
faq	—	Преимущественно контент в формате вопрос-ответ

Лимиты запросов

Уровень	Лимит	Как получить
Публичный	50 запросов/день	По умолчанию (анонимно)
Зарегистрированный	500 запросов/день	Используйте инструмент `register` с вашим email

Лимиты сбрасываются в полночь по UTC. Информация о лимитах включена в каждый ответ.

Как это работает

База знаний предварительно создана из статей ASTGL с использованием семантических эмбеддингов (nomic-embed-text, 768 измерений). Контент разбит на разделы и записи FAQ, преобразован в эмбеддинги и сохранен в базе данных SQLite с использованием sqlite-vec для поиска по векторному сходству.

Конечным пользователям не нужен Ollama — все эмбеддинги предварительно вычислены и поставляются в npm-пакете. Единственное требование для выполнения — Node.js.

Производительность

Типичное время ответа: 100-500 мс (поиск эмбеддингов + векторный поиск)
Результаты эмбеддингов кэшируются в памяти (LRU, 200 записей) — повторные запросы выполняются почти мгновенно
Вызовы Ollama включают тайм-аут 10 с + автоматический повтор
Логирование запросов выполняется асинхронно/пакетами, чтобы не блокировать ответы
Проверки лимитов запросов кэшируются на 5 секунд

Для сопровождающих

Настройка

git clone https://github.com/Jmeg8r/mcp-astgl-knowledge.git
cd mcp-astgl-knowledge
npm install

Скрипты

Скрипт	Описание
`npm run build`	Компиляция TypeScript
`npm run dev`	Запуск MCP-сервера в режиме разработки (tsx)
`npm start`	Запуск скомпилированного MCP-сервера
`npm run ingest`	Пересборка knowledge.db из локального markdown (требуется Ollama)
`npm run ingest-projects`	Индексация документации проектов из projects.json сайта astgl
`npm run discover`	Опрос RSS/sitemap для поиска нового контента
`npm run structure`	Обработка обнаруженного контента (классификация, эмбеддинги, индексация)
`npm run pipeline`	Обнаружение + структурирование за один шаг
`npm run daily-report`	Генерация аналитического отчета AEO
`npm run alerts`	Запуск проверок оповещений о пробелах в контенте
`npm run freshness`	Проверка на устаревший контент и изменения версий экосистемы
`npm run citation-test`	Ручное тестирование цитирования ИИ
`npm run related`	Генерация внутренних ссылок на статьи через векторное сходство

Переменные окружения

Переменная	По умолчанию	Описание
`OLLAMA_URL`	`http://localhost:11434`	Эндпоинт Ollama (только для разработки/пересборки)
`EMBED_MODEL`	`nomic-embed-text`	Модель эмбеддингов
`DISCORD_WEBHOOK_URL`	—	Discord webhook для отчетов/оповещений
`ASTGL_API_KEY`	—	API-ключ зарегистрированного уровня
`ASTGL_ARTICLES_DIR`	`~/Projects/astgl-site/src/content/answers`	Локальный источник markdown
`ASTGL_PROJECTS_JSON`	`~/Projects/astgl-site/src/data/projects.json`	Источник данных о проектах

Автоматизированные задачи

Задача	Расписание	Цель
Конвейер контента	Каждые 6 ч	Обнаружение + структурирование нового контента
Ежедневный отчет	8:00	Аналитика запросов + метрики здоровья → Discord
Оповещения о контенте	9:00	Обнаружение пробелов, отсутствие цитирований, сканирование конкурентов → Discord
Проверка свежести	10:00	Устаревший контент + отслеживание версий экосистемы → Discord

Лицензия

MIT

Available Tools

3 tools

get_answerC

Get a direct answer to a question about MCP servers, local AI, or AI automation from ASTGL's knowledge base. Returns the best matching answer with source URL and related articles.

ParametersJSON Schema

Name	Required	Description	Default
`question`	Yes	A specific question (e.g., 'What is an MCP server?')

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool returns 'the best matching answer with source URL and related articles', which gives some output context, but lacks details on error handling, rate limits, authentication needs, or how 'best matching' is determined. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence that efficiently conveys the core functionality and output. It's front-loaded with the main purpose and avoids unnecessary details. However, it could be slightly more concise by integrating the output details more seamlessly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (single parameter, no output schema, no annotations), the description is minimally adequate. It covers the purpose and output format but lacks usage guidelines, behavioral details, and differentiation from siblings. With no output schema, it should ideally explain return values more thoroughly, though it does mention 'source URL and related articles'.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, with the 'question' parameter fully documented in the schema. The description adds no additional parameter semantics beyond what's in the schema (e.g., no examples of effective questions or formatting tips). Baseline score of 3 is appropriate since the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Get a direct answer to a question about MCP servers, local AI, or AI automation from ASTGL's knowledge base.' It specifies the verb ('Get'), resource ('direct answer'), and scope ('about MCP servers, local AI, or AI automation'), but doesn't explicitly differentiate from sibling tools like 'list_topics' or 'search_articles' beyond mentioning it returns 'the best matching answer'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like 'list_topics' or 'search_articles'. It mentions the tool returns 'the best matching answer with source URL and related articles', but doesn't specify scenarios where this is preferable over other search or listing tools. No exclusions or prerequisites are stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_topicsB

List all topics covered in the ASTGL knowledge base. Shows article titles, descriptions, URLs, and section headings.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions what data is returned but doesn't cover critical aspects like whether this is a read-only operation, potential rate limits, authentication requirements, pagination behavior, or error conditions. For a tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately concise with two sentences that directly convey the tool's purpose and output format. It's front-loaded with the main action and avoids unnecessary elaboration. However, it could be slightly more structured by explicitly separating purpose from output details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no annotations, no output schema, and 0 parameters, the description should provide more complete context about behavioral aspects. While it adequately describes what the tool does, it lacks information about return format details, error handling, performance characteristics, or limitations. For a tool with minimal structured data, the description doesn't compensate sufficiently.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the empty parameter set. The description appropriately doesn't add parameter information beyond what's in the schema, which is correct for a parameterless tool. Baseline for 0 parameters is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('List all topics') and resource ('ASTGL knowledge base'), with specific details about what information is shown (article titles, descriptions, URLs, section headings). It distinguishes from sibling tools like 'get_answer' and 'search_articles' by focusing on comprehensive topic listing rather than specific answers or filtered searches. However, it doesn't explicitly contrast with siblings in the text itself.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like 'search_articles' or 'get_answer'. It doesn't mention use cases, prerequisites, or exclusions. The agent must infer usage from the purpose alone, which is insufficient for optimal tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_articlesC

Search ASTGL articles about MCP servers, local AI, and AI automation. Returns relevant article sections with source URLs for citation.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Search query (e.g., 'how to build an MCP server')
`limit`	No	Maximum number of results to return (default: 5)

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that the tool returns 'relevant article sections with source URLs for citation', which gives some context about output format. However, it doesn't address important behavioral aspects like whether this is a read-only operation, potential rate limits, authentication requirements, or how relevance is determined.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately concise with two sentences that efficiently convey the tool's purpose and output. It's front-loaded with the main functionality. However, the first sentence could be slightly more streamlined by integrating the topic scope more smoothly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a search tool with 2 parameters, 100% schema coverage, and no output schema, the description provides adequate but incomplete context. It explains what the tool searches and what it returns, but doesn't address behavioral aspects like whether this is a read-only operation or how results are ranked. Without annotations or output schema, more behavioral context would be helpful.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema. It mentions the search scope but doesn't provide additional context about how the 'query' parameter should be formulated or how 'limit' affects results beyond what the schema already states.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: searching ASTGL articles about specific topics (MCP servers, local AI, AI automation) and returning relevant sections with source URLs. It specifies the verb 'Search' and resource 'ASTGL articles', but doesn't explicitly differentiate from sibling tools like 'get_answer' or 'list_topics'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided about when to use this tool versus the sibling tools 'get_answer' or 'list_topics'. The description mentions the search scope (MCP servers, local AI, AI automation) but doesn't indicate when this tool is preferred over alternatives or any prerequisites for its use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

3 tool updatesv1.0.0Apr 13, 2026
- First observedget_answer
- First observedlist_topics
- First observedsearch_articles

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.4/5.0

Scored 2026-04-13 17:55 across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: get_answer retrieves direct answers to specific questions, list_topics enumerates all available topics, and search_articles performs keyword-based searches. There is no overlap in functionality, making tool selection unambiguous for an agent.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (get_answer, list_topics, search_articles) with clear, descriptive verbs. The naming is uniform and predictable across the entire set.

Tool Count4/5

Three tools is reasonable for a knowledge base server, covering core operations like querying, listing, and searching. It might feel slightly thin if advanced filtering or topic management were expected, but it's well-scoped for basic access.

Completeness4/5

The tools provide good coverage for accessing a knowledge base: retrieving answers, listing content, and searching. A minor gap is the lack of tools for updating or managing the knowledge base, but this is acceptable if the server is read-only.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

forkast-mcp-docs A
io.github.ForkastPredict
MCP server for querying Forkast documentation
Documentation Access Search Developer Tools
42
mcp A
ai.llmse
Public MCP server for the LLM Search Engine
Search RAG Systems Developer Tools
102
driflyte-mcp-server
com.driflyte
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
Search Web Scraping Knowledge & Memory
211
mcp-aichatOAuth
io.github.AceDataCloud
MCP server for AI dialogue using various LLM models via AceDataCloud
AI & Machine Learning
2

Related MCP Servers

ragi
RAG Systems Search
SusuTawar
A
license
A
quality
D
maintenance
Local-first RAG indexing and semantic search MCP server. Enables document retrieval and context-aware queries using local embedding models.
Updated a month ago (2026-08-13 16:07 UTC)
3
6 npm
MIT
moss-brain
Knowledge & Memory Search
Naut1cal5
A
license
Not graded
quality
B
maintenance
MCP server that provides semantic memory with search, related-content traversal, and write-back capabilities, all powered by local embeddings of your notes, documents, and chat histories.
Updated 2 months ago (2026-07-09 19:48 UTC)
3
MIT
knowledge-engine
RAG Systems Knowledge & Memory
gorosofia
F
license
Not graded
quality
B
maintenance
MCP server for querying a personal knowledge base using semantic RAG, powered by DeepSeek and local embeddings from Ollama.
Updated 2 months ago (2026-07-30 17:14 UTC)
-
delapan
RAG Systems Knowledge & Memory Search
anthonysuherli
A
license
Not graded
quality
B
maintenance
MCP server that grounds AI answers in a local, maintained knowledge base and optionally fills gaps from the web, fully local with SQLite.
Updated 2 months ago (2026-07-28 08:14 UTC)
AGPL 3.0