create_search_session

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

No annotations are supplied, so the description carries the full burden of behavioral disclosure. It mentions that the session is 'continuous,' which hints at persistent state, but fails to explain what that means — whether a new session replaces an existing one, whether prior results are preserved, or what cleanup requires. For a stateful session-creating tool, this is a meaningful 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?

The definition is a single efficient clause with no wasted words, which is structurally clean. However, the brevity comes at the cost of leaving key information out — it is terse rather than genuinely complete — so it earns a mid score on this dimension.

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 session-management tool with no annotations, an under-specified city parameter, and 10 siblings implying a multi-step workflow, the description is too thin. An output schema exists, which partially covers return-value expectations, but the missing lifecycle context (how sessions interrelate with the other tools) and the unspecified city values leave the agent under-equipped.

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?

With schema description coverage at 0% and a single 'city' parameter, the description must compensate by explaining the expected value format. It only says 'supported cities' without listing examples, specifying whether city names should be in Chinese or pinyin, or defining the supported set. The agent has no schema hints to fall back on either, since the property has no description, enum, or format.

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 states a specific action (create a continuous search session) and resource (browser search sessions for supported cities), which distinguishes it from sibling result-fetching tools like get_results or get_listing_detail. However, 'supported cities' is undefined and '自如' is ambiguous, so an agent cannot determine which cities qualify or what the tool's exact scope is without external knowledge.

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?

No guidance is provided on when to create a session versus the many sibling tools that operate within one, such as search_location, set_filter_range, or close_search_session. No preconditions, exclusions, or mention of session lifecycle ordering are given, so the agent must infer usage context entirely.

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