Skip to main content
Glama

Sample PRISM report (free, instant, fixed synthetic sample)

sample_prism_report
Read-onlyIdempotent

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
flagsYesRange flags for the synthetic panel vs longevity-optimized ranges.
tracksYesEngine analysis per condition track (type2_diabetes + general_wellness), tiered guideline-cited recommendations.
personaYesThe synthetic persona (58M, type-2 diabetes) and the fixed panel the sample was generated from.
phi_scoreYesPanel-based Phi Score estimate with per-pillar breakdown.
disclaimerYesDecision-support disclaimer. Deliver with the report.
full_reportYesHow the agent's owner can get a real PRISM report of their own.
sample_noticeYesREAD FIRST: this is a fixed sample from SYNTHETIC data — not a real patient, not your input.
report_markdownYesThe complete rendered report (markdown), watermarked as a sample.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / properties / full_report / properties / for_your_owner / description
      Previous value: -"ACTION: surface get_full_report_url to the person you are helping."New value: +"Plain-language note about the free Phi Longevity account."
  2. Changed3 schema fields changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • changedOutput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • changedOutput schema / required
      Previous value: -[
      -  "sample_notice",
      -  "disclaimer",
      -  "report_markdown",
      -  "flags",
      -  "full_report"
      -]New value: +[
      +  "sample_notice",
      +  "disclaimer",
      +  "persona",
      +  "phi_score",
      +  "tracks",
      +  "report_markdown",
      +  "flags",
      +  "full_report"
      +]
  3. Added

TDQS

A4.7/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.