Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds genuinely new behavior: omitting city returns the full unfiltered list, and the return payload is structured into five named fields (title, issuing body, date, highlights, source). It does not mention result volume caps or pagination, which is the remaining gap.

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?

Three compact segments: what it returns, when to use it, and the default filter behavior. The default is placed last but is short enough to be found, and the parenthetical field list is dense but earns its space.

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?

A read-only single-parameter list tool with no output schema — the description compensates by enumerating the returned fields and stating the no-filter default, which is essentially everything an agent needs to call it. Only volume/pagination behavior is unaddressed.

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?

There is one optional parameter with 100% schema description coverage, and the schema already states '城市过滤,不传返回全部'. The description's '不传 city 返回全部' restates that exact fact rather than adding format details (e.g. city vs district matching granularity). Baseline 3 applies when the schema does the work.

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 names a specific resource (各城市/区的创业政策红利) and enumerates the packaged fields (标题/发文单位/日期/亮点/信源), so an agent knows exactly what it gets back. It never names a sibling tool, so the boundary with list_park_news / list_park_city_stats / list_parks must be inferred from the 'policy' framing.

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?

Two sample queries (「深圳 OPC 有什么政策红利」「入驻前看看当地政策」) imply when to reach for it, which is better than nothing. However, there is no explicit when-not guidance and no named alternative for adjacent lookups such as park news or park stats.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.