Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Grokipedia MCP Server search for the history of Neural Networks"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for searching and retrieving content from Grokipedia
The User of the MCP assumes full responsibility for interacting with Grokipedia.
Please see the Xai Terms of Service if you have any doubts.
Elon, please don't sue me. I only wanted my agents to have access to truthful information and stop referencing wikipedia all the time.
Add this to your MCP configuration file:
{
"mcpServers": {
"grokipedia": {
"command": "uvx",
"args": ["grokipedia-mcp"]
}
}
}You should see the Grokipedia server available with these tools:
search - Search with filters
get_page - Get page overview
get_page_content - Get full content
get_page_citations - Get citations
get_related_pages - Get linked pages
get_page_sections - List all section headers
get_page_section - Extract specific sections
And these prompts:
research_topic - Research workflow
find_sources - Find citations
explore_related - Explore connections
compare_topics - Compare two topics
Related MCP server: Grokipedia MCP Server
Search with Filters: Search with sorting (relevance/views) and filtering (min views)
Page Content: Retrieve articles, citations, and metadata with smart truncation
Related Pages: Discover linked/related articles
Section Extraction: Get specific sections from long articles
Smart Suggestions: Helpful alternatives when pages aren't found
Guided Prompts: Pre-built workflows for research, sources, exploration
Using uv:
cd grokipedia-mcp
uv syncFor development with MCP Inspector and CLI tools:
uv sync --devThe fastest way to test and debug (requires dev dependencies):
uv run --dev mcp dev main.pyThis launches the MCP Inspector UI where you can:
Explore available tools
Test search queries
Retrieve page content
View structured output
# Using the installed entry point
uv run grokipedia-mcp
# Or as a Python module
uv run python -m grokipedia_mcp
# Or directly
uv run python main.pysearchSearch for articles in Grokipedia with filtering and sorting options.
Parameters:
query (string, required) - Search query
limit (int, optional, default: 12) - Maximum number of results
offset (int, optional, default: 0) - Pagination offset
sort_by (string, optional, default: "relevance") - Sort by "relevance" or "views"
min_views (int, optional) - Filter to articles with at least this many views
Returns: List of search results with title, slug, snippet, relevance score, and view count.
Examples:
// Basic search
{"query": "machine learning", "limit": 5}
// Sort by most viewed
{"query": "python", "sort_by": "views"}
// Filter popular articles only
{"query": "artificial intelligence", "min_views": 1000}get_pageGet complete page information including metadata, content preview, and citations summary. Includes smart suggestion of alternatives if page not found.
Parameters:
slug (string, required) - Article identifier (from search results)
max_content_length (int, optional, default: 5000) - Maximum content length
Returns: Complete page object with metadata, truncated content, and citation summaries.
Features:
Suggests similar pages if the requested slug doesn't exist
Provides overview with content preview and citations
Use this when: You need an overview of a page with metadata and a content preview.
Example:
{"slug": "Machine_learning"}get_page_contentGet only the article content without citations or metadata.
Parameters:
slug (string, required) - Article identifier
max_length (int, optional, default: 10000) - Maximum content length
Returns: Only the article content (title and content text).
Use this when: You need to read the full article content without citations.
Example:
{"slug": "Machine_learning", "max_length": 15000}get_page_citationsGet the citations list for a specific page.
Parameters:
slug (string, required) - Article identifier
limit (int, optional) - Maximum number of citations to return (returns all if not specified)
Returns: List of citations with titles, URLs, and descriptions. Includes total count and returned count.
Use this when: You need to access source references and citations.
Examples:
// Get all citations
{"slug": "Machine_learning"}
// Get first 10 citations only
{"slug": "Machine_learning", "limit": 10}get_related_pagesGet pages that are linked from a specific article.
Parameters:
slug (string, required) - Article identifier
limit (int, optional, default: 10) - Maximum number of related pages to return
Returns: List of related/linked pages with titles and slugs.
Use this when: You want to discover related topics or explore connections between articles.
Examples:
// Get related pages
{"slug": "Machine_learning"}
// Get more related pages
{"slug": "Quantum_computing", "limit": 20}get_page_sectionsGet a list of all section headers in an article.
Parameters:
slug (string, required) - Article identifier
Returns: List of all section headers with their levels (h1, h2, h3, etc.).
Use this when: You want to see the structure/outline of an article before reading specific sections.
Example:
{"slug": "Machine_learning"}get_page_sectionExtract a specific section from an article by header name.
Parameters:
slug (string, required) - Article identifier
section_header (string, required) - Section header to extract (case-insensitive)
max_length (int, optional, default: 5000) - Maximum section content length
Returns: Content of the specified section only.
Use this when: You need just one section of a long article (e.g., "Applications", "History", "Examples").
Examples:
// Get specific section
{"slug": "Neural_networks", "section_header": "Applications"}
// Get longer section
{"slug": "Python", "section_header": "Syntax", "max_length": 10000}Note: Articles can be 100,000+ characters. Content is automatically truncated to prevent overwhelming LLM context windows. Use the max_length parameters to control the amount returned.
The server provides pre-built prompts for common workflows:
research_topicGuided workflow to research a topic: search → retrieve → analyze related pages and citations
find_sourcesFind authoritative sources and citations for academic/research purposes
explore_relatedDiscover connections between topics and suggested further reading
compare_topicsCompare two topics side-by-side with their content and citations
The server uses:
FastMCP for declarative MCP server implementation
grokipedia-api-sdk AsyncClient for API communication
Lifespan context for client connection management
Structured output using Pydantic models from the SDK
Comprehensive error handling with specific exception types
The server handles various error scenarios:
ValueError for invalid parameters or not found pages
RuntimeError for network or API errors
Detailed logging at debug, info, warning, and error levels
grokipedia-mcp/
├── grokipedia_mcp/
│ ├── __init__.py # Package exports
│ ├── __main__.py # CLI entry point
│ └── server.py # FastMCP server implementation
├── main.py # Direct execution entry point
├── pyproject.toml # Project configuration
└── README.md # This fileUse the MCP Inspector for interactive testing:
uv run mcp dev main.pyMIT
Get complete Grokipedia page with metadata, content preview, and citations.
Use for: reading articles, getting overviews, checking citations and sources. Returns: title, description, content preview (truncated), citations list. Tips: Use get_page_content for full untruncated content. Slug comes from search results.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Unique slug identifier of the page to retrieve | |
| max_content_length | No | Maximum length of content to return (default: 5000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnly/idempotent/destructive profile. Description adds crucial behavioral context: content is 'truncated' (distinguishing from full content sibling) and specifies exact return fields (title, description, citations list). Could enhance with rate limit or caching notes, but adequately supplements annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Efficiently structured with clear sections (implied purpose, Use for, Returns, Tips). Zero redundancy; every line provides actionable guidance. Front-loads core purpose in first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter read operation without output schema, description comprehensively documents return structure and differentiates from 5 sibling tools. No gaps given tool complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage documenting both slug and max_content_length. Description adds semantic value by specifying 'Slug comes from search results'—guidance not present in schema about parameter provenance—exceeding baseline expectations for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with specific verb+resource ('Get complete Grokipedia page') and explicitly scopes the operation to 'metadata, content preview, and citations'. Clearly distinguishes from sibling get_page_content by noting this returns truncated preview content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'Use for' section listing appropriate contexts (reading articles, overviews, checking citations). Names specific alternative 'Use get_page_content for full untruncated content' and notes prerequisite 'Slug comes from search results'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the source citations for a Grokipedia article.
Use for: finding source materials, verifying claims, academic research, fact-checking. Returns: list of citations with title, URL, and description. Tips: Great for grounding AI-generated knowledge with original sources.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Unique slug identifier of page to retrieve citations from | |
| limit | No | Maximum number of citations to return (optional, returns all if not specified) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no output schema exists, the description valuably documents the return structure ('list of citations with title, URL, and description'). The 'Tips' section adds context about grounding AI knowledge. Does not contradict annotations (readOnlyHint=true aligns with 'Get').
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Excellent structure with clear section headers ('Use for:', 'Returns:', 'Tips:'). Information is front-loaded with the core purpose, and every sentence provides distinct value (use cases, return format, usage tips) without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter read-only tool, the description is complete. It compensates for the missing output schema by detailing the return format, leverages annotations for safety profile, and provides sufficient context for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with slug and limit fully documented in the schema. The description does not add parameter-specific guidance, which is acceptable given the schema completeness—baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with specific verb ('Get') and resource ('source citations for a Grokipedia article'), clearly distinguishing this from siblings like get_page or get_page_content which retrieve article content rather than bibliographic sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'Use for' section listing specific scenarios (verifying claims, academic research, fact-checking), offering strong positive guidance. Lacks explicit 'when not to use' or named sibling alternatives, though the specific use cases effectively imply the boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full article content from Grokipedia (larger than get_page preview).
Use for: reading complete articles, comprehensive research, when you need all content. Returns: title, full content (up to max_length), content_length. Tips: Set max_length higher for very long articles. Returns raw markdown.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Unique slug identifier of the page to retrieve content from | |
| max_length | No | Maximum length of content to return (default: 10000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations confirm read-only/idempotent status, the description adds crucial behavioral context: it discloses the return structure (title, full content, content_length), format (raw markdown), and operational tip about adjusting max_length for long articles—essential given the lack of an output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Uses an efficient structured format (main description, Use for, Returns, Tips) with zero filler. Every sentence conveys distinct information about scope, usage, output, or configuration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, the description comprehensively documents return values and format. Combined with complete schema coverage and clear sibling differentiation, it provides sufficient context for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage establishing a baseline of 3, the description adds meaningful usage semantics for max_length by advising to 'set max_length higher for very long articles' and explaining its effect on returned content ('up to max_length').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource combination ('Get full article content from Grokipedia') and immediately distinguishes itself from the sibling tool get_page by noting it returns 'larger than get_page preview,' clearly establishing its scope relative to alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'Use for' section listing specific scenarios (reading complete articles, comprehensive research). Implicitly contrasts with get_page via size comparison, though it stops short of explicitly stating 'use get_page instead for previews.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract a specific section from a Grokipedia article by header name.
Use for: focusing on particular aspects of a topic (e.g., 'History', 'Applications'). Returns: section header and content. Tips: Use get_page_sections first to discover available section headers.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Unique slug identifier of page to extract section from | |
| section_header | Yes | Exact header text of the section to extract (case-insensitive) | |
| max_length | No | Maximum length of section content to return (default: 5000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnly/idempotent/non-destructive properties. Description adds valuable behavioral context: return format ('section header and content') and operational workflow (discovery prerequisite). No contradictions with annotations; 'Extract' aligns with readOnlyHint=true.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely efficient structure using labeled clauses (Use for:, Returns:, Tips:). Every sentence earns its place—no filler. Front-loaded with core purpose, followed by usage context and workflow tip. Optimal length for quick agent comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but description compensates by stating return format ('section header and content'). Workflow guidance (use get_page_sections first) provides necessary operational context. Lacks error handling documentation (e.g., section not found), but adequately complete given schema richness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with complete property descriptions. Description enhances semantics by providing concrete example values for section_header ('History', 'Applications') that clarify expected input format beyond the schema's generic 'Exact header text' description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states specific action ('Extract') + resource ('section from a Grokipedia article') + mechanism ('by header name'). It clearly distinguishes from sibling 'get_page_sections' by targeting a specific section rather than listing all sections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('focusing on particular aspects of a topic') and provides concrete examples ('History', 'Applications'). Critically, it names the sibling alternative 'get_page_sections' with specific instruction to use it first, establishing clear workflow precedence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the table of contents (all section headers) for a Grokipedia article.
Use for: understanding article structure, finding which sections exist. Returns: list of sections with level (1=H1, 2=H2, etc.) and header text. Tips: Call before get_page_section to find valid section headers.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Unique slug identifier of page to list sections for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety profile (readOnly, idempotent, non-destructive). The description adds valuable behavioral context by describing the return value structure ('list of sections with level (1=H1, 2=H2, etc.) and header text') which compensates for the missing output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Excellent structure with clear semantic sections ('Use for:', 'Returns:', 'Tips:'). Information is front-loaded with the core purpose in the first sentence. No redundant or wasteful text; every line provides actionable guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool with complete schema coverage and safety annotations, the description is comprehensive. It explains the output format (despite no output schema), clarifies relationships to sibling tools, and provides workflow guidance. No significant gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage for the 'slug' parameter ('Unique slug identifier of page to list sections for'). The description does not add additional parameter semantics, meeting the baseline expectation when schema documentation is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with specific verb 'Get' and clear resource 'table of contents (all section headers) for a Grokipedia article'. It effectively distinguishes from siblings like get_page_content (full text) and get_page_section (single section) by emphasizing it retrieves ALL headers/structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'Use for:' scenarios (understanding structure, finding sections) and critically includes 'Tips: Call before get_page_section to find valid section headers' - directly naming a sibling tool and establishing the correct workflow sequence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Grokipedia (AI-curated knowledge base) for articles.
Use for: finding Grok-generated articles, discovering AI-synthesized knowledge, research. Returns: title, slug (for get_page), snippet, relevance score, view count. Tips: Use the slug from results with get_page/get_page_content for full articles.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query string to find matching articles | |
| limit | No | Maximum number of results to return (default: 12, max: 50) | |
| offset | No | Pagination offset for results (default: 0) | |
| sort_by | No | Sort results by 'relevance' or 'views' (default: relevance) | relevance |
| min_views | No | Filter to articles with at least this many views (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive traits. The description adds valuable behavioral context by documenting return fields ('title, slug, snippet, relevance score, view count') and data relationships (slug is specifically 'for get_page'), compensating for the missing output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Excellent structure with clear visual scanning cues ('Use for:', 'Returns:', 'Tips:'). Every sentence earns its place—no redundancy with structured fields. Front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive given the tool complexity. Despite no output schema, the description documents return values. Combined with 100% input schema coverage and strong annotations, the description provides sufficient context for correct invocation and result handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is appropriately 3. The description does not add parameter-specific semantics beyond what's in the schema (e.g., no syntax examples or query formatting tips), but references 'relevance' and 'view count' which map to sort_by options.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Search') and clear resource ('Grokipedia'), distinguishing it from sibling 'get_page' tools that retrieve specific content. The parenthetical '(AI-curated knowledge base)' adds essential context about the data source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists use cases ('finding Grok-generated articles, discovering AI-synthesized knowledge, research') and provides a specific workflow tip linking to siblings ('Use the slug from results with get_page/get_page_content'). This clearly establishes when to use search vs. retrieval tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tools are mostly distinct with clear purposes, though `get_page` overlaps functionally with `get_page_content` (preview vs full) and `get_page_citations` by including citations in its response. Descriptions clarify these distinctions, but an agent might initially hesitate between the general getter and specialized ones.
Strong snake_case convention with consistent `get_page_*` pattern for article-specific operations. Minor deviations with `search` (lacks `get_` prefix) and `get_related_pages` (uses `related` instead of `page_related`), but overall readable and predictable.
Seven tools is well-scoped for a read-only encyclopedia server. The set efficiently covers discovery (search), retrieval granularity (full page, content only, section only, sections list), verification (citations), and navigation (related pages) without bloat.
Comprehensive coverage for accessing Grokipedia articles with good traversal support (search → get → related). Minor gap: no dedicated metadata-only endpoint (though `get_page` provides it alongside preview content). No write operations, which appears intentional for this domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Citable retrieval across papers, books, patents, Wikipedia, and live social sources.
Search a billion+ documents — papers, books, code, legal cases, forums, Wikipedia, and more.
Search arXiv and ACL Anthology, retrieve citations and references, and browse web sources to accel…
Web search, fetch, extract, and research for AI agents. Markdown output + AI-synthesized answers.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/TheOneTrueNiz/mcp-grokipedia-tool'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
