company_patent基于明确指定的企业名称，查询该企业拥有的专利信息，包括专利名称、申请号公布、专利类型、公布日期等。
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?
Annotations are sparse (only openWorldHint) so description carries the burden. The description mentions pricing and the fields returned but does not disclose read-only behavior, potential pagination implications, rate limits, or side effects. Without readOnlyHint or destructiveHint, the agent cannot know if this is a safe query. The openWorldHint is vague and not explained. No contradiction but significant missing transparency.
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 a single sentence, efficiently stating the core purpose and return fields. Pricing is included as a separate line, which is useful but not behavioral. It is well-structured and front-loaded, with no filler. However, it omits some needed context, but that's reflected in other scores. For conciseness alone, it earns a 4.
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?
Given the tool is a simple query with one required parameter and an output schema exists, the description need not detail return values. It covers what the tool does, the key fields, and pricing. The existence of pagination parameters and their defaults are in the schema. The primary gap is lack of usage context, but that falls under other dimensions. For a straightforward query tool, this is largely complete.
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 description coverage is 100%, so all parameters (company_name, page, limit) already have clear descriptions. The tool description adds no additional parameter context beyond the schema, e.g., it doesn't explain pagination behavior or format of company_name. Baseline of 3 is appropriate when schema fully documents params and description doesn't enhance.
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 that the tool queries patent information for a specified company, listing specific fields (patent name, application number, type, publication date). This distinguishes it from siblings like chain_have_patent_company_list which filter companies by patent existence, not detail retrieval. The verb 'query' and resource 'patent information' are specific and unambiguous.
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 usage (when you need patent details for a specific company) but provides no explicit guidance on when not to use it or alternatives. It doesn't mention that for listing companies with patents you'd use chain_have_patent_company_list, nor does it note prerequisites like requiring an exact company name. This leaves the agent to infer context from the sibling list.
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).