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

With no annotations provided, the description carries the full behavioral burden. It does add meaningful context: '查询' signals a read-only operation, and the Returns section discloses the output shape (JSON string with name, type, location, capacity, price range, facilities). However, it does not mention authentication requirements, pagination limits, or how filters combine (AND vs OR), leaving some behavioral assumptions to the agent.

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 well-organized with a purpose statement, a usage-trigger sentence, an Args block with one line per parameter, and a Returns block. It is front-loaded and scannable. Minor redundancy exists between the opening sentence and the usage sentence, both conveying the venue-search purpose, but nothing is wasted.

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?

For a simple 3-parameter, all-optional query tool, this description is nearly complete: it covers purpose, when to call, every parameter with semantics and examples, and the return format. The output schema exists per context signals, so return-value explanation is bonus. Remaining gaps (auth, pagination, failure behavior) are minor for a read-only list query.

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 0%, so the description fully compensates. Each parameter gets an explanation beyond the bare schema: venue_type has concrete examples (桌游吧, 运动场地, 露营基地), location has real district examples (南山区, 罗湖区), and min_capacity clarifies the integer-or-string acceptance plus the '0 means no filter' semantic. This is exactly what the dimension rewards.

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 opens with '查询粗趣小程序合作场地列表' — a specific verb (查询/query) plus a specific resource (合作场地列表/partner venue list) with an explicit scope (粗趣小程序). This clearly distinguishes it from siblings like query_activities, which targets activities rather than venues.

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 states an explicit usage trigger: '当用户需要找场地、了解场地信息时调用此工具' (call when the user needs to find venues or learn venue info). This gives the agent a clear decision rule. It does not explicitly name alternatives or exclusion cases, but given the sibling set, the venue-vs-activity contrast is strong enough to route correctly.

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