What can you do with this server?

This server provides AI assistants with access to the As The Geek Learns (ASTGL) knowledge base (astgl.ai), covering MCP servers, local AI, and AI automation. * Search articles: Query the knowledge base by search term, filter by content type (article, tutorial, FAQ, comparison, guide, newsletter, project), and limit results. Returns relevance scores and source URLs. * Get direct answers: Ask a specific question and receive a concise answer with its source URL and related articles. * List all topics: Browse the entire knowledge base — titles, descriptions, URLs, and section headings. * Get tutorials: Retrieve step-by-step guides for specific learning goals. * Compare topics: Get side-by-side comparisons of two topics. * Get latest content: Retrieve the most recently added entries. * Register: Register an email to increase the daily query limit from 50 to 500.

de en es ja ko ru zh

mcp-astgl-knowledge

by Jmeg8r

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

mcp-astgl-knowledge

An MCP server that lets AI assistants search and cite content from As The Geek Learns — covering MCP servers, local AI, AI automation, and ASTGL project documentation.

When an AI assistant connects to this server, it gains access to 49 indexed entries (articles, tutorials, comparisons, guides, and project docs). Every response includes source URLs back to astgl.ai.

Quick Start

Claude Desktop

Add to your claude_desktop_config.json:

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

Claude Code

Add to your project's .mcp.json:

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

Cursor / Generic MCP Client

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

With Registration (500 queries/day)

{
  "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`

Search the knowledge base by query. Returns ranked results with relevance scores and source URLs.

Parameter	Type	Required	Description
`query`	string	Yes	Search query (e.g., "how to build an MCP server")
`limit`	number	No	Max results, 1-20 (default: 5)
`content_type`	string	No	Filter by type: article, tutorial, faq, comparison, guide, newsletter, project

`get_answer`

Get a direct answer to a specific question. Prefers FAQ entries for concise responses.

Parameter	Type	Required	Description
`question`	string	Yes	A specific question (e.g., "What is an MCP server?")
`content_type`	string	No	Filter by content type

`get_tutorial`

Get step-by-step instructions from tutorial and guide content.

Parameter	Type	Required	Description
`query`	string	Yes	What you want to learn (e.g., "setup Ollama on Mac")

`compare_topics`

Side-by-side comparison of two topics.

Parameter	Type	Required	Description
`topic_a`	string	Yes	First topic
`topic_b`	string	Yes	Second topic

`get_latest`

Get the most recently added content.

Parameter	Type	Required	Description
`limit`	number	No	Max results, 1-20 (default: 5)

`list_topics`

Browse all topics in the knowledge base with content types and section headings.

`register`

Parameter	Type	Required	Description
`email`	string	Yes	Your email address

Content Types

Type	Count	Description
article	29	Informational content about MCP, local AI, automation
project	9	ASTGL project documentation (KlockThingy, Revri, Cortex, etc.)
tutorial	8	Step-by-step how-to guides
comparison	2	Side-by-side topic analysis
guide	1	Comprehensive reference material
newsletter	—	Personal updates and announcements
faq	—	Primarily Q&A content

Rate Limits

Tier	Limit	How to Get
Public	50 queries/day	Default (anonymous)
Registered	500 queries/day	Use the `register` tool with your email

Limits reset at midnight UTC. Rate limit info is included in every response.

How It Works

The knowledge base is pre-built from ASTGL articles using semantic embeddings (nomic-embed-text, 768 dimensions). Content is chunked by section and FAQ entry, embedded, and stored in a SQLite database with sqlite-vec for vector similarity search.

End users don't need Ollama — all embeddings are pre-computed and shipped in the npm package. The only runtime requirement is Node.js.

Performance

Typical response time: 100-500ms (embedding lookup + vector search)
Embedding results are cached in memory (LRU, 200 entries) — repeated queries are near-instant
Ollama calls include 10s timeout + automatic retry
Query logging is async/batched to avoid blocking responses
Rate limit checks are cached for 5 seconds

For Maintainers

Setup

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

Scripts

Script	Description
`npm run build`	Compile TypeScript
`npm test`	Run the test suite (node:test via tsx)
`npm run dev`	Run MCP server in dev mode (tsx)
`npm start`	Run compiled MCP server
`npm run ingest`	Rebuild knowledge.db from local markdown (requires Ollama)
`npm run ingest-projects`	Index project docs from astgl-site projects.json
`npm run discover`	Poll RSS/sitemap for new content
`npm run structure`	Process discovered content (classify, embed, index)
`npm run pipeline`	Discover + structure in one step
`npm run daily-report`	Generate AEO analytics report
`npm run alerts`	Run content gap alert checks
`npm run freshness`	Check for stale content and ecosystem version changes
`npm run publish-drift`	Compare local publishable content against what npm actually serves
`npm run citation-test`	Manual AI citation testing
`npm run related`	Generate internal article links via vector similarity

Environment Variables

Variable	Default	Description
`OLLAMA_URL`	`http://localhost:11434`	Ollama endpoint (dev/rebuild only)
`EMBED_MODEL`	`nomic-embed-text`	Embedding model
`DISCORD_WEBHOOK_URL`	—	Discord webhook for reports/alerts
`ASTGL_API_KEY`	—	Registered tier API key
`ASTGL_ARTICLES_DIR`	`~/Projects/astgl-site/src/content/answers`	Local markdown source
`ASTGL_PROJECTS_JSON`	`~/Projects/astgl-site/src/data/projects.json`	Projects data source

Automated Jobs

Job	Schedule	Purpose
Content pipeline	Every 6h	Discover + structure new content
Daily report	8 AM	Query analytics + health metrics → Discord
Content alerts	9 AM	Gap detection, zero-citation, competitor scan → Discord
Freshness check	10 AM	Stale content + ecosystem version tracking → Discord

License

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