Skip to main content
Glama
Sign In
MetricBridge (formerly Health Export AI)

MetricBridge (formerly Health Export AI)

by PhilipAD
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

get_lab_results

Read-onlyIdempotent

Retrieve Apple Health Records lab results filtered by test name, LOINC code, or date range; returns values, units, dates, institutions, and reference ranges exactly as reported, without interpretation.

Instructions

The user's lab results from Apple Health Records (health-labs.json), exported only when they switched on Lab results > Include in exports in the MetricBridge iOS app, and only into a picked folder (never iCloud Drive). Off by default. Each test (LOINC code when the lab sent one, name, unit) lists its results oldest first, with the value, date, institution and the lab's own reference range, all exactly as reported. Nothing is flagged, graded or interpreted: do not call a result normal or abnormal, and never convert between units (a test in two units is listed once per unit, splitByUnit: true). Filters: {test (case-insensitive part of the name, e.g. ldl), loinc (exact code, e.g. 13457-7), start, end (local days, inclusive)}. Above 400 matching results the newest 400 are returned with resultsOmitted. No match returns count 0 with knownTests. When the file is missing the answer is available:false, which means the user has not exported lab results, not that they have none.

Input Schema

NameRequiredDescriptionDefault
endNoLast result day (inclusive), YYYY-MM-DD.
testNoPart of a test name, case-insensitive, e.g. ldl or vitamin d. Omit for every test.
loincNoExact LOINC code, e.g. 13457-7. Omit for every test.
startNoFirst result day (inclusive), YYYY-MM-DD.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.10.0

TDQS

A4.4/5.0
Behavior5/5

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

Goes far beyond the readOnly/idempotent annotations: discloses the 400-result cap with `resultsOmitted`, the no-match return (`count 0` with `knownTests`), the missing-file return (`available:false` meaning 'not exported', not 'no data'), the splitByUnit duplication rule, and the no-interpretation policy. This is exactly the extra context annotations cannot carry.

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-loaded with what the data is and its export precondition, then filters, then edge-case return behavior. Dense but almost every clause carries operational value; the parenthetical export-path detail is slightly verbose for the value it adds.

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?

No output schema exists, yet the description explains the return shape thoroughly: ordered results with value/date/institution/reference range, `resultsOmitted`, `count`, `knownTests`, `available`, and `splitByUnit`. An agent can call this correctly and interpret every outcome without further documentation.

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 coverage is 100%, so all four parameters are already documented with types, formats and examples. The description's filters block (including the `ldl` and `13457-7` examples and 'local days, inclusive') largely restates what the schema already says, adding only the note that filtering is by name-part vs exact code 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: the user's lab results from Apple Health Records (health-labs.json), with the exact scope of what each test entry contains. This is clearly distinguishable from siblings like get_health_metrics or get_structured_export, which cover other data domains.

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 strong contextual usage conditions: results exist only when the user enabled Lab results > Include in exports, exports go only to a picked folder, and the tool is off by default. It also sets explicit behavioral constraints (never interpret, never convert units), but it does not name an alternative sibling for non-lab data queries.

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

Deploy Server

Other Tools