company_salary基于明确指定的企业名称，查询该企业的工资待遇信息，包括平均工资、同地区比例、同行业比例、对比去年、最多人拿等。
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?
The annotations include openWorldHint: true, but no readOnlyHint or destructiveHint. The description mentions pricing information (0.2 credits per run), which is a useful behavioral disclosure not in the annotations. However, it doesn't describe other behavioral aspects like whether results are paginated (beyond the page/limit params) or if there are any usage limits. The pricing disclosure adds some value, but the description could be more transparent about the nature of the operation (read-only vs. other) without explicit annotation.
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?
The description is concise and front-loaded: it starts with the core function and then lists specific output types. The pricing info is appended separately, which is useful but could be considered supplementary. Overall, it's a single sentence that efficiently conveys the purpose. No wasted words.
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?
The output schema exists (though not shown in detail), and the description lists expected return data (average salary, regional/industry percentages, year-over-year comparison, most common salary). This helps the agent understand what to expect. However, given the tool's complexity (multiple comparison metrics), the description could be more explicit about the input prerequisites (e.g., company name format) or any caveats (e.g., if salary data is unavailable for obscure companies). It's adequate but not thorough.
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?
The schema description coverage is 100%, so parameters are well-documented in the schema. The description adds some meaning by listing the types of data returned (average salary, regional comparison, etc.), which connects to the company_name parameter. However, it doesn't elaborate on the page/limit parameters beyond what's in the schema. Since schema coverage is high, baseline 3 is appropriate, but the description adds minimal extra value.
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?
The description clearly states the tool's purpose: to query salary information for a specified company, including average salary, regional/industry comparisons, year-over-year changes, and common salary ranges. This is specific about what it does (query salary info for a company) and differentiates it from sibling tools like company_basic_info or company_data_search, which cover other aspects. However, it doesn't explicitly distinguish itself from other company_* tools in the sibling list, but the salary focus is unique enough.
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?
The description implies when to use it: when you need salary information about a specific company. It states the requirement of an explicit company name (企业名称). However, it doesn't explicitly state when NOT to use it or mention alternatives (e.g., if you need other company info like financials, use listed_company_financial_info). Given the large sibling list, more explicit guidance would help, but the context is reasonably clear.
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).