Wikipedia MCP Server
Provides capabilities to search for keywords and fetch specific page content from Wikipedia, allowing AI models to retrieve information and context from the online encyclopedia.
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., "@Wikipedia MCP Serversearch for the history of the Apollo 11 mission"
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.
Wikipedia MCP Server
A Model Context Protocol server that provides capabilities to query Wikipedia. This server enables LLMs to get information from Wikipedia.
Available Tools
search- Searchkeywordon Wikipedia.Required arguments:
keyword(string): The search keywordlanguage(string): The language
fetch- Fetch Wikipedia page content.Required arguments:
id(integer): The pade IDlanguage(string): The language
Related MCP server: Wikipedia MCP Server
Installation
Using uv (recommended)
When using uv no specific installation is needed. We will
use uvx to directly run wikipedia-mcp.
Using PIP
Alternatively you can install wikipedia-mcp via pip:
pip install wikipedia-mcp-serverAfter installation, you can run it as a script using:
python -m wikipedia_mcpConfigurations
Using uvx
{
"mcpServers": {
"wikipedia-mcp": {
"command": "uvx",
"args": [
"wikipedia-mcp-server@latest"
]
}
}
}Using docker
{
"mcpServers": {
"wikipedia-mcp": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"ghcr.io/progamesigner/wikipedia-mcp:latest"
]
}
}
}Using pip installation
{
"mcpServers": {
"wikipedia-mcp": {
"command": "python",
"args": [
"-m",
"wikipedia_mcp"
]
}
}
}Build
Docker build:
docker build -t wikipedia-mcp .Available Tools
2 toolsfetchA
Fetch the content of a Wikipedia page by its ID in a specified language.
This function retrieves the full HTML content of a Wikipedia page by its page ID. It uses the MediaWiki API to fetch the content and returns it as a string. The content is normalized to ensure consistent Unicode representation.
:param id: The page ID of the Wikipedia article to fetch. :param language: The language of the Wikipedia article (e.g., 'en' for English). :return: The content of the article as a string, or None if not found.
:raises KeyError: If the 'parse' or 'text' keys are not present in the response. :raises httpx.HTTPStatusError: If the request fails or returns an error status.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The page ID to fetch content for | |
| language | Yes | The language to fetch in |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits: uses MediaWiki API, returns string or None, raises specific exceptions. No annotations are provided, so this is sufficient. No contradictions.
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 well-structured with docstring sections, but slightly verbose. It could be more concise while retaining all information.
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 (2 params, no output schema), the description covers inputs, output, and errors adequately. It mentions return value and exceptions, leaving no major gaps.
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%, but the description adds value by explaining parameter roles in context (MediaWiki API, normalization). This goes beyond the schema's own descriptions.
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 it fetches content of a Wikipedia page by ID in a specified language. It distinguishes from sibling 'search' by specifying the exact action and parameters.
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?
Usage is implied by the description (when you have a page ID), but there is no explicit guidance on when to use this tool over alternatives like 'search', nor any when-not-to-use advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchB
Search Wikipedia for a keyword in a specified language. Returns a list of search results with page IDs, titles, and summaries.
:param keyword: The keyword to search for. :param language: The language to search in (default is 'en' for English). :return: A SearchResponse containing a list of SearchItem objects.
:raises httpx.HTTPStatusError: If the request fails or returns an error status.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | The keyword to search for | |
| language | No | The language to search in | en |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions that the tool returns search results and raises HTTP errors, but does not disclose potential limitations like pagination, result limits, or that it is read-only (though implied).
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 moderately concise but includes redundant parameter documentation (already in schema) and a verbose docstring format. The first two lines provide the core purpose, but the rest is extraneous.
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?
The description covers the return format (page IDs, titles, summaries) and error cases, but lacks details on result limits, pagination, or behavior for empty results. Given no output schema, it is partially 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?
The schema has 100% description coverage for both parameters. The description reiterates the same semantics ('keyword to search', 'language default en') without adding new meaning, so baseline 3 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?
The description clearly states the tool searches Wikipedia for a keyword and returns results with page IDs, titles, and summaries. However, it does not differentiate from the sibling tool 'fetch', which retrieves a specific article, but the purpose is clear enough.
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 guidance on when to use this tool vs alternatives. The sibling 'fetch' is not mentioned, and there is no when-not or prerequisites provided.
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. Dates show when Glama detected each change.
2 tool updates
v1.0.1- First observed
fetch - First observed
search
TDQS
The tools have clearly distinct purposes: search finds pages by keyword and returns a list, while fetch retrieves the full content of a specific page by its ID. There is no functional overlap.
Both tool names are single-word verbs ('fetch', 'search') that accurately describe their actions. They follow a consistent simple verb pattern without mixing conventions.
With only 2 tools, the server feels minimal for a Wikipedia MCP server. While the core operations (search and fetch by ID) are covered, 2 tools is on the low side for typical server scopes.
The server lacks several obvious operations, such as fetching a page by title directly (requiring a search then fetch), retrieving random articles, or accessing page summaries. This creates a notable gap in the tool surface.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
LLM-ready web search + instant answers + URL-to-clean-text fetch for agents and RAG.
Direct access to 40+ scraping and search tools. Extract structured data from Google (Search, Maps, Trends), Amazon, Airbnb, Social Media, and any web page directly into your AI agent.
Gateway between LLM agents and world data through eight tools and a bundled endpoint catalog.
Web search, fetch, extract, and research for AI agents. Markdown output + AI-synthesized answers.
Related MCP Servers
- AlicenseNot gradedqualityFmaintenanceEnables AI agents to search, read, and explore Wikipedia articles via tools like summaries, categories, and random articles, with no API keys required.1MIT
- AlicenseAqualityDmaintenanceEnables AI assistants to access Wikipedia content, search articles, retrieve historical events, and fetch images through the Wikipedia API.4311MIT
- FlicenseNot gradedqualityDmaintenanceProvides access to Wikipedia through 10 tools including search, article retrieval, summarization, and fact extraction, with multi-language support and robust error handling.-
- FlicenseNot gradedqualityDmaintenanceEnables searching and retrieving Wikipedia content across multiple languages, including article summaries, sections, coordinates, and related topics.-
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/progamesigner/wikipedia-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server