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

Ein MCP-Server, der es KI-Assistenten ermöglicht, Inhalte von As The Geek Learns zu durchsuchen und zu zitieren – dies umfasst MCP-Server, lokale KI, KI-Automatisierung und die Dokumentation von ASTGL-Projekten.

Wenn sich ein KI-Assistent mit diesem Server verbindet, erhält er Zugriff auf 49 indexierte Einträge (Artikel, Tutorials, Vergleiche, Anleitungen und Projektdokumentationen). Jede Antwort enthält Quell-URLs, die zurück zu astgl.ai führen.

Schnellstart

Claude Desktop

Fügen Sie dies zu Ihrer claude_desktop_config.json hinzu:

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

Claude Code

Fügen Sie dies zu der .mcp.json Ihres Projekts hinzu:

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

Cursor / Generischer MCP-Client

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

Mit Registrierung (500 Abfragen/Tag)

Registrieren Sie sich über das register-Tool, um einen API-Schlüssel zu erhalten, und fügen Sie diesen dann Ihrer Konfiguration hinzu:

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

Related MCP server: moss-brain

Tools

`search_articles`

Durchsuchen Sie die Wissensdatenbank nach einer Abfrage. Gibt rangierte Ergebnisse mit Relevanz-Scores und Quell-URLs zurück.

Parameter	Typ	Erforderlich	Beschreibung
`query`	string	Ja	Suchanfrage (z. B. "how to build an MCP server")
`limit`	number	Nein	Maximale Ergebnisse, 1-20 (Standard: 5)
`content_type`	string	Nein	Filtern nach Typ: article, tutorial, faq, comparison, guide, newsletter, project

`get_answer`

Erhalten Sie eine direkte Antwort auf eine spezifische Frage. Bevorzugt FAQ-Einträge für prägnante Antworten.

Parameter	Typ	Erforderlich	Beschreibung
`question`	string	Ja	Eine spezifische Frage (z. B. "What is an MCP server?")
`content_type`	string	Nein	Filtern nach Inhaltstyp

`get_tutorial`

Erhalten Sie Schritt-für-Schritt-Anleitungen aus Tutorial- und Guide-Inhalten.

Parameter	Typ	Erforderlich	Beschreibung
`query`	string	Ja	Was Sie lernen möchten (z. B. "setup Ollama on Mac")

`compare_topics`

Direkter Vergleich zweier Themen.

Parameter	Typ	Erforderlich	Beschreibung
`topic_a`	string	Ja	Erstes Thema
`topic_b`	string	Ja	Zweites Thema

`get_latest`

Erhalten Sie die zuletzt hinzugefügten Inhalte.

Parameter	Typ	Erforderlich	Beschreibung
`limit`	number	Nein	Maximale Ergebnisse, 1-20 (Standard: 5)

`list_topics`

Durchsuchen Sie alle Themen in der Wissensdatenbank mit Inhaltstypen und Abschnittsüberschriften.

`register`

Registrieren Sie Ihre E-Mail-Adresse, um 500 Abfragen/Tag freizuschalten (statt 50).

Parameter	Typ	Erforderlich	Beschreibung
`email`	string	Ja	Ihre E-Mail-Adresse

Inhaltstypen

Typ	Anzahl	Beschreibung
article	29	Informative Inhalte über MCP, lokale KI, Automatisierung
project	9	ASTGL-Projektdokumentation (KlockThingy, Revri, Cortex, etc.)
tutorial	8	Schritt-für-Schritt-Anleitungen
comparison	2	Themenanalyse im direkten Vergleich
guide	1	Umfassendes Referenzmaterial
newsletter	—	Persönliche Updates und Ankündigungen
faq	—	Primär F&A-Inhalte

Ratenbegrenzungen

Stufe	Limit	Wie man es erhält
Öffentlich	50 Abfragen/Tag	Standard (anonym)
Registriert	500 Abfragen/Tag	Verwenden Sie das `register`-Tool mit Ihrer E-Mail

Die Limits werden um Mitternacht UTC zurückgesetzt. Informationen zur Ratenbegrenzung sind in jeder Antwort enthalten.

Funktionsweise

Die Wissensdatenbank wird aus ASTGL-Artikeln unter Verwendung semantischer Embeddings (nomic-embed-text, 768 Dimensionen) vorberechnet. Die Inhalte werden nach Abschnitten und FAQ-Einträgen unterteilt, eingebettet und in einer SQLite-Datenbank mit sqlite-vec für die Vektor-Ähnlichkeitssuche gespeichert.

Endbenutzer benötigen kein Ollama – alle Embeddings sind vorberechnet und im npm-Paket enthalten. Die einzige Laufzeitvoraussetzung ist Node.js.

Leistung

Typische Antwortzeit: 100-500ms (Embedding-Suche + Vektorsuche)
Embedding-Ergebnisse werden im Arbeitsspeicher zwischengespeichert (LRU, 200 Einträge) – wiederholte Abfragen sind nahezu sofort verfügbar
Ollama-Aufrufe beinhalten 10s Timeout + automatische Wiederholung
Abfrage-Logging erfolgt asynchron/gebatcht, um Antworten nicht zu blockieren
Ratenbegrenzungsprüfungen werden für 5 Sekunden zwischengespeichert

Für Betreuer

Einrichtung

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

Skripte

Skript	Beschreibung
`npm run build`	TypeScript kompilieren
`npm run dev`	MCP-Server im Entwicklungsmodus ausführen (tsx)
`npm start`	Kompilierten MCP-Server ausführen
`npm run ingest`	knowledge.db aus lokalem Markdown neu erstellen (erfordert Ollama)
`npm run ingest-projects`	Projektdokumentationen aus astgl-site projects.json indexieren
`npm run discover`	RSS/Sitemap auf neue Inhalte prüfen
`npm run structure`	Entdeckte Inhalte verarbeiten (klassifizieren, einbetten, indexieren)
`npm run pipeline`	Entdecken + Strukturieren in einem Schritt
`npm run daily-report`	AEO-Analysebericht generieren
`npm run alerts`	Prüfungen auf Inhaltslücken ausführen
`npm run freshness`	Auf veraltete Inhalte und Änderungen der Ökosystemversion prüfen
`npm run citation-test`	Manueller KI-Zitierungstest
`npm run related`	Interne Artikellinks via Vektorähnlichkeit generieren

Umgebungsvariablen

Variable	Standard	Beschreibung
`OLLAMA_URL`	`http://localhost:11434`	Ollama-Endpunkt (nur Dev/Rebuild)
`EMBED_MODEL`	`nomic-embed-text`	Embedding-Modell
`DISCORD_WEBHOOK_URL`	—	Discord-Webhook für Berichte/Warnungen
`ASTGL_API_KEY`	—	API-Schlüssel für registrierte Stufe
`ASTGL_ARTICLES_DIR`	`~/Projects/astgl-site/src/content/answers`	Lokale Markdown-Quelle
`ASTGL_PROJECTS_JSON`	`~/Projects/astgl-site/src/data/projects.json`	Projektdatenquelle

Automatisierte Jobs

Job	Zeitplan	Zweck
Content-Pipeline	Alle 6h	Neue Inhalte entdecken + strukturieren
Täglicher Bericht	8 Uhr morgens	Abfrage-Analysen + Gesundheitsmetriken → Discord
Inhaltswarnungen	9 Uhr morgens	Lückenerkennung, Null-Zitierungen, Wettbewerberscan → Discord
Frischeprüfung	10 Uhr morgens	Veraltete Inhalte + Verfolgung der Ökosystemversion → Discord

Lizenz

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