Uphealth Signal
Server Details
The adaptive health-messaging engine for apps and agents. Federally-sourced. 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 targets a distinct operation: creating a stream, advancing with feedback, listing topics, looking up facts, and reading state. No overlapping purposes.
All tool names follow a verb_noun pattern, but verbs vary (create, get, list, lookup, read) without a unified convention, slightly reducing consistency.
5 tools is well-scoped for a focused health messaging service, covering the core workflow without excess.
Core read and advance operations are present, but missing tools for listing streams, managing templates, or deletion are minor gaps.
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?
Beyond annotations (readOnlyHint=false, destructiveHint=false), the description adds critical behaviors: cues are federally-sourced and audience-safety-checked, display mode avoids PHI, and the engine requires prior feedback for advancement. 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 is a single, dense paragraph of five sentences. Every sentence adds value, covering purpose, safety, prerequisites, and constraints. It is front-loaded with the core action and avoids fluff.
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 params, nested objects, output schema exists), the description covers the essential flow: creation, synchronous first cue, display mode, and sequencing moat. It is nearly complete, though it could mention the one-to-one mapping to the output schema.
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%), and the description adds meaningful context for most parameters: template_id links to catalog and 422 behavior, attributes are de-identified, audience_tags schema referenced, idempotency_key explained, etc. This elevates it above the baseline of 3.
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 creates a Signal cued stream for one patient and returns the first cue synchronously. The verb 'create' and resource 'patient stream' are specific. It 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?
The description advises choosing a template_id from the catalog and pre-satisfying audience_tags and patient_context. It implies prerequisites and mentions the feedback requirement. However, it does not explicitly state when not to use this tool or list direct alternatives.
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, openWorldHint=true), the description adds details: cues are federally-sourced and safety-checked, engine refuses to advance blind (409), and caching behavior with conflicting keys. No contradictions 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 is front-loaded with the core purpose, then details constraints and caching. It is somewhat lengthy but every sentence adds value. Could be slightly trimmed but remains effective.
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 (nested objects, idempotency, enums, error handling) and the presence of an output schema, the description covers prerequisites, behavior, and idempotency well. Minor gap: no details on what the returned cue looks like, but output schema likely covers that.
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 50% but description adds context for 'response_action' by referencing an external catalog resource. It also reinforces idempotency_key behavior partially covered in schema. Stream_id is well-described in schema. Overall, extra value is provided but not exhaustive.
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' and the resource 'the prior cue' to get the next cue. It distinguishes from siblings like create_patient_stream or read_stream_state by focusing on feedback-based advancement of 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?
The description explicitly states prerequisites (prior-message feedback) and error conditions (409 if skipped or conflicting idempotency_key). It does not name alternative tools directly but implies this is for step-by-stepping through a cue sequence.
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?
Beyond the annotations (readOnlyHint: true, openWorldHint: false), the description adds that the corpus is internal and doesn't enumerate messages, providing clear behavioral context. 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 is two sentences, front-loaded with the main purpose, and includes usage guidance and a pointer to further resources. Every sentence earns its place with 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?
For a read-only tool with no parameters and an output schema, the description adequately covers what the tool does, when to use it (before creating a stream), and points to additional context. It is complete given the tool's simplicity.
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 no parameters, so the baseline is 4. The description adds value by explaining the output (topic labels), but since an output schema exists, this is not required. Still, it does no harm and provides context.
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 curated sandbox topic labels for the Discovery corpus, emphasizing it's a preview tool. It distinguishes itself from message enumeration and points to a complementary resource, making the purpose specific and well-defined.
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 advises using the tool to preview content domains before creating a stream and directs to the signal://catalog resource for more details. However, it does not explicitly compare to sibling tools or state when not to use this tool.
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 already declare readOnlyHint=true, and description adds behavioral details: returns one result, zero setup, no key required, rate-limited, and returns source and link. 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?
Description is informative and front-loaded with key points, but includes promotional text for the keyed version, which slightly detracts from conciseness. Still efficient overall.
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 simplicity of the tool and existence of an output schema, the description covers input, output (fact, source, link), and limitations (rate-limited). Adequate but could mention output structure briefly.
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?
Input schema coverage is 100% with description for q. The tool description adds examples and context, enhancing understanding beyond the schema. Offset by the schema already being explicit.
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, with source and link. It differentiates from siblings like create_patient_stream and get_next_cued_message, which are about 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 and no key required, free and rate-limited, and advises when to use the alternative (get a Discovery key for adaptive sequencing). Provides clear when-to-use and when-not-to-use guidance.
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?
Description adds key behavioral context beyond annotations: 'Read-only — does NOT advance the stream or consume a cue.' This is critical for correct invocation and not contradicted by annotations (readOnlyHint=true, 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?
Two sentences, front-loaded with purpose and key constraints. No wasted words; every sentence 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?
Given that an output schema exists (not shown but noted), description covers what the tool returns (state, cued message, event count) without needing to repeat. Complements structured fields well.
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 description need not add much; it does not elaborate on stream_id beyond what schema says. Description adds context about the sequence but not parameter specifics. Baseline 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 reads a stream's state, current cued message, and event count. It specifies read-only behavior and contrasts with advancing tools, distinguishing it from siblings 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 explicit usage context ('Use it between feedback turns to inspect where a patient is...') and implies when not to use (i.e., not when advancing the stream is needed), but does not explicitly list alternative tools or exclusions.
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!