Skip to main content
Glama
Sign In
Last EHR

Last EHR

by cbetz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

read_chart_section

Read-only

Read one section of a patient's chart with optional code and date filters to answer questions about specific records or time windows without fetching the whole chart.

Instructions

Read one section of a patient's chart, with optional code and date filters. Use for questions about a specific kind of record or time window — like a last immunization, blood pressure over six months, current goals or care plans, or documents — instead of fetching the whole chart.

Input Schema

NameRequiredDescriptionDefault
codeNoA code token, e.g. a LOINC/SNOMED/RxNorm/CVX code or system|code — never free text. Supported on Observation, Condition, AllergyIntolerance, MedicationRequest, and Immunization, and only matches records that carry a coding.
countNo
dateToNoLatest date, YYYY-MM-DD.
statusNoFilter by the section's status, e.g. 'active' for current problems, medications, goals or care plans; 'requested' or 'in-progress' for open tasks; 'completed' for administered immunizations. If the value is not legal for that section the reply lists the ones that are.
includeNoAlso return resources this section points at, so references stop being dead ends. 'authors' = who performed, requested, or asserted it (a Practitioner or Organization); 'encounter' = the visit; 'facility'/'location' = Encounter only; 'provenance' = who or what created each row, which is how you answer whether an entry was AI-written and who approved it. Not every section supports every option; the reply names the ones it does.
categoryNoObservation only: separates kinds of result — 'vital-signs' for vitals, 'laboratory' for labs. Use it whenever the question is about one or the other.
dateFromNoEarliest date, YYYY-MM-DD.
patientIdYesThe patient resource id.
measurementNoObservation only, and the preferred way to ask for a vital sign: the NAME of the measurement — 'blood pressure', 'heart rate', 'temperature', 'weight', 'oxygen saturation'. The tool resolves the name to the right LOINC code(s), so never recall a code from memory for a vital. 'blood pressure' resolves to both systolic and diastolic. If the name is not recognized the reply lists the ones that are. Do not combine with code.
resourceTypeYesWhich chart section to read.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior3/5

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

readOnlyHint=true already establishes the safety profile, so the bar is low. The description body itself adds only scope framing; the genuinely useful behavioral detail (invalid status values get the legal list echoed back, unsupported include options are named, unrecognized measurement names are rejected with candidates) lives in schema parameter text rather than the description, and nothing is said about result volume or count defaults.

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?

Two sentences, no filler. The core action leads, and the usage sentence packs a when-to-use rule, four concrete examples, and a scope-vs-alternative contrast without repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 10 parameters (2 required) and an enumerated resourceType, the description gives enough framing to call the tool correctly, and the schema fills in the parameter detail. The main gap is that there is no output schema and the description never indicates what shape a response takes or how boundaries between sections are handled.

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 90%, so parameters are already well explained — code, status, include, category, and measurement all carry rich inline guidance including the 'do not combine with code' constraint. The description adds nothing parameter-specific beyond restating that code and date filters exist, so baseline 3 applies.

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 ('Read one section of a patient's chart') and immediately scopes it with 'optional code and date filters'. The named examples — last immunization, blood pressure over six months, goals/care plans, documents — make the section-based read model concrete and distinguish it from a whole-chart 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?

Explicitly says when to use it ('questions about a specific kind of record or time window') and gives the alternative it replaces ('instead of fetching the whole chart'). The one soft spot is 'or documents', which sits ambiguously against the read_document sibling without saying which to pick for document content.

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