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., "@ksp-mods-mcp search for mods with tag 'parts'"
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.
MCP server for searching KSP mods from the CKAN index.
Requires uv.
uv tool install git+https://github.com/tabbykat113/ksp-mods-mcpThat's it. The index is built automatically on the first tool call.
The database is stored in your platform's data directory (~/.local/share/ksp-mods-mcp/ckan.db on Linux, AppData/Local/ksp-mods-mcp/ckan.db on Windows). Override with the CKAN_DB environment variable if needed.
You can also run harvest manually at any time to update the index — it's a no-op if nothing changed upstream.
Related MCP server: mcp-server-npm
Edit claude_desktop_config.json (find it via Settings → Developer):
{
"mcpServers": {
"ckan": {
"command": "ksp-mods-mcp"
}
}
}Use ksp-mods-mcp as the command. The server communicates over stdio.
Tool | Description |
| Search by name/author regex, tags, KSP version compatibility, cached status. Paginated. |
| Details for a mod by identifier. Selectable categories: metadata, relations, install, versions, github, spacedock, raw. |
| Related mods via dependency/recommendation relationships. Forward and reverse. Paginated. |
| All tags in the index ranked by mod count. |
| Parts inside a mod's cached ZIP. Three detail levels: summary, basic, long. |
| Full detail for a single part: formatted module stats (engine thrust/Isp, RCS, reaction wheels, etc.) and resource amounts. |
| DB stats, last harvest timestamp, and whether the CKAN download cache is detected. |
| Re-harvest the CKAN-meta archive. No-op if unchanged; use |
name — regex matched against identifier and display name, e.g. "engineer", "^MechJeb", "visual|scatter"
author — regex matched against author(s), e.g. "sarbian", "squad|nertea"
tags + tags_mode — "and" (all tags required) or "or" (any tag)
ksp_versions — e.g. ["1.12"]; matches any mod with a release supporting that version
sort_by — "downloads" (default), "downloads asc", "name", "name desc", "download_size", "install_size", "updated", "updated asc"
cached_only — only return mods whose latest-version ZIP is present in the CKAN download cache
limit / offset — pagination (max 100 per page)
identifiers — list of CKAN mod identifiers to find relations for
categories — which relationship types to include (default: depends, recommends, suggests):
Forward: depends, supports, recommends, suggests
Reverse: depends_by, supported_by, recommended_by, suggested_by
Pass ["all"] to include all categories
Results are deduplicated: if the same mod appears via multiple sources or categories, the highest-priority category wins and all source mods are listed in related_mods
limit / offset — pagination (max 100 per page)
If CKAN is installed and has downloaded mods, is_cached: true appears on any result whose latest-version ZIP is present in the local download cache. The cache directory is detected automatically (%LOCALAPPDATA%/CKAN/downloads on Windows, $XDG_DATA_HOME/CKAN/downloads on Linux). Override with the CKAN_DOWNLOAD_CACHE environment variable.
Note: is_cached reflects the latest version of a mod. If you have an older version cached but not the latest, the flag will not appear — the cached copy may not match what CKAN would install. If you're pinned to an older KSP version (e.g. 1.8.1) and intentionally keep older mod versions, use the ksp_versions filter to find compatible mods and disregard the cached status.
Both list_parts_tool and get_part_tool require a cached ZIP to work.
list_parts_tool has three detail levels:
summary — total part count and category breakdown
basic — per-part name, resolved title, and category
long — basic + cost, mass, tech node, bulkhead profiles, supported module type names, unsupported module names, and carried resource names
get_part_tool always returns full detail: all of the above plus structured module data (engine thrust, Isp, propellants; RCS thrust and propellants; reaction wheel torque; solar panel output; command pod crew; parachute drag; decoupler ejection force; docking node type; generator and converter rates; harvester efficiency) and full resource amounts. Module types with no formatter are listed by name under unsupported_modules.
git clone https://github.com/tabbykat113/ksp-mods-mcp
cd ksp-mods-mcp
uv sync
uv run harvest
uv run ksp-mods-mcpGet details for a KSP mod by its CKAN identifier.
Args: identifier: Exact CKAN identifier (e.g. "MechJeb2", "Trajectories"). Use search_mods to find identifiers first. categories: Which detail categories to include. Defaults to ["metadata"]. Available categories: - "metadata": name, abstract, authors, tags, license, version info (max_ksp_version, latest_version, last_updated_at), download_count, resources - "relations": depends, recommends, suggests, conflicts, provides - "install": install directives - "versions": full version history with per-version KSP compatibility - "github": GitHub repo stats, README preview, and latest release. Lazily fetched and cached (TTL 7 days). Includes fetched_at timestamp. - "spacedock": SpaceDock stats, descriptions, and latest version info. Lazily fetched and cached (TTL 3 days). Includes fetched_at timestamp. - "raw": full raw CKAN JSON (superset of all above) force_refresh: If True, bypass the cache TTL and re-fetch all requested enrichment categories (github, spacedock) from their sources.
Returns an error object if the mod is not found. Metadata results include is_cached: true if the mod's ZIP is in the CKAN download cache.
| Name | Required | Description | Default |
|---|---|---|---|
| categories | No | ||
| identifier | Yes | ||
| force_refresh | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so well. It discloses that github and spacedock categories are lazily fetched, cached with specific TTLs (7 days and 3 days), and include fetched_at timestamps. It also states that force_refresh bypasses cache TTL, that not-found returns an error object, and that metadata includes is_cached when the ZIP is in the CKAN cache.
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 long but justifiably so given the empty schema. The opening is front-loaded with the core purpose, the Args section is scannable, and the bullet list provides necessary category details without redundant prose.
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 all three parameters, the exact identifier requirement, all available categories, cache and refresh behavior, error handling, and the special is_cached meaning. With an output schema already present, no further explanation of return values 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 0%, so the description must fully document the parameters. It explains identifier as an exact CKAN identifier with examples, enumerates every category with its included fields, and clearly defines force_refresh. This is exemplary parameter documentation.
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 opens with 'Get details for a KSP mod by its CKAN identifier', a specific verb, resource, and key distinction. It also contrasts with sibling search_mods_tool by telling agents to use that tool to find identifiers first, and with get_part_tool by clearly targeting mods.
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 routes users to search_mods_tool to discover identifiers, which gives clear prerequisite guidance. The categories explanation helps agents choose what to request. It does not explicitly exclude alternatives like get_part_tool or list_tags_tool, but the main usage intent is unmistakable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full details for a single KSP part from a mod's cached download ZIP.
Returns structured part data including formatted stats for all supported modules (engines, RCS, reaction wheels, solar panels, etc.) and a list of unsupported module names.
Use list_parts_tool with detail="basic" first to get valid part names. Only works for mods present in the local CKAN download cache.
Args: identifier: Exact CKAN mod identifier (e.g. "CryoEngines"). part_name: Internal part name as it appears in the CFG file (e.g. "cryoengine-stromboli-1"). This is the "name" field, not the display title. Use list_parts_tool to find it.
Returns a part object with: name, title, category, cost, mass, tech_required, bulkhead_profiles, modules (list of formatted module data per supported module type), unsupported_modules (list of module type names with no formatter), resources (list of {name, amount, max_amount}). Returns an error object if the mod is not cached, the ZIP cannot be read, or the part name is not found.
| Name | Required | Description | Default |
|---|---|---|---|
| part_name | Yes | ||
| identifier | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, and it delivers: it discloses the partial-success behavior (formatted stats for supported modules plus a list of unsupported module names), and enumerates three specific failure modes returning an error object (mod not cached, ZP unreadable, part name not found). It stops short of explicitly stating this is a read-only operation, but 'Get' semantics strongly imply it.
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 longer than average, but it is organized into clear sections (summary, usage guidance, Args, Returns) and every sentence carries information. Minor redundancy: the cache constraint appears twice ('cached download ZP' in summary and 'local CKAN download cache' in usage). A small tightening would make it flawless, but structure is strong.
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 an output schema exists to cover return values, the description adds precisely the non-schema context an agent needs: the prerequisite cache condition, the correct calling sequence via list_parts_tool, full parameter semantics, and error-object behavior. For a 2-parameter read tool with no annotations, nothing critical is missing—an agent can invoke this correctly on first try without opening any other 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?
Schema description coverage is 0%, so the description must fully compensate—and it does. The Args section explains both parameters beyond the schema: identifier gets a format example and the word 'Exact'; part_name gets a CFG-file source explanation, an example, the critical warning that it's the 'name' field not the display title, and a pointer to list_parts_tool. This is model-level parameter documentation.
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 opens with a specific verb+resource: 'Get full details for a single KSP part from a mod's cached download ZIP.' This clearly distinguishes it from siblings: list_parts_tool (lists parts), get_mod_tool (mod-level data), and search_mods_tool (search). The word 'single' and the mention of module-level stats make the scope unambiguous.
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?
Explicit routing is provided: 'Use list_parts_tool with detail="basic" first to get valid part names.' It also states the hard prerequisite—'Only works for mods present in the local CKAN download cache'—so an agent knows when the tool will fail. This is exactly the when/when-not guidance that helps an agent select correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get mods related to a given list of mods via CKAN dependency/recommendation relationships.
For each result, shows the same fields as search_mods plus the relationship category and which input mods it was found through.
If the same mod appears via multiple input mods or multiple relationship types, it is deduplicated: the highest-priority category wins, and all source mods are listed.
Args: identifiers: List of CKAN mod identifiers to find recommendations for. Use search_mods to find identifiers first. categories: Which relationship categories to include. Defaults to ["depends", "recommends", "suggests"]. Available categories (in priority order): - "depends": mods that the input mods depend on - "supports": mods that the input mods declare support for - "recommends": mods recommended by the input mods - "suggests": mods suggested by the input mods - "depends_by": mods that depend on any of the input mods - "supported_by": mods that declare support for any of the input mods - "recommended_by": mods that recommend any of the input mods - "suggested_by": mods that suggest any of the input mods Pass ["all"] to include all categories. limit: Number of results per page (default 20, max 100). offset: Pagination offset (default 0).
Returns JSON with keys: total, offset, limit, results. Each result has: identifier, name, abstract, tags, authors, max_ksp_version, latest_version, last_updated_at, download_count, download_size, install_size, category, related_mods.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| categories | No | ||
| identifiers | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden and meets it thoroughly: it discloses deduplication semantics ('the highest-priority category wins, and all source mods are listed'), category priority ordering, default categories, the meaning of each relationship type (depends, supports, recommends, suggests), and the pagination defaults. No behavioral trait such as dedup or priority is hidden.
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 well organized: purpose statement first, then dedup behavior, an Args block with clean bullet points, and a return-format note. It is long, but the category definitions, priority list, and result-field enumeration earn their place rather than padding; each sentence adds operational information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 0% schema parameter coverage and no annotations, the description covers all four parameters with semantics and defaults, explains dedup and priority behavior, and enumerates the return JSON keys and per-result fields. An agent has everything needed to call the tool correctly, and the existing output schema covers the structured return contract.
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 fully compensate — and it does. identifiers comes with a workflow hint (use search_mods to find them), categories lists every option in priority order plus the special 'all' value and the default set, and limit/offset state their defaults and the max of 100. This adds substantial meaning beyond the bare schema for every parameter.
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 opening line, 'Get mods related to a given list of mods via CKAN dependency/recommendation relationships,' names a specific verb, resource, and mechanism. It clearly distinguishes this from siblings like search_mods_tool (text search) and get_mod_tool (fetch a single mod) without needing to open either schema.
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 gives an explicit workflow prerequisite — 'Use search_mods to find identifiers first' — and the purpose implicitly defines when to use it: when the agent has mod identifiers and wants related/dependent mods. However, it never explicitly states when not to use this tool or how it differs from siblings beyond the prerequisite, so exclusion guidance is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return current status of the CKAN mod index.
Reports total mod count, number with download data, number with tags, and when the index was last harvested.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently states that the tool only retrieves and reports status information, listing exactly what metrics are included and when the index was last harvested. It does not explicitly declare itself read-only, but 'Return current status' strongly implies no side effects, which is adequate for a zero-parameter status tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, front-loads the primary purpose, and immediately lists the exact reported values. Every word contributes useful information, with no fluff 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?
Given that there are no parameters, no annotations, and an output schema is present, the description is largely complete for calling the tool correctly. It could have explicitly noted that this is a read-only status check and not a refresh operation, but the lack of parameters and the simple output contract make the tool straightforward to invoke.
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 is empty with no parameters, so the baseline is 4. There is nothing for the description to add about parameter semantics, and the description appropriately focuses on the tool's output rather than inputs.
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's function: 'Return current status of the CKAN mod index.' It also enumerates the specific data returned—total mod count, number with download data, tags, and harvest time—which leaves no ambiguity about what the tool does and distinguishes it from sibling tools like refresh_index.
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 that the tool should be used when the agent needs to check the current state of the mod index, and it does not suggest any exclusions. However, it never explicitly says when to use this over alternatives such as refresh_index or list_tags_tool, so the usage guidance is left to inference rather than direct instruction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the KSP parts included in a mod's cached download ZIP.
Only works for mods whose ZIP is present in the local CKAN download cache (i.e., mods you have downloaded via CKAN). Use index_status to check whether ckan_cache_available is true, and search_mods with cached_only=true to find mods that are cached.
Parts are scanned from GameData/{identifier}/Parts/**/*.cfg inside the ZIP. Bundled dependencies under other GameData/ subdirectories are ignored. Titles are resolved from the mod's English localization file where available.
Args: identifier: Exact CKAN mod identifier (e.g. "HeatControl", "NearFuturePropulsion"). detail: Level of detail to return: - "summary": total part count and breakdown by category (cheapest) - "basic": per-part name, resolved title, and category (default) - "long": basic + cost, mass, tech_required, bulkhead_profiles, modules (list of supported module type names), unsupported_modules (list of unsupported module type names), resources (list of resource names). Use get_part_tool for full module and resource detail.
Returns JSON. On success: summary: {total_parts, categories: {CategoryName: count}} basic/long: {total_parts, categories, parts: [...]} Returns an error object if the mod is not cached or the ZIP cannot be read.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | basic | |
| identifier | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It clearly states the ZIP-scanned scope, the GameData/{identifier}/Parts/**/*.cfg path, that bundled dependencies are ignored, that localization is used for titles, and that an error object is returned on failure. This is thorough and adds significant 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 detailed but every sentence adds necessary information. It is well-structured with a clear first-sentence summary, usage constraints, scanning behavior, parameter documentation, and return format. Nothing is fluff or repeated from the schema.
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 is complete for the tool's complexity. It covers prerequisites, parameter semantics, return structure for all detail modes, and error behavior. The presence of an output schema plus this rich description leaves no meaningful gap for an agent selecting or invoking the 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?
Schema description coverage is 0%, yet the description fully compensates. It explains identifier with exact format and examples, and detail with all three allowed values, their meanings, the default, and a cost note. This is exactly the level of guidance an agent needs.
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 ('List') and a specific resource ('KSP parts included in a mod's cached download ZIP'). It clearly defines scope and differentiates itself from sibling tools like get_part_tool by focusing on enumeration rather than single-part detail.
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 states when the tool works (only for mods with ZIPs in the CKAN cache), provides concrete prerequisite checks via index_status and search_mods with cached_only=true, and directs users to get_part_tool for full module/resource detail. This is exceptionally clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all tags used in the CKAN mod index, with mod counts.
Args: limit: Maximum number of tags to return, ordered by popularity (default 50).
Returns JSON list of {tag, count} objects.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It discloses ordering by popularity, the limit parameter behavior, and the exact return shape as a JSON list of {tag, count} objects. 'List' also implies a read-only operation. It omits auth/error details, but they are not critical for a simple listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-sentence purpose, an Args section, and a Returns section. There is no filler or redundant content, and the most important purpose statement is front-loaded.
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 single-optional-parameter read-only listing tool with an output schema, the description is complete. It covers what is listed, how the limit works, ordering, and the return format. An agent has enough information 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?
Schema coverage is 0% because the schema only provides type and default. The description compensates fully by explaining the limit parameter: maximum number of tags, ordered by popularity, default 50. This gives the agent meaningful behavioral semantics beyond the bare 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 states a clear action and resource: 'List all tags used in the CKAN mod index, with mod counts.' The output is also specified as 'JSON list of {tag, count} objects.' It is easy to distinguish from sibling tools like list_parts_tool or search_mods_tool because the resource is explicitly 'tags'.
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 clearly implies when to use the tool: when an agent needs the tag vocabulary of the CKAN mod index with popularity counts. It does not explicitly mention alternatives or exclusion criteria, but the resource specificity makes the intended usage clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Re-harvest the CKAN-meta archive to update the mod index.
By default, this is a no-op if nothing has changed upstream (ETag check). Use force=True to bypass the check and rebuild unconditionally.
Args: force: Bypass ETag check and re-download/re-index everything.
Returns JSON with harvest result: status ("skipped" or "updated") and stats.
| Name | Required | Description | Default |
|---|---|---|---|
| force | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it does well: it discloses that the operation is conditional (ETag check makes it a no-op), that force=True bypasses the check and rebuilds unconditionally, and that the result is a JSON status. It could go further by noting operational costs or side effects of a forced rebuild, but the core behavioral traits are transparent.
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 compact and front-loaded: the opening sentence states the action, followed by behavior, parameter, and return-value notes. The only minor redundancy is that force semantics are stated twice ('Use force=True...' and 'Args: force...'), which is a standard docstring pattern and not wasteful.
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 single-parameter maintenance tool with an output schema, this is nearly complete: default vs. forced behavior, parameter semantics, and return shape are all covered. Minor missing context includes operational caveats (e.g., cost/duration of a forced rebuild, whether the index is briefly unavailable), but nothing required to invoke the tool correctly is absent.
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 fully compensate, and it does: it explains that force bypasses the ETag check and re-downloads/re-indexes everything, which goes beyond the schema's bare boolean type and default. The agent gets complete semantic understanding of the only parameter.
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 ('Re-harvest') plus a clear resource ('the CKAN-meta archive to update the mod index'). This clearly distinguishes it from the sibling read-oriented tools (search, get, list, status), so an agent can tell what this tool does without opening the schema.
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 explains the default behavior (no-op via ETag check) and when to use force=True, giving the agent conditional invocation guidance. However, it does not explicitly name alternatives or state when not to use this tool versus the sibling tools, so exclusion criteria are only implied by sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search KSP mods by name, author, tags, and/or KSP version compatibility, paginated.
Args: name: Case-insensitive regex matched against mod identifier and display name. Examples: "engineer", "^MechJeb", "visual|scatter" author: Case-insensitive regex matched against mod author(s). A mod matches if any of its authors match. Examples: "sarbian", "squad|nertea" tags: List of tags to filter by. Examples: ["plugin"], ["parts", "resources"] tags_mode: How to combine multiple tags — "and" (mod must have all tags, default) or "or" (mod must have at least one tag). ksp_versions: KSP game versions to filter by. A mod matches if any of its released versions supports at least one of the given KSP versions. Uses prefix matching, so "1.12" matches "1.12.0", "1.12.5", etc. Examples: ["1.12"], ["1.11", "1.12"] sort_by: Sort order — "downloads" (default), "downloads asc", "name", "name desc", "download_size", "download_size asc", "install_size", "install_size asc", "updated", "updated asc". cached_only: If True, only return mods whose ZIP is present in the local CKAN download cache. Requires CKAN to have been used to download mods. limit: Number of results per page (default 20, max 100). offset: Pagination offset (default 0).
Returns JSON with keys: total, offset, limit, results. Each result has: identifier, name, abstract, tags, authors, max_ksp_version, latest_version, last_updated_at, download_count, download_size (bytes), install_size (bytes). Results include is_cached: true only for mods present in the CKAN download cache.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| tags | No | ||
| limit | No | ||
| author | No | ||
| offset | No | ||
| sort_by | No | downloads | |
| tags_mode | No | and | |
| cached_only | No | ||
| ksp_versions | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does so thoroughly: it discloses case-insensitive regex matching, match-any-author semantics, tags_mode combination rules, KSP version prefix matching, the cached_only requirement, and the conditional presence of is_cached in results. This goes well beyond a simple 'search' statement.
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 summary sentence is front-loaded, and the Args section is tightly structured with each parameter earning its place through concrete examples and operational details. No filler or redundant restatement of the schema exists.
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 9-parameter, 0-required search tool with no annotations, the description is complete: it defines all input behaviors, lists all sort options, clarifies the cache filter, and documents the response keys. An agent has enough context to select and invoke this tool correctly without further investigation.
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%, but the description supplies rich semantics for every parameter: regex examples for name and author, tag combination logic, ksp_versions prefix matching, sort_by enumerations, limit/offset defaults and bounds, and the cached_only behavior. This fully compensates for the schema's lack of 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 opens with a specific verb and resource: 'Search KSP mods by name, author, tags, and/or KSP version compatibility, paginated.' This clearly distinguishes search_mods_tool from sibling tools like get_mod_tool (single mod lookup), list_tags_tool (tag enumeration), and index_status (index health).
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?
Usage context is implied by the search-focused description and detailed parameter semantics, but it never explicitly says when to prefer this tool over get_mod_tool, list_tags_tool, or other siblings, nor does it mention any alternatives. The guidance is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0get_mod_toolget_part_toolget_recommendations_toolindex_statuslist_parts_toollist_tags_toolrefresh_indexsearch_mods_toolScored across 8 tools
Each tool maps to a distinct operation: searching, fetching a mod, getting recommendations, listing tags/parts, getting part details, checking status, or refreshing the index. The only related pair is list_parts_tool/get_part_tool, but their descriptions clearly separate summary/basic listing from full part detail. No two tools appear to do the same thing.
Most tools follow a verb_noun_tool pattern (search_mods_tool, get_mod_tool, list_tags_tool, list_parts_tool, get_part_tool). Two tools, index_status and refresh_index, deviate by omitting the _tool suffix, and index_status is a noun phrase rather than a verb phrase. Still, all names are snake_case and readable.
Eight tools is an appropriate size for a KSP mod metadata and part-inspection server. Each tool has a clear role, with no bloated or redundant surface. The scope is substantial but easy to navigate.
The server covers mod discovery, detailed metadata and relationships, recommendations, tag taxonomy, and inspection of cached mod ZIPs and parts. It also provides index maintenance via refresh_index and cache awareness via index_status and cached_only search. For a read-only CKAN-based mod server, the tool set is essentially complete.
MCP registry & directory: search, find & install 31k+ MCP servers & tools. Catalog and marketplace.
Search the official MCP registry: 17,000+ servers with trust grades, stars, tools, install config.
Public MCP server for discovering open jobs. Search, filter, and get application links.
Publish and discover MCP servers via the official MCP Registry. Powered by HAPI MCP server.
