Explains lab results for diabetes, kidney, lupus and cancer care, citing guidelines. Free sample.
Scored across 5 tools
Most tools are clearly distinct: reference tools (get_methodology, list_supported_biomarkers) vs. analysis tools. However, analyze_biomarkers and quick_check both process biomarker values and could be confused despite the description clarifying the engine call vs. local check.
The naming pattern is mostly consistent with verb prefixes like get_, list_, analyze_, and sample_. quick_check breaks the verb_noun pattern by using an adjective modifier, but it's still readable and recognizable.
Five tools is well-scoped for a specialized longevity biomarker API. Each tool serves a distinct purpose—analysis, reference, methodology, quick screening, and sample output—without redundancy or bloat.
The surface covers the full intended workflow: understand methodology, see supported biomarkers, run a quick local check or full engine analysis, and view a sample report. There are no obvious missing operations for a stateless research/education analysis API.
Analyze a SYNTHETIC biomarker panel with Phi Longevity's PRISM engine. Returns tiered, guideline-cited recommendations. For research/education with SYNTHETIC or de-identified data only. Do NOT submit protected health information (PHI). This endpoint is stateless and does not store inputs.
| Name | Required | Description | Default |
|---|---|---|---|
| age | No | Age in years of the synthetic persona (improves reference-range interpretation). | |
| biomarkers | Yes | Map of biomarker name -> numeric value, e.g. { "Hemoglobin A1c": 5.4 }. SYNTHETIC ONLY. | |
| biologicalSex | No | Biological sex of the synthetic persona (sex-specific reference ranges). | |
| conditionFocus | No | Optional condition track. Default general_wellness. |
| Name | Required | Description |
|---|---|---|
| meta | No | Engine metadata for this analysis run. |
| issues | No | Flagged issues detected in the panel. |
| claim_panel | No | Not used on this surface. |
| full_report | Yes | How the agent's owner can get a complete PRISM report. |
| recommendations | Yes | Tiered, guideline-cited recommendations from the PRISM engine. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds valuable beyond-annotation context: the endpoint is stateless and does not store inputs, plus it reiterates the PHI restriction. This meaningfully improves safety transparency.
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 three tight sentences with no filler. The action is front-loaded, followed by scope/safety restrictions and the statelessness note. Every sentence earns its place.
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 rich schema, output schema, and annotations cover invocation details, while the description supplies scope, PHI prohibition, and statelessness. The main completeness gap is explicit routing to sibling tools such as quick_check, but the tool remains safely callable as described.
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 schema already documents all four parameters, including age/sex interpretation effects and conditionFocus defaults. The description adds little parameter-level detail beyond restating the synthetic-only constraint, so the baseline 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 states a specific verb ('Analyze') and resource ('SYNTHETIC biomarker panel') and describes the output as 'tiered, guideline-cited recommendations.' It clearly narrows scope to synthetic/de-identified research data, but it does not explicitly distinguish itself from siblings like quick_check or sample_prism_report.
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: use for research/education with synthetic or de-identified data only, and explicitly forbids submitting PHI. It lacks explicit alternatives or a when-not-to-use comparison with sibling tools, but the constraints are strong enough to guide appropriate selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarize how the Phi Score works (5 clinical pillars + weights) and link to the full methodology.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| note | Yes | Decision-support disclaimer and synthetic-data rule. |
| source | Yes | Attribution. |
| phi_score | Yes | Plain-English summary of how the 0-100 Phi Score is computed. |
| agent_docs_url | Yes | Agent integration docs. |
| methodology_url | Yes | Full public methodology page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds useful behavioral context: the tool produces a summary containing the five pillars and weights and provides a link to the full methodology, with no contradictions.
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 sentence that communicates the action, the subject, the specific components covered, and the linking behavior. No filler or redundancy.
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-only tool with an output schema, the description completely explains what the agent can expect: a summary of the five pillars and weights, plus a link to full methodology. No invocation-relevant information 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?
The tool has zero parameters, so the empty schema fully documents the invocation surface. Description correctly adds nothing about parameters since none exist; this matches the baseline for parameterless tools.
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 action ('Summarize') and a clear resource (how the Phi Score works), with concrete content: five clinical pillars and weights. It clearly distinguishes itself as the summary-oriented counterpart to full_prism_report.
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 phrasing implies this tool is for getting a concise overview of the Phi Score methodology and a link to details, but it never explicitly states when to choose this over full_prism_report or any other sibling. Usage context is implied rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the biomarkers PRISM scores, with units and reference ranges, grouped by clinical pillar. Reference data only — no patient data.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| biomarkers | Yes | The 51-marker catalog with clinical reference ranges. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds useful scope beyond annotations with 'Reference data only — no patient data,' and the output schema covers return details, so the description does not need to repeat them.
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 one front-loaded sentence plus a short scope sentence. It states the action, the resource, the output contents, and the key restriction with no filler or redundancy.
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 parameterless, read-only reference-list tool with annotations and an output schema, the description is complete: it says what is returned, how it is organized, and that patient data is excluded. Nothing needed for a correct call 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?
The tool has zero parameters, so the baseline is 4 and there is no parameter semantics burden on the description. The description's mention of units, reference ranges, and pillar grouping refers to the output, which is appropriate for a parameterless list tool.
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 names a specific verb and resource: 'List the biomarkers PRISM scores, with units and reference ranges, grouped by clinical pillar.' The closing contrast, 'Reference data only — no patient data,' clearly separates this from the patient-facing sibling tools even though they are not named.
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 a clear usage boundary by stating this is reference data only and not patient data, so an agent can infer when not to use it. However, it does not explicitly name an alternative tool for patient-data analyses, stopping short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Instantly flags a few biomarker values against PRISM's longevity-optimized reference ranges (local check, no engine call). For research/education with SYNTHETIC or de-identified data only. Do NOT submit protected health information (PHI). This endpoint is stateless and does not store inputs.
| Name | Required | Description | Default |
|---|---|---|---|
| biomarkers | Yes | Map of biomarker name -> value, e.g. {"HbA1c":6.1,"LDL-C":145}. SYNTHETIC ONLY. |
| Name | Required | Description |
|---|---|---|
| note | Yes | Scope disclaimer — quick flags, not a diagnosis or full analysis. |
| flags | Yes | Range flags for each recognized biomarker. |
| unmatched | No | Submitted names not in the 51-marker catalog. |
| claim_panel | No | Not used on this surface. |
| full_report | Yes | How the agent's owner can get a complete PRISM report. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior, so the bar is lower. The description adds valuable behavioral context beyond those hints: the check is local, makes no engine call, is stateless, and does not store inputs. This meaningfully informs the agent about side effects and data handling.
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 compact and front-loaded: the first sentence states the operation and scope, the second adds data-class restrictions, and the third clarifies statelessness. Every sentence earns its place and there is no redundant filler.
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 tool has one simple parameter, an output schema, and rich annotations, so the description does not need to explain return values. It covers the essential additional context an agent needs: intended use, data sensitivity, PHI prohibition, and stateless behavior. It is complete for correct invocation.
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%, and the schema already explains the biomarker map format and gives an example. The tool description adds no parameter-specific meaning beyond restating that biomarker values are checked, 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 uses a specific verb ('flags') and a specific resource ('biomarker values against PRISM's longevity-optimized reference ranges'), and it distinguishes itself from a heavier sibling like analyze_biomarkers by noting it is a local check with no engine call. The title reinforces this by adding 'instant, no analysis'.
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 clearly scopes when this tool is appropriate: research/education only, with synthetic or de-identified data, and never with PHI. It does not explicitly name alternatives for other use cases, but the 'no engine call' distinction and the data restrictions give an agent clear enough context to choose it for quick local checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a complete pre-generated SAMPLE Phi Longevity PRISM report for a fixed SYNTHETIC persona (58-year-old male, type-2 diabetes). It is a fixed sample: it takes no input, analyzes nothing you send, and is not a real patient. For research/education with SYNTHETIC or de-identified data only. Do NOT submit protected health information (PHI). This endpoint is stateless and does not store inputs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| flags | Yes | Range flags for the synthetic panel vs longevity-optimized ranges. |
| tracks | Yes | Engine analysis per condition track (type2_diabetes + general_wellness), tiered guideline-cited recommendations. |
| persona | Yes | The synthetic persona (58M, type-2 diabetes) and the fixed panel the sample was generated from. |
| phi_score | Yes | Panel-based Phi Score estimate with per-pillar breakdown. |
| disclaimer | Yes | Decision-support disclaimer. Deliver with the report. |
| full_report | Yes | How the agent's owner can get a real PRISM report of their own. |
| sample_notice | Yes | READ FIRST: this is a fixed sample from SYNTHETIC data — not a real patient, not your input. |
| report_markdown | Yes | The complete rendered report (markdown), watermarked as a sample. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses that the endpoint is stateless, does not store inputs, returns a fixed sample, and is not a real patient. It also adds a PHI warning, which is important behavioral context for safe use. No contradiction with annotations exists.
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 front-loaded with the core purpose and each sentence adds value: fixed sample, no input, synthetic-only use, PHI warning, and statelessness. It is appropriately sized with no wasted words.
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 no-input, fixed-sample endpoint with an output schema and safety annotations, the description covers everything an agent needs: what it returns, what it does not do, allowed use cases, and data-handling behavior. No important context 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?
The input schema has zero parameters and schema description coverage is 100%, so there is nothing for the description to document. The description reinforces this by stating 'it takes no input,' which is sufficient for a no-parameter endpoint.
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: 'Returns a complete pre-generated SAMPLE Phi Longevity PRISM report for a fixed SYNTHETIC persona.' It further distinguishes itself from real analysis tools by saying it 'takes no input, analyzes nothing you send, and is not a real patient,' making its purpose unmistakable.
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 and exclusions: it is 'For research/education with SYNTHETIC or de-identified data only' and explicitly warns 'Do NOT submit protected health information (PHI).' However, it does not name sibling alternatives or explicitly state when to prefer a different tool, so it falls just short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
analyze_biomarkers4 fields changedInput schema / properties / include_partner_optionsRemoved value: -{
- "description": "If true, include partner/product options. Default false.",
- "type": "boolean"
-}Output schema / properties / claim_panel / descriptionPrevious value: -"OPTIONAL owner handoff: attach these exact values to the owner's Phi Longevity account (sign-in + explicit confirm). Present only when the consent bridge is enabled."New value: +"Not used on this surface."Output schema / properties / claim_panel / properties / claim_url / descriptionPrevious value: -"One-click claim link — share ONLY with your owner."New value: +"Not used on this surface."Output schema / properties / full_report / properties / for_your_owner / descriptionPrevious value: -"ACTION: surface get_full_report_url to the person you are helping."New value: +"Plain-language note about the free Phi Longevity account."full_prism_reportquick_check3 fields changedOutput schema / properties / claim_panel / descriptionPrevious value: -"OPTIONAL owner handoff (present only when the consent bridge is enabled)."New value: +"Not used on this surface."Output schema / properties / claim_panel / properties / claim_url / descriptionPrevious value: -"One-click claim link — share ONLY with your owner."New value: +"Not used on this surface."Output schema / properties / full_report / properties / for_your_owner / descriptionPrevious value: -"ACTION: surface get_full_report_url to the person you are helping."New value: +"Plain-language note about the free Phi Longevity account."sample_prism_report1 field changedOutput schema / properties / full_report / properties / for_your_owner / descriptionPrevious value: -"ACTION: surface get_full_report_url to the person you are helping."New value: +"Plain-language note about the free Phi Longevity account."analyze_biomarkers5 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseInput schema / properties / biomarkers / propertyNamesAdded value: +{
+ "type": "string"
+}Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / requiredPrevious value: -[
- "full_report"
-]New value: +[
+ "recommendations",
+ "full_report"
+]full_prism_report3 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseInput schema / properties / biomarkers / propertyNamesAdded value: +{
+ "type": "string"
+}get_methodology2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"list_supported_biomarkers2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"quick_check4 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseInput schema / properties / biomarkers / propertyNamesAdded value: +{
+ "type": "string"
+}Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"sample_prism_report3 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / requiredPrevious value: -[
- "sample_notice",
- "disclaimer",
- "report_markdown",
- "flags",
- "full_report"
-]New value: +[
+ "sample_notice",
+ "disclaimer",
+ "persona",
+ "phi_score",
+ "tracks",
+ "report_markdown",
+ "flags",
+ "full_report"
+]sample_prism_reportanalyze_biomarkers2 fields changedOutput schema / properties / full_report / properties / for_your_ownerAdded value: +{
+ "description": "ACTION: surface get_full_report_url to the person you are helping.",
+ "type": "string"
+}Output schema / properties / full_report / requiredPrevious value: -[
- "what_a_full_report_adds",
- "get_full_report_url",
- "agent_docs_url",
- "data_rule"
-]New value: +[
+ "for_your_owner",
+ "what_a_full_report_adds",
+ "get_full_report_url",
+ "agent_docs_url",
+ "data_rule"
+]quick_check2 fields changedOutput schema / properties / full_report / properties / for_your_ownerAdded value: +{
+ "description": "ACTION: surface get_full_report_url to the person you are helping.",
+ "type": "string"
+}Output schema / properties / full_report / requiredPrevious value: -[
- "what_a_full_report_adds",
- "get_full_report_url",
- "agent_docs_url",
- "data_rule"
-]New value: +[
+ "for_your_owner",
+ "what_a_full_report_adds",
+ "get_full_report_url",
+ "agent_docs_url",
+ "data_rule"
+]quick_check1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "claim_panel": {
+ "additionalProperties": false,
+ "description": "OPTIONAL owner handoff (present only when the consent bridge is enabled).",
+ "properties": {
+ "claim_url": {
+ "description": "One-click claim link — share ONLY with your owner.",
+ "type": "string"
+ },
+ "expires_at_ms": {
+ "description": "Epoch ms when the unclaimed panel is hard-deleted.",
+ "type": "number"
+ },
+ "marker_count": {
+ "type": "number"
+ },
+ "note": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "claim_url",
+ "expires_at_ms",
+ "marker_count",
+ "note"
+ ],
+ "type": "object"
+ },
+ "flags": {
+ "description": "Range flags for each recognized biomarker.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "name": {
+ "description": "Biomarker name as PRISM recognizes it.",
+ "type": "string"
+ },
+ "pillar": {
+ "description": "Clinical pillar.",
+ "type": "string"
+ },
+ "status": {
+ "description": "One of: within / above / below longevity-optimized range.",
+ "type": "string"
+ },
+ "unit": {
+ "description": "Measurement unit.",
+ "type": "string"
+ },
+ "value": {
+ "description": "The submitted value.",
+ "type": "number"
+ }
+ },
+ "required": [
+ "name",
+ "value",
+ "unit",
+ "pillar",
+ "status"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "full_report": {
+ "additionalProperties": false,
+ "description": "How the agent's owner can get a complete PRISM report.",
+ "properties": {
+ "agent_docs_url": {
+ "type": "string"
+ },
+ "data_rule": {
+ "type": "string"
+ },
+ "get_full_report_url": {
+ "description": "Signup link (free account) for the agent's owner.",
+ "type": "string"
+ },
+ "what_a_full_report_adds": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "what_a_full_report_adds",
+ "get_full_report_url",
+ "agent_docs_url",
+ "data_rule"
+ ],
+ "type": "object"
+ },
+ "note": {
+ "description": "Scope disclaimer — quick flags, not a diagnosis or full analysis.",
+ "type": "string"
+ },
+ "unmatched": {
+ "description": "Submitted names not in the 51-marker catalog.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "flags",
+ "note",
+ "full_report"
+ ],
+ "type": "object"
+}analyze_biomarkers1 field changedOutput schema / properties / claim_panelAdded value: +{
+ "additionalProperties": false,
+ "description": "OPTIONAL owner handoff: attach these exact values to the owner's Phi Longevity account (sign-in + explicit confirm). Present only when the consent bridge is enabled.",
+ "properties": {
+ "claim_url": {
+ "description": "One-click claim link — share ONLY with your owner.",
+ "type": "string"
+ },
+ "expires_at_ms": {
+ "description": "Epoch ms when the unclaimed panel is hard-deleted.",
+ "type": "number"
+ },
+ "marker_count": {
+ "type": "number"
+ },
+ "note": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "claim_url",
+ "expires_at_ms",
+ "marker_count",
+ "note"
+ ],
+ "type": "object"
+}quick_checkfull_prism_reportanalyze_biomarkersget_methodologylist_supported_biomarkersCash-pay lab tests: catalog search, all-in quotes by state, draw sites by ZIP, reviewed ranges.
Find public biomarker education, available blood tests, panels, and budget-aware starting points.
Doctor-reviewed blood-test markers, conditions & symptoms as agent tools. EN/RU/HE. Hosted.
Read-only U.S. lab-test catalog, collection-site search, and reference-range context.
Add one secure layer between your agents and this server.
