how_to_install
Get setup verification and silent setup steps for LC Mod Installer, plus an install command for a mod. Does not install anything remotely.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | No |
Get setup verification and silent setup steps for LC Mod Installer, plus an install command for a mod. Does not install anything remotely.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The statement "Does not install anything remotely" usefully reinforces the readOnly/non-destructive annotations and preempts the assumption that a tool named how_to_install might mutate state. However, it adds nothing about what is returned (verification results? step text? a command string?) or about the openWorld behavior of the returned install command.
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 short sentences with no padding, and the key constraint is placed second where it reads clearly. The only weakness is that the first sentence crams multiple distinct outputs together instead of enumerating them cleanly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one optional param, no output schema), so the description does not need to explain return structure in depth. Still, with no output schema and no gloss on "setup verification" or "silent setup steps," an agent cannot tell what form the answer takes or how to use it downstream.
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 single parameter `id` has zero schema description coverage, and the description never explains that it identifies a mod — only the oblique phrase "an install command for a mod" hints at it. The description also fails to say what happens when `id` is omitted, even though the schema marks it optional.
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?
"Get setup verification and silent setup steps ... plus an install command for a mod" names a resource-ish thing (setup steps, install command) but bundles three loosely defined outputs. "Setup verification" and "silent setup" are undefined jargon, so an agent cannot confidently predict what the tool returns. It is not tautological, but it is vague enough to require inference.
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?
There is no explicit when-to-use guidance and no reference to siblings like mod_info or search_mods, which an agent would need to choose between. The only orientation given is the negative "Does not install anything remotely," which clarifies behavior but not tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.