company_session基于明确指定的企业名称，查询该企业涉及的开庭公告信息，包括开庭日期、案号、案由、原告、被告、公告内容、地区、承办部门、审判长、法院、法庭等。
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 only provide openWorldHint: true, and the description doesn't contradict it. The description adds a list of returned attributes (court date, case number, cause of action, plaintiff, defendant, etc.) that enriches behavioral context, plus transparent pricing (0.2 credits/run). However, it doesn't disclose pagination limits despite exposing page/limit params, nor does it reveal what happens with no matching company. It adds some value beyond the minimal annotation but doesn't go far.
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, front-loaded paragraph that leads with the core action before listing fields - an efficient structure. Every element (purpose, return fields, pricing) earns its place. It loses one point because the field enumeration runs long and the pricing JSON block adds slight visual noise, but overall it's tight for the information density delivered.
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 there is an output schema (so return structures need not be spelled out) and only 3 flat parameters, the description covers the essential context: what the tool does, what data comes back, and what it costs. It could be more complete by noting pagination interaction with page/limit or data freshness, but for a moderate-complexity read query tool with strong schema support, it's above adequate.
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 coverage is 100% - page, limit, and company_name all have inline descriptions. The description adds minimal parameter value, only re-emphasizing that company_name should be a specific enterprise name ('基于明确指定的企业名称'). Per rubric, baseline is 3 when schema carries the burden, and the description doesn't meaningfully exceed the baseline by adding usage syntax, defaults explanation, or format expectations beyond what the schema already documents.
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 uses a specific verb-resource pairing ('查询该企业涉及的开庭公告信息' - query the court session announcement info for the company) and enumerates the exact return fields (开庭日期、案号、案由、原告、被告、公告内容、地区、承办部门、审判长、法院、法庭等). This clearly distinguishes it from close siblings like company_judgement (judgment announcements), company_executed, and company_shareholder, which cover different legal/corporate data domains.
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 context through the phrase '基于明确指定的企业名称' (based on the clearly specified company name), signaling that a precise company name is the key input for this court-session-specific query. However, there is no explicit when-to-use/when-not-to-use guidance or named alternatives (e.g., no mention that court session data differs from verdicts in company_judgement, or that company_tenderbid is for bidding announcements). Usage context is implicit, not stated.
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).