Skip to main content
Glama
tibia-sh

tibiawiki-mcp

by tibia-sh
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

tibiawiki-mcp

An offline MCP server for TibiaWiki. It answers the questions the wiki itself cannot:

  • Which creatures are weak to fire and give over 500 experience?

  • What drops a Dragon Shield, and how likely is it?

  • Where do I buy a Steel Helmet, and for how much?

The server makes no network calls. Every answer comes from a local SQLite snapshot you build yourself, so queries return in milliseconds and work offline.

Why it exists

TibiaWiki runs on Fandom without Cargo, Semantic MediaWiki or CirrusSearch, so there is no way to query it by attribute — every structured value is trapped inside Infobox wikitext, and the built-in search returns Dragon Necklace for fire resistant dragon. The public REST API over the same wiki exposes exactly one query parameter. Building a local index is the only way to ask a real question, and it costs about three minutes.

Related MCP server: anydocs

Requirements

  • Node ≥ 22.13 to run it (node:sqlite landed in 22.5 and is unflagged from 22.13).

  • Node ≥ 22.18 to develop it — the test suite runs TypeScript directly, and type-stripping is only on by default from 22.18. Consumers are unaffected: the published package ships compiled JavaScript.

  • uv to build the index.

Install

pnpm add -g @tibia.sh/tibiawiki-mcp
tibiawiki-mcp build-index      # ~3 minutes, ~14 MB

Use with Claude Code

Two ways, and they ship different things.

As an MCP server only — the npm package:

claude mcp add --transport stdio tibiawiki -- npx -y @tibia.sh/tibiawiki-mcp

As a plugin — the server plus a skill that teaches an agent how to query it (name resolution, the 100-is-neutral modifier convention, the data quirks that produce wrong answers). The plugin pieces never reach the npm tarball, because package.json has files: ["dist", "data/spell-areas.json"].

Marketplace install is not supported yet. .mcp.json points at ${CLAUDE_PLUGIN_ROOT}/dist/index.js, dist/ is deliberately not committed, and Claude Code does not run a build or a pnpm install for a plugin it fetches. A marketplace or bare git clone install therefore starts with no server. Use the local checkout below, which builds first. Shipping dist/ or publishing a prebuilt bundle would fix this and is not done here.

git clone https://github.com/tibia-sh/tibiawiki-mcp
cd tibiawiki-mcp && pnpm install && pnpm build   # dist/ is gitignored, so build once
claude --plugin-dir .

The build step is not optional: dist/ is deliberately not committed, and .mcp.json points at ${CLAUDE_PLUGIN_ROOT}/dist/index.js. A freshly cloned plugin without it will fail to start.

What the skill adds

The MCP server alone gives an agent the tools. The bundled skill gives it the judgement to use them well — and it costs one line of context until it fires:

  • resolve approximate names with tibia_search before tibia_get

  • modifiers are percentages where 100 is neutral, so a Dragon at modifier_fire: 0 is immune to fire, not weak to it

  • hitpoints: null means unrecorded, not zero — 433 creatures have no recorded health

  • imbuement.slots is a category list, not a count

  • non-active pages are hidden unless include_inactive: true

Tools

Tool

Answers

tibia_search

"Is there a page called roughly X?"

tibia_get

"Tell me everything about X." — creature, item, NPC, quest or spell

tibia_find_creatures

"Which creatures match these stats?"

tibia_find_items

"Which items match these stats?"

tibia_how_to_obtain

"Where do I get X?" — drops, vendors and quest rewards in one call

Damage modifiers are percentages where 100 is neutral: above 100 the creature takes extra damage from that element. weak_to and resistant_to encode that for you.

Deprecated, event-only and unavailable pages are excluded by default; pass include_inactive: true to see them.

Refreshing

Re-run tibiawiki-mcp build-index. A failed rebuild never replaces a working index — the new one is validated before it is installed. Every tool response reports indexGeneratedAt, so staleness is always visible to whoever is asking.

The index lives at $TIBIAWIKI_MCP_DB, or ${XDG_CACHE_HOME:-~/.cache}/tibiawiki-mcp/tibiawiki.db.

Checking for upstream drift

Spell area shapes are decoded once and committed to data/spell-areas.json. To find out whether TibiaWiki has re-uploaded any of the source animations since:

pnpm decode-spell-areas <path-to-index.db> --check

It fetches metadata only, prints any image whose revision moved (and any new candidate the file has never seen), and exits non-zero if there is drift — so it can run on a schedule. Re-run without --check to regenerate.

Releases

Releases go to npm as @tibia.sh/tibiawiki-mcp, starting at 0.1.0.

The version number describes the server, not the data. The index it serves is a local snapshot you build yourself, so upgrading the package never refreshes it — see Refreshing.

The tarball ships exactly dist/ and data/spell-areas.json, plus the package.json, README.md and LICENSE npm always adds; npm pack --dry-run is the check that nothing else leaks in.

Attribution

Data from TibiaWiki (https://tibia.fandom.com), licensed CC BY-SA. Tibia is made by CipSoft; game content and images are copyright CipSoft GmbH.

The index is generated by tibiawiki-sql (Apache-2.0). Images are deliberately never fetched or stored.

This project's own code is MIT licensed; see LICENSE. That covers the code only — the data it serves is CC BY-SA and not ours to relicense.

Available Tools

5 tools
tibia_find_creaturesC
Read-only

UNAVAILABLE: the local TibiaWiki index is missing or unusable, so tibia_find_creatures cannot answer anything until it is built.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

C2.7/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds genuinely new behavioral information by disclosing the tool's current unusable state and its cause (missing/unusable local index). It stops short of saying what the agent will actually receive on invocation (error vs. empty result) or how to fix the index.

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?

A single sentence, front-loaded with 'UNAVAILABLE' so the critical fact is unmissable. It is appropriately sized for the amount of information it chooses to convey, though it wastes a few words restating the tool name.

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

Completeness2/5

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

For a parameterless, output-schema-less tool the description would normally need little, but here it is the only signal that the tool is out of service and it provides no remediation path, no statement of what the agent will get on a call, and no pointer to the sibling tools that could answer the same question.

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 input schema has zero parameters, which is the baseline-4 case; there are no parameter semantics for the description to explain or compensate for.

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

Purpose2/5

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

The description only tells the agent the tool is broken; it never states what tibia_find_creatures actually does in a working state (presumably looking up creatures in TibiaWiki). The name carries essentially all of the purpose information, and the text is a status notice rather than a purpose statement.

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?

It implies the tool should not be called right now ('cannot answer anything until it is built'), which is useful, but it names no alternative even though tibia_search, tibia_get, and tibia_find_items exist as potential fallbacks, and gives no condition under which the tool becomes usable.

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

tibia_find_itemsC
Read-only

UNAVAILABLE: the local TibiaWiki index is missing or unusable, so tibia_find_items cannot answer anything until it is built.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

C2.4/5.0
Behavior3/5

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

Annotations already establish readOnlyHint=true and openWorldHint=false, so safety is covered. The description does add one genuinely useful behavioral fact beyond the annotations: the tool is currently non-functional because the local index is missing, plus the unmet prerequisite (index must be built). It discloses nothing else about query behavior, limits, or failure modes.

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

Conciseness3/5

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

One sentence, front-loaded with 'UNAVAILABLE,' which is the right priority order for an agent. It is not bloated, but it is sparse to the point of under-specification rather than efficient concision.

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

Completeness2/5

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

For a zero-parameter read tool with annotations covering safety and no output schema, the description still needs to convey what the tool returns and how it differs from tibia_search/tibia_find_creatures. It delivers only an availability warning and no remediation path or fallback, leaving an agent unable to plan around the failure.

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 tool takes zero parameters and the schema is trivially empty with no descriptions needed, so the baseline of 4 applies. The description neither helps nor harms here, though it also never indicates what input the tool would take once operational.

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

Purpose2/5

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

The text only reports a runtime status ('index is missing or unusable') and never states what tibia_find_items does when it is available. An agent can infer 'find items' solely from the tool name, and cannot distinguish it from siblings like tibia_search or tibia_find_creatures based on this description.

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

Usage Guidelines1/5

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

There is no guidance on when to use this tool, and no alternative is offered for the unavailable case even though tibia_search and tibia_get are viable siblings. The only actionable signal is a blanket 'cannot answer anything,' which is effectively a do-not-call notice with no fallback.

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

tibia_getC
Read-only

UNAVAILABLE: the local TibiaWiki index is missing or unusable, so tibia_get cannot answer anything until it is built.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

C2.7/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description adds a genuine operational fact beyond them: the backing TibiaWiki index is missing, so every call will fail. That is useful availability disclosure, though it says nothing about failure modes, cost, or what happens once the index exists.

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?

One front-loaded sentence with the critical status ('UNAVAILABLE') in the first word and no filler. It is appropriately sized for the message it carries, though the message itself is thin.

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

Completeness2/5

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

An agent reading this knows not to call tibia_get, but is left without a next step: no sibling is suggested and no hint is given about how the index gets built. For a tool that is unusable, routing guidance is the one thing the description most needs to provide.

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 tool takes zero parameters and the schema is trivially complete, so there is nothing for the description to disambiguate. Baseline 4 applies for a no-parameter tool.

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

Purpose2/5

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

The description never states what tibia_get actually retrieves (a page, entity, or record) — it only reports its own unavailability. It effectively restates the tool name and an error state rather than naming a verb+resource, so an agent cannot tell what the tool would do even once the index is built.

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?

It states a negative condition ('cannot answer anything until it is built'), which implies the tool should not be called now, but it names no alternative among the four siblings (tibia_search, tibia_find_creatures, tibia_find_items, tibia_how_to_obtain) and no positive when-to-use condition.

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

tibia_how_to_obtainC
Read-only

UNAVAILABLE: the local TibiaWiki index is missing or unusable, so tibia_how_to_obtain cannot answer anything until it is built.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

C2.8/5.0
Behavior3/5

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

Annotations declare a safe read-only, non-open-world operation, and the description adds a critical fact those annotations do not carry: the tool is currently non-functional. However it does not say what a call actually returns in this state (error, empty result, or refusal), so the failure mode remains unspecified.

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?

A single sentence that front-loads the 'UNAVAILABLE' status, which is the most important thing an agent needs to know. No wasted words, though the sentence is really a status banner rather than a tool definition.

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?

For a zero-parameter, read-only tool with no output schema, the description is adequate in flagging that it cannot answer anything. It is incomplete in that it offers no remediation path or statement of what the tool would do once the index exists, leaving the agent unable to plan around it.

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 tool takes zero parameters, so there is no parameter semantics to convey; the baseline of 4 applies. The empty schema is consistent with the description.

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

Purpose2/5

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

The description never states what tibia_how_to_obtain actually does when operational; it only reports that the backing TibiaWiki index is missing. The agent must infer the function (explaining how an item/spell is acquired) entirely from the name, and there is no differentiation from siblings like tibia_find_items or tibia_get.

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?

There is no guidance about when to use this tool versus the sibling lookups, nor any redirect to an alternative while the index is down. The only implicit message is 'do not call this,' which is a status notice rather than usage guidance.

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. 5 tool updatesv0.1.0
    • First observedtibia_find_creatures
    • First observedtibia_find_items
    • First observedtibia_get
    • First observedtibia_how_to_obtain
    • First observedtibia_search
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3/5.0

Scored across 5 tools

Disambiguation3/5

Names suggest partially distinct purposes (direct lookup vs search vs creature/item finders vs obtain-method lookup), but tibia_get, tibia_search, and tibia_how_to_obtain plausibly overlap, and every description is an identical 'UNAVAILABLE' message that provides no differentiating guidance to an agent.

Naming Consistency5/5

All five tools use a uniform 'tibia_' prefix followed by a clear snake_case verb/noun (get, search, find_creatures, find_items, how_to_obtain), with no style deviations.

Tool Count4/5

Five tools is a lean but reasonable surface for a wiki lookup server; each covers a distinct lookup mode, though the set is a bit thin with no listing/browsing capability.

Completeness3/5

Core lookups (get, search, creatures, items, obtain-methods) are covered, but there is no way to list or browse categories, examine NPCs, quests, or locations, and all tools are currently non-functional pending index construction.

Resources

Related MCP Connectors

Related MCP Servers

  • anydocs

    kiyeonjeon21
    A
    license
    A
    quality
    A
    maintenance
    Provides fast, token-efficient search over coding agent documentation (e.g., Claude Code, Cursor) using local SQLite FTS5 indexing, with tools for searching snippets, reading pages, and grepping markdown.
    5
    MIT

  • AI Knowledge Base MCP Server

    Alpha-W0lf
    A
    license
    B
    quality
    B
    maintenance
    Provides read-only hybrid RAG search and discovery over a local-first AI knowledge corpus, enabling semantic and keyword search, browse, digest, and status tools.
    4
    PolyForm Noncommercial 1.0.0

  • Arknights Intelligence MCP

    rendyuwu
    A
    license
    A
    quality
    B
    maintenance
    Provides read-only Arknights intelligence over MCP, enabling structured queries about stages, enemies, operators, and modules with region tagging and evidence-backed analysis. It uses versioned SQLite snapshots and never fetches upstream data at query time.
    13
    Apache 2.0