list_mod_files_cf

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

No annotations exist, so the description carries the full burden. It usefully discloses the implicit filter behavior applied when instanceId is supplied and that a latest release is auto-selected, which is real behavioral context. It says nothing about result ordering, pagination, or the fact that the listing is remote CurseForge data (potentially rate-limited/slow), leaving meaningful gaps.

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 short sentences, each earning its place: purpose, conditional parameter behavior, then the actionable follow-up. Front-loaded with the core purpose and no filler.

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 two-parameter read tool with no annotations and no output schema, the description covers what the agent needs to call it and to interpret the notable instanceId-dependent result selection. Minor gap: no mention of the modId format or result volume/pagination.

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 compensate. It explains instanceId's effect well (MC version/loader filtering), but modId is never explained beyond being a number — its CurseForge project-ID form is assumed, not stated. Half the parameters remain semantically underspecified.

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: list a CurseForge mod's files, with the CurseForge qualifier distinguishing it from the generic list_mod_versions sibling. It stops short of explicitly contrasting with list_mod_versions, so the agent must infer the distinction from the 'cf' naming convention.

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 guidance: pass instanceId to filter to an instance's MC version/loader, and read the auto-picked latest release. It also routes forward to install_mod_cf via fileId for pinning or rollback. It lacks an explicit when-not-to-use statement versus list_mod_versions.

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