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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds real context beyond that: the result 'Contains personal data' (a privacy/handling caveat) and the pagination contract 'pages of up to 20 (default 20)'. It does not describe auth requirements or return fields, but that is a minor gap given the annotation coverage.

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 that defines the resource first, then the caveat, then the paging contract. Tight and readable, with only minor duplication of the schema's page-size default.

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?

No output schema exists, but the description covers the key facts an agent needs: what the list contains, that it is paginated with a bounded page size, and that results carry personal data. The only omissions are the return field shape and the alternative list/search tools.

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 100% — both page_token and max_page_size are fully documented in the schema, including the nextPageToken chaining instructions. The description's 'pages of up to 20 (default 20)' merely restates the schema's max_page_size bounds, adding no new semantic detail. Baseline 3 is appropriate.

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 (list) and resource (unassigned stops) and clarifies the concept with a gloss — 'stops that are not on any plan yet (the inbox of imported orders)'. This distinguishes it from the singular spoke_get_unassigned_stop and from spoke_list_plan_stops, though it never names those siblings explicitly.

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?

The parenthetical 'the inbox of imported orders' implies the context in which this list is relevant, but there is no explicit when-to-use vs. when-not guidance and no routing to alternatives such as spoke_search_stops or spoke_list_plan_stops. Usage must be inferred.

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