Uphealth Signal turns federally-sourced (CDC/NIH/MedlinePlus) health facts, lists, and tips into agent-callable cued-stream tools. Every cue is provenance-backed, audience-safety-checked, and sequenced on the patient's last response, so your AI health agent never fabricates health content. Free sandbox (Display mode): no PHI, no BAA. Not medical advice.
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.6/5 across 5 of 5 tools scored.
Each tool has a clearly distinct purpose: creating streams, advancing cues, reading state, listing topics, and looking up facts. No overlap in functionality.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., create_patient_stream, get_next_cued_message, read_stream_state). No deviations.
Five tools is a well-scoped set for the server's purpose: stream management, message progression, state inspection, topic discovery, and fact lookup. Each tool earns its place.
The tools cover the core workflow, but a tool to list or inspect the signal://catalog resource (referenced in descriptions) is missing, leaving a minor gap in discoverability.
create_patient_streamAInspectCreate a Signal cued stream for one patient and get the first cue back synchronously. Every cue is federally-sourced, audience-safety-checked, and sequenced on the patient's prior response — so your agent never fabricates health content. Choose a template_id from the signal://catalog resource and pre-satisfy its required audience_tags + patient_context (clinical templates 422 without them). Display mode renders in your app: no PHI, no BAA. Each later cue MUST submit the prior message's feedback — the engine refuses to advance without it (the sequencing moat).
| Name | Required | Description | Default |
|---|---|---|---|
| attributes | No | De-identified patient context. v1 accepts free-form jsonb; future templates will enforce schemas. | |
| template_id | Yes | One of the live Signal templates. Read the signal://catalog resource for each template's required audience_tags + patient_context. On a production key a clinical template 422s if its required tags/context are missing — pre-satisfy them from the catalog. A free sandbox (Discovery) key always cues the curated sandbox corpus. | |
| audience_tags | No | Subset of the 14-tag B5/B6 schema. See list_sandbox_topics for sample topic labels. | |
| delivery_mode | No | v1 is Display-only; Deliver-mode unlocks at Per-Episode tier after BAA. | display |
| idempotency_key | No | Optional. Stripe-style create idempotency: a retried create with the same key returns the ORIGINAL stream instead of minting (and billing) a second one. Forwarded as the Idempotency-Key request header. UUID v4 recommended. | |
| feedback_timeout_days | No |
| Name | Required | Description |
|---|---|---|
| _meta | Yes | Legal/disclosure block returned on every 2xx (A1 §6.7). |
| state | Yes | |
| first_cue | Yes | A cued message plus its per-cue receptivity score and audience-safety verdict. |
| stream_id | Yes | Persist this — every later cue/read references it. |
| rate_limit | No | Discovery monthly cue-cap headroom. Absent on non-Discovery tiers (no cap). |
| next_cue_eligible_at | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors beyond annotations: synchronous first cue retrieval, no PHI/BAA for display mode, the feedback requirement for advancing cues (sequencing moat), and production-key behavior for clinical templates. It is consistent with annotations (readOnlyHint=false, openWorldHint=true).
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 yet packed with essential information. Each sentence serves a purpose, front-loading the main action and then providing behavioral constraints and parameter details. No wasted words.
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 the tool's complexity (6 parameters, nested objects, enums) and presence of an output schema, the description covers key aspects: prerequisites, resource references, error conditions, and behavioral rules. It refers to external resources for additional details, making it self-contained enough for agent 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?
Schema coverage is high (83%), but the description adds meaningful context: template_id explains the catalog and 422 conditions, audience_tags references list_sandbox_topics, idempotency_key mentions Stripe-style idempotency and UUID recommendation, and delivery_mode clarifies future tiers. This enhances understanding 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 purpose: 'Create a Signal cued stream for one patient and get the first cue back synchronously.' It specifies the verb (create), resource (patient stream), and outcome (first cue). It distinguishes from siblings like get_next_cued_message, which handles subsequent cues.
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 explicit guidance: 'Choose a template_id from the signal://catalog resource and pre-satisfy its required audience_tags + patient_context.' It also warns about 422 errors for clinical templates missing required tags/context. While it doesn't explicitly state when not to use, it implies that after creating a stream, get_next_cued_message should be used for subsequent cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_next_cued_messageASubmit the patient's response to the prior cue and get the next one — federally-sourced, audience-safety-checked, and re-sequenced on that feedback. REFUSES WITHOUT PRIOR-MESSAGE FEEDBACK (the moat): the engine will not advance a stream blind, returning 409 if you skip it. response_action is one of the accepted cue vocabulary (see the signal://catalog resource). Same idempotency_key + same feedback returns the cached cue; conflicting feedback under the same key returns 409.
| Name | Required | Description | Default |
|---|---|---|---|
| feedback | Yes | ||
| stream_id | Yes | The stream_id returned by create_patient_stream. |
| Name | Required | Description |
|---|---|---|
| _meta | Yes | Legal/disclosure block returned on every 2xx (A1 §6.7). |
| state | Yes | |
| message | No | |
| next_cue | No | A cued message plus its per-cue receptivity score and audience-safety verdict. |
| stream_id | Yes | |
| idempotent | No | true when this is the cached result of a repeated idempotency_key. |
| rate_limit | No | Discovery monthly cue-cap headroom. Absent on non-Discovery tiers (no cap). |
| normalized_action | No | null when the submitted response_action was a recognized value; otherwise the acknowledge-class value the well-formed-but-unrecognized action was folded to (forward-compat tolerance). Always present on a cue result; absent on the exhausted-stream result. |
| sandbox_exhausted | No | Present + true when the sandbox subset is exhausted; no next_cue then. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds significant behavioral context beyond annotations: caching on same idempotency key, conflicting feedback results in 409, and that it is 'federally-sourced, audience-safety-checked'. Annotations already indicate idempotent and not read-only, so no 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?
Two dense sentences front-load purpose and quickly add details. Some jargon ('moat', 'federally-sourced') but overall efficient.
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 complexity of nested objects and stateful behavior, the description covers key aspects: purpose, error conditions, caching, and vocabulary reference. Output schema exists so return value details are not needed.
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 low (50%), but description compensates by explaining the meaning of response_action (cue vocabulary reference), idempotency_key behavior (caching/conflict), and stream_id usage. Adds value beyond 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 verb 'Submit the patient's response... and get the next cue' and specifies the resource (cue/stream). It is distinct from siblings like create_patient_stream or read_stream_state, but does not explicitly differentiate 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?
Explicitly states when to use (after prior cue) and when not to (without prior feedback, returning 409). Points to alternative resource for cue vocabulary, and explains idempotency key behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_sandbox_topicsAList the curated sandbox topic labels that define the free Discovery corpus — every topic federally-sourced and audience-safety-checked. Use it to preview what content domains exist before creating a stream. Does NOT enumerate messages — the corpus stays internal. For the full live template catalog + gating contract, read the signal://catalog resource.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| _meta | Yes | Legal/disclosure block returned on every 2xx (A1 §6.7). |
| topic_labels | Yes | |
| template_id_for_sandbox | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds context beyond annotations: topics are curated, federally-sourced, audience-safety-checked, and the corpus stays internal. No contradiction with readOnlyHint 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?
Two sentences with no waste. First sentence states purpose, second gives usage guidance and limitation. Front-loaded and efficient.
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 output schema covering return values, the description explains the content of the topics and their purpose, providing a complete picture for a zero-parameter tool.
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?
No parameters, so description doesn't need to explain them. It adds value by describing the nature of the returned topics (curated labels from a corpus). Baseline for 0 params is 4.
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 'List' and the resource 'curated sandbox topic labels', and distinguishes from siblings by noting it does not enumerate messages and is for previewing content domains before creating a stream.
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?
Explicitly says 'Use it to preview what content domains exist before creating a stream' and warns 'Does NOT enumerate messages'. Also directs to an alternative resource for full catalog and gating contract.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_health_factAZero setup — NO key required. Returns ONE already-public federal health fact, list, or tip for a question or topic (e.g. "high blood pressure", "sleep", "type 2 diabetes"), with its federal source (CDC / MedlinePlus / NIH) and a link to the public uphealth.me page. Free + rate-limited. For adaptive, patient-specific message sequencing — receptivity-scored cues + audience-safety verdicts over the full library of federally-sourced facts, lists & tips — get a free Discovery key at https://uphealth.us/signup
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | A health question or topic, e.g. "high blood pressure", "sleep", or "type 2 diabetes". |
| Name | Required | Description |
|---|---|---|
| fact | Yes | The single already-public federal message — a fact, list, or tip (see kind). |
| topic | No | The matched topic's title. |
| upgrade | Yes | The free-key upsell — adaptive sequencing lives behind a Discovery key. |
| disclaimer | Yes | |
| attribution | Yes | "Source: <agency> via Uphealth". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses behavior beyond annotations: returns exactly one item, is rate-limited, and remains public with no key needed. No contradiction with readOnlyHint.
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?
Description is informative but slightly verbose. Front-loaded with key benefits, though could be trimmed without losing clarity.
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 lookup tool with one parameter and an output schema, the description fully covers return values (fact, source, link) and usage constraints.
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 has q with description; description adds concrete examples (e.g., 'high blood pressure') and explains the parameter's purpose, augmenting 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?
Description clearly states it returns a single public health fact, list, or tip for a given topic, with source and link. Differentiates from sibling tools like get_next_cued_message which handle adaptive patient-specific messaging.
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?
Explicitly says 'Zero setup — NO key required' for simple lookups, and directs users to get a free key for advanced adaptive messaging. Provides clear when-to-use and alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read_stream_stateARead a stream's current state, its current cued message, and event count. Read-only — does NOT advance the stream or consume a cue. Use it between feedback turns to inspect where a patient is in their federally-sourced, audience-safety-checked sequence.
| Name | Required | Description | Default |
|---|---|---|---|
| stream_id | Yes | The stream_id returned by create_patient_stream. |
| Name | Required | Description |
|---|---|---|
| _meta | Yes | Legal/disclosure block returned on every 2xx (A1 §6.7). |
| state | Yes | |
| stream_id | Yes | |
| rate_limit | No | Discovery monthly cue-cap headroom. Absent on non-Discovery tiers (no cap). |
| current_cue | No | |
| template_id | No | |
| events_count | No | |
| next_cue_eligible | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint and openWorldHint, so the bar is lower. The description adds that it is read-only and does not advance or consume a cue, giving behavioral details beyond annotations. No contradictions.
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, front-loaded with purpose, no wasted words. Every sentence adds value.
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 with one parameter, annotations cover safety, and output schema exists. Description covers purpose, usage, and behavioral traits adequately for an AI agent to use it 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% and the description for stream_id is identical to schema's description. The description does not add new meaning beyond what the schema already provides, so 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 it reads stream state, cued message, and event count, with a specific verb 'Read' and resource 'stream's current state'. It distinguishes itself from siblings like get_next_cued_message by noting it does not advance or consume a cue.
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 says 'Use it between feedback turns to inspect where a patient is in their sequence', providing clear context. It does not explicitly state when not to use, but the context implies its appropriate use case.
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!
