Provides tools for analyzing Crusader Kings III save files, enabling AI agents to retrieve realm overview, military, succession, diplomacy, vassals, and other strategic information from the game.
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., "@ck3-strategy-advisor what's my realm overview?"
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 local Model Context Protocol server that reads your Crusader Kings III save file and exposes your strategic situation to Claude as compact, curated tools. Ask Claude "what's my situation?" and it can pull your realm overview, military, succession, diplomacy, vassals, factions, and expansion options straight from your latest save.
It is read-only: it never modifies your save or your game.
Node.js ≥ 22
Non-Ironman saves only. Ironman saves are stored in a binary format; the advisor detects them and returns a friendly message instead of mis-parsing. Play (or re-save) without Ironman to use the advisor.
Mid/late-game saves are large (the embedded game state is ~200+ MB of text); parsing one peaks at roughly 1.1 GB of memory and takes a couple of seconds.
Related MCP server: Personal Resume Agent
npm install
npm run buildThe server finds your save and game directories from environment variables, with
WSL//mnt/c discovery as a fallback:
Variable | Purpose | Default |
| Folder containing your | auto-discovered at |
| CK3 game install (for localization) |
|
CK3_GAME_DIR is optional. Without it, titles/traits are shown as their raw game
keys instead of localized names — everything else still works.
The server reads the newest readable .ck3 in the save directory. CK3
autosaves are written in a binary token format (the same one Ironman uses)
regardless of whether you play Ironman, and the advisor can't decode it — so it
automatically skips binary autosaves/Ironman saves and uses your newest normal
save instead. You don't need to delete or rename autosaves; just keep making
ordinary saves and the freshest one is picked up.
Add it as a local stdio MCP server. In Claude Code:
claude mcp add ck3-advisor -- node /absolute/path/to/ck3mod/dist/index.jsOr in Claude Desktop, add to claude_desktop_config.json:
{
"mcpServers": {
"ck3-advisor": {
"command": "node",
"args": ["/absolute/path/to/ck3mod/dist/index.js"],
"env": {
"CK3_SAVE_DIR": "/mnt/c/Users/you/Documents/Paradox Interactive/Crusader Kings III/save games"
}
}
}
}Play CK3 (non-Ironman). Save your game whenever you want fresh advice.
Ask Claude about your realm. Each tool response is stamped with the save's in-game date and how long ago it was read, so you know how current it is.
Saved again? Just ask again — the server re-reads the newest save automatically.
Tool | What it returns |
| Ruler, primary title & tier, house, gold/prestige/piety, date. Start here. |
| Levy + total mobilised strength, and ongoing wars (side, casus belli, target, score). |
| Heirs in order, succession & gender laws, rival claimants. |
| Alliances, truces, independence, and who most dislikes you. |
| Your most powerful vassals: power owed, opinion, council seat, faction danger flag. |
| Titles you personally hold, grouped by tier, each with its de jure liege. |
| Factions targeting you: type, strength vs. their threshold, members, leader. |
| Stored claims (pressed/unpressed), unheld de jure titles, ongoing-war targets. |
| Search living characters by (partial) name → ids. |
| Full dossier for one character id: traits, skills, wealth, claims. |
| Look up any realm by name/key — ruler, army, allies, liege, active wars. |
These reflect what is and isn't stored in the save:
Names are stored in CK3's encoded form; find_character normalizes and does
best-effort substring matching, so very stylized names may not match.
Claims are reported as pressed/unpressed — CK3 does not store a strong/weak distinction in the save.
Men-at-arms are not broken out per ruler in the save; military reports the
realm's mobilisation totals.
Opinion values (e.g. in diplomacy/vassals) are approximate, summed from
stored opinion modifiers rather than the game's computed total.
Localization is English-only, ignores $KEY$ interpolation, and is
currently unverified against a real CK3 install (developed against a test
fixture). Real .yml quirks — a leading BOM, § colour codes and #
comments inside values, deeply nested subfolders — may not all be handled.
Without CK3_GAME_DIR, titles and traits appear as their raw game keys.
expansion lists stored levers (claims, unheld de jure titles, active-war
CBs), not a full computed enumeration of every possible casus belli.
npm test # run the vitest suite
npm run test:watch
npm run lint # eslint (typescript-eslint, flat config)
npm run format # prettier --write (check-only: npm run format:check)
npm run dev # run the server from source via tsxThe verified gamestate field paths the extractors rely on are documented in
docs/save-schema.md, and scripts/inspect-section.mjs
/ scripts/check-paths.mjs help map new fields against a real save.
The documented path for shipping this to non-developers is MCPB (a self-contained bundle with the Node runtime), so it can be installed without a local Node/npm setup. The current release targets the local stdio prototype above.
MIT © Thom Andretti
This is an unofficial, fan-made tool. Crusader Kings III is a trademark of Paradox Interactive AB. This project is not affiliated with or endorsed by Paradox Interactive.
Detailed dossier for one character by id — needs an id; use find_character if you only have a name. Traits, skills, gold/prestige/piety, health/stress, primary title, and claims (pressed/unpressed; CK3 does not store strong/weak).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | character id, e.g. from find_character |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true. Description adds specific data fields (traits, skills, etc.) and a note about CK3 claim storage, providing useful behavioral context beyond annotations.
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?
Two sentences, zero wasted words. First sentence states purpose and prerequisite, second lists contents. Ideal structure.
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?
No output schema, but description lists key data fields (traits, skills, gold, etc.), giving sufficient context for an agent to understand what is returned. Could mention a few more fields but still complete enough.
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 100% with parameter description. The description adds usage context ('e.g. from find_character'), which adds value beyond the schema alone.
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?
Clearly states it returns a detailed dossier for one character by id, and distinguishes from sibling tool find_character for name-based lookup. Verb 'get dossier' is implicit but clear from context.
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?
Explicitly says 'needs an id' and 'use find_character if you only have a name', providing clear guidance on when and when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Active alliances and truces, independence status, and the characters with the most negative opinion of you (approximate, from stored opinion modifiers). Does not include marriage candidates or neighbour-opinion (not stored in the save).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true; description adds that opinion values are approximate and from stored modifiers, and explains exclusions. No contradictions. Adds useful context beyond annotations.
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?
Description is extremely concise (one sentence plus exclusion note), front-loaded with key information, and every sentence adds value. No waste.
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 no parameters or output schema, description covers what data is returned and what is excluded. It is complete for a simple tool, though could mention ordering or format details.
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?
No parameters exist, so schema coverage is 100% trivially. Baseline 3 is appropriate as there is no need for parameter explanation.
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 shows active alliances, truces, independence status, and negative opinion characters. It distinguishes from siblings by explicitly listing exclusions (marriage candidates, neighbour-opinion) and implying other tools handle those.
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 provides clear context on what the tool includes and excludes, implicitly guiding when to use alternatives. However, it does not explicitly state when to use this tool vs. siblings, relying on inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stored expansion levers: your title claims (pressed/unpressed — CK3 does not store strong/weak), de jure titles in your realm that are currently unheld, and the targets of your ongoing wars. This lists STORED data, not a full computed enumeration of every possible casus belli.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds value by clarifying it returns stored data, not a computed list of all possible casus belli, which informs behavior expectations.
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?
Two sentences, front-loaded with the core content, no wasted words. It earns its place.
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 no parameters and no output schema, the description fully explains what the tool returns and the nature of the data (stored, not computed). No gaps evident.
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 zero parameters, the baseline is 4. The description adds no parameter info as none exist, and the schema coverage is complete, so no deduction is needed.
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 lists stored expansion levers including title claims, de jure titles, and war targets. It specifies that it's stored data, not computed, distinguishing it from siblings like 'titles' or 'diplomacy'.
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 the tool is for static stored info but does not explicitly state when to use it or when not to, nor does it name alternative tools like 'titles' for computed casus belli.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Factions currently targeting you: type, strength vs. the threshold that triggers their demand (peasant factions use discontent), member count, and leader.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations declaring readOnlyHint=true, the bar for behavioral disclosure is lower. The description adds value by specifying the return content (type, strength vs threshold with a special note for peasant factions, member count, leader). This goes beyond the annotation and provides useful behavioral context.
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 efficiently conveys the tool's output. It starts with the main subject ('Factions currently targeting you:') and then lists the specific attributes. No unnecessary words or repetition.
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?
While the description lists the return fields, it could be more complete by clarifying the format (e.g., that it returns a list of faction objects). Without an output schema, the description should provide more detail on how to interpret 'strength vs. the threshold' and whether the result is a summary or detailed list.
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 tool has no parameters, so schema coverage is trivially 100%. The description adds essential meaning by explaining what the tool returns, which is not present in the empty schema. It defines the fields and their significance (e.g., 'strength vs. the threshold that triggers their demand').
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 it lists factions targeting the user, specifying the fields included (type, strength vs threshold, member count, leader). This is specific and distinct from sibling tools like 'diplomacy' or 'vassals', which cover different aspects of the game realm.
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 for viewing active factions targeting the user, but it does not explicitly state when to use this tool over alternatives or when not to use it. There is no mention of context for when this information is relevant or any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search living characters by (partial) first name; returns ids to pass to character. Best-effort: CK3 stores names in an encoded form, so matching is approximate.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | full or partial first name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral details beyond annotations: approximate matching, living characters only, returns IDs. No contradiction with readOnlyHint=true.
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?
Two sentences, front-loaded with main purpose and critical usage note. 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?
Adequately covers behavior for a simple tool with one parameter. Missing explicit return format, but implied by sibling reference.
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 covers 100% of parameters. Description adds that name can be partial and explains approximate matching, adding value beyond schema.
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 it searches living characters by partial first name and returns IDs for use with another tool. It distinguishes itself from siblings like the 'character' tool.
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?
Provides guidance on approximate matching due to encoded names, implying careful use. Does not explicitly state when to avoid using, 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.
Look up any realm by name or title key (e.g. "Scotland", "k_france") — its ruler, army strength, allies, liege, and active wars. For your own realm use realm_overview.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | realm name or title key, full or partial |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description does not need to restate that. The description adds value by detailing the returned data (ruler, army, allies, etc.) and acceptable input formats (full or partial names/title keys), which aids the agent in understanding behavior beyond the schema.
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 extremely concise: one sentence explaining the tool and a brief sentence directing to an alternative. Every word contributes value with no redundancy.
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's simplicity (one required parameter, no output schema, no nested objects), the description is complete. It covers input format, output content, and provides a sibling alternative. No additional context is needed.
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% and already explains the parameter as 'realm name or title key, full or partial'. The description reinforces this with examples ('Scotland', 'k_france') but adds no new semantic information beyond what the schema provides.
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 verb 'look up' and the resource 'realm', specifies the input format (name or title key), and lists the returned information (ruler, army, etc.). It also distinguishes from the sibling 'realm_overview' by noting it is for one's own realm.
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 explicitly mentions when to use this tool ('look up any realm...') and directs the user to 'realm_overview' for their own realm, providing clear context for selection. However, it could elaborate on when not to use it beyond the own-realm case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Player's military strength (levy + total mobilised strength) and ongoing wars (side, casus belli, target, war score). Note: CK3 does not store a men-at-arms breakdown, so only realm totals are shown.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only (readOnlyHint=true). The description adds transparency by noting CK3 does not store a men-at-arms breakdown, so only realm totals are shown. It also lists the output fields for wars, providing clarity on what to expect.
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 long, with the purpose stated first, followed by a clarifying note about CK3 limitations. Every sentence is informative and necessary, with no fluff.
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 description covers the key aspects: what data is returned and a limitation. However, it does not specify the output structure when no wars exist (e.g., empty list), but this is a minor gap given the tool's simplicity.
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?
There are no parameters, so the schema coverage is 100%. The description adds value beyond the schema by explaining what the tool returns (military strength and wars). This meets the baseline expectation for a no-parameter tool.
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 returns player's military strength (levy + total mobilised strength) and ongoing wars with specific fields (side, casus belli, target, war score). This specificity distinguishes it from sibling tools like 'realm_overview' or 'vassals'.
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 for retrieving military and war data but does not provide explicit guidance on when to use it over alternatives or exclusionary cases. The context of sibling tools suggests it is the primary military info tool, but no direct comparison is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Snapshot of the player's ruler and realm: name, primary title & tier, house, gold, prestige, piety, and in-game date. Start here for 'what's my situation'. For military/wars use military; for heirs use succession.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so description adds context beyond that by specifying returned data (ruler, realm, stats) and framing it as a snapshot, implying no side effects.
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?
Three concise sentences with front-loaded content: first lists data, second provides usage, third gives alternatives. No extraneous 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?
Given no parameters and no output schema, description adequately explains purpose and usage. Minor lack of detail on output format (e.g., single object vs list) but sufficient for a simple snapshot tool.
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?
No parameters exist (0 params, 100% schema coverage), so baseline is 4. Description does not need to add param info and correctly omits it.
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?
Clearly states it provides a snapshot of the player's ruler and realm, listing specific fields (name, title, house, gold, etc.). Distinguishes from siblings by referencing military and succession tools.
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?
Explicitly says 'Start here for 'what's my situation'' and directs to 'military' for wars and 'succession' for heirs, providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Heirs for the player's primary title, in order, plus succession & gender laws and rival claimants. Note: CK3 does not store a partition preview, so which heir inherits which title is not simulated.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. The description adds valuable behavioral context by noting that CK3 does not simulate partition inheritance, clarifying a limitation beyond the annotations.
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?
Two concise sentences: first defines purpose, second adds critical limitation. No unnecessary 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?
With no output schema, the description adequately explains the return content (heir order, laws, claimants) and covers the limitation. A bit more detail on the output format could be beneficial but is not essential.
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?
There are no parameters, so schema coverage is 100%. The description adds meaning by explaining what the tool returns (heirs, laws, claimants), which is sufficient.
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 'Heirs for the player's primary title, in order, plus succession & gender laws and rival claimants', providing a specific verb (shows) and resource (succession info), and distinguishes from sibling tools like 'titles' or 'character'.
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 for viewing succession details and notes a limitation about partition preview, but does not explicitly state when to use this tool versus alternatives or provide use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Titles you personally hold (your domain), grouped by tier (empire/kingdom/duchy/county/barony), each with its de jure liege. For titles held by your vassals, see vassals.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds behavioral details like grouping by tier and inclusion of de jure liege, which goes beyond annotations.
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?
Two concise sentences with no wasted words. Information is front-loaded and directly addresses purpose and alternatives.
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 zero-parameter, read-only tool with no output schema, the description provides sufficient context about what is returned (grouped tiers with de jure liege) and when to use alternatives.
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?
No parameters exist, and schema coverage is 100%, so the description need not add parameter info. It adds context about output grouping, which is useful.
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 lists titles personally held, grouped by tier (empire/kingdom/duchy/county/barony), each with de jure liege. It distinguishes from the sibling tool 'vassals' by specifying the scope.
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?
Explicitly says when to use this tool (your domain) and when to use 'vassals' instead (titles held by vassals), providing a clear alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Your most powerful direct vassals: military power owed, approximate opinion of you, council seat, and whether they're in a faction against you (danger flag).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so description adds value by specifying the exact data returned (military power, opinion, council seat, faction flag), no contradictions.
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 sentence, front-loaded with key information, no verbose or redundant content.
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?
Despite no output schema, description enumerates the returned attributes clearly, sufficient for a simple listing tool with rich annotations.
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?
No parameters exist (schema coverage 100%), so description doesn't need param details. Baseline 4 applies.
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 it lists 'most powerful direct vassals' with specific attributes (military power, opinion, council seat, faction membership), distinguishing it from sibling tools like 'factions' or 'military'.
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?
Implicitly indicates use for checking vassal status but lacks explicit when-to-use or when-not-to-use guidance, nor mentions alternatives.
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.2characterdiplomacyexpansionfactionsfind_characterforeign_realmmilitaryrealm_overviewsuccessiontitlesvassalsScored across 11 tools
Each tool targets a distinct aspect of the game (character details, diplomacy, expansion, factions, etc.) with minimal overlap. The descriptions clarify boundaries, e.g., `character` is for a specific character vs. `realm_overview` for the player's snapshot.
All names use lowercase with underscores (snake_case). Most are noun phrases (e.g., `factions`, `titles`), while some are verb-noun (`find_character`, `foreign_realm`). The pattern is mostly consistent and clear, though not perfectly uniform.
With 11 tools, the set is well-scoped for a strategy advisor in CK3. Each tool covers a key gameplay area without unnecessary bloat, striking a good balance between breadth and focus.
The tool set covers major gameplay aspects: character, realm, military, diplomacy, succession, vassals, factions, expansion, titles, and foreign realms. Minor gaps exist (e.g., marriage candidates, detailed council info) but are explicitly noted as limitations of the stored data.
Savecraft serves real save game data and expert game knowledge to AI assistants.
Give Claude only the Google Drive files you choose. Every action logged.
Chess MCP for Claude: engine analysis, attack maps, game review. One URL, no install.
Teamfight Tactics data & AI coaching for Claude and ChatGPT — 19 tools, built-in Riot key.
