phi-mcp-server

Which lab tests PRISM can interpret

list_supported_biomarkers

Read-onlyIdempotent

Lists the 51 lab tests PRISM interprets, such as A1c, eGFR, LDL, ApoB, and thyroid markers, including units and reference ranges. Use it to check which biomarkers are supported.

Instructions

Lists the 51 lab tests PRISM interprets (A1c, eGFR, LDL, ApoB, thyroid and more) with units and reference ranges. Reference data only, no patient data.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_supported_biomarkers"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description	Default
`next_step`	Yes	The one next step: read this last and act on it.
`biomarkers`	Yes	The 51-marker catalog with clinical reference ranges.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.7.0Nov 6, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": false,
+  "properties": {
+    "biomarkers": {
+      "description": "The 51-marker catalog with clinical reference ranges.",
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "name": {
+            "description": "Biomarker name as PRISM recognizes it.",
+            "type": "string"
+          },
+          "pillar": {
+            "description": "Clinical pillar.",
+            "type": "string"
+          },
+          "refHigh": {
+            "description": "Upper clinical reference bound, if applicable.",
+            "type": "number"
+          },
+          "refLow": {
+            "description": "Lower clinical reference bound, if applicable.",
+            "type": "number"
+          },
+          "unit": {
+            "description": "Measurement unit.",
+            "type": "string"
+          }
+        },
+        "required": [
+          "name",
+          "unit",
+          "pillar"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "next_step": {
+      "additionalProperties": false,
+      "description": "The one next step: read this last and act on it.",
+      "properties": {
+        "call_tool": {
+          "description": "The tool to call next, when the next step is a call.",
+          "type": "string"
+        },
+        "for_you": {
+          "description": "The one thing to do next, as an instruction to you (the assistant).",
+          "type": "string"
+        },
+        "url": {
+          "description": "The link to give the person, when the next step is theirs to open.",
+          "type": "string"
+        }
+      },
+      "required": [
+        "for_you"
+      ],
+      "type": "object"
+    }
+  },
+  "required": [
+    "biomarkers",
+    "next_step"
+  ],
+  "type": "object"
+}

First observedv0.6.3Jul 31, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world. The description adds real value beyond that: the returned content is fixed reference material with units and ranges, and explicitly contains no patient data, so the agent knows no PHI is exposed. Missing only notes on result size or ordering.

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

Conciseness5/5

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

Two sentences, no filler. The scope statement (51 tests, examples, units, ranges) is front-loaded, and the privacy qualifier follows as a short, purposeful clarification.

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

Completeness4/5

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

For a zero-parameter tool with a rich set of annotations and an output schema, the description covers what it returns and confirms no patient data is involved. Only the relationship to sibling tools is absent, which is minor given how self-contained this tool is.

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

Parameters3/5

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

The tool takes zero parameters, so the baseline is a 4, but the description adds nothing about arguments because there are none to describe. The single sentence about contents is a return-value hint rather than parameter guidance, keeping this at a solid baseline.

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?

States a specific verb and resource: lists the 51 lab tests PRISM interprets, with concrete examples (A1c, eGFR, LDL, ApoB, thyroid) and what each entry contains (units, reference ranges). The static reference-list nature clearly separates it from patient-specific siblings like explain_my_lab_results or get_my_medical_records.

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

Usage Guidelines3/5

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

"Reference data only, no patient data" implies the context of use (capability discovery rather than result interpretation) but never states when to call it or which sibling to use instead. An agent can infer it is the right first step before explain_my_lab_results, but that 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.

Deploy Server