SupplyGraph.AI Data

CBD Surrounding Housing

cbd_surrounding_housing

基于中国范围内的具体地址或地点（如门牌、地标、路名、小区名、园区出入口等，必须是中国境内可定位的具体点，不能是市名或区县名本身；不支持境外地址），查询其附近/周边的房价与投资分析（返回均价/行情/走势/好卖好租指数与投居建议，不是成交明细或挂牌列表）。涉及指标/类型：AI评估均价；当前市场行情；微观/宏观走势；好卖/好租指数星级与描述；投资/居住角度建议；小区/地区未来涨幅描述与详情；小区好卖/好租分析；投资理财/刚需自住角度分析；投资选城/选小区分析详情不包含：二手房成交明细列表；挂牌房源名称与价格清单；周边配套星级与人口密度典型问法：北京市朝阳区阜通东大街6号周边房价和市场行情怎么样；成都高新区天府大道中段666号好不好卖、好不好租；苏州工业园区星湖街328号适不适合投资

Pricing: {"unit": "credits", "billing_model": "per_run", "per_run": 100, "unit_description": "optional"}

Input Schema

TableJSON Schema

Name	Required	Description	Default
`city`	Yes	中国境内地级市名称（设区的市，如「北京」「成都」「苏州」）；只返回中文城市名，不含「市」字后缀（如「北京」而不是「北京市」）。
`address`	Yes	中国境内结构化中文地址，按「国家、省份、城市、区县、城镇、乡村、街道、门牌号码、屋邨、大厦」从大到小拼接；须为中国范围内可定位地址，不支持境外地址；缺失层级跳过，顺序不可颠倒。示例：北京市朝阳区阜通东大街6号。

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

A4.2/5.0

Behavior3/5

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

Annotations only include openWorldHint, with no readOnly or destructive hints. The description uses the verb 'query' (查询) and states it returns data, implying a read-only operation, but does not explicitly mention side effects, permissions, or that it makes no modifications. It provides clarity on what is returned but not on behavioral impacts beyond that.

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 fairly detailed but well-structured, with clear sections for what it returns, what it excludes, and typical queries. It is not overly verbose given the need to convey constraints and examples, but could potentially be tightened while preserving key information.

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?

The description is complete for a tool with two parameters and no output schema. It explains the purpose, input constraints, expected output (average price, trends, indices, suggestions), and what is not included, along with usage examples. This fully covers the context needed for an agent to use it correctly.

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 schema already describes both parameters with detailed constraints, but the description adds extra context about valid addresses (must be specific point in China, not city name) and provides concrete examples. This enriches the parameter semantics beyond the schema, which already covers 100% of parameters.

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 queries surrounding housing prices and investment analysis for a given address, and explicitly lists what it returns and what it excludes. It distinguishes from sibling tools by focusing on housing, with typical examples provided.

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 provides typical query examples and explicitly states what is not included (e.g., transaction details, amenities, population density), which helps differentiate when to use this tool over siblings like cbd_surrounding_amenity or cbd_surrounding_population. It could be more explicit about when to use it, but the examples and exclusions give clear guidance.

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?