Skip to main content
Glama
u9401066

Medical Calculator MCP Server

by u9401066
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

discover

Search and filter medical calculators by specialty, clinical context, or keyword. Get a categorized list of available tools to locate the right calculator before retrieving its schema.

Instructions

🔍 統一的工具發現入口 (High-Level)

幫助 Agent 找到合適的醫學計算器。支援多種發現模式。

Args: by: 發現模式 - "all": 列出所有分類 (專科和臨床情境) - 預設 - "specialty": 依專科篩選工具 - "context": 依臨床情境篩選工具 - "keyword": 關鍵字搜尋 - "tools": 列出所有工具 value: 篩選值 (當 by 不是 "all" 或 "tools" 時必填) limit: 最多回傳幾個結果

Returns: 根據模式返回不同內容: - all: 可用的專科和情境清單 - specialty/context: 該分類下的工具清單 - keyword: 匹配的工具清單 - tools: 所有工具清單

Examples:

# 弱模型安全流程: 先 discover，再 get_tool_schema
discover(by="keyword", value="sepsis")
# → 取得候選 tool_id 之後再呼叫 get_tool_schema("qsofa_score")

# 查看所有分類 (起點)
discover()
# → {"specialties": [...], "contexts": [...]}

# 依專科篩選
discover(by="specialty", value="critical_care")
# → {"tools": [{"tool_id": "sofa_score", ...}, ...]}

# 依臨床情境篩選
discover(by="context", value="preoperative_assessment")
# → {"tools": [{"tool_id": "rcri", ...}, ...]}

# 關鍵字搜尋
discover(by="keyword", value="sepsis")
# → {"tools": [{"tool_id": "qsofa_score", ...}, ...]}

# 列出所有工具
discover(by="tools", limit=50)
# → {"tools": [...], "count": 75}

規則:

  • 不要根據記憶猜 tool_id，先用 discover() 拿 canonical id

  • 不要直接 calculate，先用 get_tool_schema(tool_id)

⏭️ 下一步: 找到工具後，使用 get_tool_schema(tool_id) 查看參數

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
byNoall
limitNo
valueNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.6.2

TDQS

A4.3/5.0
Behavior4/5

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

No annotations are present, so the description carries the full burden, and it responds with mode-specific return behavior plus guardrails against guessing IDs and calling calculate prematurely. This is thorough for a non-destructive discovery tool. It does not explicitly state read-only behavior or error handling, but these are less critical for a lookup endpoint.

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

Conciseness4/5

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

The description is well-structured with Overview, Args, Returns, Examples, Rules, and next-step sections, making it easy to scan. There is some redundancy between the Returns prose and the extensive Examples block, and the emoji/labels add minor noise. Overall it earns high marks but could be tightened.

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

Completeness5/5

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

All five modes, parameter constraints, return shapes, and workflow rules are covered, and the examples show valid call signatures for every mode. The 'next step' to get_tool_schema closes the discovery-to-call loop. For a high-level discovery tool with no annotations and a bare schema, this is effectively complete.

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

Parameters5/5

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

The schema has 0% description coverage, but the Args section fully defines 'by' with its five modes, explains that 'value' is required whenever 'by' is not 'all' or 'tools', and clarifies 'limit' as the maximum number of results. Every parameter receives meaningful semantic context that the schema itself lacks.

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 its purpose: it is the '統一工具發現入口' that helps an agent find appropriate medical calculators, and it documents five discovery modes. This is a specific verb+resource statement that is easy to act on. However, it does not explicitly distinguish itself from sibling discovery tools like find_tools_by_params or get_related_tools.

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

Usage Guidelines4/5

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

The description gives explicit workflow rules: never guess tool_id from memory, use discover() first, and do not go directly to calculate — instead call get_tool_schema(tool_id). This is strong when-to-use guidance. But it does not mention when to prefer discover over find_tools_by_params or get_related_tools, so alternative-selection guidance is incomplete.

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

Deploy Server

Other Tools