Skip to main content
Glama
chrischall

MyAtriumHealth MCP Server

by chrischall

mah_list_message_folders

Read-only

List Message Center folders with unread and total counts to locate folders with new messages. Choose compact or full response format.

Instructions

List Message Center folders with unread and total counts. Folder tags seen: 1 Conversations/inbox, 2 Archive, 3/6/7 Bookmarked, Appointments, Automated.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
viewNoResponse shape: "compact" (default) drops fields the response already carries elsewhere; "full" returns every field this server understands. compact strips image/avatar URLs from every response, and on the readers with a projection derived from a captured payload (mah_list_allergies, mah_list_health_issues, mah_list_immunizations, mah_list_medications, mah_list_care_team, mah_list_goals, mah_list_test_results, mah_list_past_visits, mah_list_insurance, mah_list_messages) also reduces each record to its clinically meaningful fields; "full" returns MyAtriumHealth's payload untouched. Every other reader gets the URL strip only, rather than a field list nobody verified.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.3.3

TDQS

A3.8/5.0
Behavior3/5

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

readOnlyHint=true already establishes the safety profile. The description adds value by explaining that folder tags (1, 2, 3/6/7) map to semantic names like Conversations/inbox, Archive, and Bookmarked, which helps interpret output. It doesn't discuss rate limits, auth, or pagination, but those may be irrelevant for a small folder list.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two compact sentences, front-loaded with purpose and then concrete tag mappings. No filler. The tag list is slightly terse but not wasteful.

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

Completeness3/5

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 no output schema, the description covers the core function and tag semantics. However, it omits what the response shape looks like (e.g., folder objects with counts) and doesn't mention prerequisites like authentication, leaving some gaps for an agent to infer.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a detailed enum description for 'view' that explains behavior across multiple readers. The description adds nothing beyond the schema, but the baseline for high coverage is 3; a 4 is warranted because the schema itself is thorough and the description doesn't need to compensate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (list), resource (Message Center folders), and value-add (unread and total counts). This clearly distinguishes it from sibling tools like mah_list_messages or mah_reply_message, which operate on messages rather than folders.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage (browsing folder structure before listing messages) but gives no explicit when-to-use or when-not-to guidance. It doesn't reference alternatives like mah_list_messages, so the agent must infer the workflow.

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