SupplyGraph.AI Data

query_poi_medical_list

poi_data_medical

基于明确的市级或区县级行政区名称，查询该行政区范围内的医疗保健 POI 明细列表。覆盖：综合医院、三甲医院、专科医院、卫生院、药店等。不回答医院/药店数量（请用兴趣点数量指标）。典型问法：某区综合医院分布、有哪些三甲医院、药店列表。

Pricing: {"unit": "credits", "billing_model": "per_data_unit", "meter": {"credits_per_unit": 1, "unit_description": "One data unit = one region × one POI type (example: Wuhou District × metro station). Not charged per POI store/row."}}

Input Schema

TableJSON Schema

Name	Required	Description
`version`	No	可选数据版本，如 '2022' 或 '2022-12-01'；不传则使用库内默认/最近可用版本。
`gov_name`	No	可选，单一地区名（地级市或区县）。不支持同时查多个地区；不传时从 input_text 抽取。
`poi_type`	No	可选，POI 类型名或编码（如地铁站 / 150500）；用于消歧；不传时从 input_text 识别，且限定在本主题候选集内。
`input_text`	Yes	用户查询文本，描述「医院诊所药店等医疗点分布」POI 明细/分布意图；须指向单一地区（地级市或区县）。示例：武侯区的综合医院分布

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

First observedAug 19, 2026

TDQS

A3.9/5.0

Behavior3/5

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

Only annotation is openWorldHint=true, which is minimal. The description adds some context (e.g., covers specific POI types, scoping to single region), but does not disclose details about pagination, output format, or potential limitations (e.g., data freshness). It does not contradict annotations, but provides limited behavioral insight beyond the annotation.

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 concise and front-loaded with the core purpose. The pricing note is a bit extra but useful. Every sentence contributes value, and there is no redundancy. Its length is appropriate for the complexity.

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

Completeness4/5

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

Given the presence of a full output schema and 100% parameter documentation, the description covers the essential usage context. It explains the scope (single region), typical use cases, and pricing. It could be slightly more explicit about output size or data coverage, but overall it is complete for an agent to use correctly.

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?

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds value by clarifying the typical use of input_text and the fact that gov_name and poi_type are optional and can be auto-extracted from input_text. However, it does not go beyond this, so a baseline of 3 is appropriate.

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

Purpose5/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: querying medical/healthcare POI detail lists within a specified city or district, covering hospitals, pharmacies, etc. It specifies the scope (administrative region) and typical question patterns, effectively distinguishing it from sibling POI tools (e.g., dining, transport).

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 clearly indicates when to use this tool (for medical POI distribution queries) and provides typical question examples. It does not explicitly state when not to use it or mention alternative tools for other POI categories, but the sibling context makes this inferable. It also clarifies that it does not answer counts (use a specific metric), which is helpful.

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

All SupplyGraph.AI Data tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.2/5.0

Disambiguation4/5

Most tools have clearly distinct purposes, with consistent scopes (e.g., chain_* vs park_* vs company_* vs gov_data_*). The list/num pairs are clearly differentiated. A few overlapping concepts exist (e.g., company_patent vs enterprise_change_innovation) but descriptions clarify the angle. Some typos (company_randomin_spection) don't cause ambiguity.

Naming Consistency4/5

Naming follows a mostly predictable snake_case pattern with prefixes indicating domain (chain_, park_, company_, enterprise_change_, gov_data_, poi_data_, business_surrounding_, cbd_surrounding_). Most tools use <prefix>_<entity>_<action> or <prefix>_<subject>. A few outliers (sg_chokepoint, tariff_calc, corporate_exception_report) deviate but are few and recognizable.

Tool Count1/5

With 198 tools, this is far beyond any reasonable scope for a single server. It exceeds even the 'extreme mismatch' threshold of 50+ tools. The large number makes selection and discoverability challenging, despite good internal organization.

Completeness4/5

The tool surface covers a vast range of enterprise data, regional macro stats, POI details, supply chain analysis, and tariffs. It appears to cover the primary domain comprehensively, with only minor potential gaps (e.g., no direct tool for company debt ratings or specific product catalogs, but these are addressed via enterprise_change_* and company_* tools).

Resources

Need Help?