Click on "Deploy 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., "@leekwars-mcp-encyclopedia search the encyclopedia for the Flame chip"
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 standalone, Leekwars-aware MCP server dedicated to encyclopedia search and retrieval.
This project exists to separate knowledge tools from the main Leekwars MCP server.
The main leekwars-mcp repository should focus on authenticated game actions, such as fetching leeks, running fights, managing AIs, buying items, and interacting with the Leekwars API.
This repository focuses only on read-only encyclopedia knowledge:
searching the Leekwars encyclopedia
retrieving encyclopedia pages by path
returning useful snippets and metadata for agents
exposing domain-aware tools for Leekwars concepts such as chips, weapons, effects, entities, and game mechanics
Related MCP server: openzim-mcp
The encyclopedia search stack may use Python-specific tooling such as bm25s. Keeping it in a separate repository avoids adding Python dependencies to the mostly TypeScript game-action server.
This split also creates a clearer MCP model:
Leekwars action server: authenticated, state-changing, game/API operations
Leekwars encyclopedia server: unauthenticated, read-only, knowledge retrieval
An MCP client or agent can connect to both servers when it needs both knowledge and actions.
Initial tools could include:
search_encyclopedia(query, k?) — search the encyclopedia and return ranked Leekwars-aware results
get_encyclopedia_page(path) — read a full encyclopedia page by path
list_encyclopedia_pages() — list known encyclopedia documents
Future tools may become more domain-specific:
find_chip(name)
find_weapon(name)
find_effect(name)
search_game_mechanics(query)
The server should return structured, domain-aware results rather than generic text blobs. A search result should ideally include:
title
path
score
snippet
document/category metadata when available
Example shape:
{
"title": "Chip: Flame",
"path": "chips/flame.md",
"score": 12.34,
"snippet": "Flame deals fire damage...",
"kind": "chip"
}Primary workflow with uv:
uv sync
uv run leekwars-mcp-encyclopediaPlain venv + pip workflow:
python -m venv .venv
.venv/bin/pip install -e .
.venv/bin/leekwars-mcp-encyclopediaThe default command starts the stdio MCP server. The index is generated at startup if .cache/bm25/ is missing.
leekwars-mcp-encyclopedia
leekwars-mcp-encyclopedia serve
leekwars-mcp-encyclopedia index --rebuildThe server reads encyclopedia markdown only from:
vendor/encyclopedia/root/Generated search indexes live under .cache/bm25/ and are git-ignored.
leekwars-mcpThis repository is intended to replace the encyclopedia-related tools currently living in leekwars-mcp, especially:
search_encyclopedia
get_encyclopedia_page
Once this project exists, those tools can be removed from the action server or kept temporarily as deprecated compatibility wrappers.
Read a markdown encyclopedia page by path relative to the vendored encyclopedia root.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description must disclose behavior. 'Read' implies read-only with no side effects, but doesn't mention error handling, path validation, or that pages are markdown (though it says 'markdown'). Basic transparency but lacks depth.
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 concise sentence front-loading the action ('Read') and object ('markdown encyclopedia page'), with specific qualifier ('by path relative to root'). No wasted 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?
Output schema exists, covering return values. Description is sufficient for a simple read operation; mentions markdown format and path reference. Could mention error cases but not missing critical info.
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 0% but description adds that 'path' is relative to 'vendored encyclopedia root', which is meaningful beyond the schema's 'string' type. Single parameter well explained.
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 reads a markdown encyclopedia page by path relative to a root, which is a specific verb+resource. It distinguishes from sibling 'search_encyclopedia' which searches instead of direct retrieval.
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 when-to-use or when-not-to-use guidance. Implicitly, if you know the exact path, use this; otherwise search. But no alternatives or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Leekwars encyclopedia with a query and return the top BM25 matches.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral traits. It mentions returning top BM25 matches, implying a read operation, but does not disclose any additional behavior such as rate limits, authentication requirements, query length limits, or error handling. The description is minimal 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?
The description is a single sentence that front-loads the core action (search) and result (top BM25 matches). Every word is meaningful, and there is no extraneous 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 has a single required parameter and an output schema (not shown), the description does not need to detail return values. It is complete enough for a basic search tool, but could be improved by noting that the query is required (already in schema) and that results are limited or ranked. The presence of a sibling tool adds context, but the description alone is slightly lacking.
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 must compensate. The only parameter is 'query', which is self-explanatory, but the description adds only the context of BM25, which is more about ranking than the parameter's meaning. It does not elaborate on query format, encoding, or special syntax, leaving the agent with minimal guidance beyond the schema's type.
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 the Leekwars encyclopedia and returns top BM25 matches. It specifies the verb 'search' and the resource 'encyclopedia', but does not differentiate from the sibling tool 'get_encyclopedia_page', which likely retrieves a specific page. The purpose is clear but could be more distinctive.
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 user wants to search the encyclopedia, but it provides no explicit guidance on when to use this tool versus the sibling 'get_encyclopedia_page'. There are no stated exclusions or alternative recommendations.
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.
v0.1.0get_encyclopedia_pagesearch_encyclopediaScored across 2 tools
The two tools have clearly distinct purposes: one retrieves a specific page by path, the other searches the encyclopedia. No overlap.
Both tools use snake_case and follow a consistent verb_noun pattern: 'get_encyclopedia_page' and 'search_encyclopedia'.
With only 2 tools, the server feels thin for an encyclopedia, but it covers basic read and search operations. Could be acceptable for a focused domain.
The set lacks tools for discovering pages (e.g., list or browse), which limits the agent's ability to navigate. Significant gaps remain.
Token-free MCP server for structured RevoGrid Core, Pro, and Enterprise knowledge retrieval.
Read-only MCP for the Eco game wiki: search, Markdown pages, and wiki_* lookups. No keys, no writes.
An MCP server for deep research or task groups
