Hosted MCP server for the Healthie EHR & telehealth API: patients, appointments, charting, tasks.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4/5 across 16 of 16 tools scored. Lowest: 2.9/5.
Each tool targets a distinct resource and action (e.g., create_note vs create_task, list_patients vs list_appointments). No two tools overlap in purpose, making selection unambiguous.
All tools follow a consistent 'healthie_<verb>_<noun>' pattern with lowercase verb and noun. Plural nouns are used for list operations, singular for get operations, maintaining a predictable convention.
16 tools cover the major entities in a healthcare EHR system (users, appointments, notes, tasks, goals, metrics, documents, forms, conversations) without being excessive or sparse.
The tool set is heavily read-oriented with only two mutation tools (create_note, create_task). Missing update/delete operations for most resources (e.g., no update_appointment, delete_user) and no create for key entities like appointments or patients, leaving significant gaps for typical workflows.
healthie_create_noteCreate a note / chat entry (WRITE — creates a record)BCreates a note/chat entry in Healthie (additive). Requires content (the note text); optionally attach it to a client (user_id) or mark it as an org chat. GraphQL: mutation createNote(input: createNoteInput).
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | The note text. | |
| user_id | No | The client/user the note is about. | |
| org_chat | No | True if created in the organization chat context. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotation contradiction: the description says 'additive' and 'creates a record', while annotations declare destructiveHint: true. These directly conflict. No other behavioral disclosure beyond this contradiction is provided (e.g., idempotency, side effects), so transparency fails.
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 sentences provide purpose, requirement, and optional parameters, followed by an optional GraphQL note. The structure is front-loaded with the core purpose, the language is direct, and every word 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?
There is no output schema, and the description does not mention what the note creation returns or whether it is idempotent. The annotation contradiction (destructiveHint vs 'additive') creates confusion about expected behavior. While the operation itself is simple, the lack of return info and safety reconciliation leaves gaps for an AI 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 description coverage is 100%, so the baseline is 3. The description slightly enhances parameter meaning by explaining user_id as 'attach to a client' and org_chat as 'mark as org chat', but these are largely redundant with the schema and do not add substantial new semantics.
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 clearly states 'Creates a note/chat entry in Healthie (additive)' with a specific verb and resource. The title echoes this by marking it as WRITE. This distinguishes it from siblings like healthie_create_task, which targets tasks rather than notes.
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 description gives context on how to use the tool ('Requires content', 'optionally attach it to a client... or mark as org chat') but does not explicitly state when to use this tool versus alternatives like healthie_create_task, nor does it give any exclusion criteria. Usage is implied rather than directly instructed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
healthie_create_taskCreate a task (WRITE — creates a record)BCreates a task in Healthie (additive). Requires content (the task text); optionally attach it to a client (user_id), set a due_date, priority, or created_by_id. GraphQL: mutation createTask(input: createTaskInput).
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | The task text/description. | |
| user_id | No | The client/user the task is about. | |
| due_date | No | Due date (YYYY-MM-DD). | |
| priority | No | Priority (integer). | |
| created_by_id | No | Id of the user creating the task. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly says "additive" (non-destructive), but the annotations declare destructiveHint: true. This is a direct contradiction, leaving the agent with contradictory signals about the tool's safety profile.
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?
The description is two sentences, front-loaded with the primary verb, and includes the GraphQL mutation path without unnecessary fluff. Every sentence carries useful content.
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 simple create tool with complete schema coverage and no output schema, the description covers purpose, required/optional parameters, and the mutation endpoint. It lacks alternative disambiguation or return behavior, but those are not strictly necessary 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?
The schema already provides full descriptions for all 5 parameters (100% coverage). The description merely restates their roles without adding constraints, relationships, or syntax details beyond 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?
The description uses the specific verb "Creates" with the resource "task in Healthie" and clarifies additive behavior. This distinguishes it from sibling tools like healthie_create_note and healthie_list_tasks.
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?
It states required content and optional parameters, giving clear context for invocation. However, it does not explicitly mention when to use this tool over alternatives like healthie_create_note, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
healthie_current_userCurrent user / accountAFetch the authenticated Healthie account (the provider/user that owns the API key). Good first call to verify auth. Read-only. GraphQL: query currentUser.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already declares the read-only nature. The description adds value by explaining that it returns the account owning the API key and reinforces the read-only behavior, which is useful for an agent's trust assessment.
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?
The description is very concise: three short sentences covering what it does, when to use it, and the read-only nature. No word is wasted and it is front-loaded.
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 zero-parameter, read-only query, the description fully covers the purpose, target resource, and authentication context. It lacks output schema but the description already implies the return is the current account; no gaps for agent decision-making.
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 has zero parameters, so the schema offers 100% coverage by being empty. Per guidelines, 0 params baseline is 4; no further explanation is needed.
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 clearly states the tool fetches the authenticated Healthie account, identifying the specific resource (the provider/user that owns the API key). This distinguishes it from sibling tools like get_user or get_organization, which target other entities.
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?
It explicitly recommends using this as a first call to verify auth, giving a clear use case. It does not name after natively excludes cases, but the context of the current account makes the intended scope obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
healthie_get_appointmentGet an appointmentAFetch a single appointment by id. Read-only. GraphQL: query appointment(id).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The appointment id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, and the description redundantly states 'Read-only.' It adds the GraphQL query detail, which offers minimal extra context. No additional behavioral traits like error handling or auth requirements are disclosed, but the tool is simple enough that the description plus annotations suffice.
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?
The description is two short sentences, front-loaded with the core action and resource. Every word earns its place, and there is no waste or redundancy beyond the harmless repetition of 'Read-only.'
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 read-only tool with one fully described parameter and a readOnlyHint annotation, the description is complete. It clearly states what to provide (id) and that the operation is read-only, and no output schema is needed to understand the return value.
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 input schema covers the sole 'id' parameter fully with a description. The tool description does not add semantic meaning beyond what the schema provides, so a baseline score of 3 is appropriate.
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 'Fetch a single appointment by id,' which is a specific verb and resource with clear scope. It distinguishes from siblings like healthie_list_appointments by emphasizing single record retrieval.
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 description clearly indicates when to use the tool: when you need one appointment by id. It doesn't explicitly mention alternatives or exclusions, but the context is clear and sufficient for a simple get-by-id operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
healthie_get_organizationGet organizationAFetch the current organization / practice (name, NPI, contact, user counts). Read-only. GraphQL: query organization.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond the readOnlyHint annotation by naming the returned fields (name, NPI, contact, user counts) and noting it is a GraphQL query. However, it does not disclose any edge cases or limitations such as what 'user counts' includes, so it stays at a baseline level.
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?
The description is two sentences long, front-loads the purpose, and includes the key behavioral note about read-only and GraphQL. Every word 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?
For a simple parameterless read tool, the description provides enough information about what the tool returns and its technical implementation. No output schema exists, but the listed fields suffice for an agent to understand the return value.
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 has zero parameters, so the schema trivially covers 100%. The description correctly avoids parameter details, earning the baseline score of 4 for parameterless tools.
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 clearly states the verb 'Fetch' and the resource 'current organization / practice', and lists the key data fields returned. It distinguishes itself from sibling tools since no other tool fetches organization-level information.
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 description implies when to use it—when you need the current practice's details—by specifying the resource scope. It does not explicitly reference alternatives, but the sibling list makes it clear this is the only org-level read tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
healthie_get_userGet a user / patientAFetch a single user (patient or provider) by id. Read-only. GraphQL: query user(id).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The user id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The read-only behavior is already declared via annotations (readOnlyHint: true), and the description redundantly restates it. The addition of 'GraphQL: query user(id)' provides some underlying implementation detail, but no further behavioral traits (e.g., error handling, permissions, pagination) are disclosed. Since annotations cover the safety profile, this is acceptable but not rich.
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?
The description is very brief and front-loaded, consisting of three short clauses. However, 'Read-only' repeats information already present in annotations, and the GraphQL note is somewhat redundant for an AI agent. It is concise, but not perfectly free of waste.
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?
The tool is simple (one parameter, no nested objects, no output schema). The description clearly states what it fetches (a user) and the identifier (id). For a get-by-id operation, this is nearly complete, though it could mention that it returns the full user object or note any error behavior. Given the low complexity, the information is sufficient for correct invocation.
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 schema already provides 100% coverage of the 'id' parameter with the description 'The user id.' The description's phrase 'by id' reinforces this but does not add new semantic details such as format, constraints, or examples. The baseline of 3 is appropriate when schema fully documents the parameters.
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 clearly states the action ('Fetch') and the resource ('a single user (patient or provider) by id'). It distinguishes itself from sibling tools like list_patients (which lists) and get_appointment (different resource). The subject is specific and 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?
The description mentions 'by id', which implies the primary use case: retrieving a specific user when the id is known. While it does not explicitly name alternatives or exclusions, the contrast with listing tools (e.g., list_patients) is clear from the singular vs. list phrasing. This provides adequate context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
healthie_list_appointmentsList appointmentsAList appointments, optionally filtered by patient, provider, date range, time-filter or status. Read-only. GraphQL: query appointments(user_id, provider_id, filter, startDate, endDate, filter_by_appointment_status).
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | Time filter: "future" (default), "past", "ended", "didnt-occur". | |
| endDate | No | End date (YYYY-MM-DD) to bound results. | |
| user_id | No | Filter to appointments for this patient/client id. | |
| startDate | No | Start date (YYYY-MM-DD) to bound results. | |
| provider_id | No | Filter to appointments for this provider id. | |
| filter_by_appointment_status | No | Filter by appointment status label. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description repeats 'Read-only' and adds the GraphQL query shape. Since the annotation already covers the safety profile, the description adds minimal extra behavioral context beyond what the schema provides; it does not disclose pagination, response format, 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?
The description is concise, consisting of two short sentences that front-load the primary action and then list filter options. It includes the GraphQL syntax without unnecessary fluff, making it easy to scan and parse.
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?
Given there is no output schema, the description explains the list purpose and filter options well. It does not mention return format or pagination, but for a filtered-list tool with read-only annotation, this is a minor gap. Overall, it provides enough context for an agent to understand the tool's role.
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%, so the baseline is 3. The description lists the GraphQL parameters and explains filters (patient, provider, date range, time-filter, status) but these mirror the schema descriptions without adding new semantic detail beyond parameter purposes.
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 clearly states the tool lists appointments with optional filters by patient, provider, date range, time-filter, or status. It distinguishes itself from sibling tools like healthie_get_appointment (singular) and healthie_list_appointment_types by explicitly focusing on appointments and list behavior.
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 description implies usage for listing appointments and mentions optional filters, but it does not explicitly state when to use this tool over alternatives or provide exclusionary guidance. The read-only nature and GraphQL query are context, but no direct comparison to siblings is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
healthie_list_appointment_typesList appointment typesAList the practice's appointment types (services), optionally keyword-filtered. Read-only. GraphQL: query appointmentTypes(keywords, offset, page_size, should_paginate).
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | Pagination offset. Default 0. | |
| keywords | No | Free-text search over appointment type names. | |
| page_size | No | Results per page. Default 25. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint: true, and the description redundantly states 'Read-only.' It adds minor context about the practice scope and GraphQL query structure, but does not disclose return format, pagination behavior, or other operational details. The annotation covers the safety profile, matching the baseline.
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?
The description is two concise sentences, front-loaded with the core purpose. The additional 'Read-only.' and GraphQL query line are brief and do not waste words. It is well-structured and easily parsed.
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 simple read-only list tool with full schema descriptions and zero required parameters, the description is adequate. It explains the scope, filtering option, and underlying GraphQL query. However, it lacks explicit alternatives or return-value details, which would make it fully complete.
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 input schema descriptions cover all three parameters (offset, keywords, page_size) at 100% coverage. The description's mention of 'keyword-filtered' and the GraphQL call adds no significant meaning beyond what the schema already provides, so 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 clearly states the tool lists the practice's appointment types (services), which is a specific verb+resource. It distinguishes itself from sibling tools like healthie_list_appointments by explicitly targeting appointment types rather than appointments.
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 description mentions optional keyword filtering and read-only behavior but provides no explicit guidance on when to use this tool versus alternatives. It lacks exclusions or alternative tool mentions, so usage context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
healthie_list_conversationsList conversationsAList messaging conversations, optionally between the current user and a given user. Read-only. GraphQL: query conversations(user_id).
| Name | Required | Description | Default |
|---|---|---|---|
| user_id | No | Get conversations between the current user and this user id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description repeats 'Read-only' which is already in the annotations, and adds a GraphQL implementation detail, but it does not disclose behavioral traits beyond that, such as permissions, pagination, or response format. The optional user filter is already captured by the schema, so no new behavioral information is added.
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?
The description is concise and front-loaded with the core purpose. The 'Read-only' phrase is redundant with the annotation, but the GraphQL note adds useful technical context without excessive length.
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 simple read-only, single-parameter tool, the description is adequate. It does not explain return values, but there is no output schema and the tool's purpose is straightforward. The sibling context and annotations fill most 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?
The schema description for user_id fully covers the parameter semantics ('Get conversations between the current user and this user id'), and the description adds no new meaning beyond that. With 100% schema coverage, a baseline of 3 is appropriate.
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 clearly states the tool's function with a specific verb and resource: 'List messaging conversations.' It also mentions the optional user filter, distinguishing it from sibling list tools like appointments, documents, or forms.
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 description provides clear context for when to use the tool (listing conversations, optionally filtered by user) but does not explicitly mention alternatives or exclusions. Sibling names make the distinction obvious, so this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
healthie_list_documentsList documentsAList documents, optionally scoped to a patient (viewable_user_id) or by keyword. Read-only. GraphQL: query documents(viewable_user_id, keywords, offset, page_size, should_paginate).
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | Pagination offset. Default 0. | |
| keywords | No | Free-text search over document names. | |
| page_size | No | Results per page. Default 25. | |
| viewable_user_id | No | Patient id whose documents to list. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description reinforces 'Read-only.' It adds behavioral context about optional filtering and provides the underlying GraphQL query signature, which gives the agent insight into the API mapping beyond the annotation.
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?
The description is two sentences, front-loaded with the core purpose, and contains no redundant information. The GraphQL signature is compact and adds value without bloat.
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 simple list tool with all-optional parameters, the description covers the essential behavior: listing documents with optional filters. The read-only annotation and schema fill in remaining details. The GraphQL signature adds extra context, though the unexplained 'should_paginate' is a minor omission.
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%, so the schema fully documents all four parameters. The description lists the same parameter names in the GraphQL signature but does not add new semantic detail. The mention of 'should_paginate' in the GraphQL is extraneous and could be confusing since it's not in the input 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?
The description clearly states 'List documents' with optional scoping by patient or keyword. The verb 'list' and resource 'documents' are specific, and the scoping options distinguish it from sibling list tools for other resources.
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 description provides clear context on when to use: when listing documents, optionally filtered by viewable_user_id or keyword. It does not explicitly mention alternatives or exclusions, but the resource-specific nature makes the intended use apparent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
healthie_list_form_answer_groupsList completed forms / charting notesAList completed form submissions (charting notes / filled intake forms), optionally scoped to a patient or a form template. Read-only. GraphQL: query formAnswerGroups(user_id, custom_module_form_id, should_paginate, offset).
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | Pagination offset. Default 0. | |
| user_id | No | Filter to submissions for this patient id. | |
| custom_module_form_id | No | Filter to submissions of this form template id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates read-only; the description redundantly says 'Read-only' but adds a GraphQL query signature. However, it does not disclose additional behavioral traits such as return format, pagination behavior, or rate limits. With annotations covering safety, the description adds marginal value, matching a 3.
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?
The description is two sentences long and front-loads the purpose. The GraphQL detail is somewhat technical and may be extraneous for typical users, but the text is efficient and free of fluff, earning a 4.
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 simple list tool with three optional parameters and read-only annotation, the description covers purpose, filters, and read-only nature. Without an output schema, it doesn't describe return values, but this is acceptable for a basic list operation. Overall, it's sufficiently complete for the tool's complexity.
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% for all three parameters, so the schema fully documents each. The description restates scoping in prose and includes a GraphQL query with should_paginate, a parameter not present in the input schema, which may confuse users. Since the schema carries the burden, the description adds little beyond baseline.
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 clearly states 'List completed form submissions (charting notes / filled intake forms)' with a specific verb and resource. It also mentions optional scoping to patient or form template, which distinguishes it from sibling tools like healthie_list_forms that likely deal with form templates, not submissions.
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 description provides clear context: use this to list completed form submissions, optionally filtered by patient or template. It doesn't explicitly exclude alternatives, but the phrase 'completed form submissions' implicitly differentiates from healthie_list_forms (templates) and other list tools. No explicit when-not guidance, but the context is clear enough for a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
healthie_list_formsList charting / intake form templatesAList custom module form templates (charting notes, intake forms), optionally by keyword or category. Read-only. GraphQL: query customModuleForms(keywords, category, offset, page_size, should_paginate).
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | Pagination offset. Default 0. | |
| category | No | Filter by form category. | |
| keywords | No | Free-text search over form names. | |
| page_size | No | Results per page. Default 25. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint=true, and the description repeats 'Read-only', which is redundant. It adds the underlying GraphQL query name and parameters, but does not describe return format or pagination behavior, so it provides only modest additional transparency.
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?
The description is a single concise sentence that front-loads the core action and resource, then adds a helpful GraphQL reference. Every word 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?
For a simple list tool with read-only annotations and a fully documented schema, the description is adequate: it names the resource, filter capabilities, and underlying query. It does not explicitly describe the output list shape, but the title and 'List' verb imply it; this misses an opportunity for full completeness.
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 schema describes all four parameters with defaults and meanings, achieving 100% coverage. The description only restates 'keyword or category' and lists the GraphQL parameters, adding no new semantic meaning beyond 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?
The description uses a specific verb ('List') and identifies the resource as 'custom module form templates' with examples 'charting notes, intake forms'. This clearly distinguishes it from sibling list tools like list_documents or list_form_answer_groups.
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 description states the tool lists form templates and can filter 'by keyword or category', providing clear context for when to use it. However, it does not mention specific alternatives or exclusions, so it earns a 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
healthie_list_goalsList goalsAList goals, optionally scoped to a patient. Read-only. GraphQL: query goals(user_id, offset, per_page).
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | Pagination offset. Default 0. | |
| user_id | No | Filter to goals for this patient id. | |
| per_page | No | Results per page. Default 25. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description reinforces this with 'Read-only.' It adds the underlying GraphQL query signature (query goals(user_id, offset, per_page)), which provides implementation context beyond the structured metadata. No contradiction with 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?
The description consists of two short, direct clauses: 'List goals, optionally scoped to a patient. Read-only. GraphQL: query goals(user_id, offset, per_page).' No filler or redundancy; front-loaded with the action and resource.
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 simple optional-param list tool, the description plus schema and annotations are sufficient. No output schema exists, but the return behavior is evident from a list operation. The GraphQL hint adds useful context without over-explaining.
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%, so each parameter is already documented. The description adds minimal extra value by mapping 'scoped to a patient' to user_id and showing the parameter order in the GraphQL signature, but it does not introduce new meaning beyond 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?
The description uses a specific verb ('List') and resource ('goals'), and adds 'optionally scoped to a patient' to clarify scope. This clearly differentiates it from sibling list tools for other resources like appointments or patients.
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 description provides clear context by stating it lists goals and can be filtered by patient. It does not explicitly mention alternatives or exclusions, but the resource name makes the intended usage obvious compared to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
healthie_list_metric_entriesList metric entriesAList tracked metric entries (weight, blood pressure, etc.), optionally scoped to a client or a category. Read-only. GraphQL: query entries(client_id, category, offset, page_size).
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | Pagination offset. Default 0. | |
| category | No | Entry category, e.g. "MetricEntry", "Weight". | |
| client_id | No | Filter to entries for this client id. | |
| page_size | No | Results per page (max 500). Default 25. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds 'Read-only' plus a GraphQL query snippet, which is consistent but not substantial. It does not disclose additional side effects, pagination limits, or auth requirements, but the annotation covers the safety profile.
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?
The description is two concise sentences covering purpose, scoping, read-only nature, and the underlying query. Every clause contributes information, with no filler or redundancy.
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 simple list operation with four optional parameters, the description explains the resource type, optional filters, and read-only behavior. While there is no output schema, the purpose and usage are sufficiently clear for an agent to invoke the tool correctly.
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 schema covers 100% of parameters with descriptive explanations, so the baseline is 3. The description's mention of client/category scoping aligns with the schema, and the GraphQL line lists parameter names but adds little beyond the existing schema descriptions.
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 specifies the exact operation ('List tracked metric entries') with concrete examples (weight, blood pressure) and optional scoping, distinguishing it from sibling list tools like healthie_list_appointments. The GraphQL query further confirms the resource and action.
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?
It states the tool is optionally scoped to a client or category, providing clear context for when to use filters. However, it does not explicitly name alternatives or when not to use this tool, so it lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
healthie_list_patientsList patients / clientsAList patients/clients, optionally filtered by keyword search or active status. Read-only. GraphQL: query users(keywords, offset, page_size, should_paginate, active_status).
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | Pagination offset. Default 0. | |
| keywords | No | Free-text search over name/email. | |
| page_size | No | Results per page (max 100). Default 25. | |
| active_status | No | Filter by status: "active" or "archived". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description repeats 'Read-only' which is already disclosed by the readOnlyHint annotation, adding little new information. It does include the GraphQL query for transparency, but does not detail pagination behavior, return format, or any side effects beyond what annotations and schema provide.
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?
The description is concise with two sentences. The first states the core function, the second adds relevant technical context. No redundant words exist, and it is appropriately sized for the tool's simplicity.
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?
The description is mostly complete for a simple list tool with good schema coverage and annotations. It does not explain return values, but for a list operation that is not critical. It also omits pagination defaults, though those are in the schema. Overall, it provides sufficient context to use the tool correctly.
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 100%, so parameters are well-documented. The description adds only a grouped mention of 'keyword search or active status' which aligns with the schema, but does not add substantive meaning beyond it. Note: the GraphQL query mentions 'should_paginate' which is not in the schema, potentially causing confusion, but it does not directly affect parameter understanding.
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 clearly states the tool lists patients/clients with optional filtering by keyword or active status. It uses a specific verb ('List') and identifies the resource, distinguishing it from sibling tools like get_user or list_appointments.
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 description implies it is for listing patients with optional filters, which provides clear context for when to use it. It does not explicitly mention alternatives or exclusions, but the context signals show sibling tools, and the description's scope is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
healthie_list_tasksList tasksAList tasks, optionally scoped to a client or filtered by completion status. Read-only. GraphQL: query tasks(client_id, completed_status, offset, per_page).
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | Pagination offset. Default 0. | |
| per_page | No | Results per page. Default 25. | |
| client_id | No | Filter to tasks about this client id. | |
| completed_status | No | Completion filter, e.g. "complete" or "incomplete". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a GraphQL query template ('query tasks(client_id, completed_status, offset, per_page)') beyond the readOnlyHint annotation, revealing the underlying interface and parameter usage. It does not describe rate limits, error behavior, or response format, but for a read-only list operation, the read-only trait is already covered by annotations and the description reinforces it without contradiction.
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?
The description is extremely concise: two sentences covering purpose, filters, read-only status, and the GraphQL query. It is front-loaded with the verb and resource, and every word serves a clear function. No redundant or fluff content is present.
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?
Given there is no output schema, the description carries the burden of explaining what the tool returns, which it does implicitly through 'List tasks' and the GraphQL query. It could more explicitly state that it returns a paginated list of tasks, but the operation is simple and the parameters are all documented in the schema. The read-only annotation is sufficient for safety context, so this is adequately complete 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?
The schema description coverage is 100%, with each parameter already explained (e.g., 'Pagination offset', 'Filter to tasks about this client id'). The description's prose ('optionally scoped to a client or filtered by completion status') mirrors the schema without adding new meaning, and the GraphQL line simply lists parameter names without further semantic details. Thus, it does not significantly add beyond 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?
The description clearly states the tool's function: 'List tasks' with optional scoping and filtering. It distinguishes itself from sibling tools by targeting the 'tasks' resource specifically, unlike list_appointments or list_patients, and the verb 'list' contrasts with create_task. This is a specific verb+resource combination with clear scope.
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 description provides context on when to use the tool by noting optional filters ('scoped to a client or filtered by completion status') and explicitly stating 'Read-only,' which implies it is for querying, not mutating tasks. However, it does not explicitly name alternatives or state when not to use it, so it lacks full exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
