List the prompts of the project

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

Annotations cover read-only and open-world behavior, and the description adds that each returned prompt carries a visibility value and that PromptEye measurements are based on answers to these prompts. This gives useful domain context beyond the annotations, though it does not describe pagination or response shape.

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?

The description is two sentences and front-loads the core object: prompts of the active project with visibility. The second sentence adds relevant context about PromptEye measurements and brand relevance, but it is slightly conceptual rather than strictly operational, so it is concise but not maximally tight.

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 list operation with all parameters documented in the schema, the description gives sufficient conceptual info about what is returned (prompts plus visibility). Without an output schema, it could describe the response wrapper or pagination more explicitly, but the tool remains callable based on this description and the schema.

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%, so the parameters (limit, cursor, date range, groupId, categoryId) are already documented in the schema. The description adds no additional parameter guidance, so the baseline of 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?

The description identifies the resource ('the prompts') and scope ('active project') and adds that each prompt is listed with the visibility it earns, which distinguishes it from a generic prompt listing. It lacks an explicit verb like 'list' or 'returns', relying on the title and the phrase 'this is where to look', so it is clear but not maximally specific.

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 phrase 'this is where to look for which questions carry the brand and which do not' provides a clear use case: inspecting per-prompt visibility context. It does not name sibling tools like get_prompt, list_prompt_groups, or get_visibility_summary, nor does it state when not to use them, so exclusions are missing.

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