ghl_project_get_list

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

Annotations already declare readOnlyHint/idempotentHint/openWorld, so the safety profile is covered; the description adds real value by naming the OAuth scope (projects/workspace.readonly) and the v3 Version header requirement. However, most of the preamble describes behaviors of other tools (task batch-get RBAC filtering, lexorank positions, delete cascades, task search sync), which are irrelevant here and dilute the disclosure.

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?

Six sentences of generic project-management API preamble precede the three sentences that actually describe this tool, and those preamble facts (task batch-get RBAC, lexorank, recurring task fields, delete cascades) belong to sibling tools. The genuinely useful content — endpoint, version header, scope, statuses pointer — is buried at the end rather than front-loaded.

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 read-only get-by-id with complete schema coverage and no output schema, the description supplies the endpoint, version header, auth scope, and a hint that the returned list carries a parent folder/space reference. Only the shape of the returned list object is left unexplained, which is a minor gap given annotations cover safety.

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 both listId and locationId are already fully documented in the schema, including the APP-channel vs OAuth/PIT rule for locationId; baseline 3 applies. The description's mention of `parentId` adds response-shape context but is a property of the returned list, not an input, which could momentarily mislead an agent scanning for callable parameters.

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 tool-specific line, 'Fetches one list by id,' gives a specific verb plus resource, and the endpoint line confirms it is a single-resource GET. It is distinguishable from siblings like ghl_project_list_list_tasks or ghl_project_get_folder_lists by the 'by id' framing, but that distinction is never stated explicitly and the reader must infer it from the surrounding hierarchy preamble.

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: 'Fetches one list by id' tells you the required input shape, and the cross-reference to `GET /projects/lists/{listId}/statuses` hints that a sibling tool exists for statuses. There is no explicit 'use this when you already have a listId; use get_folder_lists / get_space_lists when you need to enumerate' guidance, and no exclusions or prerequisites.

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