Skip to main content
Glama

SupplyGraph.AI.Daasmart

Park Have No Patent Company Count

park_have_no_patent_company_num

基于具体园区名称没有专利的企业数量查询。 涉及指标/类型:没有专利的企业数量 不包含:其他企业分类的统计;企业名单明细 典型问法:中关村软件园没有专利的企业有多少;张江高科技园区没有专利的企业数量;苏州工业园区没有专利的企业有多少家

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
yearNo统计年份,如 2024;可选。
park_nameYes园区名称,如「中关村软件园」「张江高科技园区」「苏州工业园区」。

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
textYesText or Markdown response with the company count result. Also used for in-progress, failed, cancelled, or waiting-user messages.

TDQS

A3.9/5.0
Behavior3/5

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

Annotations only provide openWorldHint, placing some burden on the description. The description discloses that it returns counts only (not lists), but it does not discuss data assumptions, freshness, or how the count is computed. It adds minimal behavioral context beyond the annotation, so a score of 3 is appropriate.

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 compact, starting with the main purpose, then metric, exclusions, and examples. It includes pricing metadata, which is somewhat extraneous but not problematic. The structure is logical and front-loaded, with no unnecessary fluff. Slightly less tight than the ideal, but efficient.

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?

For a simple count tool with only two parameters and an output schema, the description covers the essential aspects: what it does, what it excludes, and typical queries. It does not explain edge cases or data limitations, but given the low complexity and presence of output schema, it is adequately complete.

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 provides full descriptions for both parameters (park_name and year), covering 100% of them. The tool description does not add extra semantics beyond the schema, and the schema descriptions are self-explanatory. Thus, a baseline of 3 is warranted.

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 counts enterprises without patents for a specific park ('基于具体园区名称没有专利的企业数量查询'), explicitly mentions the metric type, and excludes list details and other categories, which distinguishes it from sibling list tools like park_have_no_patent_company_list. It also provides typical question examples, making the purpose unambiguous.

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 implies usage for count-only queries by stating exclusions ('不包含:其他企业分类的统计;企业名单明细'), which suggests using list tools for details. Typical questions give context, but it does not explicitly name alternative tools (e.g., park_have_no_patent_company_list). This is clear enough but not as explicit as referencing specific alternatives.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3/5.0
Disambiguation2/5

大量工具功能高度重叠,例如chain_*和park_*系列均为按不同筛选条件查询企业列表或数量,只是参数不同却拆分为独立工具;enterprise_change_*系列同样针对不同指标逐一拆分。虽然描述清楚各自区别,但代理面对198个工具时极易选错,且许多工具本质应合并为带参数的单一接口。

Naming Consistency3/5

多数工具采用snake_case加领域前缀(如chain_、park_、company_、gov_data_、poi_data_),但存在明显变体如company_certlist、company_randomin_spection(拼写异常)、corporate_exception_report、due_diligence_report、sg_chokepoint等,混用英文抽象名词与动词短语,整体模式可辨认但不统一。

Tool Count1/5

工具总数高达198个,远超合理范围(即使复杂领域也应控制在25个以内)。大量工具是同一逻辑的不同参数变体(如list/num、不同资质条件),完全可以通过参数化减少数量,严重冗余,代理难以有效浏览和选择。

Completeness4/5

工具覆盖领域广泛,包括企业信息、产业链分析、园区统计、地区宏观、POI明细、供应链风险、关税计算等,基本覆盖了商业数据查询的主要需求。虽缺少更新/删除等操作(但作为查询服务器可接受),且部分细分领域可能有遗漏,但整体功能较为完整。

Resources