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

With no annotations, the description carries the burden of behavioral disclosure. It does mention releasing a browser page, which is a concrete side effect. However, it does not disclose whether the operation is irreversible, destructive, or whether any session data is lost. It adds some context but could be richer.

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, concise sentence that directly conveys the action and its effect. It is front-loaded with the primary purpose and contains no extraneous wording. Every word earns its place.

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?

The tool is simple with one parameter and an output schema exists, so return values needn't be explained. However, the description omits usage context, such as lifetime management or prerequisites (e.g., that a session must have been created first). An agent receives no indication of when this should be called relative to other operations, making it incomplete for effective use.

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%, and the description does not mention the session_id parameter at all. The parameter is only documented in the schema as a required string, but nothing explains what value to pass or how it identifies the session. The description fails to compensate for the coverage gap, leaving the agent without guidance on this critical input.

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 the verb 'close' and the resource 'search session', and adds the effect of releasing the associated browser page. This distinguishes it from the sibling tool create_search_session, which does the opposite, and from other search operations. The purpose is 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?

No guidance is given on when to invoke this tool versus alternatives. It does not mention that it should be used after a search session is no longer needed, or any conditions for use. The description simply states what it does without contextualizing when it is appropriate.

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

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.

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. The verb '读取' (read) reasonably implies a non-mutating operation, and the mention of '状态版本' (state version) adds context about what the tool returns. However, it does not explicitly state that it has no side effects or whether it refreshes the current state, which leaves some ambiguity.

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, concise sentence that directly conveys the tool's action and result items. There is no filler or redundant information, and the key terms are front-loaded. This is appropriately minimal for a read operation.

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?

The description lists what it reads but omits guidance on when to use it relative to sibling tools (e.g., after creating a search session) and any behavioral details like whether it requires an active session. The output schema exists, so return structure is covered, but the description alone is insufficient for correct invocation in a complex workflow.

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?

The only parameter, session_id, has no description in the schema (schema coverage 0%). The description does not explain what session_id refers to or how it relates to the 'current page'. Given the low coverage, the description should compensate, but it does not, leaving the agent to infer from the tool name and sibling patterns.

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 the verb '读取' (read) and the resource ('筛选字段、可选标签、已选值和状态版本'), which specifies the tool's purpose as retrieving filter schema information. It is distinct from sibling setter tools like select_filter_option or set_filter_range because it is a read operation, though it does not explicitly name alternative tools.

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 use this tool versus the sibling setter tools. The description does not mention prerequisites, ordering, or scenarios where it should be called, such as before setting filters. The context implies it is a read operation, but there is no explicit cue for the agent to decide between it and other tools.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the core behavior (scrape a detail page, return structured data + optional report) and hints at the include_report toggle. But it does not disclose that this is a live external-site scrape with rate-limit/failure implications, the retry semantics behind the retries parameter, or error handling behavior — gaps for a network-bound tool with zero annotations.

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?

A single efficient sentence that front-loads the purpose (scrape detail page URL) before describing the output. Every element earns its place and there is zero waste, though the parameter-to-behavior mapping (include_report) could have been made slightly more explicit within the same length.

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?

The output schema covers return values, so that part is handled. But for a moderately complex network-scraping tool with 4 parameters, zero schema descriptions and no annotations, the description is thin: it omits when-to-use guidance, retry/timeout semantics, and scraping-behavior caveats. Adequate for the core purpose but with clear gaps.

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 must compensate. It partially does: the url parameter is implied ('单个自如详情页 URL') and the include_report parameter is mapped via '可选中文 Markdown 报告'. However, retries and timeout_seconds are left entirely unexplained, and with zero schema descriptions those two parameters are undocumented everywhere.

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 verb (抓取/scrape), a precise resource (单个自如详情页 URL), and the output shape (structured fields + optional Chinese Markdown report). This clearly distinguishes it from the search-session siblings (create_search_session, set_sort, get_results), which all operate on queries and result lists rather than a single listing detail.

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?

Usage is implied rather than stated: a detail-page scraper naturally follows after obtaining listing URLs via get_results. However, the description never says when to use this versus get_results, nor names an alternative or any exclusion condition. No explicit when/when-not guidance is given.

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

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

With no annotations provided, the description carries the full burden. It does not disclose whether the operation is read-only, if it validates conditions, requires active session, or has side effects. The term 'verification result' suggests some checking but is not explained. This is a significant gap for a tool likely in a multi-step workflow.

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, which is concise, but it lacks structure and front-loading of essential usage context. It lists return fields but does not prioritize critical information like usage or prerequisites. It feels under-specified rather than efficiently concise.

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's complexity (3 parameters, output schema, likely part of a session-based workflow), the description is severely incomplete. It does not explain how it fits with sibling tools like create_search_session or set_filter_range, does not mention session lifecycle, and provides no context on when results are final or how verification works. An agent cannot reliably use this tool.

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%, and the description provides no information about any of the three parameters (session_id, limit, expected_filters). An agent would not know what session_id refers to, what limit controls, or how expected_filters affects the result. The description does not compensate for the lack of schema coverage.

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 it returns house name, URL, current conditions, and final condition verification results, which gives a specific verb and resource (retrieve results). However, it doesn't clearly differentiate from siblings like get_listing_detail or get_filter_schema, and the phrasing is somewhat ambiguous about what 'final condition verification' means.

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?

There is no guidance on when to use this tool versus alternatives. It does not mention session context, prerequisites like having an active session, or whether it should be called after setting filters. An agent would have no idea when to invoke it.

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

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

There are no annotations, so the description carries the full burden of behavioral disclosure. The only disclosed behavior is that other selected fields are unaffected; it does not mention side effects, whether the operation is destructive/reversible, what happens when expected_version mismatches, or any concurrency behavior. This is insufficient for a state-mutating tool.

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, which is concise and front-loaded with the main action. However, it is so sparse that it sacrifices necessary context for a 3-parameter tool. While brevity is a virtue, here it leaves the definition incomplete.

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?

The tool has an output schema, so return values need not be explained. Yet the description fails to explain the purpose of the required parameters (session_id, field_id) and the optional expected_version, nor does it state any behavioral guarantees beyond preserving other fields. For a tool operating on a session, this is a significant gap.

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 must compensate for parameter documentation. However, it only hints at field_id through the phrase 'specified field' and says nothing about session_id or expected_version. An agent cannot determine the meaning or role of these parameters from the description.

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 the action: reset the specified field to its default value, and adds a scope constraint ('does not affect other selected fields') that distinguishes it from a global reset. It names the resource (field) and the operation precisely, though it does not name a sibling alternative explicitly.

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 provides no guidance on when to use this tool versus alternatives like set_filter_range or select_filter_option. It does not mention prerequisites (e.g., an active session) or any conditions that should trigger this tool, leaving the agent to infer usage from the tool name.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action of restoring state, which implies a mutation, but does not mention side effects, reversibility, or permissions. The only behavioral hint is the 'empty_results' reason, which is more parameter-specific than a behavioral trait. This is a significant gap for a state-changing tool.

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, concise sentence with no fluff. It front-loads the core action first and then adds the conditional parameter detail. It earns its place, though it is perhaps too brief to meet the completeness expected for the tool.

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?

Despite having an output schema, the description is severely incomplete for a tool with 4 parameters, 0% schema coverage, and no annotations. It fails to explain what a checkpoint is, how to obtain one, the role of 'expected_version', or any workflow context. An agent cannot reliably know how to invoke this tool correctly beyond the vague restore action.

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 must compensate for all parameters. It only explains the special case for 'reason' (use 'empty_results' on zero results), but does not describe 'session_id', 'checkpoint', or 'expected_version'. This leaves most parameters undefined, providing minimal semantic value beyond the schema.

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?

States a clear purpose: restoring the complete state before a filtering operation. The verb 'restore' and resource 'checkpoint' are specific, and it's distinguishable from siblings like 'reset_filter' in that it restores a prior snapshot rather than just clearing selections. However, it doesn't explicitly differentiate from all siblings, which would push it to 5.

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?

Provides a conditional guideline for the 'reason' parameter when zero results occur, but gives no guidance on when to use this tool vs. alternatives like 'reset_filter' or 'close_search_session'. No exclusions or alternative conditions are mentioned, leaving the tool selection context largely implicit.

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

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

Annotations are absent, so the description carries the full burden of behavioral disclosure. It only states that the tool 'searches' but does not specify side effects, return format, pagination, session requirements, or any operational constraints. For a tool with no annotations, this is insufficient; an agent cannot infer whether this is a pure read or if it modifies state.

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 brief (two clauses) and avoids verbosity, which is positive. However, the structure mixes a purpose statement with a usage instruction in a way that is slightly confusing. It could be improved by separating the usage note into a dedicated 'when to use' section, but it does not waste words.

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 search tool with 3 parameters and an output schema (not described here), the description is inadequate. It does not explain how matches are returned, how to handle multiple results, or the role of session_id in the search context. Even though an output schema exists, the agent lacks behavioral context (e.g., disambiguation, session management) that a complete description should provide.

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% and the description mentions no parameters. The agent must rely solely on parameter names (keyword, session_id, expected_version) with zero context. The description does not clarify the purpose of session_id or expected_version, nor the expected format of keyword. This is a critical gap given the low schema coverage.

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 what the tool does: it searches for a residential area, business district, or subway station. This is a specific verb (search) with a clear resource type, and it differentiates from other siblings (no other search tool exists). The additional note about 'multiple user answers' is more of a usage directive than a purpose statement, but the core purpose is 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 offers a cryptic usage note: 'multiple user answers should be first selected by the Agent' but does not explain when to use this tool versus alternatives. No explicit exclusions or comparisons to sibling tools are provided. The note implies a precondition (agent should consolidate user inputs) but is vague and lacks actionable guidance.

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

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

With no annotations provided, the description must carry the behavioral burden. It does disclose a non-obvious behavior: when the page is not retained, it returns skipped=true instead of raising a tool error. However, it omits other important traits like state mutation, side effects, or permissions, so coverage is partial.

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 with no fluff, efficiently delivering two pieces of information: the action and the skipped-behavior nuance. It is front-loaded with the action, though it sacrifices completeness for brevity.

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 has 4 parameters, no annotations, and no schema descriptions, the description is severely under-specified. It leaves the agent without enough context to correctly invoke the tool, especially regarding parameter meaning and session handling.

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?

The schema has 0% description coverage, so the description must compensate. It does not explain any of the four parameters (option, field_id, session_id, expected_version). The word '标签' could relate to option but is not explicit, adding no real semantic value.

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 ('select current tag') but 'tag' is ambiguous and does not map clearly to the schema's option/field_id parameters. It does not differentiate from sibling tools like set_filter_range or set_sort, leaving the core purpose fuzzy.

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 use this tool versus alternatives. The description only mentions a behavior on failure (skipped=true) but offers no context for when selection is appropriate or when another tool (e.g., set_filter_range) should be chosen.

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

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

With no annotations, the description must disclose behavior. It reveals a key limitation (only rent field support), which is useful. However, it doesn't mention side effects, return values, or any prerequisites, so behavioral coverage is partial.

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 that front-loads the purpose and includes no unnecessary words. It is appropriately concise and structured.

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 5 parameters, no schema descriptions, and no annotations, the description is incomplete. It only addresses one parameter and says nothing about required fields like session_id or expected_version, leaving the agent without enough information to call the tool correctly.

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 is the only source for parameter meaning. It clarifies field_id via the rent example but leaves maximum, minimum, expected_version, and session_id unexplained, which is insufficient for a 5-parameter tool.

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 the tool sets range fields, specifically for rent, providing a verb-resource pair. However, it doesn't differentiate from siblings like set_sort or select_filter_option, so it lacks explicit sibling distinction.

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?

It gives contextual usage by noting that only field_id=rent is currently supported, implying when to use it for rent range settings. But it doesn't explicitly state when not to use it or suggest alternatives, leaving the guidance implied.

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

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It only says 'set' without specifying side effects (e.g., whether it mutates the session state, whether the sort persists, or what the response contains). No information about expected_version conflict handling or the result of a successful call is given. The description does not contradict annotations (since none exist), but it fails to disclose any behavioral traits.

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 short sentence with no redundancy or filler. It is appropriately front-loaded with the core action. However, it is so brief that it borders on terse, though the lack of wasted words earns a solid score for conciseness.

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 appears to be part of a multi-step search workflow (siblings include create_search_session and get_results), the description is incomplete. It fails to mention the need for an existing session, any ordering constraints, or the expected output/return value. With no annotations and no parameter guidance, an agent receives insufficient context to invoke the tool correctly in a complex workflow.

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 must compensate for the parameters. It partially explains the 'option' parameter by giving examples (price or area), but it says nothing about session_id (its role as a session identifier is implied but not explicit) and completely omits expected_version. The description adds minimal value beyond the raw schema and does not adequately document the parameters.

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 the action: '设置结果排序方式' (set result sorting method), with concrete examples of values like price or area. This distinguishes it from sibling tools like select_filter_option and set_filter_range, which handle filtering rather than sorting. The verb-resource pair is specific enough for an agent to infer its core function.

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 use this tool versus alternatives. It does not mention prerequisites such as requiring an active search session (created by create_search_session), nor does it explain how sorting differs from filtering or when to call get_results after sorting. The description leaves the decision entirely to the agent's inference.

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