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

Annotations declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false, so the mutation/open-world safety profile is already covered. The description adds the genuinely useful behavioral fact that the operation is asynchronous ('Queue') and provider-backed, but says nothing about cost, latency, what gets created, or how to retrieve results.

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 the verb first and the capability list following. Zero filler and no repetition of the name or title.

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 tool with a deeply nested multi-branch schema, no output schema, and no param descriptions, the description is too thin: it omits the async submit-then-poll workflow, the preview vs materialize choice, and how results attach to the project. An agent could pick the right operation family but would not know the surrounding workflow.

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% over a very large nested schema with oneOf branches, enums (mode, profile, output, detail), and defaults. The description's operation-family list loosely maps to operation.type values, which has some value, but it never mentions mode, profile, attachToProject, title, or the preview/materialize distinction, so it leaves most of the parameter surface undocumented in both the schema and the description.

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 specific verb ('Queue ... mobility analysis') and resource, and enumerates the five operation families (routing, reachability/isochrones, nearest, travel-time metrics, map-matching) that map onto the schema's operation.type discriminators. It does not explicitly distinguish itself from the sibling geobble_project_mobility_analysis_status, though 'Queue' implies the submission half of an async pair.

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?

There is no explicit when-to-use or when-not-to-use guidance. The description never tells the agent that this only queues a job and that results must be fetched via geobble_project_mobility_analysis_status, nor does it explain when to prefer preview vs materialize mode. The word 'Queue' is the only hint about the workflow.

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