Skip to main content
Glama
deenesjakoruzh
Cicatriiz

Healthcare MCP Server

by Cicatriiz
OverviewSchemaSourceRelated ServersScoreDiscussions
JavaScript
Remote

Сервер MCP для здравоохранения

значок кузнеца Сервер протокола контекста модели (MCP), предоставляющий помощникам на базе искусственного интеллекта доступ к данным здравоохранения и инструментам медицинской информации.

Обзор

Healthcare MCP Server — специализированный сервер, реализующий протокол контекста модели (MCP) для предоставления помощникам ИИ доступа к данным здравоохранения и инструментам медицинской информации. Он позволяет моделям ИИ извлекать точную и актуальную медицинскую информацию из авторитетных источников.

Related MCP server: Smart EHR MCP Server

Функции

  • Информация о лекарственных препаратах FDA : поиск и извлечение полной информации о лекарственных препаратах из базы данных FDA.

  • PubMed Research : Поиск медицинской литературы в базе данных научных статей PubMed.

  • Темы здравоохранения : доступ к научно обоснованной информации о здоровье на Health.gov

  • Клинические испытания : Поиск текущих и завершенных клинических испытаний

  • Медицинская терминология : поиск кодов МКБ-10 и определений медицинской терминологии.

  • Кэширование : эффективная система кэширования с пулом соединений для сокращения вызовов API и повышения производительности.

  • Отслеживание использования : анонимное отслеживание использования для мониторинга использования API

  • Обработка ошибок : надежная обработка и ведение журнала ошибок.

  • Несколько интерфейсов : поддержка интерфейсов stdio (для CLI) и HTTP/SSE

  • Документация API : интерактивная документация API с пользовательским интерфейсом Swagger

  • Комплексное тестирование : обширный набор тестов с pytest и отчетами о покрытии

Установка

Установка через Smithery

Чтобы автоматически установить сервер медицинских данных и медицинской информации для Claude Desktop через Smithery :

npx -y @smithery/cli install @Cicatriiz/healthcare-mcp-public --client claude

Ручная установка

  1. Клонируйте репозиторий:

    git clone https://github.com/Cicatriiz/healthcare-mcp-public.git
cd healthcare-mcp-public

  2. Создайте виртуальную среду:

    python -m venv venv
source venv/bin/activate  # On Windows: venv\Scripts\activate

  3. Установить зависимости:

    pip install -r requirements.txt

  4. Настройте переменные среды (необязательно):

    # Create .env file from example
cp .env.example .env
# Edit .env with your API keys (optional)

  5. Запускаем сервер:

    python run.py

Использование

Работа в различных видах транспорта

  • Режим stdio (по умолчанию, для Cline):

    python run.py

  • Режим HTTP/SSE (для веб-клиентов):

    python run.py --http --port 8000

Тестирование инструментов

Вы можете протестировать инструменты MCP с помощью нового тестового набора на основе pytest:

# Run all tests with pytest and coverage
python -m tests.run_tests --pytest

# Run a specific test file
python -m tests.run_tests --test test_fda_tool.py

# Test the HTTP server
python -m tests.run_tests --server --port 8000

Для обеспечения обратной совместимости вы по-прежнему можете запускать старые тесты:

# Run all tests (old style)
python -m tests.run_tests

# Test individual tools (old style)
python -m tests.run_tests --fda        # Test FDA drug lookup
python -m tests.run_tests --pubmed     # Test PubMed search
python -m tests.run_tests --health     # Test Health Topics
python -m tests.run_tests --trials     # Test Clinical Trials search
python -m tests.run_tests --icd        # Test ICD-10 code lookup

Ссылка на API

Сервер Healthcare MCP предоставляет как программный API для прямой интеграции, так и RESTful HTTP API для веб-клиентов.

Конечные точки RESTful API

При работе в режиме HTTP доступны следующие конечные точки:

Проверка здоровья

GET /health

Возвращает состояние сервера и его служб.

Поиск лекарств FDA

GET /api/fda?drug_name={drug_name}&search_type={search_type}

Параметры:

  • drug_name : Название препарата для поиска

  • search_type : Тип информации для извлечения

    • general : Основная информация о препарате (по умолчанию)

    • label : Информация о маркировке лекарственных средств

    • adverse_events : Зарегистрированные неблагоприятные события

Пример ответа:

{
  "status": "success",
  "drug_name": "aspirin",
  "search_type": "general",
  "total_results": 25,
  "results": [
    {
      "brand_name": "ASPIRIN",
      "generic_name": "ASPIRIN",
      "manufacturer": "Bayer Healthcare",
      "product_type": "HUMAN OTC DRUG",
      "route": "ORAL",
      "active_ingredients": [
        {
          "name": "ASPIRIN",
          "strength": "325 mg/1"
        }
      ]
    }
  ]
}

Поиск PubMed

GET /api/pubmed?query={query}&max_results={max_results}&date_range={date_range}

Параметры:

  • query : Поисковый запрос по медицинской литературе

  • max_results : Максимальное количество возвращаемых результатов (по умолчанию: 5, максимум: 50)

  • date_range : Ограничить статьями, опубликованными в течение нескольких лет (например, «5» для последних 5 лет)

Пример ответа:

{
  "status": "success",
  "query": "diabetes treatment",
  "total_results": 123456,
  "date_range": "5",
  "articles": [
    {
      "pmid": "12345678",
      "title": "New advances in diabetes treatment",
      "authors": ["Smith J", "Johnson A"],
      "journal": "Journal of Diabetes Research",
      "publication_date": "2023-01-15",
      "abstract": "This study explores new treatment options...",
      "url": "https://pubmed.ncbi.nlm.nih.gov/12345678/"
    }
  ]
}

Темы о здоровье

GET /api/health_finder?topic={topic}&language={language}

Параметры:

  • topic : Здоровье тема для поиска информации

  • language : язык для контента (en или es, по умолчанию: en)

Пример ответа:

{
  "status": "success",
  "search_term": "diabetes",
  "language": "en",
  "total_results": 15,
  "topics": [
    {
      "title": "Diabetes Type 2",
      "url": "https://health.gov/myhealthfinder/topics/health-conditions/diabetes/diabetes-type-2",
      "last_updated": "2023-05-20",
      "section": "Health Conditions",
      "description": "Information about managing type 2 diabetes",
      "content": ["Diabetes is a disease...", "Treatment options include..."]
    }
  ]
}

Поиск клинических испытаний

GET /api/clinical_trials?condition={condition}&status={status}&max_results={max_results}

Параметры:

  • condition : Медицинское состояние или заболевание, которое нужно найти

  • status : Статус испытания (набор, завершен, активен, не_набор или все)

  • max_results : Максимальное количество возвращаемых результатов (по умолчанию: 10, максимум: 100)

Пример ответа:

{
  "status": "success",
  "condition": "breast cancer",
  "search_status": "recruiting",
  "total_results": 256,
  "trials": [
    {
      "nct_id": "NCT12345678",
      "title": "Study of New Treatment for Breast Cancer",
      "status": "Recruiting",
      "phase": "Phase 2",
      "study_type": "Interventional",
      "conditions": ["Breast Cancer", "HER2-positive Breast Cancer"],
      "locations": [
        {
          "facility": "Memorial Hospital",
          "city": "New York",
          "state": "NY",
          "country": "United States"
        }
      ],
      "sponsor": "National Cancer Institute",
      "url": "https://clinicaltrials.gov/study/NCT12345678",
      "eligibility": {
        "gender": "Female",
        "min_age": "18 Years",
        "max_age": "75 Years",
        "healthy_volunteers": "No"
      }
    }
  ]
}

Поиск кода МКБ-10

GET /api/medical_terminology?code={code}&description={description}&max_results={max_results}

Параметры:

  • code : код МКБ-10 для поиска (необязательно, если указано описание)

  • description : Описание медицинского состояния для поиска (необязательно, если указан код)

  • max_results : Максимальное количество возвращаемых результатов (по умолчанию: 10, максимум: 50)

Пример ответа:

{
  "status": "success",
  "search_type": "description",
  "search_term": "diabetes",
  "total_results": 25,
  "codes": [
    {
      "code": "E11",
      "description": "Type 2 diabetes mellitus",
      "category": "Endocrine, nutritional and metabolic diseases"
    },
    {
      "code": "E10",
      "description": "Type 1 diabetes mellitus",
      "category": "Endocrine, nutritional and metabolic diseases"
    }
  ]
}

Исполнение универсального инструмента

POST /mcp/call-tool

Текст запроса:

{
  "name": "fda_drug_lookup",
  "arguments": {
    "drug_name": "aspirin",
    "search_type": "general"
  },
  "session_id": "optional-session-id"
}

Программный API

При программном использовании сервера MCP доступны следующие функции:

Поиск лекарств FDA

fda_drug_lookup(drug_name: str, search_type: str = "general")

Параметры:

  • drug_name : Название препарата для поиска

  • search_type : Тип информации для извлечения

    • general : Основная информация о препарате (по умолчанию)

    • label : Информация о маркировке лекарственных средств

    • adverse_events : Зарегистрированные неблагоприятные события

Поиск PubMed

pubmed_search(query: str, max_results: int = 5, date_range: str = "")

Параметры:

  • query : Поисковый запрос по медицинской литературе

  • max_results : Максимальное количество возвращаемых результатов (по умолчанию: 5)

  • date_range : Ограничить статьями, опубликованными в течение нескольких лет (например, «5» для последних 5 лет)

Темы о здоровье

health_topics(topic: str, language: str = "en")

Параметры:

  • topic : Здоровье тема для поиска информации

  • language : язык для контента (en или es, по умолчанию: en)

Поиск клинических испытаний

clinical_trials_search(condition: str, status: str = "recruiting", max_results: int = 10)

Параметры:

  • condition : Медицинское состояние или заболевание, которое нужно найти

  • status : Статус испытания (набор, завершен, активен, не_набор или все)

  • max_results : Максимальное количество возвращаемых результатов

Поиск кода МКБ-10

lookup_icd_code(code: str = None, description: str = None, max_results: int = 10)

Параметры:

  • code : код МКБ-10 для поиска (необязательно, если указано описание)

  • description : Описание медицинского состояния для поиска (необязательно, если указан код)

  • max_results : Максимальное количество возвращаемых результатов

Источники данных

Этот сервер MCP использует несколько общедоступных API-интерфейсов здравоохранения:

Премиум-версия (еще в разработке)

Это бесплатная версия Healthcare MCP Server с ограничениями на использование. Для расширенных функций и более высоких ограничений на использование ознакомьтесь с нашей премиум-версией:

  • Неограниченные вызовы API

  • Расширенные инструменты обработки данных в здравоохранении

  • Индивидуальные интеграции

  • Приоритетная поддержка

Лицензия

Лицензия Массачусетского технологического института

Available Tools

7 tools
fda_drug_lookupC

Look up drug information from the FDA database

ParametersJSON Schema
NameRequiredDescriptionDefault
drug_nameYesName of the drug to search for
search_typeNoType of information to retrieve: 'label', 'adverse_events', or 'general'general

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure but only states the basic action. It doesn't cover aspects like rate limits, authentication needs, response format, or potential errors (e.g., drug not found), which are critical for a lookup tool interacting with an external database.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence with no wasted words, making it easy to parse and front-loaded with essential information. It efficiently communicates the core purpose without unnecessary elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of an FDA database lookup with no annotations and no output schema, the description is insufficient. It lacks details on what information is returned, how results are structured, or any behavioral traits, leaving significant gaps for the agent to understand the tool's operation fully.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100%, with clear descriptions for both parameters, including an enum for 'search_type'. The description adds no additional parameter information beyond what the schema provides, so it meets the baseline score of 3 without compensating or detracting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Look up') and resource ('drug information from the FDA database'), making the tool's purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'clinical_trials_search' or 'pubmed_search' which also involve medical data lookup, missing an opportunity for clearer distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. The description doesn't mention sibling tools or specify use cases like FDA-specific regulatory information versus clinical trials or PubMed articles, leaving the agent without context for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_all_usage_statsB

Get overall usage statistics for all sessions

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states it 'gets' data, implying a read-only operation, but doesn't specify if it requires authentication, has rate limits, returns aggregated or raw data, or any other behavioral traits. This leaves significant gaps for a tool that likely accesses usage data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence with no wasted words. It front-loads the key action and resource, making it highly efficient and easy to parse for an AI agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'overall usage statistics' includes (e.g., metrics, time frames, format) or behavioral aspects like data freshness or access controls. For a tool that likely returns complex data, this leaves too much undefined.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't mention parameters, aligning with the schema. A baseline of 4 is applied since it doesn't add unnecessary details, though it could briefly note the lack of parameters for clarity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Get') and resource ('overall usage statistics for all sessions'), making the purpose immediately understandable. It doesn't differentiate from its sibling 'get_usage_stats', which appears to be a similar tool, so it doesn't reach the highest score for sibling distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like 'get_usage_stats' or other siblings. It lacks context about prerequisites, timing, or comparisons, leaving the agent to infer usage based on the name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_usage_statsB

Get usage statistics for the current session

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden but only states what the tool does, not how it behaves. It doesn't disclose whether this is a read-only operation, what permissions are needed, rate limits, error conditions, or return format. Significant behavioral context is missing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that directly states the tool's purpose with zero wasted words. It's appropriately sized for a zero-parameter tool and front-loads the essential information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what 'usage statistics' includes, the format of returned data, or behavioral aspects like whether this requires authentication or has side effects.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, maintaining focus on the tool's purpose without unnecessary detail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Get') and resource ('usage statistics') with scope ('for the current session'), making the purpose understandable. It doesn't explicitly differentiate from sibling 'get_all_usage_stats', but the 'current session' scope provides implicit distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives like 'get_all_usage_stats' is provided. The description implies usage for current session statistics but doesn't mention prerequisites, exclusions, or comparison with sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

health_topicsC

Get evidence-based health information on various topics

ParametersJSON Schema
NameRequiredDescriptionDefault
languageNoLanguage for content (en or es)en
topicYesHealth topic to search for information

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'gets' information, implying a read-only operation, but does not clarify aspects like data sources, accuracy, rate limits, or authentication needs. For a health information tool with zero annotation coverage, this is a significant gap in transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that is front-loaded with the core purpose. It avoids redundancy and waste, making it easy to parse quickly. Every word contributes to understanding the tool's function without unnecessary elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of annotations and output schema, the description is incomplete for a health information tool. It does not address critical context like data reliability, source attribution, or response format, which are important for an agent to use the tool effectively. The description alone is insufficient for safe and informed usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, fully documenting both parameters ('language' and 'topic'). The description adds no additional semantic context beyond what the schema provides, such as examples of valid topics or language implications. With high schema coverage, the baseline score of 3 is appropriate, as the description does not compensate but also does not detract.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose as 'Get evidence-based health information on various topics,' which specifies the action (get), resource (health information), and key attributes (evidence-based, various topics). It distinguishes from siblings like 'clinical_trials_search' or 'pubmed_search' by focusing on general health topics rather than specific databases or codes, though it could be more explicit about the distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It does not mention any context, prerequisites, or exclusions, such as when to prefer 'pubmed_search' for academic literature or 'lookup_icd_code' for medical coding. This leaves the agent without explicit usage instructions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

lookup_icd_codeC

Look up ICD-10 codes by code or description

ParametersJSON Schema
NameRequiredDescriptionDefault
codeNoICD-10 code to look up (optional if description is provided)
descriptionNoMedical condition description to search for (optional if code is provided)
max_resultsNoMaximum number of results to return

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the lookup action but doesn't describe traits like whether it's read-only, requires authentication, has rate limits, returns structured data, or handles errors. For a tool with zero annotation coverage, this is a significant gap in transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose and appropriately sized for a simple lookup tool, making it easy to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., code details, descriptions), behavioral aspects, or error handling. For a tool with 3 parameters and no structured output info, more context is needed to guide effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100%, so the schema already documents all parameters (code, description, max_results) with details like optionality and constraints. The description adds no additional meaning beyond what the schema provides, such as explaining search logic or result format. Baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Look up ICD-10 codes by code or description.' It specifies the verb ('look up'), resource ('ICD-10 codes'), and two search methods. However, it doesn't explicitly distinguish this from sibling tools like 'health_topics' or 'pubmed_search', which might also involve medical information retrieval but for different resources.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools or clarify scenarios where this lookup is preferred over others (e.g., 'clinical_trials_search' for trial data). Usage is implied by the purpose but lacks explicit context or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 7 tool updatesv1.0.0
    • First observedclinical_trials_search
    • First observedfda_drug_lookup
    • First observedget_all_usage_stats
    • First observedget_usage_stats
    • First observedhealth_topics
    • First observedlookup_icd_code
    • First observedpubmed_search
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.3/5.0
Disambiguation4/5

Most tools have distinct purposes targeting different healthcare data sources like clinical trials, drugs, health topics, ICD codes, and PubMed. However, get_all_usage_stats and get_usage_stats overlap in functionality, both dealing with usage statistics, which could cause confusion in selection.

Naming Consistency3/5

The naming is mixed with some tools using verb_noun patterns like clinical_trials_search and pubmed_search, while others use noun phrases like health_topics or lookup_icd_code. This inconsistency reduces predictability but remains readable overall.

Tool Count5/5

With 7 tools, the count is well-scoped for a healthcare server, covering key areas like drug info, medical literature, coding, and trials. Each tool appears to earn its place without being overwhelming or insufficient.

Completeness4/5

The toolset provides broad coverage for healthcare information retrieval, including drugs, literature, codes, and trials. A minor gap exists in lacking update or management tools for these resources, but agents can work effectively with the search and lookup functions provided.

Maintenance

ActivityInactive
ResponsivenessUnresponsive

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Senechal MCP Server

    mattjoyce
    A
    license
    Not graded
    quality
    D
    maintenance
    A Model Context Protocol server that provides health data from the Senechal API to LLM applications, enabling AI assistants to access, analyze, and respond to personal health information.
    GPL 3.0

  • Smart EHR MCP Server

    jmandel
    A
    license
    Not graded
    quality
    D
    maintenance
    A Model Context Protocol server that connects AI tools to Electronic Health Records using SMART on FHIR, allowing secure searching, querying, and analysis of patient data from compatible EHRs.
    85
    MIT

  • HAPI-MCP

    ericmc21
    F
    license
    Not graded
    quality
    D
    maintenance
    A Model Context Protocol server that enables querying FHIR healthcare data using natural language, allowing doctors to retrieve patient information, medications, observations, and other healthcare records.
    1
    -

  • Clinical MCP Server

    dianapopovici
    A
    license
    Not graded
    quality
    C
    maintenance
    A governed, audited Model Context Protocol server that provides AI agents with secure, read-only access to a clinical knowledge base through least-privilege tools, policy validation, and append-only audit logging.
    MIT

Appeared in Searches

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Cicatriiz/healthcare-mcp-public'

If you have feedback or need assistance with the MCP directory API, please join our Discord server