install_mod_cf

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

With no annotations, the description carries the full burden and does well: it discloses recursive dependency installation, the third-party-distribution block path and the `blocked` return field, and a hard prohibition on scraping/mirrors. It stops short of saying what happens if the mod is already installed (overwrite vs skip) or what errors look like.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, all load-bearing: what it does, the blocking edge case with the follow-up call, and the hard constraint. The primary behavior and the fileId exception are front-loaded in the opening parenthetical.

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 no-annotation, no-output-schema mutation tool, the definition covers the key surprises an agent would otherwise hit: dependency recursion, the blocked-distribution branch, and the follow-up tool. Only idempotency/overwrite semantics and failure modes are missing.

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 all three parameters rest on the description. It explains fileId's role well (optional pin overriding the default latest-compatible resolution) and implies instanceId's target, but modId is never defined as the CurseForge project id, and the interaction between fileId and instance compatibility is left ambiguous.

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?

States a specific verb and resource (install a mod from CurseForge into an instance) plus the source qualifier that separates it from the sibling install_mod. The default resolution rule (latest release matching instance MC version/loader) further pins down exactly what gets installed.

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?

Gives clear conditional routing: omit fileId for latest compatible release, supply fileId to pin. It explicitly hands off to resolve_blocked_mods after a manual download, naming the sibling and the condition. It never explicitly contrasts with install_mod (the non-CurseForge installer), which keeps it from a 5.

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