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

With no annotations, the description carries the full behavioral burden and does disclose the key trait: it is a non-mutating inspection ('without rewriting anything') that produces cited output. It does not mention the effect of the 'target'/'has_image' inputs on behavior or any limits, so it is good but not exhaustive.

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 names the action, the output, and the key constraint with zero filler. Every clause carries information.

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?

The existence of an output schema means return values need not be explained, and the non-mutation nature is covered. However, four of five parameters lack any semantic guidance and no annotations exist, so the agent lacks enough to confidently populate target/context/history/has_image.

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 only 20% across 5 parameters, so the description must compensate and largely does not. It says nothing about 'target', 'context', 'history', or 'has_image', leaving the agent to guess how targeting the analysis or supplying conversation history changes the result.

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 states a specific verb and resource ('Profile a prompt's task type') plus the concrete artifact it returns ('list the techniques improve_prompt would apply, with citations'). It explicitly differentiates itself from its closest sibling by adding 'without rewriting anything', so an agent can distinguish it from improve_prompt without opening either schema.

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?

'without rewriting anything' and the reference to improve_prompt imply the usage context: inspect/analyze before committing to a rewrite. It names the sibling tool, but it never states explicit when-to-use/when-not conditions or prerequisites (e.g. when to choose this over calling improve_prompt directly), leaving the routing partly to inference.

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

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

No annotations exist, so the description carries the full burden, and it discloses meaningful behavior: the statelessness constraint, the four-part return payload, and the degraded 'host' path where improved_prompt is only a template requiring host_instructions. It omits cost/latency, credential requirements, and determinism concerns, so it is strong but not exhaustive.

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?

Front-loads the purpose, then moves through usage constraint, return shape, and edge case in four dense sentences. The long list of nine-plus technique names is the one slightly bloated element, though it justifies the tool's scope.

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 an output schema present, the return explanation is a bonus rather than a requirement, and the description goes further by covering the host-backend edge case the schema only implies. For an 8-parameter tool with one required field, nothing needed to call it correctly is missing.

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 baseline is 3. The description still adds value by tying prompt/context/history together into one verbatim-passing rule and by naming 'backend_used' and the host-draft fallback, giving the backend parameter practical meaning beyond the enum values.

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 opening sentence gives a concrete verb and object ('Rewrite a prompt so a model answers it better') and names the concrete technique families applied, so the agent knows exactly what the tool produces. It never differentiates itself from the sibling 'analyze_prompt', so the boundary is left to the name alone.

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?

Gives clear operational guidance for invocation: 'The server cannot see the conversation, so pass the current prompt verbatim plus the earlier turns and context it depends on.' That is a real usage condition an agent must know. It stops short of naming analyze_prompt/list_techniques as alternatives or saying when not to call it.

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

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

With no annotations, the description carries the full behavioral burden. 'List' correctly implies a non-mutating read and 'with the papers behind it' adds return-content context beyond the schema, but nothing is said about permissions, data freshness, or result size, so a low-risk listing tool is only partially covered.

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 no filler; the scope statement and the payload hint both earn their place. Nothing to trim.

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 zero-parameter read tool with an output schema already documenting return values, the description only needs to establish what is listed and that papers accompany each technique, which it does. The gap is the absence of any note on how this catalog relates to the sibling 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?

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. The schema has an empty properties object and no semantics are needed.

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 ('every technique the improver knows') and adds scope detail ('with the papers behind it') that hints at the payload. It is clearly distinct from the sibling mutation-style tools improve_prompt and analyze_prompt, though it never names or contrasts them 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 description implies a discovery/inventory use case but gives no explicit when-to-use guidance or conditions for preferring it over improve_prompt or analyze_prompt. An agent can infer it is a read-only catalog lookup, but the routing is left to inference.

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