What can you do with this server?

This MCP server lets AI assistants search, browse, and cite ASTGL content on MCP servers, local AI, and AI automation. * Search articles semantically (search_articles) — ranked results with relevance scores, source URLs, and limits up to 20. * Get direct answers (get_answer) — best-match answers (prefers FAQ entries) with citations to astgl.ai. * Browse the knowledge base (list_topics, list_tags) — titles, descriptions, section headings, and tags with counts; no embeddings needed. * Get step-by-step tutorials (get_tutorial) and compare two topics (compare_topics) side by side. * Find recent or structured content — get_latest, plus find_articles lookup by tag, type, title text, or date range. * Unlock higher limits — register with an email for 500 queries/day vs. 50 anonymous. * Generate and manage content (maintainer tools) — idea journal, markdown exports, roundups, QA compilations, dashboards, and query analytics. Note: the semantic tools require a local Ollama running nomic-embed-text; metadata tools work without it. Only a subset of the 17 tools appears in this schema.

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 can search the indexed ASTGL entries (articles, tutorials, comparisons, guides, and project docs). Search results include source URLs back to astgl.ai.

Requirement: the semantic tools (search_articles, get_answer, get_tutorial, compare_topics) embed your query at runtime with a local Ollama running nomic-embed-text (default http://localhost:11434). The metadata tools (find_articles, list_tags, list_topics, get_latest) work without Ollama.

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

More tools

The server registers 17 tools in total. The others:

Tool	What it does	Main parameters
`find_articles`	Structured lookup by tag, type, title text and date range (no embeddings)	`tag`, `content_type`, `title`, `date_from`, `date_to`
`list_tags`	Every tag with its article count	—
`suggest_ideas`	Topic suggestions from query analytics (gaps, low-confidence queries)	`days` (default 7), `limit`
`add_idea` / `list_ideas` / `export_ideas`	Idea journal stored alongside the index	`title`, `description`, `status`, `priority`, `source`
`export_article`	One article as a markdown post	`url`
`export_topic_roundup`	Roundup post from related articles	`topic`, `limit`
`export_qa_compilation`	FAQ-style markdown from article Q&A pairs	`topic`, `limit`
`generate_dashboard_data`	JSON analytics snapshot (optionally written to `data/dashboard.json`)	`days` (default 30), `output_file`

Content Types

Type	Description
article	Informational content about MCP, local AI, automation
project	ASTGL project documentation
tutorial	Step-by-step how-to guides
comparison	Side-by-side topic analysis
guide	Comprehensive reference material
newsletter	Personal updates and announcements
faq	Primarily Q&A content
concept	Wiki concept pages (only allowlisted pages are public)
entity	Wiki entity pages (only allowlisted pages are public)

Counts change as content is added; call list_topics or list_tags for the current index. draft and synthesis entries exist only in the maintainer database and are removed from the published one. The content_type descriptions in the tool schemas list only the first seven types.

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.

Limits and registrations are enforced by the server process itself: usage and registrations are kept in a local SQLite file (data/query-log.db next to the package, or ASTGL_QUERY_LOG_DB), and anonymous clients get a persistent ID in ~/.astgl-client-id. An ASTGL_API_KEY only counts as registered if it exists in that local registrations table.

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.

Article embeddings are pre-computed and shipped in the npm package, so you never re-index content. Your query is still embedded at runtime through Ollama for the semantic tools (see the requirement above).

The server opens data/knowledge.db when it exists (a maintainer checkout) and otherwise build/knowledge-public.db. The npm package ships only build/knowledge-public.db, which npm run build-public-db produces by physically removing every non-public row (see docs/adr/).

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
`npm run build-public-db`	Write `build/knowledge-public.db` with non-public rows removed (runs in `prepack`)

Other maintainer scripts (draft ingest and reconcile, rewrite queue, wiki sync, backup pruning, dashboard data, MCPB bundle) are listed in package.json.

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
`ASTGL_QUERY_LOG_DB`	`data/query-log.db`	Query log, rate limits and registrations
`ASTGL_CITATION_TEST_DB`	`data/citation-test.db`	Citation test results

Automated Jobs

Job	Schedule	Purpose
Content pipeline	Every 6h	Discover + structure new content
Daily report	8 AM	Query analytics + health metrics (JSON report)
Content alerts	9 AM	Gap detection, zero-citation, competitor scan (JSON report)
Freshness check	10 AM	Stale content + ecosystem version tracking (JSON report)
Draft pipeline	Midnight	Index pre-publication drafts
Wiki sync	00:30	Incremental sync of tagged wiki pages into the index
Draft reconciler	2 AM	Retire draft entries whose source is gone
Citation testing reminder	Mondays 9 AM	Reminder to run citation tests

Schedules are defined in cron/*.json; the scheduled report jobs print JSON that an external scheduler picks up and delivers. Run the report scripts with --discord to post to DISCORD_WEBHOOK_URL instead. macOS launchd plists for the pipeline, draft and wiki jobs are in launchd/.

Architecture

flowchart TD
    Client["MCP client<br/>(Claude, Cursor, ...)"] -->|"stdio"| Server["MCP server<br/>src/index.ts (17 tools)"]
    Server --> RL["Rate limit + query log<br/>data/query-log.db"]
    Server --> Search["src/search.ts"]
    Search -->|"embed query"| Ollama["Ollama<br/>nomic-embed-text"]
    Search -->|"sqlite-vec KNN"| KDB[("knowledge.db<br/>or knowledge-public.db")]
    Sources["astgl.ai RSS / sitemap<br/>+ local markdown"] -->|"discover, structure, ingest"| KDB
    KDB -->|"build-public-db"| Pub[("build/knowledge-public.db<br/>(shipped in npm)")]
    Jobs["Report jobs<br/>daily report, alerts, freshness"] -.->|"--discord (manual)"| Discord["Discord webhook"]

A rendered diagram is in docs/diagrams/mcp-astgl-knowledge.architecture.svg (source: docs/diagrams/mcp-astgl-knowledge.architecture.json).

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

ActivityMaintained

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 2 months ago (2026-08-13 16:07 UTC)
3
13 npm
MIT
moss-brain
Knowledge & Memory Search
Naut1cal5
A
license
Not graded
quality
D
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 3 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 3 months ago (2026-07-28 08:14 UTC)
AGPL 3.0