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

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds two genuinely useful traits beyond that: 'provider-backed' (an external routing provider is called, implying quota/cost/network dependency) and 'Queue' (the work is enqueued rather than returned inline). It still omits what a queued call returns (a job handle?), how to poll, and any rate/point limits.

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?

A single front-loaded sentence with zero filler; every clause (queue, provider-backed, the five operation families) earns its place. It is not padded, though the terseness trades away information that the next dimensions penalize.

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 high-complexity tool — five mutually exclusive nested operation shapes, 500-point origin arrays, H3 vs contour output, no output schema, no schema field descriptions — one sentence is far from complete. The async lifecycle (job handle, status polling), preview vs materialize semantics, and per-operation input expectations are all 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% and the input is a deeply nested discriminated union, so the description carries real weight — and it does helpfully name the five operation families the `operation.type` const values encode. But it leaves the most consequential top-level fields unexplained: `mode` (preview vs materialize), `attachToProject`, `title`, and `profile` (driving/walking/cycling/truck) get no mention at all.

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?

A specific verb ('Queue') plus resource ('mobility analysis') and an enumeration of the five analysis families (routing, reachability/isochrones, nearest, travel-time metrics, map-matching) that maps onto the schema's operation discriminator. An agent can immediately tell what the tool computes, though it never names or contrasts itself with project_mobility_analysis_status, the status/polling counterpart.

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?

No when-to-use / when-not guidance and no prerequisites are stated. The word 'Queue' hints at an async submission pattern, but the description never says to poll project_mobility_analysis_status afterwards, nor when to prefer preview over materialize, nor when to reach for project_run_spatial_operation instead.

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