chatgpt_list_projects

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

Annotations already declare readOnly, idempotent, non-destructive, and openWorld, so safety is covered. The description adds real value beyond that by disclosing what is deliberately omitted from results (project prompts, unrelated config) and that the pagination cursor is preserved across calls.

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?

Two dense sentences with the return contract front-loaded and exclusions following immediately. No filler, though the second sentence is cryptic enough to read as jargon rather than guidance.

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 usefully enumerates returned fields, which is the right call. But for a paginated nested-parameter tool it does not explain pagination mechanics (limit bounds, offset vs cursor) or when to prefer this over the sibling project-conversation tool, leaving gaps an agent would hit on a second page.

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% for a nested pagination object with four sub-fields (after, limit, cursor, offset), so the description must carry the burden. It only mentions the cursor and an opaque constraint ('pagination parameters can only override query keys actually recorded'), leaving limit, offset, and after undocumented.

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 names a specific verb and resource (web project list interface) and enumerates returned fields (project ID, name, share scope, partial conversation metadata) plus explicit exclusions (no project prompts, no unrelated config). This makes it easy to distinguish from chatgpt_list_conversations and chatgpt_list_project_conversations, though it never names those siblings directly.

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 statement of when to use this tool versus chatgpt_list_project_conversations or chatgpt_search_conversations. Usage is only implied by the fact that it lists projects.

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