Health by Dr Brad

Official

by DrBradStanfield

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

Compute the health plan

get_plan

Read-onlyIdempotent

Compute your health plan from your own record: current values, due screenings, and evidence-based suggestions with reasons and citations, all offline. Educational, not medical advice.

Instructions

Compute the user’s plan from their record — current values, what screening or test is due, and suggestions with the reason and citations behind each one. This is the app’s own protocol, computed offline from the file; it is educational, not medical advice. On Dropbox the result also lists files in the folder that are not in the record (folder); offer to import them, never do it unasked.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description
`due`	Yes
`today`	Yes
`units`	Yes	The SI unit each `inputs` field is stored in, keyed by input field. A catalogued labValues[] row is stored in its SI unit, converted from what the lab printed; a test the catalogue does not know keeps the unit it was reported in.
`folder`	No	Dropbox only: files in the folder root that are not in the record. Offer to import them; never do it unasked.
`inputs`	Yes	The values the plan was computed from, in SI canonical units (see `units`, keyed by input field). `currentValues` is the same rows converted to `unitSystem`, plus any row marked excluded.
`source`	Yes
`profile`	Yes	`bmiCategory` is waist-informed: a BMI of 25–29.9 with a waist-to-height ratio below 0.5 reads Normal (AACE 2025 / NICE). `waistToHeightRatio` is the ratio it used, or null.
`labValues`	Yes
`screenings`	Yes
`unitSystem`	Yes
`generatedAt`	Yes
`instruction`	Yes	How this plan must be presented. Follow it.
`medications`	Yes
`suggestions`	Yes
`currentValues`	Yes
`missingInputs`	Yes	Inputs the record does not hold that would change this plan. Ask the user for these, then add them.
`schemaVersion`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 20, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, so the safety profile is covered. The description adds meaningful context beyond that: the plan is computed offline from the file, it is educational and not medical advice, and on Dropbox it also surfaces non-record folder members that the agent may offer (but must not perform) to import. No auth or rate-limit details are given, so not a 5.

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?

Three sentences, front-loaded with the core purpose, followed by the offline/educational caveat and the Dropbox-import rule; every clause carries information. The first sentence is heavy with comma-separated detail but remains scannable.

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?

With an output schema present, return values need no explanation, and the annotations cover the safety profile. The description still supplies the non-obvious essentials an agent needs: offline computation, the educational disclaimer, and the conditional Dropbox folder-listing behavior with its do-not-import-unasked guard.

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 tool takes zero parameters, so per the baseline there is nothing for the description to disambiguate. The mention of `folder` refers to an output field rather than an input, which is mildly useful orientation but adds no parameter semantics.

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+resource (compute the user's plan from their record) and enumerates the outputs: current values, due screenings/tests, and suggestions with reasons and citations. It explicitly distinguishes itself from siblings like read_record and import_documents by clarifying that this is the app's own protocol computed offline, not a raw record fetch.

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 clear context for use (derive the personalized plan from the local file) and an explicit behavioral constraint for the Dropbox case: offer to import listed files, never do it unasked. It does not name an alternative sibling tool or state a when-not condition, so it falls short of the 5 benchmark.

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

Deploy Server