company_licensing基于明确指定的企业名称，查询该企业获得的行政许可信息，包括行政许可证号、许可名称、许可内容、有效期自、有效期至、许可机关等。
Pricing: {"unit": "credits", "billing_model": "per_run", "per_run": 0.2}
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | 指定返回第几页结果，从 1 开始，默认 1；与 limit 配合使用。 | |
| limit | No | 指定单次请求最多返回的记录数，默认 20，最大 100。 | |
| company_name | Yes | 企业名称（必填）。用于查询该企业的行政许可。示例：通威股份有限公司 |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
描述直接表明该工具是“查询”操作，并说明返回的信息维度，让智能体能预判其只读性和输出内容。当前仅有 openWorldHint 注解，未出现矛盾，也没有未说明的副作用行为。对于简单列表查询而言，透明度足够。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
描述紧凑，开篇即说明核心用途和前置条件，随后用列举字段的方式补齐输出预期。无冗余感叹、市场营销式语言或重复 schema 内容的赘述，pricing 信息也为决策提供了有用信息。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
该工具为单一公司名称驱动的行政许可列表查询，结构简单；描述已覆盖目的、必填参数、返回字段。缺少的“当查询不到时返回空”等边界说明可以通过输出 schema 和上下文推断，故整体完整度良好但非极高。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
输入 schema 对 3 个参数的说明覆盖率达 100%，描述没有在参数语义上补充额外信息。描述中强调“明确指定的企业名称”与 schema 中必填参数一致，但未增加新型格式、边界条件或返回分页的细节。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
初始描述使用具体动词“查询”和明确资源“企业获得的行政许可”，并列举返回字段（许可证号、许可名称、有效期等），功能范围清晰。区别于同组中的商标、版权、资质等查询工具，可识别性强。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
既定条件“基于明确指定的企业名称”明确给出了适用前提：调用前需要已确认的精确企业名称。虽然未特别写出不适用场景或其他备选工具，但描述的上下文已限定用于查询企业行政许可。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
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 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.
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.
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).