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

Annotations only cover safety (readOnlyHint=false, destructiveHint=false, openWorldHint=true); the description adds real substance by disclosing what the run actually does — three fixed breakpoints, four classes of risk checks, and generation of a shareable report. It stops short of stating whether the run is synchronous or background, and openWorldHint=true is never explained as hitting the live site.

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, front-loaded with the action and resource, then the audit contents, then the argument default. No filler, no restatement of the title, and the longest detail (viewports) is compressed into a single clause.

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?

With no output schema, the description should say what an agent gets back (an audit id?) and that the run is asynchronous with results retrieved separately — that is what an agent needs to proceed correctly, and it is missing. It does cover inputs and behavior well, and annotations carry the safety profile, so it is viable but incomplete.

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 coverage is 100%, so baseline is 3, and the description earns an increment by explaining the fallback rule the schema omits: url overrides the project's main_url when provided. It adds nothing about the required project_id or the analytics-oriented context parameter, but the schema already documents both.

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 first sentence gives a specific verb and resource ("Start a detailed Mobile Readiness Audit for a project") and the second enumerates concrete scope: three viewport captures, console/link/accessibility/layout checks, and report preparation. It is clearly distinguishable from read-side siblings (get_mobile_audit_status, list_mobile_audits, parse_mobile_audit_report) without naming them, though explicit sibling routing is absent.

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?

Usage is only implied by the purpose statement — there is no statement of when to choose this over list_mobile_audits or get_mobile_audit_evidence, and no preconditions (an existing project, a reachable main_url). Critically, it never says this is the entry point of a flow whose results must be polled via get_mobile_audit_status, which the sibling set makes a likely agent error.

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