industry-chain-mcp-server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct function within its domain (e.g., enterprise base info vs. branches vs. holders; bidding info vs. search vs. stats). Even similar tools like advanced_filter_get_enterprise_count and advanced_filter_get_enterprise_list are clearly differentiated by purpose (count vs. list).
Naming Consistency5/5
All tool names follow the consistent pattern 'category_verb_noun' (e.g., advanced_filter_get_enterprise_count, enterprise_get_enterprise_base_info, bid_bigdata_bid_search). They are all in snake_case, using English verbs and nouns uniformly.
Tool Count4/5
With 24 tools, the server is slightly above the typical well-scoped range but still justified by the comprehensive domains covered (enterprise info, bidding, patents, policies, supply chain). Each domain has a reasonable number of tools.
Completeness4/5
The server covers a broad set of queries across enterprise data, bidding, patents, and policies. However, it lacks upstream supply chain tools and certain lifecycle operations (e.g., create/update), which may be out of scope for a read-only data API. Minor gaps exist but overall coverage is strong.
Average 3.2/5 across 24 of 24 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 16 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose behavioral traits such as pagination behavior, authentication needs, result limits, or data freshness. The agent is left guessing about side effects or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is extremely concise (one short sentence). While not verbose, it lacks necessary detail for a tool with multiple parameters. Conciseness is positive but here it under-specifies.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 0% parameter documentation, the description is wholly incomplete. Missing details on return format, error handling, and usage constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. Description does not explain the meaning or usage of any parameter, not even the required 'matchKeyword' or optional 'keywordType'. The agent must infer parameter semantics solely from names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states clearly that the tool queries bidding information enterprises participate in. It uses specific verb '查询' (query) and resource '招投标信息' (bidding info). While siblings exist, the description distinguishes it sufficiently from stats-oriented tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs siblings like 'bid_bigdata_bid_search' or 'bid_bigdata_planned_projects'. The description provides no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It only says 'query info' without disclosing pagination behavior, keyword matching rules, or any side effects. Essential behavioral traits are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one short sentence) but sacrifices essential detail. It is not inappropriately long, but it under-specifies the tool's usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no output schema, and no annotations, the description is severely incomplete. It does not mention result format, pagination limits, or how keywords are matched, leaving the agent with insufficient information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to the parameters. Parameters like keywordType and matchKeyword are not explained, and their expected values remain unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries enterprise planned project announcements, which is a specific verb and resource. However, it does not differentiate from sibling tools like bid_bigdata_bidding_info or enterprise_get_enterprise_base_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as bid_bigdata_bid_search or enterprise_get_keyword_search. The description lacks context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description does not disclose whether the tool is read-only, requires authentication, or has rate limits. It fails to mention any behavioral traits beyond the basic search function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but not highly structured. The first line is a summary, followed by a parameter list. It is not verbose, but could benefit from clearer formatting (e.g., bullet points).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks information about return format, error handling, sorting, or fields returned. With no output schema, the agent is left guessing about the tool's output, making it incomplete.
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?
Despite 0% schema description coverage, the description explains each parameter's meaning in Chinese (e.g., matchKeyword lists acceptable types). It also notes the page size limit of 50, adding value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '专利信息搜索' (patent information search) is vague and essentially restates the tool name. It does not distinguish from sibling tools like patent_bigdata_patent_stats, which also deals with patents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as patent_bigdata_patent_stats. There is no mention of prerequisites, typical use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks any behavioral information (e.g., read-only nature, rate limits, side effects). It only describes parameters, leaving the agent uninformed about tool behavior.
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 with a clear front-loaded purpose sentence followed by a parameter list. It could be improved with structured formatting (e.g., markdown) but is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 11 parameters, no schema descriptions, no output schema, and no annotations, the description should provide more context (e.g., output format, examples, pagination details). It covers parameters partially but lacks completeness.
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 description lists several parameters with brief explanations (e.g., matchKeyword, biddingType, pageSize max), adding value beyond the schema which lacks descriptions. However, it omits three parameters (biddingPurchasingType, biddingProjectMinAmount, biddingProjectMaxAmount) and provides no examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is for querying and filtering bidding announcement information ('查询和筛选招投标公告信息'), and the tool name 'bid_search' aligns. It implicitly distinguishes from siblings like statistics and detail tools, but does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, such as other bid_bigdata tools or unrelated search tools. Missing context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fails to disclose behavior such as side effects, authentication needs, or rate limits, leaving agents uninformed.
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 a single concise sentence that immediately states the verb and resource, but lacks structure for complex details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without output schema or annotations, the description does not explain return format, pagination, or error conditions, making it insufficient for reliable tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description hints at matchKeyword content ('enterprise name, credit code') but entirely omits keywordType, leaving the parameter's purpose unclear given 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves bid-winning statistics for enterprises based on name or credit code, distinguishing it from sibling tools like tender or procurement stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any context for optimal usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose behavioral traits such as read-only nature, authentication requirements, rate limits, or side effects. As a query tool, it likely is read-only, but this is not stated.
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 short and efficiently conveys purpose and parameter options. However, the parameter list is somewhat raw and could be better integrated into the overall narrative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simple schema (2 params, no output schema) and lack of annotations, the description adequately explains parameter usage but lacks broader context such as return values, error handling, or example usage.
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?
With 0% schema description coverage, the description adds meaning by listing concrete values for matchKeyword (企业名称/注册号/统一社会信用代码/企业id) and keywordType (name/nameId/regNumber/socialCreditCode). However, it omits the relationship between the parameters and default behavior, reducing completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it queries basic enterprise business information ("查询企业基础工商信息"), which is a clear verb+resource. However, it does not differentiate from sibling tools like enterprise_get_enterprise_profile or enterprise_get_enterprise_business_info, leaving ambiguity about what 'basic' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It simply lists parameters without contextual usage advice or conditional logic, forcing the agent to infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose behavioral traits such as read-only nature, authentication requirements, rate limits, or side effects. The brief description only mentions 'statistics' without further details.
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 includes parameter definitions in a structured list. However, the main purpose statement is minimal and could be front-loaded with more detail to improve clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description is incomplete. It does not explain what the statistical analysis returns (e.g., counts, trends), nor does it mention any constraints or prerequisites. The tool's purpose is implied but not fully conveyed.
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?
Despite 0% schema description coverage, the description explicitly lists the two parameters and provides examples for keywordType (name, nameId, regNumber, socialCreditCode) and explains matchKeyword as enterprise name/ID. This adds meaningful context beyond the schema's bare titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states '企业专利统计分析' (enterprise patent statistical analysis), giving a general verb and resource. However, it lacks specificity about what kind of statistics (e.g., counts, trends) and does not differentiate from the sibling tool 'patent_bigdata_patent_search' which likely lists patents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'patent_bigdata_patent_search' or other enterprise tools. The description does not mention any prerequisites or context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only states the tool's function but does not mention read-only nature, data freshness, rate limits, authentication requirements, or whether it returns aggregated counts or detailed records. This is insufficient for a tool with no annotation support.
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 a single sentence that conveys the core purpose without extraneous words. It is front-loaded and efficient, though it could benefit from slight structure (e.g., listing parameters).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description should provide more context about the return format (e.g., count, summary fields), pagination, and scope. The tool has 2 parameters and sibling tools with varying functionality, so the minimal description leaves gaps for an agent to correctly invoke the tool.
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 description adds partial meaning by indicating that matchKeyword can be an enterprise name or unified social credit code. However, it does not explain the keywordType parameter, and the schema has 0% description coverage. The description adds some value but leaves ambiguity about the optional parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states that the tool obtains statistical items of bidding information based on enterprise name or social credit code. This is clear and uses a specific verb+resource. However, it does not differentiate from siblings like bid_bigdata_bidding_info or bid_bigdata_bid_win_stats, which may cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus its siblings. There is no mention of prerequisites, when-not-to-use, or alternatives. The agent lacks context for selecting this tool over similar ones.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, authorization requirements, rate limits, or side effects. The description carries the full burden but fails to provide needed context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with two short paragraphs. The purpose is front-loaded, and parameter list is structured. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no description of return values, the description is incomplete. It does not explain what data the tool returns, which is critical for an information retrieval tool.
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 coverage is 0%, but the description includes parameter explanations (e.g., 'matchKeyword' accepts name/registration number/credit code, 'keywordType' lists options). This adds meaning beyond the raw schema but lacks completeness (e.g., no format or validation details).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('查询') and resource ('企业控股股东信息'), indicating it queries controlling shareholder info. It is distinguishable from sibling tools like enterprise_get_enterprise_base_info, though no explicit differentiation is provided.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description does not specify prerequisites, limitations, or context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must shoulder the burden of behavioral disclosure. It only reveals a maximum return of 500 entries, but omits any information about authentication, rate limits, data freshness, pagination details, side effects, or permissions. This is minimal disclosure for a tool that likely mutates nothing but still requires transparency.
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 (two sentences) and front-loads the core purpose and limit. However, it references another tool for parameters, which could be considered a slight overhead. It is efficient but could include a brief summary of key parameters without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (13 parameters, no output schema, no annotations), the description is incomplete. It lacks details on output format, pagination (beyond limit), error handling, default behavior, and parameter meanings. The reliance on a sibling tool for parameter info creates a dependency that reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 13 parameters with 0% description coverage, and the description adds no parameter explanations. The statement 'request parameters are the same as advanced_filter_get_enterprise_count' defers completely to another tool, leaving agents without immediate access to parameter semantics. This scores a 1 as the description fails to add any value for parameter understanding.
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: query a list of enterprises via advanced filters, returning up to 500 entries. It explicitly distinguishes itself from the sibling tool advanced_filter_get_enterprise_count by mentioning 'list' vs 'count', making the differentiation clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a list of enterprises is needed (as opposed to just the count), but it does not provide explicit guidance on when to use this tool versus the many other enterprise-related sibling tools, nor does it include any when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, authorization requirements, or any side effects. It merely says 'query', implying read-only but not explicitly.
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 purpose. It uses a structured list for parameters, making it easy to scan. No unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks context on the output format or return data. Without an output schema, the agent does not know what fields the profile contains, which is important for interpreting results.
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 description adds significant value beyond the input schema by explaining the accepted values for 'matchKeyword' (enterprise name/reg number/credit code/ID) and 'keywordType' (name, nameId, etc.). With 0% schema coverage, this is crucial for correct parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries enterprise profile information, using a specific verb ('query') and resource ('enterprise profile'). However, it does not differentiate from the sibling tool 'enterprise_get_enterprise_base_info', which likely has a similar purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as 'enterprise_get_enterprise_base_info' or other enterprise tools. No context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should carry the full burden of behavioral disclosure. However, it only describes the query parameters and does not mention any side effects, authorization needs, rate limits, or whether the tool is read-only. The agent cannot assess safety or impact.
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 appropriately sized for a simple query tool: a one-line purpose followed by parameter list. It front-loads the purpose. However, the parameter list could be more structured (e.g., using a table) to improve scannability, but it is not overly verbose.
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 tool has 4 parameters, no output schema, and no annotations, the description adequately covers the input semantics. All parameters are explained. Since there is no output schema, the agent can infer that the return value is a list of investment info entries. The description is sufficient for a basic query tool.
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 has 4 parameters with 0% description coverage, so the description must compensate. It explains 'matchKeyword' as accepting multiple identifier types and lists allowed values for 'keywordType' (e.g., 'name', 'regNumber'). This adds meaning beyond the schema, though the explanations are informal and not structured as a spec.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/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: '查询企业对外投资信息' (query enterprise external investment information). It specifies a verb and a resource, but does not differentiate from sibling enterprise tools like 'enterprise_get_enterprise_base_info' or 'enterprise_get_enterprise_branch_info', leaving ambiguity about what specific investment details are returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists parameters but provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or any context for invocation. The agent receives no help in deciding between this and sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits but only states it performs a fuzzy search. It does not mention read-only behavior, rate limits, or whether results are paginated (though implied by parameters).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence for purpose and three lines for parameters, front-loaded and no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While parameters are well described, the description lacks overall context such as output format, error behavior, or performance considerations. It is adequate for a simple search but not fully complete.
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 description provides explicit detail for each parameter beyond the schema titles: matchKeyword's purpose, pageIndex start value, pageSize max of 50. This compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a fuzzy keyword search for enterprises. However, it does not differentiate from sibling tools that also query enterprise data, and the phrase '各类信息' is vague about which fields are searched.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like enterprise_get_enterprise_base_info. It simply describes the operation without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states what data is returned but does not disclose whether the operation is read-only, auth requirements, rate limits, or behavior beyond the basic purpose.
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 a single short sentence that conveys the core purpose upfront. It is concise but could be more structured with explicit parameter breakdown.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters and no output schema or annotations, the description covers the main output (procurement stats with distributions) but omits parameter details and behavioral context, leaving gaps 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%; the description mentions 'name or ID' which maps to matchKeyword and keywordType, but does not clarify the exact meaning, format, or allowed values for these 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 that the tool retrieves enterprise procurement statistics including product and area distribution, using name or ID. This distinguishes it from sibling tools like bid_bigdata_bidding_info or bid_bigdata_bid_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The sibling names imply differentiation, but the description does not state use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only describes input parameters but does not disclose behavior such as whether modifications occur, authentication needs, rate limits, or error responses. The tool appears to be a query, but this is not explicitly stated.
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, listing parameters with brief Chinese explanations. It is front-loaded with the purpose sentence. While efficient, the formatting could be improved for readability, but each line serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no output schema, and no annotations, the description should explain what the tool returns. It only covers input parameters, leaving output format, error handling, and behavior for missing results unspecified. This incompleteness limits an agent's ability to use the tool 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?
Schema description coverage is 0%, but the description adds significant meaning: it explains matchKeyword as '企业名称/注册号/统一社会信用代码/企业id', enumerates keywordType values, and clarifies pageIndex and pageSize. This goes well beyond the bare schema.
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 explicitly states '查询企业主要人员信息' (query enterprise main person info), providing a clear verb and resource. Among sibling tools like enterprise_get_enterprise_base_info and enterprise_get_enterprise_branch_info, this one specifically targets main person info, distinguishing its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists parameters but provides no guidance on when to use this tool versus alternatives. There is no mention of use cases, prerequisites, or when not to use it. The sibling tools suggest different enterprise information endpoints, but no explicit criteria for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as read-only nature, rate limits, or effects. For a query tool, basic safety is implied but not explicitly stated.
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 brief (one line plus parameter list) and to the point. It front-loads the purpose and lists parameters clearly, but could be more structured with formatting for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and limited description. While parameter info is provided, the return format, pagination behavior, and error handling are not explained. For a moderately complex tool, this is adequate but not complete.
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?
Schema description coverage is 0%, but the description adds meaning by explaining matchKeyword (企业名称/注册号/统一社会信用代码/企业id) and keywordType (name, nameId, etc.). However, pageIndex and pageSize are only listed without additional context like defaults or range.
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 explicitly states '查询企业分支机构信息' (query enterprise branch information), which clearly indicates the verb and resource. It distinguishes from sibling tools like enterprise_get_enterprise_base_info and enterprise_get_enterprise_business_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as enterprise_get_enterprise_base_info or enterprise_get_enterprise_profile. The description only explains parameters, not usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only implies a read operation (query) but does not disclose authentication needs, error handling, rate limits, or side effects. The description is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two sentences plus parameter list. The first sentence states the purpose immediately, and the parameter list is clear and front-loaded. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description does not explain the structure or fields of the returned data. It only gives examples of tags without detailing the full response. For a query tool, this is a notable gap.
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?
Schema description coverage is 0%, but the description adds meaning: matchKeyword is an enterprise identifier (name/reg number/social credit code/ID) and keywordType lists specific allowed values (name, nameId, etc.). This clarifies the parameters beyond the schema types.
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 that the tool queries enterprise tag information, listing examples like main business, financing, scale. It distinguishes from siblings by focusing specifically on tags, while other enterprise tools handle base info, profile, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool over alternatives (e.g., enterprise_get_enterprise_base_info). No context on prerequisites or scenarios. Only parameter descriptions are present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It does not disclose behavioral traits such as read-only nature, authentication requirements, rate limits, or side effects. The tool is a query, but that is implied rather than stated. The description only says 'query' without clarifying safety or impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two sentences for purpose, one parameter description with clear title and explanation. No fluff. Front-loaded with the main action. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool returns downstream products, but there is no output schema and the description does not describe the return format, structure, or example. For a simple query tool, missing this information reduces completeness. Also lacks context on typical use cases or relationship to other tools.
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?
Schema description coverage is 0%, so the description must add meaning. It does: 'keywords: supply chain product keywords, multiple words separated by commas.' This explains the format and intended content. It adds value beyond the schema's type-only information. However, it lacks examples or constraints like max length.
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: 'Query downstream product list based on product name.' It specifies the resource (downstream products) and the action (query). The phrase 'product name refers to products involved in the supply chain' adds context. This distinguishes it from sibling 'supply_get_down_stream_enterprises' which focuses on enterprises.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The sibling 'supply_get_down_stream_enterprises' is a similar tool, but no comparison or usage context is provided. There is no mention of prerequisites, limitations, or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only explains parameters. It does not disclose whether the operation is read-only, destructive, rate limits, data freshness, or pagination behavior beyond parameter names.
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?
Description is moderately concise with a clear one-liner purpose and a list of parameters. It is front-loaded but could be better structured (e.g., bullet points) for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers only about half of the 18 parameters (missing hasPack, hasStock, etc.) and provides no information about output format or pagination behavior, leaving gaps for a complex query tool.
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?
Though schema coverage is 0%, the description adds significant semantics by explaining parameter details: comma separation for multiple values, allowed values (是/否), address format, date format, and page index starting at 1.
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?
Description clearly states the tool queries a list of downstream enterprises based on product names, distinguishing it from sibling tools like supply_get_down_stream_products which likely query products.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists parameters but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusion criteria or usage context. Usage is implied by the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear full burden. It does not disclose whether the tool is read-only, any side effects, required permissions, rate limits, or error behavior. It only hints at output content but lacks explicit behavioral traits.
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, front-loading the purpose, then listing parameters with brief explanations. Every sentence contributes; no fluff. It could be slightly more structured, but it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description partially compensates by listing the types of information returned (levels, authorities, subsidies, trends). However, it does not provide a detailed output structure or example, leaving some ambiguity about the exact format.
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?
Schema description coverage is 0%, but the description adds value by explaining the possible values for matchKeyword (name, registration number, etc.) and keywordType, and suggests using enterprise_get_keyword_search if full name is not available. This goes beyond the schema definitions.
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: query enterprise approved policy project statistics, covering levels, authorities, subsidies, and trends. It uses a specific verb ('查询') and resource ('获批政策项目统计'), and is distinguishable from sibling tools like policy_bigdata_policy_info and policy_bigdata_policy_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for understanding enterprise-approved policy projects but does not explicitly state when to use this tool vs alternatives. No when-not or alternative recommendations are provided; usage is implied from the purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states the purpose and parameter types, lacking details on mutability, auth needs, rate limits, or output characteristics. For a query tool, basic read-only behavior could be implied but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, starting with a clear purpose sentence followed by parameter descriptions. No wasted words; each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain return values or behavior. It adequately covers parameters but omits output format, pagination, or error scenarios, which an agent needs to invoke correctly among 22 sibling tools.
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?
Schema description coverage is 0%, but the description adds meaning by listing accepted values for matchKeyword (enterprise name/registration number/credit code/ID) and keywordType options ('name', 'nameId', 'regNumber', 'socialCreditCode'). This compensates well for the bare schema.
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 enterprise business-related information to identify main business and industry chain capabilities. The verb '查询' (query) and resource '企业业务相关信息' are specific, and the tool is well-differentiated from siblings like enterprise_get_enterprise_base_info which focus on base info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for identifying main business and chain capabilities but does not explicitly state when to use or not use this tool, nor does it reference alternatives among the many sibling tools. Some implied context exists but no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose whether the tool is read-only or has any side effects. For a query tool, it's likely safe, but the lack of explicit behavioral context is a gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no wasted words. Structure is efficient and clear.
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?
Lists fields returned, covering key information. No output schema, but description compensates. Lacks details on error handling or pagination, but sufficient for a simple query.
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?
Parameter schema has 0% coverage, but description explains matchKeyword is the policy ID. This adds basic meaning but no format or constraints beyond the name.
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?
Description clearly states it queries policy details by ID, listing specific fields included. It distinguishes from sibling tools like policy_bigdata_policy_search and policy_bigdata_approved_project_stats.
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?
Explicitly says to use when querying policy details by ID. While it doesn't list exclusions, the context implies this is for retrieving details rather than searching, and siblings cover search and stats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions pagination limits (pageSize max 50) and default values, which is helpful. However, it does not discuss permissions, rate limits, error handling, or the nature of the operation (read-only). For a search tool, this is minimally adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. It begins with a clear one-sentence summary of the tool's purpose, followed by a structured list of parameters with explanations. Every sentence adds value, and there is no redundant or irrelevant information.
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 complexity of 8 parameters and no output schema, the description covers all parameters with examples and constraints (e.g., date format, address structure). It could be improved by explaining the order of results or how to handle empty results, but it is largely complete for effective tool usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries full responsibility for parameter semantics. It provides detailed explanations for all parameters, including examples for 'matchKeyword', enumeration values for 'pnType', and complex format guidance for 'address' (including nested lists). This adds significant meaning beyond the bare schema.
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 it searches for policies, application guides, and public announcements with filtering options. The verb '搜索' and resource '政策法规、申报指南或公示公告' are specific, and the tool name 'policy_search' distinguishes it from sibling tools like 'policy_info' or 'approved_project_stats'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but does not explicitly state when to use it versus alternatives (e.g., 'policy_bigdata_policy_info' for details, 'policy_bigdata_approved_project_stats' for statistics). The context from sibling tools provides implicit guidance, but the description itself lacks explicit usage or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description effectively communicates the key behavioral trait: it only returns a count. However, it lacks details on error handling, rate limits, or what happens with no matching results.
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, using a single paragraph with a bullet-like parameter list. It is front-loaded with purpose, but the parameter list could be more structured (e.g., grouping related parameters like time ranges).
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 13 parameters and no output schema, the description covers all parameters with examples and units, and states the return behavior. It is mostly complete, though missing information on optional vs required usage and result format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides zero description coverage, so the description carries full burden. It fully compensates by listing each parameter with examples and units (e.g., 单位万元), adding significant meaning beyond the bare schema.
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 the number of enterprises nationwide based on advanced filter criteria, and explicitly notes it only returns the count. This distinguishes it from the sibling tool 'advanced_filter_get_enterprise_list', which likely returns a list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when only a count is needed, but does not explicitly state when to use this tool versus alternatives, nor does it provide prerequisites or exclusions. With 23 siblings, more explicit guidance would be beneficial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![industry-chain-mcp-server MCP server](https://glama.ai/mcp/servers/handaas/industry-chain-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/handaas/industry-chain-mcp-server)

Score Badge

Copy to your README.md:

[![industry-chain-mcp-server MCP server](https://glama.ai/mcp/servers/handaas/industry-chain-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/handaas/industry-chain-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/handaas/industry-chain-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server