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 quantum computing"
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 page information including metadata, content preview, and citations summary.
| 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 already declare readOnlyHint, destructiveHint, and idempotentHint. Description adds value by specifying what information is returned (metadata, content preview, citations summary), but lacks details on authentication, rate limits, or response format beyond the 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?
Single sentence with no unnecessary words. Front-loaded with core action and resource, efficiently conveying purpose.
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?
Adequate for a read-only tool with 2 parameters and no output schema. Mentions key elements returned, but omits details about pagination, response structure, or how 'preview' differs from full content. Sibling tools fill gaps, but description alone is minimally complete.
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% and includes descriptions for both parameters. The description does not add additional parameter meaning beyond what is already in the schema, so 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 clearly states verb 'Get' and resource 'page information', listing included facets (metadata, content preview, citations summary). Differentiates from siblings like get_page_citations or get_page_content by offering a comprehensive view.
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?
No explicit guidance on when to use this tool versus alternatives such as get_page_citations or get_page_content. Context is implied but not stated, leaving the AI agent to infer use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the citations list for a specific page.
| 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the description does not contradict them. However, it adds no extra behavioral context (e.g., pagination, ordering, or citation format), which is acceptable for a simple read operation.
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?
The description is a single sentence that conveys the core functionality without extraneous words. It is front-loaded and efficient.
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 tool's simplicity (read-only list, two parameters, no output schema), the description is nearly complete. It might benefit from mentioning that citations are returned in a list, but the overall information is sufficient for an agent.
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 clear descriptions for both 'slug' and 'limit'. The description does not add additional meaning beyond what the schema provides, so baseline score of 3 is appropriate.
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 clearly states the action (Get) and resource (citations list for a specific page). It distinguishes from sibling tools like get_page_content and get_page, making its purpose unambiguous.
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?
The description provides no guidance on when to use this tool versus alternatives, such as when to choose get_page_citations over search or get_page_sections. No exclusions or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get only the article content without citations or metadata.
| 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?
Annotations already indicate read-only, non-destructive, idempotent behavior. The description adds behavioral context by specifying that citations and metadata are excluded, going beyond what annotations provide.
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?
The description is a single, concise sentence that delivers the key purpose without any wasted words. It is front-loaded and efficient.
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 presence of annotations and full schema coverage, the description is largely complete for this simple retrieval tool. It could optionally mention output format, but the absence is not critical.
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?
The input schema covers all parameters with descriptions (100% coverage). The description does not add any additional meaning or context beyond what the schema already provides.
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 clearly states the tool retrieves 'only the article content without citations or metadata', using a specific verb and resource. It distinguishes itself from siblings like 'get_page_citations' and 'get_page'.
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?
The description implies usage when only content is needed, but does not explicitly state when to use this tool versus alternatives, nor provides any exclusions or context for when not to use it.
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 an article by header name.
| 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 already indicate read-only, non-destructive, and idempotent behavior. The description adds no additional behavioral context beyond what is in the schema (e.g., case-insensitivity is noted in schema parameter description, not the main description). Thus, it adds minimal value beyond 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?
The description is a single, front-loaded sentence with no unnecessary words. It is efficient and to the point.
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 tool's simplicity (3 parameters, no output schema), the description is adequate but minimal. It does not mention output format or error handling for missing sections, which could be useful but is not critical for basic usage.
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%, so the parameter descriptions already define slug, section_header, and max_length. The main description does not add new semantic information beyond the schema.
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 clearly states the action (extract), resource (specific section from an article), and method (by header name). It distinguishes from sibling tools like get_page (whole page) and get_page_sections (multiple 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?
The description implies usage when a specific section is needed by header name, but it does not explicitly state when to use this tool versus alternatives like get_page_sections or search. No 'when not to use' guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a list of all section headers in an article.
| 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 declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safe, non-destructive behavior is clear. The description adds the output context ('section headers') but no additional behavioral details (e.g., ordering, pagination). Given strong annotations, this is adequate.
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?
A single, front-loaded sentence that efficiently conveys the tool's purpose without redundancy. Every word adds value.
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 list tool with one required parameter and strong annotations, the description is sufficient to convey what the tool does and returns. It doesn't document edge cases or output format, but the tool's simplicity reduces the need for more.
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?
The schema provides full description for the single 'slug' parameter (100% coverage). The description adds that the tool lists 'all section headers', implying the output but not adding extra parameter semantics. Baseline is met.
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 clearly states the tool retrieves 'all section headers in an article', with a specific verb ('Get'), resource ('section headers'), and context ('in an article'). It distinguishes from sibling tools like 'get_page_section' (singular) and 'get_page_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?
The description implies usage for listing section headers but provides no explicit guidance on when to use this tool versus alternatives like 'get_page_section' or 'get_page_content'. No when-not-to-use or pre-conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for articles in Grokipedia with optional filtering and sorting.
| 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 readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the description adds little beyond the existing filtering/sorting context. It does not mention pagination, result format, or any other behavioral traits.
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?
The description is a single, concise sentence that efficiently communicates the tool's core function with no unnecessary words.
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 100% schema coverage and annotations, the description is adequate but could optionally note that it returns a list of matching articles. It is not incomplete for its purpose.
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%, meaning the input schema already explains all parameters. The description offers no additional meaning beyond what's in the schema.
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 clearly states the tool searches for articles in Grokipedia with optional filtering and sorting, distinguishing it from siblings that retrieve specific page details.
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?
The description implies usage for searching across articles but does not explicitly state when to use versus siblings like get_page or get_related_pages, nor does it provide when-not or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.2.2get_pageget_page_citationsget_page_contentget_page_sectionget_page_sectionsget_related_pagessearchEach tool targets a distinct aspect of Grokipedia pages or search, with no overlapping functionality. Tools like get_page, get_page_content, get_page_sections clearly separate page information.
All tools except 'search' use the 'get_' prefix consistently for retrieval operations. 'search' is a minor deviation but is a common and clear verb for that purpose.
With 7 tools, the set is well-scoped for a wiki knowledge base, covering retrieval of pages, content, sections, citations, related pages, and search without being overwhelming.
The tool set provides comprehensive read access to Grokipedia pages, including metadata, content, sections, citations, and search. Missing write operations, but that may be intentional for a read-only server.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Web search, scraping, RAG answers with citations, and translation as MCP tools.
Search a billion+ documents — papers, books, code, legal cases, forums, Wikipedia, and more.
Citable retrieval across papers, books, patents, Wikipedia, and live social sources.
Web search, URL content extraction to Markdown, site mapping, and recursive web crawler.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/fastmcp-me/grokipedia-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
