phi-mcp-server

Check which routine tests and exams may be due for a long-term condition (no lab values or records needed)

check_care_gaps

Read-onlyIdempotent

Identify overdue checks for type 2 diabetes, kidney disease, lupus, or cancer history using condition, medicines, and test timing. Get a prioritized, guideline-cited checklist and doctor questions.

Instructions

Use this when the person you are helping has type 2 diabetes, kidney disease, lupus or a cancer history and wants to know which routine tests and checks may be due. It needs NO lab values, dates, names or records: only the condition, a few medicine classes, and for each routine test whether it was done recently (recent / overdue / never / unsure). It returns a prioritized list, the guideline source for each item (ADA, KDIGO, EULAR, AAO, NCCN, ESC), the questions to ask each doctor, and a one-page printable checklist. Decision support for visit preparation, not a diagnosis. Safe to use for a real person because you send only these closed options. Nothing is stored unless the person opens the save link: then only these options and the checklist are held for about 30 minutes for them to claim, and deleted if unclaimed. Designed to be re-run: the result includes check_again (a date to run it again). If you can schedule check-ins for the person, a weekly check while items are open works well; saving the checklist to a free Phi Longevity account lets Phi Longevity keep track from their records.

Input Schema

Name	Required	Description
`conditions`	Yes	The long-term condition(s) the person has. One or more of: type2_diabetes, kidney_disease, lupus, cancer_survivorship.
`medications`	No	Medicine classes the person takes, if relevant. Allowed: metformin, insulin, sulfonylurea, ace_inhibitor_or_arb, hydroxychloroquine, glucocorticoids.
`test_status`	No	For each routine test you know about: recent (done within its usual interval), overdue, never, or unsure. Omit tests you do not know; they are listed as 'not checked yet'. Test ids: a1c, uacr, egfr_creatinine, lipid_panel, dilated_eye_exam, foot_exam, vitamin_b12, liver_fibrosis_screen, cbc, electrolytes_potassium, bone_mineral_labs, urinalysis_urine_protein, lupus_activity_labs, hcq_retinal_screen, blood_pressure_check, vaccines_review, cardiac_function_test, thyroid_tsh, bone_density_scan, survivorship_follow_up, age_appropriate_cancer_screens, distress_screen.
`treatment_exposures`	No	For cancer survivorship only: past treatment types. Allowed: anthracycline_or_trastuzumab, chest_radiation, neck_radiation, aromatase_inhibitor_or_androgen_deprivation, immune_checkpoint_inhibitor.

Output Schema

Name	Required	Description
`gaps`	Yes	Prioritized checks, most important first.
`counts`	Yes
`applied`	Yes	The options that were recognised and used.
`summary`	Yes	One plain sentence: how many checks to ask about.
`next_step`	Yes
`check_again`	Yes	When to run this check again (a weekly check-in while items are open).
`save_to_phi`	Yes	Save this checklist to a free Phi Longevity account.
`unrecognized`	Yes
`guidelines_as_of`	Yes
`not_medical_advice`	Yes
`questions_by_clinician`	Yes
`printable_checklist_markdown`	Yes	One-page checklist the person can print or paste.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.7.0Nov 6, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Goes well past the annotations: it discloses that nothing is stored unless a save link is opened, that saved data is held ~30 minutes and deleted if unclaimed, and what the response contains (prioritized list, guideline source per item, doctor questions, printable checklist). This directly supports the readOnly/idempotent/non-destructive hints without contradicting them.

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?

Front-loads purpose, then inputs, then output, then privacy and re-run guidance in a sensible order. It is dense but long, and the closing account/scheduling upsell ('saving the checklist to a free Phi Longevity account...') sits outside the tool's actual behavior and could be trimmed.

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 four-parameter tool with a nested object and a large enum set, the description covers population, inputs, safety posture, data retention, output contents, and re-run cadence. With an output schema present it does not need to spell out return values, and it still summarizes them usefully.

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?

Schema description coverage is 100%, so the schema already documents all four parameters, including the test-status enum and its 'omit what you don't know' behavior. The description restates the inputs ('only the condition, a few medicine classes, and for each routine test whether it was done recently') and adds the rationale that the closed options make it safe for a real person, but adds no new per-parameter meaning.

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 ('check which routine tests and checks may be due') plus the exact population it applies to (type 2 diabetes, kidney disease, lupus, cancer history). The clause 'It needs NO lab values, dates, names or records' implicitly separates it from lab-results siblings like explain_my_lab_results and 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 Guidelines4/5

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

Gives an explicit trigger ('when the person you are helping has... and wants to know which routine tests may be due') and an explicit boundary ('decision support for visit preparation, not a diagnosis'), plus re-run guidance with the check_again date and a weekly cadence. It never names a sibling tool as the alternative, so the routing is implied rather than stated.

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

Deploy Server