What can you do with this server?

This server provides structured, read-only access to the Sovereign AI Blog — an engineering log focused on self-hosted AI on NVIDIA DGX Spark (GB10/SM121A) hardware — enabling AI agents to retrieve verified technical content instead of relying on stale training data. * Search articles (search_blog): Full-text TF-IDF search across 60+ articles with optional tag filtering, sorting by relevance or date, and configurable result count. An empty query returns the newest articles. * List tags (list_tags): Retrieve all topic tags with article counts, sortable by frequency or alphabetically — useful for exploring the content space before a filtered search. * Fetch full article (get_article): Retrieve a complete article by slug, including Markdown body, metadata (title, description, tags, publication date, word count), and editorial quality signals. * Diagnose SGLang configs (diagnose_sglang): Pattern-match SGLang runtime errors and config parameters against a curated rule set for GB10/SM121A hardware. Returns critical issues, warnings, a recommended baseline config, and links to relevant articles. Topics covered: SGLang/vLLM patches for GB10, KV-cache and quantization tradeoffs, Voxtral and TTS pipelines on ARM64, podcast-grade audio generation, MCP server design, and self-hosted AI operations.

de en es ja ko ru zh

Sovereign AI Blog

by cipherfoxie

Overview Schema Related Servers Score Discussions

Python

Hybrid

Sovereign AI MCP

License: MIT Content: CC BY-SA 4.0 MCP Registry Glama MCP server Write-up

MCP server exposing the Sovereign AI Blog to AI agents. The blog is a hands-on engineering log of self-hosted AI on NVIDIA DGX Spark (GB10/SM121A).

Live endpoint: https://mcp.sovgrid.org/self-hosted-ai Transport: Streamable HTTP (FastMCP) Auth: none (free tier, 60 req/min/IP)

Why use it

Training data on niche hardware (GB10, SM121A, SGLang on ARM64) is sparse and stale. This MCP gives agents direct, structured access to 60+ articles documenting actual setups, fixes, and benchmarks. If you're building or debugging on similar stacks, your agent can pull verified, version-current information instead of hallucinating.

The corpus covers SGLang and vLLM patches for GB10, voxtral and TTS pipelines on ARM64, KV-cache and quantization tradeoffs, podcast-grade audio generation, MCP server design, knowledge-base construction, and the operational side of running it all on a hardened European VPS.

Related MCP server: mcp-astgl-knowledge

Tools

Tool	Purpose
`search_blog(query, tag?, sort?, n?)`	TF-IDF full-text search. Optional `tag` filter, `sort` by relevance or `date_desc`. Empty `query` lists newest articles. Returns ranked `SearchResult` items with quality score, style, slug, and excerpt.
`list_tags(sort?)`	List all topic tags across the corpus with article counts. Sort by `count_desc` (default) or `alpha`. Use to discover the topic space before filtering `search_blog`.
`get_article(slug)`	Fetch full article body and frontmatter by slug. Returns markdown content plus tags, quality score, publish date.
`diagnose_sglang(error_message)`	Pattern-match a runtime error against a curated rule set for SGLang on GB10/SM121A. Returns matched fixes with links to setup articles.

All tools are read-only, idempotent, and declared with ToolAnnotations so MCP clients can calibrate retry policy and trust signals. Inputs use Pydantic Annotated[type, Field(description=...)] so parameter docs reach agents through introspection. Outputs are typed BaseModel shapes — schemas are real, not vacuous dicts.

Quick start

With Claude Code

claude mcp add sovereign-ai --transport http https://mcp.sovgrid.org/self-hosted-ai

Verify:

claude mcp list | grep sovereign-ai

With Cline / Continue / other MCP clients

Add to your client's MCP server config:

{
  "sovereign-ai": {
    "type": "http",
    "url": "https://mcp.sovgrid.org/self-hosted-ai"
  }
}

Run locally

From source (uv)

git clone https://github.com/cipherfoxie/sovereign-mcp.git
cd sovereign-mcp
uv sync
uv run uvicorn src.main:app --host 127.0.0.1 --port 8002

Docker

git clone https://github.com/cipherfoxie/sovereign-mcp.git
cd sovereign-mcp
docker build -t sovereign-mcp .
docker run -p 8002:8002 sovereign-mcp

The repo ships a placeholder data/knowledge-base.json (zero articles, valid schema) so the server starts and answers MCP introspection cleanly out-of-the-box. To populate it with real content, generate from the sovgrid.org blog source using scripts/generate_knowledge_base.py, or build your own KB matching the schema in src/knowledge.py. Or just use the live endpoint at https://mcp.sovgrid.org/self-hosted-ai.

A walk-through of the same KB pattern (Markdown plus JSON index, no vector store) is documented in Build a Self-Hosted Knowledge Base with Plain Text and LLMs.

Architecture

FastMCP 1.27+ with Streamable HTTP transport at path /self-hosted-ai
DNS rebinding protection via TransportSecuritySettings: only allows requests with Host: mcp.sovgrid.org (or localhost for healthchecks)
Health endpoint at /health returns article count and KB generation timestamp
Knowledge base is a flat JSON file generated from blog Markdown content; loaded at startup, queried via TF-IDF for search_blog

The server is stateless. All blog content is already public (CC BY-SA 4.0). No PII, no auth tokens, no secrets.

Operations

Live deployment runs on a privacy-focused European VPS via Docker, fronted by Caddy with TLS. Server logs flow into a privacy-respecting analytics pipeline (Caddy JSON access logs, no client-side tracking, no JS pixels).

License

Server code: MIT, see LICENSE
Blog content (returned by tools): CC BY-SA 4.0, see creativecommons.org/licenses/by-sa/4.0/

Contact

Blog: sovgrid.org
Nostr: cipherfox@sovgrid.org (NIP-05) — npub1ndrjgfcwkc0y4753zyj3p7qjf795pvjq2dn4m7y7f72vmu7t0nrs6y363u
Bug reports / questions: open an issue

Available Tools

4 tools

diagnose_sglangA

Read-onlyIdempotent

Inspect

Validate an SGLang configuration for NVIDIA DGX Spark (GB10/SM121A).

Pure pattern-matching against known failure modes documented in the Sovereign AI Blog. No inference, no external calls. Returns critical issues, non-fatal warnings, and a recommended baseline config.

All parameters are optional; supply only what you have. With no inputs you get the recommended config and a 'unknown' verdict.

ParametersJSON Schema

Name	Required	Description
`attention_backend`	No	SGLang --attention-backend value (e.g. 'flashinfer', 'triton'). Empty string = skip this check.
`mem_fraction`	No	SGLang --mem-fraction-static value (e.g. 0.88). 0.0 = skip this check.
`cuda_graph_max_bs`	No	SGLang --cuda-graph-max-bs value. 0 = skip this check.
`image_tag`	No	Docker image tag in use (e.g. 'lmsysorg/sglang:latest', 'lmsysorg/sglang:v0.4.0'). Empty = skip.
`hardware`	No	Hardware description (e.g. 'GB10', 'DGX Spark', 'SM121A'). Empty = skip GB10-specific rules.
`error_message`	No	Paste error log output here for pattern matching against known failure modes.

Output Schema

ParametersJSON Schema

Name	Required	Description
`issues`	Yes	Critical issues that will prevent SGLang from running correctly
`warnings`	Yes	Non-fatal warnings (suboptimal but non-blocking)
`recommended_config`	Yes	Verified-good baseline config for GB10/SM121A
`verdict`	Yes	Overall verdict. 'unknown' = no inputs provided.

TDQS

A4.5/5.0

Behavior4/5

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

Annotations declare readOnlyHint and idempotentHint. The description adds that it is 'pure pattern-matching, no inference, no external calls', and details the output structure (critical issues, warnings, recommended config). This goes beyond the annotations.

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

Conciseness5/5

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

The description is compact, front-loaded, and every sentence adds value. Two paragraphs with no wasted words.

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

Completeness5/5

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

Given 6 optional parameters and an output schema (not shown but noted), the description explains purpose, behavior, and output structure comprehensively. It also states when to use (with any available config info) and the 'no inputs' case.

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?

Schema coverage is 100% and parameter descriptions are adequate. The description reinforces that parameters are optional and how default values affect behavior (skip check), which adds value beyond the schema.

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

Purpose5/5

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

The description clearly states the tool validates an SGLang configuration for a specific hardware (NVIDIA DGX Spark). It distinguishes itself from sibling tools (get_article, list_tags, search_blog) which are unrelated.

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

Usage Guidelines4/5

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

The description explains that all parameters are optional, to supply only what you have, and that with no inputs it returns a recommended config and 'unknown' verdict. It does not explicitly discuss when not to use, but the sibling tools are unrelated so context is clear.

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

get_articleA

Read-onlyIdempotent

Inspect

Retrieve the full content of a blog article by its slug.

Returns the article body (Markdown) plus metadata. If the slug does not match any article, returns an Article with error='article_not_found' and other fields at their defaults.

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes	Article slug as returned by search_blog (e.g. 'setup-mistral-sglang-setup'). Lower-case, hyphenated.

Output Schema

ParametersJSON Schema

Name	Required	Description
`slug`	Yes	Article slug
`title`	No	Article title
`url`	No	Public URL of the article
`date`	No	Publication date (ISO 8601)
`tags`	No	Topic tags assigned to the article
`description`	No	Short article description
`body`	No	Full article body in Markdown
`quality_score`	No	Build-time quality score from the editorial pipeline (unbounded weighted composite across 13 signals, higher is better; thresholds depend on style)
`quality_style`	No	Editorial style category (e.g. 'best_practice_learnings', 'werthaltige_code_beispiele'). Empty if not categorised.
`quality_class`	No	Editorial content class (e.g. 'Ephemeral', 'Evergreen'). Empty if not classified.
`word_count`	No	Word count of the article body
`error`	No	Set to 'article_not_found' if no article matches the slug

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already declare readOnlyHint and idempotentHint true. The description adds the error behavior (returns article with error field on missing slug) and the return content structure (Markdown body plus metadata). This provides additional useful behavioral context beyond the annotations.

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

Conciseness5/5

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

The description is concise: two sentences. The first states the primary purpose, the second covers return type and error case. No redundant or extra information. Every word contributes.

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

Completeness4/5

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

Given the simple nature of the tool (one parameter, no nested objects, output schema exists), the description adequately covers retrieval and error handling. Missing discussion of authentication or rate limits, but these are not critical for this read-only, idempotent tool. Overall complete enough.

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?

Schema coverage is 100% with a detailed parameter description. The tool description does not add new information about the slug parameter beyond what the schema already provides. Baseline score of 3 is appropriate for this case.

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

Purpose5/5

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

The description clearly states the verb 'retrieve', the resource 'blog article', and the key parameter 'slug'. It distinguishes from sibling tools like 'search_blog' by focusing on full content retrieval. The purpose is specific and unambiguous.

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

Usage Guidelines4/5

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

The description indicates when to use the tool (to get full article content by slug). It implicitly guides usage after search_blog via the parameter description. However, it lacks explicit when-not or alternative tool references, which would elevate it to 5.

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

list_tagsA

Read-onlyIdempotent

Inspect

List all topic tags used across the Sovereign AI Blog corpus, with article counts. Use this to browse the topic space before calling search_blog with a tag filter.

ParametersJSON Schema

Name	Required	Description	Default
`sort`	No	Result ordering. 'count_desc' lists most-used tags first (default). 'alpha' sorts alphabetically.	count_desc

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior3/5

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

Annotations already declare readOnlyHint true and idempotentHint true, so description need not repeat. Description adds article counts behavior but no further traits. No contradiction.

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

Conciseness5/5

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

Two sentences with zero wasted words. Front-loaded with purpose, efficient structure.

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

Completeness5/5

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

Combined with output schema and annotations, description provides sufficient context: specifies corpus, indicates output includes counts, and links to sibling. No gaps.

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?

Schema covers 100% of parameters with description, and the tool description adds no extra parameter details beyond what schema provides. Baseline 3 is appropriate.

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

Purpose5/5

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

Clearly states it lists all topic tags with article counts, specifying the corpus ('Sovereign AI Blog') and linking to sibling tool. Verb+resource+scope are explicit.

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

Usage Guidelines4/5

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

Explicitly suggests using before calling search_blog with a tag filter, providing clear use context. No exclusion or when-not-to, but sufficient guidance for selection.

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

search_blogA

Read-onlyIdempotent

Inspect

Search the Sovereign AI Blog for articles matching a natural language query, optionally filtered by tag and sorted by relevance or date.

Behaviour matrix:

query='', sort=* -> list newest-first, optionally tag-filtered
query!='', sort=relevance -> TF-IDF ranked, optionally tag-filtered
query!='', sort=date_desc -> TF-IDF filtered (score > 0.001), then sorted by date

Pure read-only, deterministic for a given KB snapshot.

ParametersJSON Schema

Name	Required	Description	Default
`query`	No	Natural language search query (e.g. 'flashinfer OOM on GB10'). Multi-word queries are tokenized and TF-IDF ranked. Pass empty string to list articles without ranking by relevance.
`tag`	No	Optional tag filter (e.g. 'setup', 'fixes', 'strategy'). Only articles with this tag are considered. Use list_tags to discover available tags.
`sort`	No	Result ordering. 'relevance' uses TF-IDF score (default for non-empty query). 'date_desc' sorts newest first (default behaviour when query is empty). When query is empty, 'relevance' is treated as 'date_desc'.	relevance
`n`	No	Maximum number of results to return

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.6/5.0

Behavior5/5

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

The description goes beyond annotations (readOnlyHint, idempotentHint) by detailing the TF-IDF ranking mechanism, a scoring threshold (0.001), determinism for a given knowledge base snapshot, and the behavior matrix. It clearly states the tool is pure read-only.

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

Conciseness5/5

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

The description is concise and well-structured: a one-line summary, followed by a behavior matrix table. Every sentence adds value, and there is no redundancy.

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

Completeness4/5

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

Given the moderate complexity, full schema coverage, and presence of an output schema, the description covers all necessary behavioral aspects (filtering, sorting, default behaviors). It could optionally mention result format or pagination, but the output schema presumably handles that.

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?

With 100% schema coverage, baseline is 3. The description adds significant value by explaining how query, sort, and tag interact (e.g., empty query defaults to date_desc, non-empty query uses relevance, etc.), which is not captured in the parameter descriptions alone.

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

Purpose5/5

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

The description clearly states that the tool searches the Sovereign AI Blog for articles matching a natural language query, with optional tag filtering and sorting. It distinguishes itself from sibling tools like list_tags (which discovers tags) and get_article (which retrieves a specific article), and the unrelated diagnose_sglang.

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

Usage Guidelines4/5

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

The description provides a 'Behaviour matrix' that explains how different parameter combinations behave, giving implicit usage guidance. It also explicitly suggests using list_tags to discover available tags. However, it does not directly compare when to use this tool versus get_article or diagnose_sglang.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.5/5.0

Disambiguation5/5

Each tool has a well-defined, distinct purpose: diagnosing SGLang configs, retrieving blog articles, listing tags, and searching. No overlaps.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case (diagnose_sglang, get_article, list_tags, search_blog).

Tool Count5/5

With 4 tools, the count is well within the ideal 3-15 range and is proportionate to the server's focused blog+diagnostic scope.

Completeness5/5

The blog domain is fully covered: searching, retrieving specific articles, and browsing tags. The diagnostic tool adds auxiliary functionality without creating gaps.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

supportsheep
io.github.pooriaarab
Remote MCP server for supportsheep: run AI interviews and manage support content for your blog.
Customer Support Content Management Systems Marketing
1
UnifAPI
com.unifapi
Hosted MCP server for live public-data APIs and Skills for AI agents.
Open Data Search AI & Machine Learning
2
Reasoning Commons
io.github.chenyuan35
AI Reasoning Cache & Consensus Layer with 11 MCP tools via Streamable HTTP.
AI & Machine Learning Knowledge & Memory Autonomous Agents
2
pocket-agent-mcp A
io.github.cwhited26
Pocket Agent (aipocketagent.com) MCP server — read tools for personas, apps, and product info.
Agent Orchestration AI & Machine Learning
411

Related MCP Servers

agent-zone-mcp
Agent Orchestration Developer Tools RAG Systems
statherm
A
license
Not graded
quality
C
maintenance
MCP server for Agent Zone — vendor-neutral infrastructure knowledge, K8s validation, and execution templates for AI agents. 200+ articles, 10 tools, no API key required.
Updated 6 months ago (2026-02-26 06:36 UTC)
15
MIT
mcp-astgl-knowledge
Search RAG Systems Documentation Access
Jmeg8r
A
license
B
quality
B
maintenance
MCP server for searching and citing ASTGL (As The Geek Learns) articles about MCP servers, local AI, and AI automation. Provides semantic search, direct Q\&A, and topic browsing across 20 authoritative articles with pre-computed embeddings.
Updated 22 days ago (2026-08-12 15:53 UTC)
3
165
MIT
mcp-nvidia
Search RAG Systems Documentation Access
bharatr21
A
license
A
quality
C
maintenance
MCP server to search across NVIDIA blogs and releases to empower LLMs to better answer NVIDIA-specific queries.
Updated 4 months ago (2026-05-02 21:34 UTC)
2
37
1
MIT
hidrix-tools
Search Web Scraping Social Media
sonpiaz
A
license
Not graded
quality
F
maintenance
MCP tool server that gives any AI agent the ability to search, scrape, and analyze content across the internet.
Updated 4 months ago (2026-04-23 20:41 UTC)
43
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/cipherfoxie/sovereign-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server