Skip to main content
Glama
YukiSakiko

mcp-server-moegirl-wiki

by YukiSakiko
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Remote

mcp-server-moegirl-wiki

PyPI version License: MIT

English | 简体中文

MCP server for 萌娘百科 (Moegirl Wiki). Two tools: search entries and fetch a page's intro.

Install

uvx mcp-server-moegirl-wiki         # recommended
pipx run mcp-server-moegirl-wiki
pip install mcp-server-moegirl-wiki

Related MCP server: Internetsearch-mcp-server

Tools

search_moegirl(keyword: str, limit: int = 5)

Returns {"results": [{"title", "url", "snippet"}, ...], "count": int}.

get_page(title: str, max_length: int = 6250)

Returns {"title", "content", "url", "page_id"} — full plain-text rendering of the page (all sections, templates expanded, links resolved). Auto-follows redirects. content is truncated to max_length characters; default 6250 covers a typical character page in full, pass larger (e.g. 20000) for very long pages.

Environment variables

Variable

Default

Description

MOEGIRL_MAX_LENGTH

6250

Default max_length for get_page when the caller does not specify one. Useful for tuning per-deployment without forking the package. Invalid/non-positive values are ignored with a warning.

Configuration

Claude Desktop

{
  "mcpServers": {
    "moegirl-wiki": {
      "command": "uvx",
      "args": ["mcp-server-moegirl-wiki"]
    }
  }
}

MaiBot (config/bot_config.toml)

MaiBot's default config already has the [mcp] block — just replace the servers line:

servers = [{name = "moegirl", enabled = true, transport = "stdio", command = "uvx", args = ["mcp-server-moegirl-wiki"], env = {MOEGIRL_MAX_LENGTH = "6250"}, url = "", headers = {}, http_timeout_seconds = 30.0, read_timeout_seconds = 300.0, authorization = {mode = "none", bearer_token = ""}}]

Tweak MOEGIRL_MAX_LENGTH to taste (raise to 20000 for very long pages, lower to 1500 for quick lookups). If uvx is not on PATH, swap command/args for command = "pipx", args = ["run", "mcp-server-moegirl-wiki"].

Development

git clone https://github.com/XXXxx7258/mcp-server-moegirl-wiki
cd mcp-server-moegirl-wiki
uv sync --group dev
uv run pytest -m network
uv run ruff check .

Limitations

  • get_page returns rendered plain text (templates expanded, links resolved). Raw wikitext (prop=revisions, action=parse, ?action=raw, Special:Export) is blocked by Moegirl Wiki's site-wide ACL — empirically verified that bot-password login does not unlock it; only sysop/staff groups can call these actions.

  • Uses the mzh.moegirl.org.cn mirror.

License

MIT

Available Tools

2 tools
get_pageA

获取萌娘百科条目的纯文本全文（所有章节、模板已展开、链接已解析、自动跟随重定向、按 max_length 截断）。

ParametersJSON Schema
NameRequiredDescriptionDefault
titleYes
max_lengthNo

TDQS

A4.4/5.0
Behavior4/5

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

No annotations are provided, so the description carries full burden. It discloses key behaviors: redirect following, truncation by max_length, template expansion, and link resolution. However, it does not mention error handling or the return structure.

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 a single dense sentence that packs all information. It is front-loaded with the verb and resource, but could be broken into multiple sentences for clarity. Still, it is concise with no wasted words.

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

Completeness5/5

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

Given the tool's simplicity (2 parameters, no output schema, no annotations), the description covers all essential behaviors: redirects, truncation, template expansion, and link resolution. It provides enough context for an agent to use the tool correctly, though error cases are not mentioned.

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?

Schema description coverage is 0%, so the description must compensate. It explains both parameters: 'title' is the page title, and 'max_length' controls truncation. This adds meaning beyond the schema, though it could be more precise about title matching.

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 it retrieves the pure text full text of a Moegirl Wiki page, with specific details on template expansion, link resolution, redirect following, and truncation. It differentiates from the sibling search_moegirl tool which searches for pages.

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?

The description implicitly indicates usage: when you need the full text content of a known page. While it doesn't explicitly state when not to use it, the sibling search_moegirl provides contrast. Missing explicit exclusions or alternatives, but context is clear.

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

search_moegirlA

搜索萌娘百科条目。先用 generator=search 全文索引（命中时同时返回摘要片段），0 命中或异常时退回 opensearch 标题模糊匹配以保命中率。

ParametersJSON Schema
NameRequiredDescriptionDefault
keywordYes
limitNo

TDQS

A3.5/5.0
Behavior4/5

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

With no annotations provided, the description fully carries the burden of disclosing behavior. It explains the dual-mode search (full-text index with snippet return, then fallback to title fuzzy match) and the purpose of the fallback (to ensure hit rate). This is transparent about the tool's internal logic and expected output behavior.

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 (two sentences) and front-loaded with the core purpose. It packs in the search algorithm details without unnecessary fluff. However, it could be improved by adding parameter explanations in a structured manner without sacrificing conciseness.

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 tool has two parameters, no output schema, and no annotations, the description provides a good overview of the search logic but lacks detail on parameters and return format. It is adequate for understanding what the tool does but insufficient for an agent to invoke it correctly without guessing parameter semantics.

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

Parameters1/5

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

The input schema has 0% description coverage for its two parameters (keyword and limit). The description does not explain what these parameters do, how they affect the search, or any constraints (e.g., format, range). For a tool with no schema descriptions, the description fails to compensate, leaving the agent without necessary parameter guidance.

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's function: searching Moegirl Wiki entries. It explains the two-step search strategy (generator=search full-text with snippets, then fallback to opensearch fuzzy matching), which distinguishes it from the sibling tool 'get_page' (which retrieves a specific page). This is specific and actionable for an agent.

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?

The description provides context on the search strategy (when full-text search is used and when the fallback kicks in) but does not explicitly guide the agent on when to prefer this tool over alternatives or when to avoid it. The sibling tool 'get_page' is available, but no comparison is made. The usage guidelines are implied but not explicit.

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.

  1. 2 tool updatesv0.2.2
    • First observedget_page
    • First observedsearch_moegirl
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have clearly distinct purposes: one searches for pages, the other retrieves the content of a specific page. There is no overlap or ambiguity.

Naming Consistency5/5

Both tool names follow a consistent verb_noun pattern (get_page, search_moegirl), using snake_case. The naming is clear and predictable.

Tool Count3/5

With only two tools, the server feels minimal for a wiki. While it covers basic search and retrieval, the scope is narrow; typically 4-8 tools would be more appropriate.

Completeness2/5

The tool surface has significant gaps for a wiki domain: missing operations like listing pages, retrieving sections, getting categories, or browsing history. Agents will likely fail to accomplish common wiki tasks.

Maintenance

ActivityInactive
ResponsivenessNo issues

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

Related MCP Servers