Build PRS prompt

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

Annotations already convey readOnlyHint, idempotentHint, and destructiveHint safety traits. The description adds meaningful behavioral context: multiple `result_paths` produce a comparison-first prompt, `include_url=True` with specific assistants generates a prefilled link, and `kind='score'` uses `pgs_id` or the first scored row. No contradiction with annotations.

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 purpose is front-loaded in the first sentence, and the following sentences each add necessary behavior or parameter detail. It is reasonably compact for a 9-parameter tool, though a more structured list format could improve scannability.

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 description covers the core purpose, prompt usability, comparison behavior, URL prefill options, and `kind` variants, while the output schema and annotations cover return values and safety. Auxiliary parameters like `limit`, `ancestry`, `model_scope`, and `genome_labels` are not explained, but their schema defaults provide partial context.

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?

With 0% schema coverage, the description carries the parameter-semantics burden. It explains `result_paths`, `kind`, `include_url`, `assistant`, and `pgs_id`, but leaves `limit`, `ancestry`, `model_scope`, and `genome_labels` without any descriptive guidance, relying solely on their names and defaults.

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 opens with a specific verb and resource: 'Build the reusable just-prs LLM prompt from saved by-trait results.' It further anchors the tool as the MCP equivalent of `prs prompt` / the UI Ask-AI buttons, which clearly distinguishes it from sibling compute, plotting, and query tools.

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 gives clear context on when to use the tool: when a reusable prompt is needed from saved by-trait results and when the prompt may be used in-conversation or pasted elsewhere. It also explains the one-vs-multiple genome behavior and the `kind` variants, but it does not explicitly name alternative tools or state when not to use this tool.

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