Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations are empty, so the description carries the full burden of behavioral disclosure. It says the tool 'returns' information, which hints at a read-only alias, but it never explicitly states that it does not install or download anything, nor does it mention side effects, authentication needs, or response format. For a tool named install_skill with no annotation safety hints, this ambiguity is a notable gap.

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 one sentence, front-loaded with the core idea ('Plain-English install/download alias'), and efficiently lists the returned items. It is compact and readable, though the enumerated client list adds some length without much differentiation. Still, it earns a strong score for economy of 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?

This is a high-complexity tool—43 optional parameters, no output schema, no annotations—yet the description gives only a high-level list of outputs. It lacks information about return structure, which parameters are essential, how client-specific outputs vary, or how to choose among sibling tools. For a tool with this complexity, the description is incomplete and leaves the agent without enough context to invoke 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?

The schema has 43 parameters with only 33% description coverage, so the description should compensate by explaining which parameters matter and how they map to the stated outputs. It does not. It only lists output categories (package profile, GitHub command, MCP URL, CLI commands, bridge path) without linking any to inputs like platform, localPort, or client type. This provides zero additional parameter-level meaning.

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 says it is a 'Plain-English install/download alias' and enumerates the returned artifacts (package profile, GitHub install command, MCP URL, CLI commands, bridge setup path). This makes the primary purpose understandable. However, the word 'alias' is slightly ambiguous about whether the tool actually installs something or only returns instructions, and it does not explicitly distinguish itself from sibling tools like download_skill or wisely_install_profile.

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 explicit guidance on when to use this tool versus alternatives. It mentions target clients (OpenClaw, Hermes-style agents, ChatGPT MCP clients, generic MCP clients) but does not explain when to choose this over download_skill, wisely_install_profile, or any bridge setup tool. There are no exclusions, prerequisites, or alternative recommendations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.