export_package

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

Annotations already declare readOnlyHint=false with destructiveHint=false, and the description goes further: it discloses the output directory layout, the file inventory, the CHECKLIST.md content (per-item target page/field), and explicitly bounds side effects ('nothing is uploaded or published'). It does not say whether existing export files are overwritten, which is the remaining 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?

One dense sentence carries the artifact list and the second sentence bounds behavior. It is front-loaded with the action and destination, though the first sentence is long and slightly overloaded with parenthetical file types.

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?

An output schema exists, so return values need not be explained; the description instead covers what is written, where, and the guarantee that nothing is uploaded. For a 2-parameter write tool this is nearly complete, with only the overwrite/idempotency question left open.

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 carry the load. It partially covers 'gate' by embedding it in the path template gate_<gate>, but the required 'path' parameter is never explained, and it is unclear whether the stated output directory is fixed or derived from path.

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 gives a concrete verb and artifact: writes named localization JSON, images/icons, SteamPipe scripts, achievement icons and CSV to .steam-mcp/exports/gate_<gate>/. That level of enumeration makes it clearly distinct from siblings like generate, apply, and import_from_steamworks.

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?

'Write everything needed to finish a gate by hand' signals the context (manual completion of a gate), and 'Nothing is uploaded or published' implicitly separates it from apply/import_from_steamworks which push to Steamworks. No sibling is named explicitly and no exclusion is stated, so this falls 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.