Skip to main content
Glama
u9401066

Medical Calculator MCP Server

by u9401066
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

get_tool_schema

Fetch complete calculator details, including parameter schemas, normal ranges, and references, so agents can prepare valid calculation inputs.

Instructions

📋 取得工具完整資訊 + 參數 Schema + 來源提示 (Low-Level)

整併了原本的 get_calculator_info 和 get_calculation_schema， 提供 Agent 執行計算所需的所有資訊:

  1. 工具基本資訊: 名稱、用途、專科、情境

  2. 參數 Schema: 每個參數的類型、單位、正常範圍

  3. 來源提示: 參數通常從哪裡取得 (Parameter Provenance)

  4. 參考文獻: PMID/DOI (100% 覆蓋率，Vancouver style)

Args: tool_id: 計算器 ID (從 discover() 取得) include_references: 是否包含參考文獻 (預設 True) - True: 包含完整參考文獻 (citation, PMID, DOI) - False: 省略以節省 tokens include_param_sources: 是否包含參數來源提示 (預設 True) - True: 包含 clinical_hint, common_sources, normal_range - False: 只返回基本 type/unit

Returns: 完整的工具資訊，包含: - tool_id, name, purpose - specialties, contexts (High-Level 分類) - required_params (必要參數列表) - param_schemas (每個參數的詳細 Schema) - references (參考文獻，若 include_references=True)

Example:

# 完整資訊 (預設)
get_tool_schema("ckd_epi_2021")

# 只要基本資訊 (節省 tokens)
get_tool_schema("ckd_epi_2021", include_references=False, include_param_sources=False)

⏭️ 下一步: calculate(tool_id, params) 執行計算

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tool_idYes
include_referencesNo
include_param_sourcesNo

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains what the tool returns in detail, including the effect of include_references and include_param_sources (including token-saving behavior), and states that references have 100% coverage in Vancouver style. It does not explicitly declare that the operation is read-only, but the 'get' verb and return structure make that clear.

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 emoji headers, numbered lists, Args/Returns sections, an example, and a next-step pointer. It is longer than minimal, but each section serves a purpose; the summary line partially duplicates the following list, but overall the organization makes scanning easy and front-loads the core purpose.

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?

For a 3-parameter info-retrieval tool, the description is complete: it names the sole required parameter, explains both optional flags with defaults, lists return contents, provides a concrete example, and points to the next action. An output schema exists, so not explaining return values further is acceptable. An agent can call this tool correctly with no ambiguity.

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?

Schema description coverage is 0%, but the Args section fully compensates: tool_id is defined as the calculator ID obtained from discover(), and both boolean flags explain their True/False behavior and defaults. This adds meaning far beyond the plain input schema, giving an agent everything it needs to set each parameter correctly.

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 function: retrieving complete tool information, parameter schema, and source hints for a calculator tool. It lists the exact content returned (basic info, param schemas, references) and positions itself as a low-level helper for calculation workflows. However, it doesn't explicitly differentiate itself from siblings like get_related_tools or find_tools_by_params, though the 'next step: calculate' hint helps.

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 clear usage context: the tool_id should come from discover(), and after getting the schema, the next step is calculate(tool_id, params). Example calls show how to optionally trim results to save tokens. It doesn't explicitly state when not to use it or name alternative tools, but the discover → get_tool_schema → calculate flow implies the intended position in the workflow.

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