just-prs-mcp

Overview Schema Source Related Servers Discussions Admin

Plot trait panel (give user html_link)

plot_trait_panel

Idempotent

Create an interactive HTML report from polygenic risk score results, with charts, model table, and Ask-AI insights, and provide a URL or file path.

Instructions

Write the just-prs trait HTML report and return a URL or file path.

REQUIRED REPORT DELIVERY: when html_link is set, your reply MUST include it as a markdown link (for example Open the interactive trait report) and explicitly tell the user to open it. This is the primary user-facing result, not an implementation detail. Do not skip the link, merely say the report was saved, fetch it, or paste the HTML. html_link is an HTTP URL when available and a file:// URI on local stdio.

This is the MCP equivalent of prs plot trait ... -o intel_o_family.html: just_prs.viz.plot_trait_scores + save_trait_report. The page has the Vega-Lite panel, median cards, model table, and Ask-AI buttons. result_paths is always a list (one genome is fine; two or more overlay people). On Streamable HTTP html_url is served from this same origin at /reports/<file> with no extra config.

Input Schema

TableJSON Schema

Name	Required	Default
`panel`	No
`ancestry`	No	EUR
`model_scope`	No	usable
`output_path`	No
`result_paths`	Yes
`genome_labels`	No

Output Schema

TableJSON Schema

Name	Required	Description
`label`	Yes	Trait label.
`summary`	Yes	Human-readable summary of what was written.
`html_url`	No	REQUIRED when set: browser URL for this report on the FastMCP HTTP origin (``/reports/<file>``). Put this exact URL in your reply as a markdown link and tell the user to open it. Do not skip it. Do not fetch or paste the HTML.
`trait_id`	Yes	Trait ontology ID plotted.
`html_link`	Yes	PRIMARY REPORT DELIVERY TARGET. Put this exact value in the user reply as a markdown link and explicitly tell the user to open the interactive report. It is an HTTP URL when available and a file:// URI for local stdio. Never omit, fetch, or paste the HTML.
`html_path`	Yes	Server filesystem path of the written just-prs HTML report. Use only when ``html_url`` is absent (stdio): tell the user to open this file. Never paste the HTML.
`n_markers`	Yes	Number of scored models with a percentile on the chart.
`n_samples`	No	Number of genomes overlaid on the panel (1 = single-genome markers).
`sample_labels`	No	Genome labels drawn on the panel, in overlay order.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.5.0Aug 19, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context: what the report contains, that html_link is an HTTP URL or file:// URI depending on transport, and that on Streamable HTTP the URL is served at /reports/<file>. It also emphasizes the required user-facing link, which is a behavior beyond what annotations convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: a brief purpose sentence, a clearly highlighted REQUIRED REPORT DELIVERY block, and supporting context. It is not overly verbose and every part adds relevant information. The use of bold/labeled sections aids readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the critical delivery requirement and gives background (MCP equivalent, page contents, URL serving). However, it lacks explanations for most input parameters, which is a notable gap given the absence of schema descriptions. The output schema exists, so return values are not a concern, but parameter understanding is incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description carries the burden. It only clarifies `result_paths` ('always a list, one genome is fine; two or more overlay people'). It does not explain `panel`, `ancestry`, `model_scope`, `output_path`, or `genome_labels`. This is insufficient for an agent to confidently set these parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

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: 'Write the just-prs trait HTML report and return a URL or file path.' It clearly distinguishes this from siblings like compute_prs by framing it as a plotting/visualization tool (MCP equivalent of `prs plot trait`). The description also clarifies the page contents and that `result_paths` can contain one or more genomes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context on how to use the tool, especially the mandatory delivery of `html_link` as a markdown link. It implies this tool is used after PRS computation, and the underlying functions are named. However, it does not explicitly list alternatives or say when not to use this tool, so a slight gap remains.

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