Click on "Install 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., "@cities2-mcp how do I increase land value?"
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.
Cities2 MCP and Modding Toolkit is a local MCP server and agent skill bundle for Cities: Skylines II gameplay questions, patch notes, and mod project workflows.
It gives AI agents access to a bundled, searchable Cities: Skylines II Wiki corpus, separately attributed curated research reports, and, when the game is installed locally, the in-game encyclopedia. Agents can use those sources to answer gameplay questions, summarize patch/update information, and explain city systems with source notes. The package also includes five agent skills for game knowledge, modding, review, debugging, and release readiness, plus local MCP workflow tools for scaffolding, inspecting, building, and packaging CS2 mod projects inside trusted workspaces.
The plugin is in active development. Package checks, direct MCP smoke tests, and selected client workflows are covered in the repository test suite and eval reports, but client plugin behavior can vary by host and version. See the known issues and eval reports for the latest verification notes.
Choose your client: Claude Code | Claude desktop | Codex CLI | Codex app | Google Antigravity
See INSTALL.md for full installation details, direct MCP config, workspace setup, build prerequisites, and troubleshooting.
Related MCP server: MCP Documentation Server
The MCP server includes a prepared text corpus from the Cities: Skylines II Wiki. An AI assistant can:
search the wiki
retrieve full pages, page-level references, and code-oriented snippets for game systems, patch notes, and modding topics
answer questions about game mechanics, recent updates, and how city systems affect your save
The MCP server also bundles curated Cities: Skylines II research reports. These reports are historically situated, separately attributed, and generated from committed research notes rather than raw transcripts. Results retain publication and source context so an assistant can distinguish time-bounded findings from current game behavior and APIs.
When Cities: Skylines II is installed locally, the MCP server reads the game encyclopedia from the installed game files. This source is enabled by default when the server can find Cities2_Data/Content/Game/Locale.cok.
The extracted encyclopedia index is cached locally on the user's machine and rebuilt only when the source game file, detected Steam build id, locale, or extractor version changes. Extracted game text is not committed to this repository, shipped in releases, or part of the redistributed wiki corpus.
The server also includes local workflow tools for CS2 mod projects. An AI assistant can:
scaffold C# code, UI, or hybrid mod project templates
write files inside configured workspaces
list project trees
run project builds and analyzers
package project output
These tools are meant for local development workflows. Claude, Codex, and Antigravity can use them to write and run trusted workspace code during builds, so configure workspaces deliberately and use manual playtesting before treating any mod as ready to share.
cities2-knowledge: answers gameplay, city-system, and player-facing patch/update questions.
cities2-modding: handles general modding questions and local mod project workflows.
cities2-mod-review: reviews CS2 mods for safety, maintainability, user value, packaging hygiene, and verification gaps.
cities2-mod-debugging: helps debug CS2 mod build, packaging, runtime, log, UI debugger, and in-game behavior issues.
cities2-mod-release: checks whether a mod is ready to share.
The modding quality skills use documented CS2 best practices and negative constraints as defaults, and they do not present a mod as ready to share until it has been locally playtested.
The MCP server runs locally and does not collect telemetry. See PRIVACY.md for details.
The MCP server code is licensed under the MIT License. The included wiki corpus is licensed under Creative Commons Attribution-ShareAlike 3.0; its source attribution and transformation notes are in the wiki corpus attribution. The curated research corpus is separately attributed, and its original report prose follows the repository license; see the research corpus attribution.
This project is not developed by, endorsed by, reviewed by, or approved by Paradox Interactive, Iceflake Studios, Colossal Order, Paradox Wikis, or any related company. Cities: Skylines II and related names are used referentially.
Run static checks for Cities: Skylines II mod project structure and lifecycle patterns.
| Name | Required | Description | Default |
|---|---|---|---|
| strict | No | ||
| profile | No | auto | |
| project_dir | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds 'static checks' which aligns, but no additional behavioral details are provided.
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 verb and resource, with 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?
Without output schema and with incomplete parameter semantics, the description fails to equip the agent for correct invocation, especially regarding what the tool returns and how to configure it.
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 0%, and the description provides no explanation for parameters 'strict', 'profile', or 'project_dir', leaving the agent without necessary context.
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 runs static checks for Cities: Skylines II mod projects, distinguishing it from sibling tools like scaffold_project or build_project.
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 on when to use vs alternatives like build_project or list_project_tree; usage is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a Cities: Skylines II mod project and return normalized diagnostics. This executes trusted workspace code; do not use it for arbitrary untrusted repositories.
| Name | Required | Description | Default |
|---|---|---|---|
| clean | No | ||
| steps | No | ||
| package | No | ||
| profile | No | release | |
| project_dir | Yes | ||
| timeout_sec | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate it's not read-only (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds that it executes trusted workspace code, which clarifies the nature but doesn't detail specific side effects or requirements beyond that. Moderate value added.
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, concise and front-loaded with the primary action. No fluff. Could be slightly more structured, but effective.
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?
Tool has 6 parameters and no output schema. Description fails to explain return format, parameter roles, or behavioral nuances. Given complexity, the description is incomplete.
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 0%, so description must compensate. It does not mention any parameters or their meanings, leaving the agent to infer from names alone. This is insufficient for a tool with 6 parameters.
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 builds a Cities: Skylines II mod project and returns normalized diagnostics. The verb 'build' and resource are specific. However, it does not differentiate from sibling tools like 'package_project', which may cause confusion.
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 only warns about using for trusted workspace code, but provides no guidance on when to use this tool versus alternatives (e.g., 'package_project', 'scaffold_project'). No explicit when-to-use or when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return one local Cities: Skylines II in-game encyclopedia entry by entry_id.
| Name | Required | Description | Default |
|---|---|---|---|
| entry_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly and idempotent behavior; description adds no additional behavioral context such as error handling or response format.
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?
Extremely concise single sentence, 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?
Given low complexity, description is minimal and fails to address missing entry_id or return value details, even without output schema.
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?
Description mentions entry_id identifies the entry, but with 0% schema coverage, lacks details on format or constraints.
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 the tool returns one encyclopedia entry by entry_id, with specific verb and resource, and distinguishes from sibling search_encyclopedia.
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?
Implies usage when entry_id is known, but no explicit guidance on when to use this vs alternatives like search_encyclopedia.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a full page from the bundled Cities: Skylines II Wiki corpus or research datasets by page_id. Results include dataset labels. Research evidence is time-bounded; check publication dates for current details.
| Name | Required | Description | Default |
|---|---|---|---|
| page_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, idempotentHint, destructiveHint) indicate it's a safe read operation. The description adds useful behavioral details: results include dataset labels, and research evidence is time-bounded, 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 sentences deliver the core function and key behavioral notes. No superfluous text; front-loaded and efficient.
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 read tool with one parameter and no output schema, the description covers source, output description (dataset labels), and a temporal caveat. Sufficient for its complexity.
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?
Only parameter is page_id (string), described simply as 'by page_id'. With 0% schema coverage, the description should explain the parameter's meaning, format, or examples. It does not.
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 action (return), resource (full page), and source (bundled wiki corpus or research datasets). It distinguishes from siblings like get_encyclopedia_entry and get_snippets by specifying full page retrieval by ID.
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 context about dataset labels and time-boundedness but lacks explicit guidance on when to use this tool versus siblings. No exclusions or alternative tool names are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve Cities: Skylines II modding code snippets extracted from the bundled wiki corpus.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true, making the behavior clear. The description adds no extra behavioral details beyond confirming it is a retrieval operation. With annotations covering the safety profile, the description provides minimal added value.
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, no fluff. However, it could be more informative without adding length, such as noting default limit behavior.
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?
Simple tool with 2 parameters and no output schema. Description covers purpose but lacks usage guidance and parameter details. Given the context of sibling tools and annotations, it is minimally adequate but leaves gaps.
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 0%, meaning no parameter descriptions exist. The tool description does not mention the 'query' or 'limit' parameters, leaving the agent with no additional meaning beyond raw schema types and defaults. This fails to compensate for the lack of schema descriptions.
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 verb 'retrieve' and the specific resource 'Cities: Skylines II modding code snippets extracted from the bundled wiki corpus'. It distinguishes from sibling tools like get_encyclopedia_entry and search by focusing on code snippets.
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 guidance on when to use this tool versus alternatives. No mention of prerequisites, query structure, or comparison with similar tools like search or get_page.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List files in a configured Cities: Skylines II mod project workspace.
| Name | Required | Description | Default |
|---|---|---|---|
| glob | No | **/* | |
| max_files | No | ||
| project_dir | Yes | ||
| include_hidden | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false; the description adds context that it lists files, confirming it's a read operation without further behavioral details like rate limits or prerequisites.
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 single-sentence description is concise but omits important parameter details, making it too brief for the tool's complexity.
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 4 parameters, no output schema, and no schema descriptions, the description lacks enough detail for an agent to use it correctly; it only states the basic action.
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 fails to explain any of the 4 parameters (project_dir, glob, max_files, include_hidden), leaving the agent without necessary context for correct invocation.
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 'list' and the resource 'files in a configured Cities: Skylines II mod project workspace', which is specific and distinct from sibling tools like 'write_project_file' or 'build_project'.
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 listing project files but provides no explicit guidance on when to use this tool versus alternatives like 'search' or no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a zip package for a Cities: Skylines II mod project.
| Name | Required | Description | Default |
|---|---|---|---|
| output_dir | No | ||
| project_dir | Yes | ||
| package_name | No | ||
| exclude_globs | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true, but description doesn't elaborate on what 'creation' entails (e.g., whether it overwrites existing output, reads the entire project directory, or validates the project structure). Provides little beyond what annotations already imply.
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 short sentence, which is concise but lacks necessary detail. It is not structured to highlight key aspects like parameters or behavior.
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 4 parameters, a destructive hint, no output schema, and is part of a suite of project tools, the description is far too minimal. It should explain the packaging process, output location, and any constraints (e.g., required file structure).
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 explain parameter meanings. It does not mention output_dir, package_name, or exclude_globs at all, leaving the AI to guess their roles.
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 creates a zip package for a specific game mod project, with a strong verb ('Create') and a specific resource ('zip package'). It distinguishes from siblings like build_project which likely compiles code rather than packaging.
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 guidance on when to use this tool vs alternatives (e.g., build_project). Doesn't mention prerequisites like having a project already scaffolded, or that packaging is typically the final step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search page-level Cities: Skylines II Wiki corpus and research dataset references: titles, sections, URLs, and links. Results include dataset labels. Research evidence is time-bounded; check publication dates for current details.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds that research evidence is time-bounded and results include dataset labels, providing context beyond annotations. 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?
Three sentences, front-loaded with the action. No redundant information, but could be slightly more efficient.
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, so description should explain return values. It mentions dataset labels and time-bounded evidence but not full structure. Adequate but not fully complete given the search complexity.
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 has 2 parameters with 0% description coverage. The description mentions searched content but does not explain the 'query' parameter format or 'limit' semantics. More detail is needed for a tool with no schema descriptions.
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 page-level references from a specific wiki and research dataset, specifying what is searched (titles, sections, URLs, links). It distinguishes from siblings like search and get_encyclopedia_entry.
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 finding wiki references but does not explicitly state when to use this tool vs alternatives. It mentions time-bound research evidence, which is a guideline, but lacks when-not-to-use or sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scaffold a Cities: Skylines II mod project from a template.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| options | No | ||
| metadata | No | ||
| template | Yes | ||
| target_dir | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are present but limited. The description does not disclose behavioral traits beyond what annotations provide. It does not mention that the tool creates files, whether it overwrites existing content, or any side effects. With annotations providing only readOnlyHint=false and destructiveHint=false, the description should add context about file creation behavior but fails to do so.
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 clear sentence with no wasted words. However, it is too minimal for the tool's complexity, sacrificing necessary 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?
Given the complexity (5 parameters, nested objects, no output schema, limited annotations), the description is severely incomplete. It does not explain what 'scaffold' means, what the output is, prerequisites, or how to use the parameters. The tool needs significantly more context for an agent to use it 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?
Schema description coverage is 0%, so the description must compensate. It only mentions 'template' indirectly ('from a template') but does not explain the meaning or purpose of parameters like 'name', 'options', 'metadata', or 'target_dir'. The description adds no meaningful semantic value beyond the parameter names.
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 action ('scaffold'), the resource ('a Cities: Skylines II mod project'), and the source ('from a template'). It distinguishes this from sibling tools like 'build_project' or 'write_project_file' by the verb 'scaffold', implying initial project creation. However, it does not explicitly differentiate from siblings.
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 no guidance on when to use this tool versus alternatives. It does not mention prerequisites, context (e.g., when an existing project already exists), or when to use other tools like 'build_project' or 'package_project'. There are no exclusions or alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the bundled Cities: Skylines II Wiki corpus and research datasets for gameplay, systems, and modding information. Results include dataset labels. Research evidence is time-bounded; check publication dates for current details.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds value by disclosing that results include dataset labels and that research evidence is time-bounded, which are useful behavioral traits not captured in 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?
The description is concise with two focused sentences. It front-loads the core purpose and immediately provides important context (dataset labels, time-boundedness). 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?
Given the lack of output schema and zero parameter coverage, the description is incomplete. It does not explain what constitutes a valid query, how to use the limit parameter, or what the output structure looks like beyond mentioning dataset labels. An agent needs more guidance to use this tool effectively.
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 0%, so the description bears full responsibility for explaining parameters. It mentions 'query' only implicitly and provides no details about the 'limit' parameter, query formatting, or expected input. This is insufficient for an agent to craft proper queries.
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 a specific corpus (Cities: Skylines II Wiki and research datasets) and specifies the type of information (gameplay, systems, modding). It mentions dataset labels and time-bounded evidence. However, it does not explicitly differentiate from sibling 'search_encyclopedia', leaving some ambiguity about which search to use.
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 the bundled wiki and research datasets, and notes that research evidence is time-bounded. It does not provide explicit guidance on when to use this tool versus alternatives like 'search_encyclopedia' or other sibling tools, nor does it specify prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the local Cities: Skylines II in-game encyclopedia read from the user's installed game files.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds that the tool reads from local installed game files, which is consistent and provides marginal context beyond the annotations. 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 that is concise and front-loaded with the core purpose. However, it could be slightly longer to include parameter hints or usage notes without becoming verbose.
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 12 sibling tools and no output schema, the description provides insufficient differentiation. It does not explain return format, pagination, or how results compare to similar tools, leaving the agent underinformed.
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 0%, and the description does not explain the meaning of the 'query' or 'limit' parameters, leaving the agent to guess their purpose and usage.
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 local Cities: Skylines II in-game encyclopedia, specifying the source as the user's installed game files. This clearly differentiates it from siblings like 'get_encyclopedia_entry' which likely retrieves a single entry.
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 guidance on when to use this tool versus alternatives like 'get_encyclopedia_entry' or 'query_reference'. There is no mention of context, when not to use, or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report Cities2-MCP source availability for the wiki corpus, bundled research datasets, and local game encyclopedia.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context about what sources are reported (wiki, research datasets, game encyclopedia) but no additional behavioral traits like rate limits or authorization needs.
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 of 14 words, conveying the essential purpose without any 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?
For a simple status tool with no output schema, the description indicates it 'reports ... source availability' but does not specify the return format or structure. This leaves ambiguity about what the agent will receive.
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 no parameters, the description needs to add no parameter-level detail. The schema coverage is 100% (trivially), so the baseline for zero parameters is 4.
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 'Report' and clearly identifies the resources: 'Cities2-MCP source availability for the wiki corpus, bundled research datasets, and local game encyclopedia.' This distinguishes it from sibling tools like get_page or search.
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 no guidance on when to use this tool versus alternatives. It does not mention when not to use it or which sibling tool is better for specific scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write files inside a configured Cities: Skylines II mod project workspace.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | upsert | |
| content | Yes | ||
| project_dir | Yes | ||
| relative_path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, so the description adds limited behavioral context. It does not elaborate on side effects, directory creation, or error states. The mode parameter is not explained, but the overall mutation intent is clear.
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 with no extraneous words. However, it omits necessary parameter details, making it too terse for the tool's complexity. Concise but incomplete.
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 destructive nature (destructiveHint true), lack of output schema, and four parameters with zero description, the description fails to provide sufficient context for safe and correct usage. It does not cover return values, error conditions, or behavior beyond the basic file write.
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 0%, yet the description adds no information about parameters. The meanings of project_dir, relative_path, content, and mode (especially the default 'upsert') are left entirely to the agent, making the tool hard to invoke without outside knowledge.
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 writes files within a configured mod project workspace. It distinguishes from sibling tools like scaffold_project (create project structure) and build_project (compile), but does not explicitly contrast them or detail the scope of file writing.
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 usage guidance is provided. The description does not indicate when to prefer this tool over alternatives, when not to use it, or any prerequisites. Sibling tools are listed but not compared.
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. Dates show when Glama detected each change.
v0.1.0analyze_projectbuild_projectget_encyclopedia_entryget_pageget_snippetslist_project_treepackage_projectquery_referencescaffold_projectsearchsearch_encyclopediasource_statuswrite_project_fileEach tool has a clearly distinct purpose: encyclopedia entries, wiki/reference search, mod project scaffolding and management, and status reporting. No two tools appear to overlap in functionality.
Almost all tools follow a verb_noun pattern in snake_case (e.g., get_encyclopedia_entry, scaffold_project). Minor deviations include 'source_status' and 'search', but they are still clear and consistent with the overall style.
With 13 tools, the set is well-scoped for a modding assistant covering reference lookup, code search, project scaffolding, build, and analysis. Each tool serves a clear purpose without bloat.
The toolset covers the key aspects of mod development: reference retrieval, scaffolding, file management, building, analysis, and packaging. A minor gap is the absence of a tool to delete or clean up project files, but core workflows are complete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
An MCP server that gives your AI access to the source code and docs of all public github repos
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
MCP server for generating rough-draft project plans from natural-language prompts.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mayor-modder/Cities2-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
