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., "@palworld-save-mcp Check if my Palworld save is ready to migrate to a dedicated server."
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 that empowers AI assistants (Claude Desktop, Cursor, Windsurf, Zed) to diagnose, inspect, and troubleshoot Palworld game saves directly on your local machine or dedicated game server.
Official Web Companion: CheckMySave.com — 100% browser-local save health diagnostic tool.
🔍 Container & Header Validation: Validates Level.sav compression bounds (Oodle / Zlib / GVAS container) and detects truncation or corrupt headers.
đź‘Ą Co-op Host Slot (0000...0001) Detection: Prevents the infamous "Host reset to Level 1" disaster when migrating 4-player co-op saves to Linux/Windows dedicated servers.
⚙️ WorldOption.sav Override Audit: Flags conflicts where WorldOption.sav overrides PalWorldSettings.ini on dedicated servers, ignoring custom XP, capture rates, and death penalties.
🗄️ Player Profile & World Parity: Audits all .sav profiles inside Players/ against world records.
đź’ľ Autosave Backup Check: Scans for historical backup snapshots to ensure safe rollbacks.
đź”’ 100% Local & Keyless: Runs via standard stdio on your local computer. Zero remote API dependencies, zero telemetry, and zero credentials required.
Related MCP server: ModWrench MCP Server
inspect_palworld_saveRuns a full 8-point diagnostic scan on a Palworld world directory.
Input: save_path (string, path to folder containing Level.sav and Players/)
Output: Detailed health scorecard (Pass / Warn / Fail) with actionable remediation steps.
check_migration_readinessEvaluates whether a local co-op save is ready to migrate to a dedicated server without losing the host character.
Input: save_path (string)
Output: Status of the 00000000000000000000000000000001 host slot and step-by-step fix commands.
check_server_overrideChecks whether WorldOption.sav is overriding PalWorldSettings.ini.
Input: save_path (string)
Output: Conflict resolution advice.
npx -y palworld-save-mcpAdd the following to your claude_desktop_config.json:
MacOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"palworld-save": {
"command": "npx",
"args": ["-y", "palworld-save-mcp"]
}
}
}Add to your .cursor/mcp.json or Windsurf MCP config:
{
"mcpServers": {
"palworld-save": {
"command": "npx",
"args": ["-y", "palworld-save-mcp"]
}
}
}Once configured, you can ask your AI assistant:
"Claude, inspect my Palworld save at C:\Users\Admin\AppData\Local\Pal\Saved\SaveGames\0\2E85FD38... and tell me if it's healthy."
"I want to move my 4-player co-op save to my Linux dedicated server. Check if my save is ready to migrate."
"Why are my XP multiplier settings in PalWorldSettings.ini not applying on my server?"
For users who prefer a drag-and-drop web interface without installing Node.js or terminal tools, visit:
👉 https://www.checkmysave.com
Runs 100% in your browser using client-side WebAssembly. No files are ever uploaded.
MIT License — see LICENSE for details.
Checks if a Palworld save is ready for migration from 4-player co-op to a Linux/Windows Dedicated Server, flagging the 0000...0001 host reset bug.
| Name | Required | Description | Default |
|---|---|---|---|
| save_path | Yes | Path to the Palworld world save directory. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully reveals that the tool performs a readiness check and flags the '0000...0001 host reset bug'. However, it does not explicitly state that the check is read-only, nor does it describe permissions, failure behavior, or the exact form of the output.
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 dense sentence that front-loads the purpose and includes the key bug detail without filler. Every clause contributes relevant context, including the migration target platforms.
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 tool with one required string parameter, no output schema, and no annotations, the description is largely sufficient for an agent to select the tool and invoke it. The main gap is the underspecified result format—whether the tool returns a boolean, report, or flag—which matters if the agent must act on the output.
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 100%, so save_path is already documented as the path to the Palworld world save directory. The description adds no parameter-level meaning beyond the schema, so the baseline of 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 uses a specific verb ('Checks') with a clear resource ('a Palworld save') and a precise scope ('ready for migration from 4-player co-op to a Linux/Windows Dedicated Server'). It also names the exact bug it flags, making it easy to distinguish from the broader inspect_palworld_save and from check_server_override.
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 intended use case is explicit: determine whether a Palworld save can be migrated from co-op to a dedicated server. It does not name sibling tools or provide when-not-to-use guidance, but the context is clear enough for an agent to route to this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Checks if WorldOption.sav is present in the save directory, which overrides PalWorldSettings.ini on dedicated servers.
| Name | Required | Description | Default |
|---|---|---|---|
| save_path | Yes | Path to the Palworld world save directory. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. 'Checks if...present' clearly implies a read-only existence check, and the override note adds useful behavioral context. It does not specify the exact return value, but for a presence check that is strongly implied.
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 focused sentence with no wasted words. The primary action is front-loaded, and the important override context is included without bloating the text.
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 one-parameter existence check, the description is complete: it names the file, the directory parameter, the server context, and the file's significance. The agent has everything needed to select and invoke the tool correctly.
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 input schema already fully describes the single parameter with 100% coverage. The description repeats 'save directory' but adds no new semantic detail beyond what the schema provides, so the baseline score of 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 states the exact verb ('Checks if...present'), the specific resource (WorldOption.sav in the save directory), and the meaningful consequence (override of PalWorldSettings.ini). This clearly separates it from the sibling tools like inspect_palworld_save or check_migration_readiness.
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 identifies the relevant context: dedicated servers where WorldOption.sav may override PalWorldSettings.ini. It does not explicitly name alternative tools or say when not to use it, but the context is clear enough for an agent to infer appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Performs a comprehensive 8-point diagnostic on a Palworld save directory. Checks container integrity, host slot 00000000000000000000000000000001 co-op migration reset, WorldOption.sav server INI conflict, and backup presence.
| Name | Required | Description | Default |
|---|---|---|---|
| save_path | Yes | Absolute or relative path to the Palworld world save directory containing Level.sav and the Players/ subfolder. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral transparency. While it lists the checks performed, it does not disclose whether the tool modifies the save directory, what the output/return format is, or whether it is strictly read-only. This leaves an agent uncertain about side effects and how to interpret results.
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 two sentences with the main purpose front-loaded and the specific checks listed compactly. It is efficient and contains no filler, though it sacrifices some behavioral detail for brevity.
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?
The tool has one parameter and no output schema, so the description must convey enough context for an agent to call it and interpret results. It describes the checks but not the return value, success/failure signals, or whether any side effects occur. For a diagnostic tool this is a notable gap.
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 schema already fully describes the single parameter save_path with 100% coverage, establishing the baseline of 3. The description adds no additional parameter-specific meaning beyond restating that it operates on the save directory.
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 states a specific verb and resource, 'comprehensive 8-point diagnostic on a Palworld save directory', and lists specific checks, making the purpose immediately clear. However, it does not explicitly distinguish itself from the sibling tools check_migration_readiness and check_server_override, though the broad scope implies a difference.
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 guidance is given on when to use this tool versus the siblings. The description implies it is a comprehensive diagnostic but does not state when to prefer it or when to use a narrower sibling tool. An agent would have to infer this from the name and sibling names.
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.
v1.0.0check_migration_readinesscheck_server_overrideinspect_palworld_saveScored across 3 tools
inspect_palworld_save is a comprehensive 8-point diagnostic that explicitly covers migration reset and WorldOption.sav override checks, so its scope subsumes check_migration_readiness and check_server_override. This creates real ambiguity about which tool an agent should call for a specific check.
All three tools follow a consistent snake_case verb_noun pattern: inspect_palworld_save, check_migration_readiness, and check_server_override. The verbs inspect and check are near-synonyms, but the structural pattern is uniform and predictable.
Three tools is a reasonable size for a focused Palworld save diagnostic server, and none feel gratuitous. However, the count is slightly padded because two tools are effectively narrower versions of checks already inside the comprehensive inspector.
The toolset covers the main diagnostic concerns: container integrity, migration readiness, the host-slot reset bug, WorldOption.sav conflicts, and backup presence. However, it only inspects and never performs a migration, creates a backup, or provides remediation actions, leaving the workflow with a notable dead end for agents tasked with actually migrating a save.
Gives your AI assistant persistent memory and intelligence about your work patterns.
Connect AI assistants to your GitHub-hosted Obsidian vault to seamlessly access, search, and analy…
Read-only local AI advice, shared reports and website audits. No PC scan or local actions.
Open, inspect, filter, edit and convert xlsx and csv files from your AI chat. Processing is local.
