Health Memory
Description
Health memory helps you save and manage personal health notes directly through ChatGPT. You can create topics, organize information, and keep track of things like symptoms, medications, and questions for your doctor—all in one place. Simply tell ChatGPT what you want to save, and it will securely store it in your health memory account on Triangle Health. You can also ask to retrieve or update your notes whenever you need them. Health memory is designed with privacy and control in mind. You decide what information is shared, and all actions are performed only with your explicit permission. This app is intended solely for personal note-taking and organization. It does not provide medical advice, diagnosis, or treatment recommendations.
Capabilities
Publisher Intelligence
Insights and recommendations for app publishers. See how your app performs and how to improve discoverability.
Server Status trianglehealth-mcp v0.1.0
https://app.trianglehealth.com/mcp Last checked: 5h ago
Technical Details
Tools(15)
Showing 15 of 15 tools
| Tool | Description | Flags | Test | Last Tested | |
|---|---|---|---|---|---|
create_topic | Create a new topic on the user's profile, or return the existing one if it already exists. Use this tool when the user asks to add a topic. Input requirements: - Single create: `name` - Bulk create: `names` array Behavior expectations: - Prefer this tool only when the user intent is to create or ensure presence of a topic. - Topic display names are unique across the whole profile, not per group. Creating a second topic with the same name as an existing one is rejected even if it would sit under a different group. For requests to organize, categorize, or move topics into groups, do not call this tool again for names that already exist; call `get_topics`, then `set_topic_group` with the existing topic row ids from that response (field names match the MCP tool schema). - When the user asks to create multiple topics in one request, prefer a single bulk call using `names` rather than multiple single-item calls. - If the user only wants to view existing topics, use the read tool instead of creating. - If this tool reports the topic already exists, treat that as a successful outcome. After calling: - Confirm what topic now exists on the profile. - Share the returned topic link when available. - Do not immediately call `get_topics` only for UI refresh when a topics widget is already open fullscreen; that can create a duplicate widget card. - Only call `get_topics` when the user explicitly asks to re-list topics in chat. | — | 100%Latency 1.2s | May 9, 2026 | |
create_topic_group | Create a new topic group on the authenticated user's profile for organizing topics. Use this tool when the user explicitly asks to create a new group/category for organizing topics. Input requirements: - Single create: `name` - Bulk create: `names` array Behavior expectations: - Use this tool only for grouping/organization requests. - When creating multiple groups from one user request, prefer one bulk call using `names` instead of multiple calls. - If the user asks to move topics too, create the group first, then assign topics with `set_topic_group`. - When the user wants existing topics sorted into categories or groups, create any missing groups, then assign each topic with `set_topic_group`. Do not try to "recreate" topics under a group with `create_topic`—duplicate names fail and topics already exist on the profile. - Avoid duplicate groups when a matching group already exists in `get_topics` output. After calling: - Confirm the group that was created. - If user asked to reorganize topics, continue with `set_topic_group` using bulk `assignments` when many topics move at once, or single-topic fields for one-off moves. | — | 100%Latency 378ms | May 9, 2026 | |
create_topic_note | Create a new user-authored note for the authenticated user's profile. Use this tool when the user explicitly asks to add a note. Notes may be global, associated with condition/topic slugs, or both. Input requirements: - Single create: - `title` - `content` - optional `topicSlugs` (or `topicSlug` shorthand) - Bulk create: - `notes` array of `{ title, content, topicSlugs? }` Behavior expectations: - Use `topicSlugs` for condition/topic associations, not as generic tags. - Confirm the target topic before creating when topic ambiguity exists. - If a requested topic does not exist, create or select the topic first. - When the user asks to create multiple notes in one request, prefer one bulk call using `notes` instead of multiple calls. - Preserve the user's original formatting intent: - If they provide plain text, keep it plain. - If they provide Markdown structure (lists, headings, emphasis), preserve it. After calling: - Confirm note creation and include the created note title. - Share the note link when returned. - Prefer telling the user the current widget can be refreshed in place (manual refresh button / auto-refresh behavior). | — | 100%Latency 938ms | May 9, 2026 | |
delete_topic | Delete/remove a topic from the authenticated user's profile. Use this tool when the user explicitly asks to remove a topic from their tracked list. Input requirements: - `topicSlug`: required; obtain from `get_topics`. Behavior expectations: - This removes the topic association from the profile (it does not delete catalog topic definitions elsewhere). - Do not invent slugs; use exact slugs from `get_topics`. - Confirm destructive intent when wording is ambiguous. After calling: - Confirm which topic was removed. - Do not auto-call read tools just for UI refresh if a topics widget is already open fullscreen. - If the user asks to verify final topic list, call `get_topics`. | destructive | 100%Latency 407ms | May 9, 2026 | |
delete_topic_group | Delete an existing topic group. Use this tool when the user asks to remove a topic group/category. Input requirements: - `topicGroupId`: required; obtain from `get_topics.topicGroups`. Behavior expectations: - Deleting a group should not delete topics; topics become ungrouped. - Confirm destructive intent before calling if user phrasing is ambiguous. - Do not invent IDs; use IDs returned by `get_topics`. After calling: - Confirm the group was deleted. - Mention that grouped topics were ungrouped. - If the user asks to verify updated structure, call `get_topics`. | destructive | 100%Latency 378ms | May 9, 2026 | |
delete_topic_note | Delete an existing user-authored note. Use this tool when the user explicitly asks to remove/delete a note. Input requirements: - `noteId`: required. Behavior expectations: - Only delete notes the user created (user-authored notes). - If the user has not identified a specific note, use search/read tools first to confirm the target. - Confirm destructive intent when user phrasing is ambiguous. After calling: - Confirm the note was deleted (or explain why not). - Do not auto-call read tools just for UI refresh if a notes widget is already open fullscreen. - If the user asks to re-list notes, call `get_topic_notes`. | destructive | 100%Latency 845ms | May 9, 2026 | |
get_topic_notes | Get notes for one specific topic on the authenticated user's profile. Use this tool for data-only note retrieval tied to one specific topic. Do not use this tool to open or render note widgets. If the user explicitly asks to "show", "open", or "display" notes UI, use `list_topic_notes` with a `topicSlug` so the widget opens with data immediately. Input requirements: - `topicSlug`: required, must come from the topic list. Behavior expectations: - Always scope to a single topic; do not use this as a global note browser. - This tool returns user-authored notes attached to that topic only. - If the topic is unknown, ask the user to choose from available topics. - Prefer calling `get_topics` first when topic context is unclear. - For ambiguous "my notes" requests, resolve or confirm topic first; do not guess a slug. After calling: - Report note count and show a concise summary. - Include returned links when useful for navigation. | read-only | 100%Latency 373ms | May 9, 2026 | |
get_topics | Get all topics currently associated with the authenticated user's profile. Use this tool for data-only questions about topics (for example counts, names, grouping, slug lookup, follow-up reasoning, or backend reads). Do not use this tool to open or render the topics widget. If the user explicitly asks to "show", "open", or "display" topics in the UI, use `list_topics` instead. Input requirements: - None. Behavior expectations: - Use this as the first step before topic-specific note operations and topic-id lookups. - When assigning topics to groups, use IDs from this response with `set_topic_group` (single-topic fields or bulk `assignments`); do not recreate topics to place them in a group. - Do not invent topic slugs; use slugs returned by `get_topics`. - If no topics are returned, explain that clearly and suggest adding one. - Do not surface internal diagnostics (for example, callable endpoint/tool availability checks). Keep language user-facing and outcome-focused. After calling: - Answer the user's question directly from returned data (for example "you have 6 topics"). - Summarize topic names only when helpful. - Preserve exact topic names/slugs for follow-up tool calls. | read-only | 100%Latency 380ms | May 9, 2026 | |
list_topic_notes | Open the topic notes widget UI and return topic-scoped note data. Use this tool when the user explicitly asks to show/open/display notes UI for a specific topic. Input requirements: - `topicSlug`: required, must be a valid topic slug from `get_topics`. Behavior expectations: - Use this tool when the user wants notes UI rendered for a specific topic. - This tool returns the same note payload shape as `get_topic_notes` so the widget can render immediately. - Do not call this tool without a topic slug. - If the user asks for counts/content without requesting UI, prefer `get_topic_notes` (for a known topic) and/or `get_topics` to choose a topic first. - If the user asks "show my notes" without a topic, first resolve topic context by calling `get_topics` and selecting the most relevant topic from user wording, or ask a concise clarifying question when no topic can be inferred. - Keep the user-facing response concise and UI-oriented. After calling: - Confirm that the notes view is open. - Answer any combined UI+data request directly from the returned payload. | read-only | 100%Latency 375ms | May 9, 2026 | |
list_topics | Open the topics widget UI and return current topic data. Use this tool when the user explicitly asks to show/open/display topic UI. Input requirements: - None. Behavior expectations: - Use this tool when the user wants the topics UI rendered. - Returns the same topic rows as `get_topics`, plus **`noteCount`** and **`notePreviews`** (user-authored note titles or first-line snippets per topic) so the fullscreen topics widget can show the same preview bullets as the dev sample. - If the user asks a data-only question (for example "how many topics do I have?"), prefer `get_topics` instead. - Keep the user-facing response concise and UI-oriented. After calling: - Confirm that the topics view is open. - Answer any combined UI+data request directly from the returned payload. | read-only | 100%Latency 379ms | May 9, 2026 | |
rename_topic_group | Rename an existing topic group. Use this tool when the user asks to rename a category/group used for topic organization. Input requirements: - `topicGroupId`: required; obtain from `get_topics.topicGroups`. - `name`: required new group name. Behavior expectations: - Resolve and confirm the target group before renaming when ambiguity exists. - Do not invent IDs; use values returned by `get_topics`. After calling: - Confirm old/new naming in plain language. - If the user asks to review updated organization, call `get_topics`. | — | 100%Latency 352ms | May 9, 2026 | |
search_topic_notes | Search user-authored notes by keyword across the authenticated user's profile. Use this tool when the user asks to find a note but does not know the exact topic or note ID. Input requirements: - `query`: required search text (phrase, title fragment, etc.). - `limit`: optional; use when the user asks for a narrower or broader result set. Behavior expectations: - This tool searches user-authored notes, including global notes without topic associations. - Returned results include all condition/topic associations when present. - Prefer this tool before update operations when you need to identify the right note ID. - Do not invent note IDs; select from returned results. - Keep follow-up deterministic: - If multiple results are close matches, ask the user to confirm which note to use. - If there are no results, report that clearly and suggest refining the query. After calling: - Summarize top matches with note ID and topics when relevant. | read-only | 100%Latency 358ms | May 9, 2026 | |
set_topic_group | Assign or unassign a topic to a topic group. Use this tool when the user asks to move a topic into a group, remove it from a group, or categorize existing topics (for example "group my topics", "put these under a specific topic"). After groups exist, assign each topic using the topic row id from `get_topics`. Do not create new topics to mirror the same names in each category. Input requirements: - Single move: the topic row id and `topicGroupId` (group id from `get_topics.topicGroups`, or `null` to ungroup). Exact property names for the tool call match the MCP tool schema. - Bulk move: `assignments` array of rows; each row has a `topicGroupId` (or `null`) and a list of topic row ids that should share that group. Each topic row id may appear at most once in the whole payload. Prefer bulk when reorganizing many topics in one turn. Behavior expectations: - Always call `get_topics` first when you need IDs. - Do not invent IDs; use exact IDs from tool results. - For reorganizing many topics at once, prefer one bulk call with `assignments` instead of many single-topic calls. - Reorganizing never requires `create_topic`; if topics already appear in `get_topics`, only change their group membership here. After calling: - Single mode: confirm which topic was reassigned and to which group (or that it was ungrouped). - Bulk mode: summarize counts from `summary` and mention any per-topic failures in `results`. - If the user asked to verify the final organization, call `get_topics`. | — | 100%Latency 387ms | May 9, 2026 | |
start_session | Initialize or continue a conversation-level session identifier for MCP tool-call correlation. Use this tool at the beginning of a new chat conversation. Input behavior: - Optionally pass a known `sessionId` to continue an existing session. - If absent, the tool will return a new `sessionId`. Behavior expectations: - Call once per conversation, then reuse the returned `sessionId` in subsequent tool calls when possible. - Include `sessionId` as an optional top-level argument on follow-up tool calls when supported by the MCP host. - Treat missing `sessionId` on other tools as recoverable; do not block user progress. - Keep session-correlation details internal. Do not mention endpoint availability, callable tools, or capability checks to the user. After calling: - Store the returned `sessionId`. - Reuse that same value for follow-up calls in this conversation. | read-only | 100%Latency 372ms | May 9, 2026 | |
update_topic_note | Update an existing user note on the authenticated user's profile. Use this tool only when the user asks to edit a previously created note they authored. Input requirements: - `noteId`: required. - At least one of: `title`, `content`, `topicSlugs`. - `content` can be plain text or Markdown. Behavior expectations: - This tool is only for user-authored notes. - `topicSlugs` are condition/topic associations; pass [] to remove all topic associations. - Do not call without a concrete update instruction. - If the user does not provide `noteId`, first identify the correct note before updating. - Preserve formatting intent on content updates: - Keep plain text as plain text unless asked to format. - Preserve existing Markdown structure when editing. - Avoid introducing extra markdown styling that the user did not request. After calling: - Confirm which fields were updated. - Do not immediately call `get_topic_notes` only for UI refresh when a notes widget is already open (especially fullscreen); that creates a duplicate widget card. - Prefer telling the user the existing widget can refresh in place (manual refresh button / auto-refresh behavior). - Only call `get_topic_notes` after mutation when the user explicitly asks to re-list notes in chat. - If the user explicitly asks to refresh topic-level counts in chat, call `get_topics`. - If update fails, report the exact reason and next step. | — | 100%Latency 369ms | May 9, 2026 |
Discoverability Score
Fair
55 of 100 — how easily AI agents find your app
- Description quality20/20
- Example prompts0/20
- Keyword coverage0/15
- Tool metadata20/20
- Visual assets5/20
- Endpoint health10/10
- Data freshness11/15
How to Improve
Add at least 2 example prompts. Prompt examples strongly improve app matching and click-through intent.
Increase keyword coverage (discovery + trigger) to improve retrieval for long-tail queries.
Provide a stable HTTPS logo URL (avoid connectors://) so cards render consistently across clients.
Add at least 2 screenshots that show real workflows to increase confidence and conversion.
Technical Details
- Status
- ENABLED
- Type
- AI-Powered App
- Auth
- Requires Login
- Listed on
- ChatGPT
- Added
- April 6, 2026
- Last synced
- May 3, 2026
- Last checked
- 5h ago
- Version
- 0.1.0
- Distribution
- Ecosystem Directory