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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds material context beyond them: the command is authenticated, the tool verifies status first, and — critically — the agent must not transmit ZIP bytes through MCP and must run the command externally. It does not cover failure modes or command expiry, so it stops short of 5.

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?

Four short sentences, front-loaded with the core action and free of filler; every clause (status check, no build, external execution, engine support) adds a distinct fact. Tight and well-ordered, though 'Supports Phaser, Godot and Unity' is peripheral to invocation.

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 command-issuing tool with no output schema, the description covers the workflow an agent needs: prerequisites (ready job), the status-check behavior, and the external-execution constraint. The remaining gap is the undocumented parameters, which is a schema-side deficiency.

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% for both required parameters (projectId, jobId), so the description carries the full burden but adds no meaning beyond implying an export 'job' and 'project'. It never explains what a jobId is or how to obtain one, leaving both parameters effectively undocumented.

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 ('Return an authenticated shell download command for a ready project export job') and immediately distinguishes itself from siblings like start_project_export ('never starts a build') and get_project_export_status (it returns a command, not status). An agent can disambiguate it from the other export-related tools without opening any schema.

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?

Provides strong contextual guidance: only for a 'ready' export job, it 'checks status first and never starts a build' (routing the agent away from start_project_export), and it must be run outside the model. It does not explicitly name the alternative tool to use when the job is not ready, which keeps it just under a 5.

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