Uphealth Signal
Server Details
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.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.
Tool Definition Quality
Average 4.5/5 across 5 of 5 tools scored.
Each tool has a clearly distinct purpose: stream creation, stream advancement, topic listing, health fact lookup, and state reading. No overlap in functionality.
All tool names follow a consistent verb_noun pattern (create_patient_stream, get_next_cued_message, list_sandbox_topics, lookup_health_fact, read_stream_state) using snake_case.
5 tools is well-scoped for a health messaging server covering stream creation, advancement, state reading, topic listing, and fact lookup. Not too few or too many.
Core workflow (create, advance, read state) is covered, along with informational tools. Missing operations like listing or deleting streams are minor gaps given the server's focused purpose.
Available Tools
5 toolscreate_patient_streamAInspect
Create 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 |
Output Schema
| 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses safety (federally-sourced, audience-checked), idempotency behavior, display mode privacy (no PHI, no BAA), and sequencing requirement. No contradiction with annotations (readOnlyHint=false, destructiveHint=false).
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?
Concise at ~6 sentences, front-loaded with core purpose, every sentence adds value without redundancy. Well-structured for quick understanding.
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?
Comprehensive given complexity: covers prerequisites, workflow, privacy modes, idempotency, and feedback requirement. Output schema exists so return values are handled; description still mentions return of first cue.
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?
Adds significant context beyond schema: explains template_id enumeration linkage to catalog, attributes as free-form, audience_tags as subset of B5/B6, delivery_mode tiers, and idempotency_key behavior. Only feedback_timeout_days lacks extra description, but schema covers it with default.
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 creates a Signal cued stream for one patient and returns the first cue synchronously. Distinguishes from siblings like get_next_cued_message by focusing on stream creation.
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?
Provides explicit guidance on when to use (choose template_id from catalog, pre-satisfy requirements) and notes that subsequent cues must submit feedback. Implicitly contrasts with get_next_cued_message for later steps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_next_cued_messageAIdempotentInspect
Submit 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. |
Output Schema
| 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). |
| sandbox_exhausted | No | Present + true when the sandbox subset is exhausted; no next_cue then. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=false, idempotentHint=true), description details specific error codes (409), caching behavior, and the 'moat' constraint. 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?
Reasonable length but includes jargon like 'moat' and 'audience-safety-checked' that may be unclear. Could be more concise.
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?
Covers key behavioral aspects (feedback requirement, errors, idempotency). Output schema exists, so description doesn't need to detail return format. Adequate for usage.
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?
Adds meaning beyond schema: explains idempotency_key behavior, response_action from a catalog. Covers 50% schema coverage well, though free_text not elaborated.
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?
Clear verb ('Submit and get') and specific resource ('next cued message'). Distinguishes from siblings like create_patient_stream which creates a stream, not advancing it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states that prior-message feedback is required (409 if skipped) and explains idempotency behavior. Provides clear context, though could mention alternatives for other actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_sandbox_topicsARead-onlyInspect
List 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 | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| _meta | Yes | Legal/disclosure block returned on every 2xx (A1 §6.7). |
| topic_labels | Yes | |
| template_id_for_sandbox | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true. The description adds behavioral context beyond annotations: it lists labels but not messages, the corpus is internal, and topics are federally-sourced and safety-checked. This provides useful transparency without contradicting structured data.
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 three short sentences with no fluff. It front-loads the purpose in the first sentence, then adds usage and exclusions efficiently.
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 simplicity (0 parameters, output schema exists), the description covers the purpose, usage, limitations, and alternative resources completely. It is sufficiently informative for an agent to decide when to invoke this 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?
With zero parameters, schema coverage is 100%, so baseline is 4. The description correctly avoids adding parameter information since none exist.
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', making the purpose unambiguous. It distinguishes this tool from sibling tools like 'create_patient_stream' or 'get_next_cued_message' by specifying it deals with topic labels for the Discovery corpus.
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 explicitly says to use it 'to preview what content domains exist before creating a stream', indicating when to use. It clarifies what it does not do ('Does NOT enumerate messages') and points to an alternative resource ('signal://catalog resource') for more detailed catalog information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_health_factARead-onlyInspect
Zero 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". |
Output Schema
| 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". |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint=true, consistent with the description. The description adds behavioral context: returns a single result, includes federal source and link, and is rate-limited. This goes beyond annotations 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 front-loaded with key information (zero setup, single fact, source) but includes a lengthy promotional sentence about the alternative service. While informative, it could be more concise by trimming the marketing language.
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 output schema exists (not shown but indicated), the description need not detail return values. It sufficiently covers the tool's output (fact, source, link) and mentions rate limiting. The tool has minimal complexity, so completeness is adequate.
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 single parameter 'q' is fully described in the schema (100% coverage). The description reinforces its purpose with examples (e.g., 'high blood pressure', 'sleep'), adding 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 clearly states the tool returns a single public health fact, list, or tip for a given topic, along with source and link. It distinguishes itself from the sibling tools by emphasizing zero setup and no key required, contrasting with the adaptive messaging sequence that requires a key.
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 'Zero setup — NO key required' and 'Free + rate-limited,' and provides clear guidance on when to use the alternative service (for patient-specific sequencing) with a link to sign up. This covers when to use and when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read_stream_stateARead-onlyInspect
Read 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. |
Output Schema
| 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description reinforces this with 'Read-only — does NOT advance the stream or consume a cue,' adding behavioral specifics beyond the 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, no wasted words. The first sentence lists what is read, and the second clarifies read-only behavior and usage context. 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?
Output schema exists, so return values are covered. The description explains what is read (state, cued message, event count) and gives a usage scenario. It does not cover error conditions or prerequisites, but for a simple read-only tool, it is adequate.
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 100% coverage for the only parameter stream_id, so baseline is 3. The description does not add additional parameter details beyond what the schema already provides.
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 explicitly states the tool reads a stream's current state, cued message, and event count, and clarifies what it does NOT do (advance stream or consume cue). This clearly defines the purpose and distinguishes it from related tools like get_next_cued_message.
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 a specific use case: 'Use it between feedback turns to inspect where a patient is...' This gives clear guidance on when to use the tool. It does not explicitly mention when not to use it or compare to alternatives, but the context is sufficient.
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.
Discussions
No comments yet. Be the first to start the discussion!