Which integrations are available for this server?

Allows fetching data from any Fandom wiki, including searching articles, retrieving full article text or summaries, listing category members, and getting wiki stats.

How do I use Fandom Wiki MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Fandom Wiki MCP Server Search the OGame wiki for 'Graviton Technology'" 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.

Fandom Wiki MCP Server

by dotnetrule

Overview Schema Related Servers Score Discussions

Python

Remote

Fandom Wiki MCP Server

A generic Model Context Protocol server for fetching data from any Fandom wiki.

Tools

Tool	Description
`search_wiki`	Search for articles on any Fandom wiki
`get_article`	Fetch the full text of an article
`get_article_summary`	Fetch just the intro/summary of an article
`list_category_members`	List pages that belong to a category
`get_wiki_info`	Get general info and stats about a wiki

Every tool accepts a wiki parameter — the subdomain of the Fandom wiki you want to query:

Wiki	`wiki` value
ogame.fandom.com	`"ogame"`
minecraft.fandom.com	`"minecraft"`
starwars.fandom.com	`"starwars"`
leagueoflegends.fandom.com	`"leagueoflegends"`

Related MCP server: mcp-mediawiki-crunchtools

Installation

pip install .

Or with uv:

uv pip install .

Usage

Run the server directly:

fandom-wiki-mcp

Or via the MCP CLI:

mcp run src/fandom_wiki_mcp/server.py

Claude Desktop Configuration

Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):

{
  "mcpServers": {
    "fandom-wiki": {
      "command": "fandom-wiki-mcp"
    }
  }
}

Or with uv (no global install needed):

{
  "mcpServers": {
    "fandom-wiki": {
      "command": "uvx",
      "args": ["--from", "/path/to/mcp-fandomwiki", "fandom-wiki-mcp"]
    }
  }
}

Example Prompts

"Search the OGame wiki for 'Graviton Technology'"
"Get the full article for 'Creeper' from the Minecraft wiki"
"List pages in the 'Ships' category on the Star Wars wiki"
"What stats does the League of Legends wiki have?"

Available Tools

5 tools

get_articleA

Fetch the full text content of a wiki article.

Args: wiki: Wiki subdomain (e.g. "ogame", "minecraft", "starwars"). title: Exact article title.

ParametersJSON Schema

Name	Required	Description	Default
`wiki`	Yes
`title`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.9/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. Only states action 'fetch', but does not disclose any behavioral traits like rate limits, authentication requirements, or error behavior. Minimal for a 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.

Conciseness5/5

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

Very concise: two sentences for description, then parameter list. No extraneous information. Structure is clear and front-loaded.

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

Completeness4/5

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

Given output schema exists (context signal), description is quite complete. Covers purpose and parameters. Could mention output format briefly, but output schema handles that.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 0% schema coverage, the description adds meaning by explaining both parameters: 'wiki' with examples, 'title' as exact article title. Compensates fully for the schema's lack of description.

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

Purpose5/5

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

Clearly states it fetches full text content of a wiki article. Verb 'Fetch' and resource 'full text content of a wiki article' are specific. Distinguishes from sibling 'get_article_summary' which presumably returns a summary.

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

Usage Guidelines3/5

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

Implies usage when full text is needed, but no explicit 'when to use' or 'when not to use' compared to siblings. No guidance on alternatives like 'search_wiki'.

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

get_article_summaryA

Fetch just the introductory summary of a wiki article.

Args: wiki: Wiki subdomain (e.g. "ogame", "minecraft", "starwars"). title: Exact article title.

ParametersJSON Schema

Name	Required	Description	Default
`wiki`	Yes
`title`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.8/5.0

Behavior2/5

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

No annotations provided, and the description does not disclose behavioral traits such as read-only nature, permissions, or limitations. It only states the basic operation, leaving the agent without important context.

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

Conciseness5/5

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

Extremely concise: one sentence for purpose, two for parameters. No wasted words. Front-loaded with the primary action.

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

Completeness4/5

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

With an output schema, return values are covered. Parameters are simple and well-explained. Could mention that only summary is returned, but it's implied by the name and description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description compensates by explaining 'wiki' as subdomain and 'title' as exact article title. However, it does not specify formats or constraints (e.g., case sensitivity).

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

Purpose5/5

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

Description clearly states 'Fetch just the introductory summary of a wiki article,' using a specific verb and resource. This differentiates from siblings like get_article (full article) and search_wiki (search).

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

Usage Guidelines4/5

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

Provides clear parameter guidance (wiki subdomain examples, exact title). Implicitly guides when to use (for summary vs full article) but lacks explicit when-not and alternative naming.

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

get_wiki_infoA

Get general information about a Fandom wiki.

Args: wiki: Wiki subdomain (e.g. "ogame", "minecraft", "starwars").

ParametersJSON Schema

Name	Required	Description	Default
`wiki`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.6/5.0

Behavior2/5

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

No annotations provided, and the description does not disclose behavioral traits like idempotency, side effects, authentication needs, or rate limits. It only states the basic function, leaving the agent uninformed beyond the immediate action.

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

Conciseness4/5

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

The description is very short (one line plus parameter definition), no wasted words. However, parameter documentation uses a separate line, which is fine. Could be more structured (e.g., stating output format) but remains efficient.

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

Completeness3/5

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

Given the presence of an output schema (not shown), the description does not need to detail return values. However, it lacks context on what 'general information' includes, and no usage scenarios are provided, making it minimally complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage for the 'wiki' parameter, but the description adds meaningful context by defining 'wiki' as a subdomain with common examples (ogame, minecraft). This compensates for the schema gap, though format details could be clearer.

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

Purpose5/5

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

The description clearly states the tool retrieves 'general information about a Fandom wiki', which is a specific action on a defined resource. This distinguishes it from sibling tools like 'get_article' (specific article) or 'search_wiki' (search), so purpose differentiation is strong.

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

Usage Guidelines3/5

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. The description implies its use for general wiki info, but lacks when-not or direct comparisons. It's adequate but not proactive.

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

list_category_membersA

List pages that belong to a category on a Fandom wiki.

Args: wiki: Wiki subdomain (e.g. "ogame", "minecraft", "starwars"). category: Category name, with or without the "Category:" prefix. limit: Maximum number of results (default 20, max 500).

ParametersJSON Schema

Name	Required	Description	Default
`wiki`	Yes
`category`	Yes
`limit`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.6/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. Does not disclose ordering, pagination behavior, rate limits, or error conditions. Only describes 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.

Conciseness5/5

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

Extremely concise with no wasted words. Front-loaded with purpose, followed by structured parameter descriptions.

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

Completeness4/5

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

Adequately covers purpose and parameters. With an existing output schema, return format is presumably documented elsewhere. Could mention that results are page titles, but still complete enough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Description adds meaning beyond schema: explains wiki subdomain with examples, category prefix flexibility, and limit with default/max values. Schema coverage is 0% but description compensates well.

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

Purpose5/5

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

The description clearly states 'List pages that belong to a category on a Fandom wiki' with a specific verb (list), resource (pages in a category), and domain (Fandom wiki). It distinguishes from siblings like get_article and search_wiki.

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

Usage Guidelines2/5

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

No guidance on when to use this tool over alternatives like search_wiki or get_article. No exclusions or when-not-to-use information.

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

search_wikiB

Search for articles on a Fandom wiki.

Args: wiki: Wiki subdomain (e.g. "ogame", "minecraft", "starwars"). query: Search query string. limit: Maximum number of results to return (default 10, max 50).

ParametersJSON Schema

Name	Required	Description	Default
`wiki`	Yes
`query`	Yes
`limit`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are present, and the description does not disclose any behavioral traits such as authentication requirements, rate limits, or side effects. The description merely states the function without additional context.

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

Conciseness4/5

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

The description is concise and well-structured, listing arguments in a clear Args block. Each sentence serves a purpose, though could be slightly more polished.

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

Completeness3/5

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

Given the presence of an output schema and relatively simple tool, the description covers core functionality. However, it lacks details on error handling, pagination behavior, or result format, leaving some gaps for the agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description explains each parameter beyond the schema: wiki specifies subdomain examples, query is a search string, and limit includes default and max values. This adds meaningful context to the parameter names.

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

Purpose4/5

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 on a Fandom wiki, specifying required arguments. However, it does not explicitly differentiate from sibling tools like get_article, which may cause confusion about when to use each.

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

Usage Guidelines2/5

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. There is no mention of context, prerequisites, or scenarios where this tool would be inappropriate.

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

Install Server

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

TDQS

A3.8/5.0

Disambiguation5/5

Each tool targets a distinct operation: full article content, summary, wiki info, category members, and search. No overlaps.

Naming Consistency5/5

All tools use consistent snake_case verb_noun pattern (get_*, list_*, search_*), making them predictable.

Tool Count5/5

Five tools cover essential read operations for a wiki client without being excessive or insufficient.

Completeness4/5

Covers core read functionality (article, summary, search, categories, wiki info). Lacks deeper features like article history or media retrieval but is appropriate for basic access.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

EcoCarbonWiki A
dev.carbonitex.ecogame
Read-only MCP for the Eco game wiki: search, Markdown pages, and wiki_* lookups. No keys, no writes.
Documentation Access Search Games & Gamification
101
mcp A
ai.llmse
Public MCP server for the LLM Search Engine
Search RAG Systems Developer Tools
102
podcasts A
com.petabloom
An MCP server that provides tools to discover and retrieve podcast episodes transcripts.
Entertainment & Media Search
52
driflyte-mcp-server
com.driflyte
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
Search Web Scraping Knowledge & Memory
211

Related MCP Servers

mediawiki-mcp-server
Search Documentation Access Open Data
shiquda
F
license
B
quality
C
maintenance
A MCP server that allows you to search and retrieve content on any wiki site using MediaWiki with LLMs 🤖. wikipedia.org, fandom.com, wiki.gg and more sites using Mediawiki are supported!
Updated a year ago (2025-07-13 01:40 UTC)
2
26
mcp-mediawiki-crunchtools
Content Management Systems Search Developer Tools
crunchtools
A
license
B
quality
C
maintenance
A secure MCP server for interacting with MediaWiki instances, allowing users to search, read, create, and manage wiki content like pages, categories, and files. It supports both public and private wikis with comprehensive authentication for full read and write operations.
Updated 3 months ago (2026-06-10 22:24 UTC)
19
AGPL 3.0
mediawiki-mcp
Content Management Systems Documentation Access Search
ttpears
A
license
A
quality
A
maintenance
An MCP server for MediaWiki instances with multi-wiki support, providing full read/write access via REST and Action APIs across multiple named wikis.
Updated 7 days ago (2026-08-27 16:45 UTC)
21
180
3
MIT
wikipedia-mcp-server
Search Open Data Education & Learning Tools
cyanheads
A
license
Not graded
quality
A
maintenance
MCP server for searching and reading Wikipedia articles, including summaries, full text, targeted sections, nearby pages, and language editions.
Updated 10 days ago (2026-08-25 07:29 UTC)
358
2
Apache 2.0

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/dotnetrule/mcp-fandomwiki'

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