Allows searching and retrieving content from Wikipedia and other Wikimedia projects, including full-text search, page titles, page details, language versions, featured content, and historical events.
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., "@wikimedia get today's featured article"
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.
A Model Context Protocol (MCP) server for interacting with Wikimedia APIs. Access Wikipedia and other Wikimedia project content programmatically with natural language queries.
Search Content: Full-text search across Wikimedia page content
Search Titles: Search page titles with autocomplete suggestions
Get Page: Retrieve page content, title, URL and metadata
Language Versions: Find versions of a page in other languages
Featured Content: Get featured articles, most read pages, and pictures of the day
Historical Events: Get events, births, deaths, and holidays for any date
Related MCP server: Wikipedia MCP Server
Python 3.12+
uv package manager
MCP server framework
All user inputs are validated
No sensitive data or credentials required
Rate limiting handled by Wikimedia API
Error messages don't expose internal details
On MacOS:
~/Library/Application Support/Claude/claude_desktop_config.jsonOn Windows:
C:\Users\<username>\AppData\Roaming\Claude\claude_desktop_config.json{
"mcpServers": {
"wikimedia": {
"command": "uv",
"args": [
"--directory",
"C:\\MCP\\server\\community\\wikimedia",
"run",
"wikimedia"
]
}
}
}{
"mcpServers": {
"wikimedia": {
"command": "uvx",
"args": [
"wikimedia"
]
}
}
}Full-text search across Wikimedia page content. Returns snippets matching the query.
query (required): Search term
limit (1-50, default 10): Number of results
project (default "wikipedia"): Wikimedia project
language (default "en"): Language code
Search Wikimedia page titles starting with the query. Returns suggestions with descriptions.
query (required): Search prefix
limit (1-100, default 10): Number of results
project (default "wikipedia"): Wikimedia project
language (default "en"): Language code
Get Wikimedia page content, title, URL and last modified date.
title (required): Page title
project (default "wikipedia"): Wikimedia project
language (default "en"): Language code
Get versions of a Wikimedia page in other languages.
title (required): Page title
project (default "wikipedia"): Wikimedia project
language (default "en"): Language code
Get featured Wikimedia content for a date. Returns featured article, most read pages, and picture of the day.
date (YYYY/MM/DD, default today): Date to get content for
project ("wikipedia" only): Must be Wikipedia
language (en/de/fr/es/ru/ja/zh): Supported languages
Get historical events from Wikimedia for a date.
date (MM/DD, default today): Date to get events for
type (default "all"): Event type - all/selected/births/deaths/holidays/events
project ("wikipedia" only): Must be Wikipedia
language (en/de/fr/es/ru/ja/zh): Supported languages
# Search for content about "artificial intelligence"
result = await client.call_tool("search_content", {
"query": "artificial intelligence",
"limit": 5,
"language": "en"
})
# Get today's featured content
result = await client.call_tool("get_featured", {
"language": "en"
})
# Get historical events for January 1st
result = await client.call_tool("get_on_this_day", {
"date": "01/01",
"type": "all",
"language": "en"
})Contributions are welcome! Please feel free to submit a Pull Request. For major changes, please open an issue first to discuss what you would like to change.
MIT License. See LICENSE file for details.
Get featured Wikimedia content for a date. Returns featured article, most read pages, and picture of the day. Parameters: date (YYYY/MM/DD, default today), project ('wikipedia' only), language (en/de/fr/es/ru/ja/zh)
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ||
| project | No | wikipedia | |
| language | No | en |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description specifies output (featured article, most read, picture of the day) and parameter defaults, but does not disclose behavior for invalid dates, rate limits, or whether the operation is read-only. Adequate but not detailed.
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?
Two sentences, concise and no wasted words. Front-loaded with main action and immediately lists parameters.
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 retrieval tool with no output schema or annotations, description covers return items and parameters well. Missing error handling details, but completeness is high given 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?
Input schema has 0% description coverage. Description compensates by specifying date format (YYYY/MM/DD), default values, allowed values for project ('wikipedia' only) and language (list of codes). Adds significant meaning beyond 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?
Description clearly states the tool gets featured Wikimedia content for a date, listing specific items returned (featured article, most read pages, picture of the day). It distinguishes from siblings like get_page (single page) and search_content (search results) by specifying the type of 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?
Description does not explicitly state when to use this tool versus alternatives. It implies usage for retrieving featured content by date, but no when-not-to or comparison to sibling tools like get_languages or get_on_this_day.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get versions of a Wikimedia page in other languages. Parameters: title (required), project (e.g., 'wikipedia'), language (e.g., 'en')
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| project | No | wikipedia | |
| language | No | en |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states the action and parameters, omitting any details on return format, limitations, permissions, or side effects. For a read operation, this minimal disclosure is insufficient.
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 followed by a parameter list. It is concise, front-loaded with the purpose, and contains no unnecessary information. Every sentence earns its place.
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 has 3 parameters, no output schema, and no annotations, the description covers the basic purpose and parameter listing but lacks information about the return value, error handling, and how this tool compares to siblings. It is minimally adequate but incomplete.
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 0% schema description coverage, the description adds examples for 'project' and 'language' and notes that 'title' is required. This adds some meaning beyond the bare schema, but it does not explain valid values, formats, or semantics. Baseline 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 tool's function: 'Get versions of a Wikimedia page in other languages.' The verb 'get' is specific, and 'versions in other languages' distinguishes it from siblings like 'get_featured' or 'search_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 provides no guidance on when to use this tool versus alternatives. No explicit when/when-not conditions or mentions of sibling tools. Usage is only implied by the purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get historical events from Wikimedia for a date. Parameters: date (MM/DD, default today), type (all/selected/births/deaths/holidays/events), project ('wikipedia' only), language (en/de/fr/es/ru/ja/zh)
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ||
| type | No | all | |
| project | No | wikipedia | |
| language | No | en |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It correctly implies a read-only operation ('Get historical events') but omits details such as rate limits, response format, or behavior on invalid/unsupported dates. The description adds no warning or context beyond the basic 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 extremely concise: one sentence stating the purpose followed by a compact parameter list. Every word adds value, with no filler or repetition. The structure front-loads the purpose and then efficiently documents parameters.
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 no output schema, the description does not explain the return format, which could impact tool selection. It also lacks context such as date range validity, error behavior, or authentication needs. For a simple historical events tool, it is minimally adequate but leaves gaps for an agent to infer expected outputs.
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 description adds significant meaning beyond the input schema. It specifies the date format (MM/DD) and default (today), lists all type enum values with their meanings, restricts project to 'wikipedia' only, and enumerates supported languages. Schema coverage is 0%, so the description fully compensates by detailing each parameter's allowed values and defaults.
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's purpose: 'Get historical events from Wikimedia for a date.' The verb 'Get' and resource 'historical events' are specific. The name 'get_on_this_day' further clarifies the context. It distinguishes from siblings like 'get_featured' (featured content) and 'search_content' (full-text search) by focusing on historical events for a single date.
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 is provided on when to use this tool versus its siblings. It does not mention prerequisites, expected date ranges, or limitations. The description only lists parameters without explaining the appropriate context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Wikimedia page content, title, URL and last modified date. Parameters: title (required), project (e.g., 'wikipedia'), language (e.g., 'en')
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| project | No | wikipedia | |
| language | No | en |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses what data is returned (content, title, URL, last modified) but omits critical behavioral aspects such as error handling for missing pages, idempotency, authentication requirements, or rate limits.
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 extremely concise—two sentences that front-load the purpose and then list parameters. Every word adds value; there is no fluff or 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?
Given the lack of an output schema and annotations, the description should provide more details about the return structure, error conditions, and page retrieval behavior. It only vaguely mentions what is returned without specifying format or edge cases.
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 0%, so the description must compensate. It lists all three parameters with examples (e.g., 'wikipedia' for project, 'en' for language), adding meaning beyond the schema's bare types. However, it does not explain valid values or format requirements for parameters like project or language.
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's purpose: 'Get Wikimedia page content, title, URL and last modified date.' It specifies the verb and resource, making the function obvious. However, it does not explicitly differentiate from sibling tools like 'get_featured' or 'search_titles', which share a similar domain.
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 is provided on when to use this tool versus alternatives. The description lacks context about specific use cases, prerequisites, or situations where other tools would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search across Wikimedia page content. Returns snippets matching the query. Parameters: query (required), limit (1-50), project (e.g., 'wikipedia'), language (e.g., 'en')
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| limit | No | ||
| project | No | wikipedia | |
| language | No | en |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description fails to disclose behavioral traits such as read-only nature, authentication, or rate limits. Only states basic functionality.
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?
Two sentences, front-loaded with purpose, no wasted words. Efficiently communicates core 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?
Lacks output schema; description minimally covers return (snippets) but omits pagination, error handling, or other details. Adequate but not thorough for a search tool.
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 0% schema description coverage, the description adds meaning by listing parameters with examples and range for limit, though query format is not detailed.
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 performs full-text search across Wikimedia page content and returns snippets, distinguishing it from siblings like get_page and search_titles.
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 versus alternatives like search_titles or get_page. Absence of context for usage scenarios or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Wikimedia page titles starting with the query. Returns suggestions with descriptions. Parameters: query (required), limit (1-100), project (e.g., 'wikipedia'), language (e.g., 'en')
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| limit | No | ||
| project | No | wikipedia | |
| language | No | en |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes read-only behavior (searching, returning suggestions) and provides parameter details. No annotation contradictions. Lacks details on rate limits or return format, but acceptable for a search tool.
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?
Two sentences: first for purpose, second for parameters. No wasted words, front-loaded with verb and resource.
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?
Complete for a simple search tool: covers functionality, return type, and all parameters. Could explicitly differentiate from sibling tools but not essential.
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 0%, but the description explains all four parameters, including range for limit and examples for project/language, adding value beyond schema types.
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?
Clearly states the tool searches Wikimedia page titles starting with the query, and returns suggestions with descriptions. Distinguishes from sibling search_content by specifying title prefix matching.
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?
Implied usage is clear from name and description, but no explicit guidance on when to use this tool versus alternatives like search_content for full-text search.
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.1.0get_featuredget_languagesget_on_this_dayget_pagesearch_contentsearch_titlesEach tool has a clearly distinct purpose: retrieving featured content, language variants, historical events, page details, content search, and title search. No overlap or ambiguity.
All tools follow a consistent verb_noun pattern (get_featured, get_languages, get_on_this_day, get_page, search_content, search_titles), making naming predictable.
6 tools is well-scoped for a Wikimedia server, covering page retrieval, search, and specialized queries without being excessive or insufficient.
The set covers core workflows (page access, search, special content), but lacks operations like page history or random page, which are minor gaps for a general-purpose server.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Wikipedia, Wikidata and Wiktionary as clean JSON, not HTML. 1.9M searchable. Free, no auth.
Search and fetch Wikidata entities, execute SPARQL queries, and resolve external identifiers.
Live Wikipedia edit feed, page summaries, trending pages, and Wikidata search.
Enable Large Language Model clients to interact seamlessly with any MediaWiki wiki. Perform action…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/RapidMCP/wikimedia'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
