HMCL MCP Server

by vfyjxf

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource (HMCL setup, agent lifecycle, versions, modpacks, game launch) with clear verbs like install, start, stop, list, search, get, download. No two tools perform the same action on the same resource, and descriptions make boundaries explicit.
Naming Consistency5/5
All tool names follow a consistent verb_noun snake_case pattern, with paired verbs (start/stop, launch/stop, install/list) and objects (hmcl, versions, modpacks, game). This makes the API predictable and easy to navigate.
Tool Count5/5
13 tools is well within the ideal 3-15 range and covers setup, environment, modpacks, versions, and game control without redundancy or bloat. Each tool has a clear, non-overlapping role.
Completeness4/5
The server covers core workflows: install/setup, status checking, version installation and listing, modpack search/download/install/list, and game launch/stop. Minor gaps like uninstall/delete tools or per-mod management are not critical for the stated purpose.
Average 4.2/5 across 13 of 13 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It names the endpoint and the basic action but does not disclose side effects (e.g., abrupt termination, unsaved progress), error behavior when no game is running, or whether the operation is idempotent. This is a minimal mutation disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately states the action, includes the endpoint for useful context, and contains no filler words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless stop operation, the description is adequate but incomplete. It does not mention expected responses or result behavior, and with no output schema or annotations, an agent must infer success/failure semantics. However, the 0-param complexity keeps this at a minimum viable level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is an empty object with 100% coverage. Baseline for 0 params is 4, and the description adds no unnecessary param detail, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Stop the currently running game process' and includes the endpoint 'POST /launch/stop'. This distinguishes it from sibling tools like stop_hmcl, which would stop a different process.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives such as stop_hmcl or launch_game. The phrase 'currently running game process' implies a condition, but no prerequisites, exclusions, or context about the intended workflow are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the download destination, SHA-1 verification, default version behavior, and the return object structure. However, it does not mention permission requirements, overwrite behavior, or any side effects beyond writing to <workdir>/mcpacks/. With no annotations, these traits are not covered elsewhere.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences contain destination, verification, parameter usage, and return format, with no superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Considering the tool has 3 parameters and no output schema, the description covers the primary action, a key behavioral detail (SHA-1), default version selection, and the full return object structure. It misses explanations for id and source, but overall is sufficiently complete for a download tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description clarifies the versionId parameter and its default behavior, and references get_modpack as the source of version names. It does not explain the id parameter (likely the modpack identifier) or the source parameter, though the enum values are self-explanatory. With 0% schema coverage, this is partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool downloads a modpack file via HMCL to a specific directory, with specific behavior (SHA-1 verification). This distinguishes it from sibling tools like install_modpack, which presumably installs the modpack.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the versionId parameter ('a version name from get_modpack') and defaulting to latest, but offers no explicit guidance on when to choose this over install_modpack or other siblings. It provides context but no when-not/alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It does explain the output structure (summary, available versions, latest version), but it omits potential prerequisites like needing HMCL to be started or installed, and any side effects (though 'get' implies read-only). It adds some useful context like 'through HMCL', but not enough to fully satisfy transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that efficiently conveys the tool's purpose, input semantics for the key parameter, and expected output fields. No redundancy or unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives a good overview of what the tool returns and the input id format, but it leaves out important context: what 'through HMCL' implies (e.g., whether HMCL must be running), and the role of the optional 'source' parameter. Without an output schema or annotations, these gaps reduce completeness for an agent deciding whether to invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage, so the description must compensate. It explains the 'id' parameter as 'Modrinth slug or CurseForge slug', which is helpful, but it does not explain the 'source' parameter at all, even though it has an enum. This omission is significant, especially since source disambiguates the id platform.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get details of a modpack project' with a specific verb and resource. It also distinguishes from siblings like search_modpacks, download_modpack, and install_modpack by focusing on retrieving summary and version details for a specified id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on usage: it's for retrieving details of a modpack by its Modrinth or CurseForge slug, and it specifies the returned information. However, it does not explicitly mention when not to use it or name alternative tools, so it's not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds useful context about the embedded CurseForge API key and the return type, but does not explicitly state read-only behavior, rate limits, pagination, or default limits. The 'search' verb implies no side effects, but this is not explicitly disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main verb, and includes only essential details. Every sentence contributes value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the return value shape (ModpackSummary[] with fields) and the special API key detail, which is important context. However, it omits default source/limit, pagination, and error scenarios. For a search tool with no output schema, this is mostly complete but missing some operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate for parameter meanings. It indirectly explains the 'source' parameter by naming Modrinth and CurseForge, but does not mention 'query' or 'limit' at all, leaving two of three parameters unexplained beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb 'Search' and resource 'modpacks', and clearly distinguishes from siblings by specifying the repositories (Modrinth/CurseForge). It differentiates from list_modpacks and get_modpack by focusing on search behavior and return type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates the tool's purpose (searching modpacks) and context (HMCL repositories), implying when to use it. However, it does not explicitly contrast with alternative tools like list_modpacks or get_modpack, nor state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses downloads (version json, client jar, libraries), destinations (<workdir>/versions/<id>/ and <workdir>/libraries/), duration ('can take a few minutes'), and asset behavior (downloaded by HMCL at first launch). This is rich behavioral context, though it doesn't state overwrite behavior or return status.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with action, no redundant phrases. Every sentence adds meaningful detail about install behavior and locations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter install operation with no output schema, the description covers the key aspects: what, where, time, and asset handling. It does not explicitly mention prerequisites (e.g., HMCL already installed) or what happens on success/failure, which prevents a higher score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already describes the version parameter with an example. The description adds little beyond restating the example and context, so it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Install') and identifies the resource ('a vanilla Minecraft version'), with an example '1.20.4'. It distinguishes from siblings like install_modpack by specifying 'vanilla' and 'through the HMCL agent'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for installing a specific vanilla version but does not explicitly state when to use it over alternatives or mention exclusions. For example, it doesn't say 'use install_modpack for modpacks' or note that HMCL must be installed first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses important behavioral details such as the loopback probe with short timeout, and the null java when no JDK is found. It could be more explicit about being read-only with no side effects, but the disclosed details are valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence listing all relevant outputs, followed by two short, high-value sentences about usage and a null case. Every sentence earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains return values: java info, workdir, directory contents, JVM status, and counts. It lacks specifics about error behavior or timeout outcomes, but the core diagnostic information is thoroughly covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters and the schema shows no properties, so there is nothing to document. Per calibration, a baseline of 4 is appropriate; the description does not need to add parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Report the current environment' and then enumerates specific outputs (java path/version, workdir, hmcl dir contents, JVM running status, counts). This clearly distinguishes it from sibling tools like install_hmcl or launch_game, which perform actions, while this tool is purely diagnostic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Run this first to diagnose setup problems' gives explicit guidance on when to use the tool and implies it should precede other tools. It does not mention alternatives or exclusions, but given the tool's diagnostic nature, this is sufficient context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses several behavioral traits: the installation path, the default instance name, and the HMCL agent dependency with automatic startup. It goes beyond a minimal statement by revealing these operational details, though it does not cover edge cases like overwrites or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long and front-loaded with the main purpose. Each sentence adds necessary information: core action, input modes, and the HMCL requirement. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 optional parameters and no output schema, the description covers the main usage scenarios, dependencies, and naming default. However, it omits the source parameter explanation and potential side effects. Given the tool's complexity, this is a solid but not exhaustive description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions for its 5 parameters, but the description explains path, id, versionId, and name, including the name default. The 'source' parameter is not addressed, leaving one parameter unclarified. Overall, the description compensates well for the lack of schema-level documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: installs a modpack as a game instance under a specific path. It distinguishes from siblings like download_modpack and install_hmcl by focusing on installation and mentioning both local file and remote download modes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the two input modes (local path or id) and notes the HMCL agent requirement with auto-start. It provides clear context but does not explicitly state when to use this tool over alternatives such as download_modpack, so no exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It transparently lists the side effects: downloading from GitHub, running a build script, copying files, and returning paths. The note 'Safe to re-run' adds important idempotency context. It does not mention potential failure modes or network requirements, but the core behavioral traits are clearly disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the primary intent, then logically walks through the install steps. Every clause adds necessary information—checking, downloading, building, copying, returning, and idempotency—with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex multi-step tool with no parameters and no output schema, the description is remarkably complete: it covers the conditional download, the build command with a prerequisite, the file placement, and the return value. The 'safe to re-run' note enhances completeness. No critical information appears missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
This tool has zero parameters, so the baseline is 4 per the rubric. The description appropriately focuses on the procedural steps rather than inputs, and the schema has nothing left undocumented. No additional parameter meaning is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the specific verb 'Prepare' and the resource 'HMCL directory', then details the exact steps: conditional download, build via node script, and copying artifacts. This clearly distinguishes it from sibling tools like start_hmcl and stop_hmcl, which focus on lifecycle, and check_environment, which validates prerequisites.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides solid usage context by specifying the install/prepare workflow and stating that it is safe to re-run, implying idempotency. It also calls out a key requirement ('requires javac on PATH'). However, it does not explicitly state when to prefer this over alternatives or mention a scenario where it should not be used, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It explains that the game runs as a separate child process, the window opens normally, the account is offline, and parameters modify defaults. This is far beyond a minimal 'launches a game' statement and provides meaningful 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: purpose, parameter meanings, and runtime behavior. Every sentence adds necessary information without redundancy, and the most important purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 5 parameters, no annotations, and no output schema, the description is quite complete: it covers all inputs and the execution model. It could be more complete by mentioning prerequisites (e.g., HMCL must be installed) or how to stop the launched game, but the essential information is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explains every parameter: version is an instance id, username defaults to Steve, maxMemory is in MB, javaPath overrides the Java used, and extraArgs are appended after the default JVM args. This fully compensates for the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific action ('Launch') and a specific resource ('a game instance'), and it adds the offline-account detail. This distinguishes it from sibling tools like start_hmcl (which starts the launcher) and stop_game (which stops a game).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context by pointing to list_versions/list_modpacks for finding a version id, but it never explicitly states when to use this tool instead of alternatives or when not to use it. The correct usage is implied by the name and purpose, not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the scanning path, return structure, format mapping, and best-effort reads. It does not cover error handling or permissions, but for a read-only listing tool, the details given are sufficient and transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences deliver all essential information without redundancy. Every clause adds value: scanning path, output shape, format mapping, best-effort caveat, and the launch_game link. The description is dense yet coherent, earning a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no parameters, the description fully specifies the tool's behavior and return format. It also situates the tool within the broader workflow via the launch_game link. No critical information is missing for an agent 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds context by explaining the output fields and how `name` relates to launch_game, which effectively covers the semantics of the implicit data the tool returns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the function: 'List installed modpacks' with a specific scanning path. It distinguishes from sibling tools like search_modpacks and list_versions by specifying the source and output format. The linkage to launch_game (passing name as version) further clarifies its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 does and hints at its use for launching games, but does not explicitly mention when not to use it or name alternatives. It gives a practical usage tip ('pass it as version to launch_game'), which is helpful guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden. It discloses the scanning location, the exact criterion for what counts as a version, the return shape, and sort order. This is strong behavioral disclosure for a simple listing tool, though it does not cover error handling or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, dense sentence provides all necessary information without filler. Every clause adds value: what is listed, where it scans, the version criterion, the return structure, and the sort order.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though there is no output schema, the description explicitly specifies the return object format and sorting, making the behavior fully predictable. For a parameterless read-only list tool, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there are no parameter semantics to describe. According to the rubric, a baseline of 4 applies; no additional parameter information is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('installed game versions') and clearly distinguishes itself from siblings like install_version and list_modpacks. The scanning behavior and version-detection rule add precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the tool is for retrieving existing installed versions and provides context about how detection works. It does not explicitly name alternatives or exclusions, but the read-only listing nature is unmistakable next to installation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses several behavioral traits: headless (GUI never opens), idempotent (no-op if already running), and the specific return payload structure. This goes beyond the name and helps the agent predict side effects and output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and front-loaded with the core action. It packs essential details (headless, no-op, return fields, GUI behavior) without any filler. The mention of 'per ensureAgent' is slightly internal but does not detract from the overall efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description is remarkably complete. It explains what happens, when it does nothing, what it returns, and how it interacts with the game window. This gives an agent all the information needed to invoke and interpret the result, especially given the sibling context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema coverage is effectively 100%. The description does not need to explain any parameter semantics. According to the rubric, the baseline for 0 parameters is 4, which is appropriate here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Start[s] the headless HMCL JVM with the injected javaagent' and returns agent status. The verb 'start' plus the specific resource distinguishes it from siblings like stop_hmcl or launch_game. It also notes the no-op behavior, adding further clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this is a headless start that returns agent status, implying it is a prerequisite for launching games. However, it does not explicitly mention when to use it versus alternatives like launch_game, nor does it include exclusions. The purpose is obvious enough that an agent would know when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It explains the shutdown mechanism, the verification status probe, and the failure mode when no agent is reachable. This is good transparency, though it could mention idempotency or side effects, but for a simple stop tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. The first front-loads the action and method, the second adds verification and failure condition. Every sentence earns its place with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple stop tool with no parameters and no output schema, the description covers the purpose, method, verification, and failure condition. It is complete enough for an agent 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is an empty object, covering 100% of the parameter space. The baseline for 0-parameter tools is 4, and the description adds no unnecessary parameter details, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool stops the headless HMCL JVM, distinguishing it from sibling stop_game. It specifies the action (POST /shutdown) and verification step, providing a clear, specific verb+resource definition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: stop the HMCL JVM and verify its shutdown. It also notes a prerequisite ('run start_hmcl first') and failure condition, which helps the agent know when to use it. However, it does not explicitly contrast with stop_game or other alternatives, leaving some room for interpretation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![HMCL-MCP MCP server](https://glama.ai/mcp/servers/vfyjxf/HMCL-MCP/badges/card.svg)](https://glama.ai/mcp/servers/vfyjxf/HMCL-MCP)

Score Badge

Copy to your README.md:

[![HMCL-MCP MCP server](https://glama.ai/mcp/servers/vfyjxf/HMCL-MCP/badges/score.svg)](https://glama.ai/mcp/servers/vfyjxf/HMCL-MCP)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/vfyjxf/HMCL-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server