Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@CardioTriage MCP Server summarize cardiovascular risk for case A"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Prompt Opinion MCP superpower for phenotype-aware emergency cardiovascular triage with FHIR R5 context, missing-data checks, structured bilingual handoff, and Chagas-compatible cardiomyopathy differential surfacing backed by ECGFounder bridge phenotype detection.
NOT FOR CLINICAL USE. Hackathon demonstration only. Synthetic FHIR metadata plus public de-identified ECG samples. Foundation model outputs are uncalibrated demo scores -- they SURFACE differentials for clinical workup, never DIAGNOSE conditions.
Related MCP server: HomeCare Cohort MCP
Live MCP endpoint: https://claudiomedina17--mcp.modal.run/mcp
Live health endpoint: https://claudiomedina17--mcp.modal.run/health
Marketplace listing evidence: docs/MARKETPLACE_VERIFICATION.md
Demo video: TBD - Phase 2
Devpost submission: TBD - Phase 2
Repository: TBD public repo URL (local prototype workspace)
Data provenance: docs/DATA_PROVENANCE.md
BYO Agent system prompt: docs/BYO_AGENT_SYSTEM_PROMPT.md
CardioTriage gives any Prompt Opinion agent a governed phenotype-aware cardiovascular triage toolkit instead of a free-text-only workflow.
It exposes six MCP tools that discover cases, retrieve FHIR R5 bundles, check critical missing data, run ECGFounder-backed phenotype inference, summarize risk signals, and render an SBAR handoff note.
The ECG tool uses ECGFounder (PKUDigitalHealth, MIT; NEJM AI 2025) embeddings and signal features to return transparent uncalibrated demo scores.
The demo is anchored on chest-pain triage, STEMI pattern recognition, and a Latam Chagas-compatible cardiomyopathy workup scenario.
The MCP server is the primary submission; the Prompt Opinion BYO Agent is the demo wrapper that proves the tools are invokable inside the platform.
CardioTriage uses a five-layer architecture:
Domain logic: synthetic FHIR R5 case bundles, HEART-style risk signals, missing-data review, and deterministic SBAR handoff scaffolding.
AI-ECG layer: ECG signal preprocessing plus ECGFounder 1024-d embeddings, centroid cosine similarity, and neurokit2-derived signal features.
MCP server: FastMCP tools exposed over Streamable HTTP for Prompt Opinion.
BYO Agent wrapper: a Prompt Opinion demo agent orchestrates the six tools with concise clinical rationale before each call.
Submission polish: provenance docs, Marketplace evidence, cache skeletons, disclaimers, and a reproducible local test suite.
# | Tool | Purpose |
1 |
| Discover the available demo case IDs A, B, and C. |
2 |
| Return the FHIR R5-style bundle for the selected case. |
3 |
| Flag missing or pending triage data such as troponin, echo, Chagas serology, or contraindications. |
4 |
| Summarize deterministic cardiovascular risk signals for STEMI, HF/Chagas, or low-risk patterns. |
5 |
| Generate an SBAR-style handoff note in |
6 |
| AI-ECG inference (lite + live), uncalibrated demo scores. Bridge phenotype detection backed by ECGFounder; surfaces Chagas-compatible cardiomyopathy pattern when context warrants serology workup. NOT a diagnostic tool. |
Tool #6 scores are evidence signals for the hackathon demo. They surface phenotype-aware differentials for workup; they are not calibrated clinical probabilities.
uv sync
uv run pytest tests/ -q
uv run python -m server.mainThe default transport is stdio. For local Streamable HTTP:
$env:CARDIOTRIAGE_MCP_TRANSPORT = "streamable-http"
$env:CARDIOTRIAGE_MCP_HOST = "127.0.0.1"
$env:CARDIOTRIAGE_MCP_PORT = "8000"
$env:CARDIOTRIAGE_MCP_PATH = "/mcp"
uv run python -m server.mainHealth smoke:
curl.exe http://127.0.0.1:8000/healthPhase 0 Gate 0 found that CardioTriage is usable in Prompt Opinion as a WORKSPACE-ONLY listing. Public Marketplace publishing may require subscription publishing enablement.
Open Prompt Opinion.
Go to Configuration -> MCP Servers -> Add.
Friendly name: CardioTriage MCP Server.
Endpoint: https://claudiomedina17--mcp.modal.run/mcp.
Transport: Streamable HTTP.
Authentication: No authentication / open.
Save and verify that the server appears in the workspace MCP server list.
Confirm /health, initialize, and tools/list expose six tools.
Use screenshots from the workspace Manage view as Marketplace evidence if public listing remains unavailable.
See docs/MARKETPLACE_VERIFICATION.md.
Open or create the Prompt Opinion BYO Agent named CardioTriage Demo.
Tools tab: attach CardioTriage MCP Server.
System Prompt tab: paste docs/BYO_AGENT_SYSTEM_PROMPT.md.
Save.
Run: Triage Case B end-to-end. Use Spanish for the handoff.
Expected trace: all six tools in order, including interpret_12_lead_ecg,
with chagas_suspect_demo_score around 0.925 and
calibration_status="uncalibrated_demo".
Offline deterministic cache skeletons live in
cardiotriage_core/demo_cache/run_case_{a,b,c}.json; rationale and final PO
handoff text remain TODO_LIVE_CAPTURE until Claudio captures real UI runs.
MIT. See LICENSE.
ECGFounder by PKUDigitalHealth (MIT license), used for ECG foundation-model embeddings.
CODE-15 / Ribeiro et al., Zenodo 4916206, CC-BY 4.0, for public de-identified ECG demo samples.
SaMi-Trop / PhysioNet Challenge 2025 for the Chagas-cohort public de-identified ECG demo sample.
Bern et al., CDC 2007, for Chagas disease clinical grounding.
Nunes et al., JACC 2013, for Chagas cardiomyopathy clinical grounding.
Anthropic Claude Haiku for the planned Prompt Opinion BYO Agent narrative layer; this repository does not run live LLM API calls during deterministic cache generation.
NOT FOR CLINICAL USE. This software is a hackathon demonstration. Demo data only: synthetic FHIR metadata plus public de-identified ECG samples. Scores are uncalibrated demo scores, not clinical probabilities. A licensed clinician must validate all findings and actions.
Flag missing or pending critical cardiovascular triage data for a synthetic case. Use before risk disposition. NOT for clinical use.
| Name | Required | Description | Default |
|---|---|---|---|
| case_id | Yes |
| Name | Required | Description |
|---|---|---|
| case_id | Yes | |
| missing | Yes | |
| disclaimer | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must convey behavior. It reveals a flagging operation, but lacks detail on what specific data is considered critical or how missing vs pending is determined. An output schema exists but is not described.
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 excessive words, meaning front-loaded in the first sentence. Perfectly concise for the information conveyed.
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 a simple tool with one parameter and an output schema, the description covers purpose, usage timing, and a safety warning. Could elaborate on what constitutes 'critical cardiovascular triage data' or the output shape, but overall 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 coverage is 0%, and the description does not explain the 'case_id' parameter beyond its existence. While the parameter name is self-explanatory, the description misses the chance to add context about its format or source.
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 the tool flags missing or pending critical cardiovascular triage data for a synthetic case, distinguishing it from siblings like ECG interpretation or risk summarization. Including 'Use before risk disposition' further clarifies its role.
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 before risk disposition' and 'NOT for clinical use', providing clear context. Does not mention alternatives, but the purpose is distinct enough from siblings to be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a deterministic SBAR-style handoff note for a synthetic case in English, Spanish, or Portuguese. Use after risk and missing-data review. NOT for clinical use.
| Name | Required | Description | Default |
|---|---|---|---|
| case_id | Yes | ||
| language | No | en |
| Name | Required | Description |
|---|---|---|
| case_id | Yes | |
| language | No | |
| style | No | |
| note | Yes | |
| text | Yes | |
| disclaimer | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits: deterministic output, SBAR-style format, synthetic case handling, and language support. The 'NOT for clinical use' warning adds important safety context. With no annotations provided, the description fully carries the transparency burden.
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, each essential. Front-loaded with the core action and constraints. No unnecessary text.
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 (two parameters, output schema present), the description covers purpose, usage timing, behavioral traits, and language options. It is complete enough for an AI agent to decide when and how to invoke it.
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 0%, so the description must compensate. The description mentions language options (English, Spanish, Portuguese), which maps to the language parameter enum, but does not explain the case_id parameter. This is partial value—adequate for a two-parameter tool, but not fully explanatory.
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 generates a deterministic SBAR-style handoff note for synthetic cases, with specific language options. It differentiates itself from sibling tools by mentioning a generative note-making purpose after review.
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 'Use after risk and missing-data review,' providing clear context for when to invoke the tool, and also warns 'NOT for clinical use.' Although it doesn't name alternative tools, the guidance is sufficient for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a synthetic FHIR-like bundle for case A, B, C, or D. Use after selecting a case ID. Synthetic data only; NOT for clinical use.
| Name | Required | Description | Default |
|---|---|---|---|
| case_id | Yes |
| Name | Required | Description |
|---|---|---|
| case_id | Yes | |
| bundle | Yes | |
| disclaimer | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description must disclose traits. It states 'synthetic data only; NOT for clinical use', which is important. However, it does not describe what the bundle contains or any limitations beyond synthetic nature.
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 the core action. Every sentence adds value: the first explains what it does, the second gives usage context and a warning. No waste.
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 (one string param, output schema exists), the description covers all essential context: synthetic nature, non-clinical, which cases, usage after selection. No gaps.
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 schema has 0% description coverage, but the description adds meaning by restricting case_id to values A, B, C, or D. This compensates for the lack of schema-level parameter documentation.
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 returns a synthetic FHIR-like bundle for specific cases (A, B, C, D). It distinguishes from siblings like list_synthetic_cases or analyze_missing_critical_data which have different purposes.
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 says 'Use after selecting a case ID', providing context for when to invoke. It implies a sequence with list_synthetic_cases but does not explicitly state when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run AI-ECG analysis on a 12-lead recording. Default case_id mode uses precomputed ECGFounder embeddings; advanced raw ECG mode routes to live inference when available. Returns uncalibrated demo scores. NOT for clinical use.
| Name | Required | Description | Default |
|---|---|---|---|
| case_id | Yes | ||
| ecg_array | No | ||
| sampling_rate | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It discloses that scores are uncalibrated and not for clinical use, but lacks detail on mode selection behavior when both parameters are provided, and does not mention permissions or error states.
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?
Three sentences: action, mode explanation, result warning. Front-loaded and without superfluous 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?
The description covers core purpose and a usage warning, but for a tool with 3 parameters and no output schema, it lacks details on parameter usage, output structure, and edge cases, making it adequate but not complete.
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 description provides minimal parameter-level meaning by linking case_id to default mode and ecg_array to raw ECG mode, but does not explain what a case_id is, the expected format of ecg_array, or the role of sampling_rate. Given 0% schema coverage, this is insufficient.
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 runs AI-ECG analysis on a 12-lead recording, with two distinct modes (case_id and raw ECG). It differentiates itself well from siblings, which handle other tasks like data analysis or handoff notes.
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 explains two modes (default case_id vs. advanced raw ECG) and includes a 'NOT for clinical use' warning. It does not explicitly specify when to use this tool over siblings, but the sibling tools are clearly distinct in purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available synthetic demo cases. Use first when an agent needs to discover CardioTriage case IDs. NOT for clinical use.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| cases | Yes | |
| disclaimer | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It accurately describes a read-only listing without side effects, and warns about clinical use. Could mention if any authentication or data freshness constraints exist, but overall adequate.
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 compact sentences that front-load the core purpose and immediately provide usage guidance. No extraneous text.
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 zero parameters and an output schema present, the description is complete. It explains when to use and what it returns (case IDs), fulfilling all needs for a listing 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 in schema, so description need not add param info. The baseline of 4 is appropriate as the description fully covers the tool's purpose without needing parameter details.
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 action ('List available synthetic demo cases') and specifies the resource ('CardioTriage case IDs'), distinguishing it from sibling tools like get_fhir_case_bundle.
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 instructs when to use ('Use first when an agent needs to discover CardioTriage case IDs') and includes a contraindication ('NOT for clinical use'), providing complete guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarize deterministic cardiovascular risk signals for a synthetic case. Use for STEMI, HF/Chagas, or low-risk pattern triage. NOT for clinical use.
| Name | Required | Description | Default |
|---|---|---|---|
| case_id | Yes |
| Name | Required | Description |
|---|---|---|
| case_id | Yes | |
| signals | Yes | |
| disclaimer | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It states the tool works on synthetic cases and is deterministic, but fails to explain what signals are summarized, data sources, or potential side effects (e.g., what happens with invalid input). The warning about clinical use is helpful but insufficient.
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 exceptionally concise: two sentences that front-load the purpose and immediately provide usage guidance and a critical warning. No unnecessary 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 simplicity (one parameter, output schema present), the description covers purpose, usage context, and limitations. It could benefit from clarifying 'deterministic risk signals' but is otherwise complete for a low-complexity 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?
The input schema has 0% description coverage, and the description does not mention the sole parameter 'case_id' at all. The title 'Case Id' in the schema provides minimal meaning, but the description adds no value beyond that.
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 'Summarize deterministic cardiovascular risk signals for a synthetic case' with specific use cases (STEMI, HF/Chagas, low-risk pattern triage), distinguishing it from sibling tools like 'interpret_12_lead_ecg' or 'list_synthetic_cases'.
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 guidance: 'Use for STEMI, HF/Chagas, or low-risk pattern triage' and includes a strong contraindication 'NOT for clinical use.' However, it does not mention alternatives or when not to use beyond clinical contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct aspect of the workflow: listing cases, retrieving data, analyzing ECG, summarizing risk, checking missing data, and generating a handoff note. No two tools have overlapping purposes.
All tool names follow a consistent verb_noun pattern (e.g., list_synthetic_cases, interpret_12_lead_ecg), using snake_case throughout. No mixing of conventions or vague verbs.
Six tools is well-scoped for a synthetic triage demo, covering discovery, data retrieval, multiple analysis types, and output generation. Neither too few nor too many for the purpose.
The tool set covers the complete triage workflow: case selection, data retrieval, ECG interpretation, risk signal extraction, missing data check, and handoff note generation. No obvious gaps for a synthetic demo.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Privacy-preserving synthetic health data generation. FHIR R4/R5 compliant.
HealthGuard - 12-tool health/medical AI safety MCP: PII redaction, HIPAA, GDPR Art.9.
Medical RAG: semantic search for clinical guidelines, drug interactions, diagnoses & EHR data.
Medical RAG: semantic search for clinical guidelines, drug interactions, diagnoses & EHR data.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/claudiomedina17/cardiotriage-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
