Read Akute Health patients, appointments, tasks, notes, medications, allergies and observations.
The last two health checks of this connector failed. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
Scored across 15 tools
Each tool targets a distinct resource (appointment, availability, note, patient, practitioner, task, allergy, appointment type, medication, observation) with clear verb distinction between get (single by id), list (filtered collection), and search (identifying-filter lookup). No two tools could be confused.
Every tool follows the akutehealth_ prefix plus a consistent verb_noun pattern (get_*, list_*, search_*). Naming is entirely predictable and readable.
15 tools is well-scoped for a clinical EHR read surface. Each tool earns its place by covering a distinct resource or operation, with no redundant tools.
The surface is read-only: there is no create, update, or delete for any resource (appointments, notes, tasks, patients, medications, observations). For an EHR integration where agents may need to schedule visits, write notes, or update tasks, this is a significant gap that will cause agent failures.
One appointment by id: times, status, patient, practitioner and appointment type. GET /appointments/{id}.
| Name | Required | Description | Default |
|---|---|---|---|
| appointment_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the returned field set and the underlying endpoint, but says nothing about auth requirements, error behavior for a missing id, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the payload, no filler. The trailing 'GET /appointments/{id}' is mildly redundant but cheap and gives endpoint context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with annotations covering safety and no output schema, the description's enumeration of returned fields fills the main gap. It lacks only guidance on failure/empty behavior, which is minor here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the single parameter (appointment_id) is undocumented in the schema. The description only says 'by id', which confirms identity lookup but adds no format, source, or constraint detail beyond the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('One appointment by id') and previews the returned fields (times, status, patient, practitioner, appointment type), which distinguishes it from the list_* siblings. It does not explicitly name those siblings, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'By id' implies the prerequisite (you must already have an appointment id, typically from list_appointments or a prior lookup), but no alternatives or when-not-to-use cases are stated. Usage is inferable rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open appointment slots of one practitioner between two date-times. GET /availability.
| Name | Required | Description | Default |
|---|---|---|---|
| user_id | Yes | Practitioner (user) id from akutehealth_list_practitioners. | |
| end_time | Yes | Window end, ISO 8601 with offset. | |
| start_time | Yes | Window start, ISO 8601 with offset, e.g. 2026-10-12T00:00:00-06:00. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the semantic content of the read (open slots for one practitioner in a window) but says nothing about pagination, result limits, timezone handling, or how slots are derived — so it goes modestly beyond the annotations without much depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the core purpose front-loaded and no padding. The trailing 'GET /availability' is largely redundant with the name and consumes space without adding agent-relevant meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
All three required parameters are fully documented in the schema and the read-only safety profile is covered by annotations, so the essential information is present. However, with no output schema there is no explanation of the returned slot shape, timezone interpretation, or result size limits, leaving the description adequate but incomplete for a scheduling query.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and each parameter is documented (including the pointer to akutehealth_list_practitioners for user_id), so the schema carries the load. The description only restates the practitioner and the two date-times implicitly, adding no format or constraint detail beyond the schema — the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource ('Open appointment slots of one practitioner') plus an explicit time scope, which is clearly distinct from siblings like akutehealth_get_appointment (a single appointment) or akutehealth_list_appointments. An agent can identify the intent without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool versus alternatives, nor any prerequisites or exclusions. The only usage signal is the endpoint string 'GET /availability', which restates the operation rather than guiding selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One clinical note by id with all its sections (subjective, objective, assessment, plan ...). GET /notes/{id}.
| Name | Required | Description | Default |
|---|---|---|---|
| note_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description usefully adds that the full note is returned with its section breakdown, but says nothing about not-found behavior, permissions, or incomplete notes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with no filler. The trailing 'GET /notes/{id}' restates what the first sentence already conveys, so it is slightly redundant but harmless.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with no output schema, the description adequately conveys what comes back (the note and its sections). It omits error/not-found behavior and where the id is obtained, leaving minor gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the single note_id parameter has no description in the schema, so the description must compensate. 'By id' does confirm the parameter is a note identifier, but it adds no format, length, or sourcing guidance beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('One clinical note by id') and names the returned scope ('all its sections (subjective, objective, assessment, plan ...)'). This distinguishes it from the sibling akutehealth_list_notes, which returns many notes rather than one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'By id' implies the caller already has a note identifier, which is the implicit usage condition. However, it never explicitly states when to use this instead of akutehealth_list_notes, nor where the note id comes from.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One patient by id: demographics, address, status, provider, custom properties and membership billing state. GET /patients/{id}.
| Name | Required | Description | Default |
|---|---|---|---|
| patient_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered without description help. The description adds the GET endpoint and the field categories returned, but discloses nothing about not-found/error behavior, auth requirements, or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact clauses with zero filler, front-loaded with the identity ('One patient by id') before the field enumeration. The trailing 'GET /patients/{id}' is mildly redundant with the name but harmless.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity read tool with one parameter and no output schema, the description covers the return contents at a useful high level and annotations cover safety. However, it omits the parameter's expected format and what happens on an unknown id, leaving real gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single parameter, so the description carries the burden — yet 'by id' merely restates the parameter name patient_id and adds no format, pattern, or length detail that the schema already encodes. It does not compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Get patient', 'One patient by id') and enumerates the returned fields (demographics, address, status, provider, custom properties, billing state). The singular 'one ... by id' implicitly contrasts with the plural list/search siblings, but it never names search_patients, so differentiation is inferential rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'One patient by id' implies the usage condition (you already have the id), but there is no explicit when-to-use statement and no named alternative such as search_patients for when only a name/demographic is known. Usage is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One user by id: name, NPI and roles. GET /users/{id}.
| Name | Required | Description | Default |
|---|---|---|---|
| user_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the returned field list, which is mild behavioral value, but says nothing about not-found behavior or id validity, which would matter for a lookup tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two telegraphic fragments with zero padding and the key information front-loaded. It is terse to the point of being clipped, but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description's field list (name, NPI, roles) usefully tells the agent what comes back. It omits error/not-found handling and id provenance, leaving a simple lookup tool only adequately specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry parameter meaning; it only says 'by id', which barely maps to user_id and adds no format or sourcing guidance. With one required parameter and no schema-level prose, this is thin.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('One user by id') and enumerates the returned fields (name, NPI, roles), so the agent knows this fetches a single practitioner. It only implicitly distinguishes itself from the sibling list_practitioners via the word 'One' rather than naming it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no mention of when to prefer this over akutehealth_list_practitioners or akutehealth_search_patients, and no prerequisites (e.g. whether the caller must already know the id). Usage is only inferable from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One task by id: title, description, due date, priority, status, tags, comments and activity. GET /tasks/{id}.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds value beyond that by enumerating the returned payload (title, description, due date, priority, status, tags, comments, activity) and the endpoint path, which matters because no output schema exists. It does not cover not-found/error behavior, hence 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact fragments with the purpose front-loaded and nothing wasted. The field enumeration is dense but each item carries real information about the return payload rather than restating the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a single required parameter and no output schema, the description supplies the missing return-shape information and the read-only nature is covered by annotations. Only error/absence behavior is unaddressed, which is a minor gap for a simple getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one required param at 0% schema description coverage; the schema carries only structural constraints (pattern, length). The phrase 'by id' ties task_id to task identity but adds no format or sourcing detail beyond that, so the description only marginally compensates for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('get task') plus the retrieval scope ('one task by id'), which cleanly separates it from the sibling list_tasks. It also enumerates the returned fields and the underlying endpoint, so an agent knows exactly what it is fetching, though it never names the sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'One task by id' implies the retrieval condition (you already hold a task id) but there is no explicit when-to-use guidance, no statement of when not to use it, and no named alternative such as list_tasks or search_patients. Usage is inferable but not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A patient's allergies and intolerances: substance, reaction, type, clinical status, onset date. GET /allergies.
| Name | Required | Description | Default |
|---|---|---|---|
| patient_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so safety profile is covered. The description adds what data is returned (substance, reaction, type, clinical status, onset date), which is mildly useful. It does not describe pagination, return format, or auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short fragments that are front-loaded with the resource and its fields. Terse but every element earns its place; the endpoint path is largely redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter list tool with no output schema and 0% schema description coverage, the description leaves the parameter undocumented and says nothing about pagination or return shape. Annotations cover safety but the definition is under-specified overall.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the schema does not document patient_id's meaning, yet the description never mentions the patient_id parameter at all. Description fails to compensate for the low coverage on the only parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (list) and resource (allergies) plus the fields returned. The name and sibling set already make the resource distinction clear, though the description doesn't explicitly differentiate from akutehealth_list_medications or observations beyond naming allergies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no mention of alternatives, no prerequisites stated. The GET /allergies endpoint note is not usage guidance. An agent gets no help deciding between this and related clinical list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Appointments by patient and/or date range, practitioner and status. Give a patient_id, or both start_range and end_range (at most 31 days apart). At most 100 are returned; narrow the dates if truncated. Room links are not returned. GET /appointments.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | ||
| end_range | No | Latest start: a date (yyyy-mm-dd) or ISO date-time. | |
| patient_id | No | ||
| start_range | No | Earliest start: a date (yyyy-mm-dd) or ISO date-time. | |
| practitioner_user_id | No | Practitioner (user) id from akutehealth_list_practitioners. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safe read-only profile, but the description adds genuinely new behavior: a 100-record return cap, truncation guidance ('narrow the dates if truncated'), and the disclosure that room links are omitted. These are exactly the traits an agent cannot read off the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded and terse; the invocation constraint, result cap, and omitted field are all packed into short clauses with no filler. The opening sentence is a fragment rather than a full sentence, but it still reads cleanly and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and zero required parameters, the description carries the return-behavior burden and does so (100 cap, truncation, omitted room links). Nothing an agent needs to invoke a filtered list correctly appears to be missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 60%, so the schema documents start_range/end_range/practitioner but leaves patient_id and status thin. The description compensates by explaining the OR relationship between patient_id and the date-range pair and the 31-day cap constraint, which the schema does not encode.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Appointments') and enumerates the filter dimensions (patient, date range, practitioner, status), which immediately separates it from the singular sibling akutehealth_get_appointment. An agent can tell what it retrieves without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete invocation rules: 'Give a patient_id, or both start_range and end_range (at most 31 days apart).' This is clear context for how to call it, but it never names an alternative or states when a different tool (e.g. get_appointment) should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The practice's appointment types (beta in Akute): name, duration, video flag, who can book, practitioners. GET /appointment_types.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered by structured data. The description adds one genuinely useful behavioral note — that the feature is beta in Akute — plus a hint at the returned shape. It does not mention pagination or result-size behavior for a list endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that wastes little space. The trailing 'GET /appointment_types' restates the underlying endpoint and adds marginal value for an agent, but it is too short to be a real conciseness problem.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of describing what comes back, and it does so by naming the principal fields. The only real gap is the absence of any pagination or result-count note, which matters for a list endpoint in a practice-management system.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4. The description correctly says nothing about inputs and instead spends its words describing the returned fields, which is the right allocation for a parameterless listing tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific resource (the practice's appointment types) and enumerates the fields returned (name, duration, video flag, who can book, practitioners), which clearly differentiates it from siblings like akutehealth_list_appointments (booked appointments) and akutehealth_list_practitioners. The verb is implied by the title rather than stated outright, but the intent is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool versus alternatives, and no prerequisites or exclusions. The only implicit signal is that it is a catalog lookup, which an agent could infer from the resource name alone. No guidance such as 'use this to resolve an appointment type ID before booking' is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A patient's medications: name, strength, directions, quantity, refills, status, diagnoses and prescriber. Optional date window on the start date. At most 100 are returned. GET /medications.
| Name | Required | Description | Default |
|---|---|---|---|
| end_date | No | A date, yyyy-mm-dd. | |
| patient_id | Yes | ||
| start_date | No | A date, yyyy-mm-dd. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds genuinely useful context beyond them: a hard cap of 100 results and the fact that the date window applies to start date, which an agent needs to interpret truncation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight fragments front-load the resource and returned fields, then filters, then the cap. No filler and nothing redundant with the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, enumerating the returned fields is exactly the right compensation, and the 100-record cap warns about truncation. It stops short of saying what happens when more than 100 exist (pagination or silent cutoff), which is the one remaining gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%; start_date and end_date are documented in the schema as yyyy-mm-dd dates, and patient_id is undocumented but self-evident. The description clarifies that the window filters on start date, adding modest value over the schema but no format or boundary details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States the resource clearly (patient medications) and enumerates the returned fields: name, strength, directions, quantity, refills, status, diagnoses, prescriber. An agent can distinguish it from list_allergies or list_observations by resource, though it never explicitly contrasts with those siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The mention of an 'optional date window on the start date' implies when the filters are relevant, but there is no statement of when to use this versus other list/get tools or any prerequisite beyond patient_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clinical notes (encounters) of ONE patient, newest first as Akute returns them: type, service date, status, authors and section text. A patient_id is required and pages are capped at 10. 'entered-in-error' notes appear only when asked for. GET /notes.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Records per page, 1-10 (default 10). | |
| offset | No | Number of records to skip, 0-500 (default 0). Pass the previous reply's next_offset. Narrow the filters instead of paging deeper. | |
| status | No | ||
| patient_id | Yes | ||
| service_date_start | No | Only notes from this day on. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description still adds real behavior beyond them: default ordering ('newest first as Akute returns them'), the 10-record page cap, and the default exclusion of entered-in-error notes. No auth or rate-limit detail, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the resource, scope and returned fields front-loaded; nothing is padded. 'as Akute returns them' is slightly vague and the trailing 'GET /notes' adds little, but overall it is efficiently sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description carries the return-value burden and does so by enumerating the fields returned plus ordering and page size. Given a read-only list tool with 5 parameters this is close to complete; only error/edge behavior is unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 60%, so the schema already documents limit and offset well. The description compensates where it matters by stating patient_id is required, that pages are capped at 10, and that the status enum's 'entered-in-error' value is opt-in only. It says nothing extra about service_date_start.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names the exact resource ('Clinical notes (encounters)'), the scope ('of ONE patient'), the ordering, and the fields returned (type, service date, status, authors, section text). This is enough for an agent to distinguish it from akutehealth_get_note and from the other list_* siblings without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States the prerequisite (patient_id required) and a meaningful inclusion rule ('entered-in-error' notes appear only when asked for), plus the pagination ceiling. It stops short of naming alternatives or saying when to prefer this over get_note / other list tools, so it is clear context without explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A patient's vital signs (default) or laboratory results: name, value, unit, date, LOINC code. At most 100 are returned. GET /observations.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Default vital-signs. | |
| patient_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful behavioral detail beyond that: a hard cap of 100 results, the default category behavior, and the underlying endpoint. It does not disclose what happens beyond the 100 cap (pagination/truncation).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short, front-loaded clauses: what is returned, the result cap, and the endpoint. No filler, though the bare 'GET /observations' adds little for an agent that already has the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return-shape burden and does so by listing the fields (name, value, unit, date, LOINC code). The 100-result cap and category default cover the key calling constraints; only pagination/truncation behavior is left unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% — category is documented (default vital-signs) while patient_id has no description. The description reinforces the category default and clarifies the returned fields, which helps, but adds nothing about the patient_id format or constraints. Baseline 3 is appropriate given partial schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the specific resource (a patient's observations) and enumerates what those observations contain (vital signs or laboratory results with name, value, unit, date, LOINC code). It is clearly distinguishable from siblings like list_medications or list_allergies, though it never explicitly contrasts with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the patient-scoped framing and the stated default (vital-signs), so an agent can infer this returns observation data for one patient. There is no explicit when-to-use guidance, no conditions, and no mention of alternatives for retrieving labs vs vitals other than the category parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The practice's users: id, name, NPI and roles (Practitioner, Prescriber, Staff, Admin ...). Date of birth, DEA number, email and licences are not returned. GET /users.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable non-obvious context: it discloses the role taxonomy (Practitioner, Prescriber, Staff, Admin) and explicitly lists fields that are NOT returned (DOB, DEA, email, licences), which shapes agent expectations. Pagination/result-size behavior is left unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact fragments, front-loaded with the resource and its fields, followed by the exclusion list and endpoint. Every clause carries information; only the trailing 'GET /users' is slightly redundant with the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly shoulders the burden by enumerating returned fields and explicitly noting omitted fields. It is nearly complete for a simple list tool; only pagination or total-count behavior is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4. The description appropriately does not invent parameter details; instead it spends its text on return semantics, which is the right allocation for a no-arg list tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource (the practice's users/practitioners) and enumerates the returned fields (id, name, NPI, roles), plus the underlying endpoint GET /users. It is clear what the tool returns, though it never explicitly contrasts itself with the singular sibling get_practitioner.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use guidance and no named alternative, despite a sibling get_practitioner that fetches one record. Usage is only implied by the plural 'list' framing; an agent must infer that this tool is for bulk retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tasks filtered by patient, status, owner, priority, tag, due date or archive state; at least one filter except archived is required. Pages are capped at 25. GET /tasks.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | ||
| limit | No | Records per page, 1-25 (default 25). | |
| offset | No | Number of records to skip, 0-500 (default 0). Pass the previous reply's next_offset. Narrow the filters instead of paging deeper. | |
| status | No | Statuses, e.g. not-started, in-progress. | |
| archived | No | ||
| owner_id | No | User id of the task owner. | |
| priority | No | For example p1. | |
| patient_id | No | ||
| due_date_end_range | No | A date, yyyy-mm-dd. | |
| due_date_start_range | No | A date, yyyy-mm-dd. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, non-destructive), so the description earns credit for adding the required-filter rule and the 25-record page cap. It still omits how paging/next_offset behaves on return, but the essentials beyond annotations are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Compact and front-loaded: filters first, constraint second, endpoint last. The trailing 'GET /tasks.' is slightly fragmentary but costs nothing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description still conveys the page cap and required-filter behavior, and the offset field documents next_offset paging. A brief note on return shape would complete it, but nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 70%, and the description lists the filter dimensions that map to the parameters, plus the non-obvious rule that at least one filter is mandatory. It does not explain limit/offset semantics, which the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States the resource (tasks) and enumerates the exact filter dimensions (patient, status, owner, priority, tag, due date, archive state), which distinguishes it cleanly from akutehealth_get_task. The GET /tasks endpoint reference reinforces a list-style read.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a concrete prerequisite: 'at least one filter except archived is required', telling the agent this is not a browse-all endpoint. It does not name a sibling alternative, but the filter constraint clearly frames when to use this vs. a single-task lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search patients by name, email, phone (with phone_type), date of birth or external id, optionally narrowed by sex and status. At least one identifying filter is required (no bulk listing); pages are capped at 25 and paging stops at offset 500. Returns demographics, address, status, provider and membership billing state. Government and insurance identifiers are never returned. GET /patients.
| Name | Required | Description | Default |
|---|---|---|---|
| sex | No | For example female or male. | |
| No | |||
| limit | No | Records per page, 1-25 (default 25). | |
| phone | No | Primary phone number, digits only. Needs phone_type. | |
| offset | No | Number of records to skip, 0-500 (default 0). Pass the previous reply's next_offset. Narrow the filters instead of paging deeper. | |
| status | No | Patient status, for example active. | |
| last_name | No | ||
| first_name | No | ||
| phone_type | No | Type of the phone number: mobile, home or work. Required with phone (Akute ignores the number without it). | |
| external_id | No | Your own id for the patient. | |
| date_of_birth | No | A date, yyyy-mm-dd. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/openWorld annotations it discloses hard pagination limits (25 per page, offset stops at 500), states that government and insurance identifiers are never returned, and summarizes the returned field groups despite there being no output schema. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four dense sentences with the required-filter constraint and pagination caps front-loaded; the trailing "GET /patients" is the only marginal content and costs almost nothing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and a large 11-parameter surface, the description compensates by naming the searchable filters, the mutually-required constraint, the pagination envelope, and the returned field groups and exclusions. Nothing essential for a correct call is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 73%, so most parameters are self-documenting, but the description adds a genuine cross-parameter constraint ("at least one identifying filter is required") that the schema's empty required list does not express, plus the phone/phone_type coupling. The per-field meaning it gives (e.g. phone_type) mostly restates the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb and resource (search patients) and enumerates the exact searchable fields, which cleanly separates it from the sibling get_patient (single lookup) and the list_* family. An agent can select it without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"At least one identifying filter is required (no bulk listing)" gives an explicit precondition and rules out the bulk-listing case, and the offset note tells the agent to narrow filters rather than page deeper. It does not, however, explicitly route to get_patient when a patient id is already known.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
akutehealth_list_tasks2 fields changedInput schema / properties / status / minItemsAdded value: +1Input schema / properties / tags / minItemsAdded value: +1akutehealth_get_appointmentakutehealth_get_availabilityakutehealth_get_noteakutehealth_get_patientakutehealth_get_practitionerakutehealth_get_taskakutehealth_list_allergiesakutehealth_list_appointment_typesakutehealth_list_appointmentsakutehealth_list_medicationsakutehealth_list_notesakutehealth_list_observationsakutehealth_list_practitionersakutehealth_list_tasksakutehealth_search_patientsRead Elation Health patients, appointments, problems, allergies, medications, notes and vitals.
Read Nookal locations, practitioners, availability, appointments, clients, cases and invoices.
Read Semble patients, bookings, invoices and products; create patients and tasks, label patients.
Read Halaxy patients, appointments, slots and invoices; create patients, appointments and notes.
Add one secure layer between your agents and this server.