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

With no annotations, the description carries full behavioral burden. It discloses that the operation is a read (读取), provides an example of the returned status string, and explicitly guarantees it will not send prompts. It does not mention potential preconditions or failure modes, but for a simple UI status read this is fairly transparent.

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?

Two concise sentences front-load the action and resource, include a concrete example, and add a non-goal statement. No wasted 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 zero-parameter read-only status tool, the description is complete: it names the resource, gives an example output, and clarifies the non-sending behavior. The absence of an output schema is compensated by the example, and an agent can invoke it without further information.

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 input schema has zero parameters, so the baseline is 4. The description reinforces that the tool takes no input and simply reports the current slider state.

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 reads the current position and accessible range of the answer-tier slider, with a concrete output example ('极高，第 4 项，共 5 项'). The explicit note that it does not send prompts distinguishes it from sibling tools like chatgpt_select_answer_tier and chatgpt_send_message.

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 a read-only inspection use case but does not explicitly state when to prefer it over alternatives such as chatgpt_select_answer_tier. It provides no explicit when/when-not guidance or named alternatives.

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 behavioral transparency burden. It discloses a key behavioral trait: the browser remains open after the MCP call ends and is reused by later calls without re-entering the site. This goes beyond what the tool name alone reveals.

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?

Two short sentences, front-loaded with the core purpose and followed by the most important behavioral detail. Every clause earns its place; there is no redundant or filler content.

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 zero-parameter status-read tool, the description covers the essential context: what state is read and how subsequent calls interact with the browser. It does not enumerate possible return values, but the simplicity of the tool makes that a minor gap rather than a serious omission.

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 tool has zero parameters, so schema coverage is effectively 100% and there is no parameter burden on the description. The baseline of 4 applies because the description is not required to explain parameter meaning.

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 clear verb ('读取') and resource ('专用 ChatGPT 浏览器的常驻状态'), making the tool's purpose understandable. It does not explicitly differentiate from similar sibling tools like chatgpt_status or chatgpt_close_browser, but the lifecycle-specific scope is clear enough.

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 useful context about browser persistence and reuse by subsequent calls, which implies when lifecycle state matters. However, it does not explicitly state when to prefer this tool over alternatives, nor does it give any 'when not to use' 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 present, the description carries the burden of safety disclosure. '读取' clearly signals a read-only operation, and the explicit statement that it will not expand submenus preempts a common side-effect concern. It does not describe output shape or other side effects, but for a read-only composite this is strong disclosure.

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?

Two tight sentences with no filler: the first lists what the tool reads, the second gives usage and a key limitation. Information is front-loaded and every clause 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 has no annotations, no output schema, and only a minimally documented parameter, so the description must be self-sufficient. It covers the returned fields, when to use, and a limitation, but it leaves historyLimit unexplained and does not describe how the composite result is structured. It is adequate but has 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?

The schema has 0% description coverage and the tool description never mentions historyLimit. '少量可见历史摘要' hints at a limited history summary but does not explain that the parameter controls the number of history items or how the default/min/max apply. The parameter name and constraints are self-evident, but the description does not add the needed meaning.

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 ('读取' / read) and enumerates the exact resources returned: current mode, model, thinking strength, temporary state, and a small visible history summary. It also distinguishes itself from sibling status/selection tools by noting it aggregates multiple state reads and does not expand submenus.

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 explicitly says to use the tool 'when a comprehensive pre-check is really needed' and to avoid calling multiple status tools in sequence, which names the main alternative. It notes the tool does not expand model/thinking-strength submenus, but it does not name a specific sibling tool or explicitly state 'do not use when only one status is needed.'

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 clearly discloses read-only behavior, local scope, and that it does not access the ChatGPT webpage. It could add detail about return values or error behavior, but the core safety-relevant behavior is transparent.

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 compact sentence states the action, scope, and an important exclusion. Every phrase adds value, and the most important 'read-only local' information is front-loaded.

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 zero-parameter read-only status tool with no output schema, the description adequately identifies what is read and what is deliberately avoided. It does not specify the exact return shape, but the simplicity of the tool makes this a minor gap rather than a critical omission.

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 tool has zero parameters and the input schema is fully covered by its empty properties definition. The description appropriately adds no parameter detail because none is needed.

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 '读取' (read) and names the concrete resources: local safety circuit breaker and unconfirmed generation task status. It also explicitly states it does not access the ChatGPT webpage, which helps distinguish it from web-facing siblings.

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 conveys when the tool is relevant: when you need local breaker/task status without touching the web. However, it does not explicitly name alternatives or list conditions for choosing this tool over siblings like chatgpt_status or chatgpt_network_diagnostics.

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?

Since no annotations are provided, the description carries the burden of behavioral disclosure. It clearly states that the tool only clears local state and does not access the web, which is valuable behavioral context. It also emphasizes the safety precondition of user confirmation. It does not detail side effects or response behavior, but for this simple local utility the key traits are covered.

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, tightly scoped sentence that front-loads the essential condition and clearly states the action. Every word earns its place; there is no redundant or vague filler.

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 single-parameter, low-complexity tool, the description provides enough context: what it does, when it should be used, and a key behavioral guarantee. The only minor gap is lack of detail about the operation's result or side effects, but that is not critical for this local clearing 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 100%, so the schema already documents the parameter adequately. The description reinforces that 'confirmed' must represent user confirmation, but it does not add significant meaning beyond the schema. Baseline 3 is appropriate.

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 ('清除'/clear) and a specific resource ('本地安全熔断'/local safety circuit breaker), making the tool's purpose unambiguous. It also adds the key condition that this happens only after user confirmation. This clearly distinguishes it from siblings like chatgpt_circuit_breaker_status, which reports status rather than clearing it.

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 explicitly states when to use the tool: only after the user has manually confirmed the ChatGPT rate-limit prompt has disappeared. It also clarifies that it does not access the web, which implies it is not a network-testing tool. However, it does not name specific alternatives or provide explicit 'when not to use' guidance beyond the confirmation condition.

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 burden of explaining behavior. It clearly states the core effect—closing the dedicated resident browser—and limits usage to explicit requests. However, it does not disclose potential side effects such as session loss, whether the browser will restart automatically, or impact on ongoing operations.

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 sentence with no filler. It communicates the action and the usage condition in two short clauses, earning every word.

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?

This is a low-complexity tool with no parameters and no output schema. The description gives enough context for an agent to decide when to call it. It could mention post-conditions or return behavior, but for a simple close action, the current description is largely complete.

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 tool has zero parameters, which warrants the baseline 4. There are no parameter semantics to clarify, and the schema already fully documents the empty parameter set.

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 ('明确关闭') on a specific resource ('ChatGPT MCP 的专用常驻浏览器'), making the tool's purpose clear. It does not explicitly compare itself with the sibling chatgpt_browser_lifecycle, so it loses the top score for sibling differentiation.

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 gives an explicit invocation condition: only call when the user explicitly requests closing the browser ('仅在用户明确要求关闭时调用'). This is good when-to-use guidance, but it does not mention alternatives or explicitly state what not to use it for, so it falls slightly short of a 5.

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?

未提供任何注解,描述承担全部行为披露责任。第二句披露了一个有用的行为特征(默认不为状态展示额外展开高级菜单),表明该工具避免触发多余 UI 操作。但未说明无会话时的失败行为、是否绝对只读、是否会等待新回复等情况。有披露但覆盖不完整。

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?

两句简短描述,核心目的前置在第一句,第二句补充关键默认行为,无冗余内容。结构紧凑且信息密度合理。

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?

工具本身简单(1 个可选参数,无输出 schema),描述覆盖了主要功能和一项默认行为。但由于没有输出 schema,描述未说明返回值的具体形态;也未提及前置条件(需要存在活动会话)以及与发送类工具的时序关系。对简单只读工具而言基本够用,但仍有明显信息缺口。

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 描述覆盖率为 100%,includeSettings 参数已有清晰说明,基线为 3。描述第二句补充了默认行为与参数的关系(includeSettings=false 时不展开高级菜单),与 schema 描述形成互补,但没有超出 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?

描述使用了明确的动词(读取)和资源(当前对话最近一条完整回复和对话状态),能清楚区别于 send/submit/write 类工具如 chatgpt_send_message 和 chatgpt_submit_prompt。不过'对话状态'这一部分与同级工具 chatgpt_status 存在潜在重叠,描述未做区分,因此扣一分。

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?

描述完全没有提供何时使用本工具以及何时改用其他工具的指引。没有提到应在 chatgpt_send_message 之后调用,也没有说明与 chatgpt_status 或 chatgpt_search_history 的取舍条件。第二句只是在描述默认行为,不构成使用场景说明。

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 clearly indicates a non-mutating list operation and discloses the return format, but it does not describe any edge cases, pagination behavior, or the effect of the limit parameter. This is adequate for a simple read-only list operation but lacks depth.

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 core action ('列出...历史对话'), states the filtering option, and lists the return fields. Every word earns its place, with no redundancy or fluff.

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 list operation with two optional parameters and no output schema, the description adequately covers the scope, filtering behavior, and return fields. It could explain how limit applies or what happens when no conversations are loaded, but those are minor gaps. The description is reasonably complete for an agent to invoke 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 coverage is 0%, so the description must illuminate the parameters. The phrase '可按标题筛选' directly clarifies that the query parameter filters by title, which is useful. However, the limit parameter is not mentioned at all, and the query parameter is not explicitly named. The schema already provides limit's default/range, so this is partial compensation.

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: listing ChatGPT side-bar history conversations that are currently loaded, with optional filtering by title. It also names the return fields (title, conversationId, URL), making the tool's function completely unambiguous. While it doesn't explicitly mention sibling tools, the 'currently loaded in sidebar' scope differentiates it from search_history or select_history.

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 a use case (retrieve currently loaded conversations) but provides no explicit guidance on when to choose this tool over alternatives like chatgpt_search_history or chatgpt_select_history. There are no exclusion criteria or references to sibling tools, leaving the agent to infer the appropriate context.

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 carries the behavioral disclosure burden. It explains that the list is dynamic and reflects actual availability, and it explicitly prohibits guessing model names — a meaningful behavioral guardrail. It does not mention read-only status or failure behavior, but for a listing tool the key behavior is well covered.

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 compact and front-loaded: it names the purpose, scope, navigation path, and the critical 'do not guess' rule in two short sentences. Every clause adds decision-relevant information with no filler.

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 zero-parameter list tool with no output schema, the description adequately covers data source, scope, and a key constraint. It does not describe the return shape or failure scenarios, but these are largely inferable from the tool name and listing purpose.

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 tool has zero parameters and the schema description coverage is 100%, so there are no parameter semantics for the description to add. Per the 0-parameter baseline, a score of 4 is appropriate.

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 specifies the action ('列出' / list), the resource (models actually available for the current ChatGPT account), and the navigation source ('当前档位→高级→模型'). It also distinguishes itself from siblings like list_modes and select_model by focusing on model availability rather than modes or selection.

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 the tool should be used when the agent needs to discover which models are actually available for the current account, but it does not explicitly state when to prefer this over chatgpt_list_modes, chatgpt_capabilities, or chatgpt_select_model. There is no 'use when' / 'use instead' 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, the description carries the behavioral transparency burden. It indicates the result is dynamic ('当前可用') and implies a read-only listing operation, but it does not explicitly state that it has no side effects or describe the return format. For a simple list tool the risk is low, but some behavioral detail is still missing.

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 focused sentence that front-loads the operation and resource, with two clarifying examples. No filler or redundant wording.

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 zero-parameter, no-output-schema listing tool, the description covers the essential information: what is listed, where, and with examples. It could mention what the returned values look like or whether it reflects live page state, but it already says '当前可用,' making it reasonably complete.

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 tool has zero parameters, so per the rubric the baseline is 4. There are no parameter details to clarify, and the description does not need to compensate for an input schema gap.

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 verb ('列出'), a precise resource ('ChatGPT 新版页面顶部当前可用的模式'), and gives concrete examples ('聊天' and '工作'). This clearly distinguishes listing modes from listing models or selecting a mode among the sibling 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?

The context is clear: this tool enumerates currently available modes, implying it should be used before selecting a mode. It does not explicitly name alternatives like chatgpt_select_mode, but the usage context is strong enough for an agent to infer when to call 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?

With no annotations provided, the description carries the full burden. It adds meaningful behavioral context by revealing the UI navigation path ('当前档位→高级→思考强度') and noting that only actually available levels are listed, implying account-based filtering. Although it doesn't explicitly declare read-only or state side effects, the verb 'list' strongly implies a safe, non-mutating operation.

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, compact sentence that front-loads the action '列出' and immediately specifies the resource and scope. It includes the helpful page hierarchy without any fluff or repetition, every word contributes meaning.

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 parameterless, no-output-schema list tool, this description is complete. It clearly states what is returned (account-available thinking intensity levels) and provides the UI context. An agent has enough information to invoke the tool and understand the result, even without an output schema.

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 tool has zero parameters and the schema is an empty object (100% coverage), so the baseline is 4. The description correctly avoids inventing parameter details and instead focuses on the output behavior, which is appropriate for a parameterless 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 specifies the exact verb '列出' (list) and the resource '思考强度' (thinking intensity), along with the scope '账号实际可用' (actually available for the account). It also clearly distinguishes itself from sibling tools like chatgpt_select_thinking_level by using 'list' rather than 'select', making the purpose unmistakable.

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 that the tool is meant to view available thinking intensity levels before selection, but it does not explicitly state when to use it or mention alternatives. The sibling chatgpt_select_thinking_level is an obvious counterpart, but the usage context is only inferred, not directly expressed.

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 discloses that the tool is read-only ('读取'), that data is local and desensitized, and explicitly lists what is excluded (query parameters, cookies, request/response bodies). This is meaningful behavioral context beyond what the schema reveals.

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 well-structured sentence, front-loaded with the core action and resource, followed by precise inclusion/exclusion details. Every phrase earns its place; there is no redundant or filler content.

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 read-only diagnostics tool, the description is largely complete: it states the data source, the exact fields available, and the sensitive data that is intentionally absent. It does not explicitly describe the return envelope or ordering, but with one optional limit parameter and a clear field list, the agent can invoke it 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?

The description does not mention the only parameter, 'limit', or explain how it controls the returned records. Schema description coverage is 0%, so the description should compensate but does not. The schema does provide constraints (default 100, min 1, max 500), yet the agent gets no contextual help from the tool description itself.

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 ('读取' / read) and resource ('本地脱敏网络异常记录'), then enumerates exactly which fields are included. This clearly distinguishes it from sibling status/lifecycle tools and leaves no ambiguity about the tool's purpose.

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 clear context: it is for reading local desensitized network anomaly records. However, it does not explicitly say when to use this tool versus alternatives like chatgpt_status or chatgpt_circuit_breaker_status, nor does it state any exclusions or routing conditions.

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 transparency burden. It states that a new normal or temporary conversation is created, but does not disclose side effects such as what happens to the current conversation, whether an unsent draft is discarded, whether authentication is required, or what result/confirmation is returned. This is a notable gap for a browser-mutation 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, front-loaded sentence with no filler. It names the core action first and then compactly lists the optional configuration dimensions. It could include more usage/behavior context, but its size and structure are efficient.

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?

With no output schema and no annotations, a five-parameter mutation tool needs more context than this one-sentence description provides. Missing are what happens to the current conversation, what the tool returns or confirms, and when to prefer this composite tool over the sibling route/select tools. The schema covers parameter syntax but not operational context.

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 100%, so the schema already documents all five parameters. The description only restates the categories (mode, model, thinking strength, capability tier, temporary) without adding meaning beyond the schema, so the baseline score of 3 is appropriate.

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 a specific action ('创建新的...对话') and lists the configurable dimensions: mode, model, thinking level, and capability tier, plus the normal/temporary distinction. It is easy to understand what the tool does, though it does not explicitly contrast itself with sibling tools like chatgpt_route_new_chat or the select_* 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?

The phrase '并可同时选择...' implies this is a combined create-and-configure operation, giving some usage context. However, it does not explicitly state when to use this tool versus alternatives such as chatgpt_route_new_chat followed by individual select_* calls, nor does it mention any exclusions.

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 discloses key behavioral traits: it reuses cached results within 30 minutes, creates a temporary chat and switches to 'Pro' when cache is absent, waits indefinitely, and returns a classification. It also clarifies it does not create a normal conversation, which is important side-effect information.

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 dense sentence that efficiently packs the purpose, caching behavior, fallback steps, and return value. It is well-structured with semicolons and contains no wasteful filler.

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 no output schema and no annotations, so the description must explain side effects and return values; it does so by specifying the returned classification and the non-creation of normal chats. However, it omits potential failure modes or timeout behavior despite '无限等待' (wait indefinitely), leaving some ambiguity.

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 description adds minimal clarification for the 'mode' parameter by mentioning '同模式' (same mode) in the cache context, but it does not define acceptable values or format. The 'force' parameter is already described in the schema, so the description does not improve on it. Given 50% schema coverage, more compensation was needed.

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's function: '执行 Pro 身份探针' (execute Pro identity probe), and details the steps: reuse cache, else create temp chat, switch to Pro, send a specific question, and wait. It differentiates from siblings by noting it does not create normal conversations.

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 its use for verifying Pro identity but does not explicitly state when to use this vs alternative chat tools. It mentions default caching behavior and that it creates a temporary conversation only when no cache exists, but lacks explicit exclusions or alternative tool recommendations.

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 carries the full burden. It adds non-obvious behavior: temporary identity probe, model-specific fallback ('gpt-5.6-pro' vs 'gpt-5.5-mini'), stopping on other answers, and a persistently resident browser. But it omits side effects like discarding the current chat, wait/return behavior, and error cases.

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 dense sentence that front-loads the core action and then details the routing policy. It is reasonably concise for the complexity, though the long run-on structure could benefit from splitting into separate sentences.

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 describing the routing policy, the tool has 7 parameters, no annotations, and no output schema. The description leaves many operational questions unanswered: what 'default tier' is, how files/timeout/wait behave, what the tool returns after sending, and failure handling. It is insufficient for an agent to invoke it confidently.

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 only 43%, and the description fails to compensate. It never mentions parameters such as mode, wait, files, or timeoutMs, and does not explain how requestPro and forceProbe map to the described probe policy. Most parameter semantics must be inferred from schema defaults and names.

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 '按可配置策略新建并发送' (create and send via configurable policy), clearly identifying a combined new-chat and send operation with routing. It distinguishes itself from sibling tools like chatgpt_new_chat and chatgpt_send_message by specifying the policy-driven workflow.

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 explicit context for when to use different paths: ordinary requests use '极高', explicit Pro requests trigger a probe with fallback rules. However, it does not explicitly name alternative tools or state when not to use this tool, so it stops short of a 5.

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 behavioral disclosure burden. It transparently states the UI mechanism (web search-chat interface) and the key behavior of bypassing sidebar loading limits, and it implies a read-only search. However, it does not mention whether a live browser session is required, potential UI side effects, or behavior when there are no results.

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 two concise sentences with no filler. It front-loads the mechanism and scope, then immediately gives the return fields. Every part contributes useful information.

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 two-parameter read-only search tool with no output schema and no annotations, the description covers purpose, mechanism, the key limitation-bypassing behavior, and return values. It lacks explicit alternate-sibling routing and parameter semantics, but the schema handles parameter constraints and the description is otherwise complete.

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 little to explain the parameters. 'query' is only inferable from the search action, and 'limit' is not described at all despite having default/min/max constraints. The description adds minimal parameter-level meaning 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?

The description states a specific action and resource: '查找历史对话' (search historical conversations) via ChatGPT's built-in search-chat UI. It also differentiates itself from sidebar-based siblings by noting it is '不受侧栏当前加载数量限制' (not limited by the sidebar's currently loaded count) and specifies the returned fields.

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 clearly implies when to use this tool: when searching the full history because the sidebar's loaded history is limited. It does not explicitly name an alternative sibling or state when not to use it, but the context is sufficiently clear.

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. It discloses that the tool selects a tier and validates the page display result, which is useful. However, it does not mention side effects, failure behavior for unsupported tiers, or prerequisites such as an open browser or an active ChatGPT session.

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 efficient sentence that front-loads the action and constraint, and it adds the verification behavior without any filler. Every part contributes meaningful information.

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 one-parameter tool, the core behavior and current constraint are covered, and the verification step is mentioned. However, with no output schema or annotations, return values, error behavior, and prerequisites are left unspecified, which an agent may need to know before invoking the 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 100% for the single parameter, and the tool description reinforces the meaning by stating that 'Pro' is the highest/default tier. This adds a small constraint beyond the schema, but it does not elaborate on accepted value formats or edge cases.

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 a specific verb ('选择' / select), a precise resource ('输入框右侧的能力档位' / capability tier beside the input box), and the currently supported value ('Pro'). It is easily distinguishable from sibling tools that list or manage modes, models, or thinking levels, though it does not explicitly name them.

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 that this tool should be used when selecting the answer capability tier and notes that only the highest tier 'Pro' is currently supported. However, it provides no explicit guidance about when to use this tool versus alternatives such as chatgpt_answer_tier_status or chatgpt_select_mode.

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 discloses that the tool opens a conversation and returns the latest answer, but it does not mention side effects such as changing the current browser/conversation state, authentication or network requirements, or failure/not-found behavior.

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?

One compact sentence front-loads the accepted identifiers, states the output, and ends with a useful precedence rule. No filler or redundancy.

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 core open-and-return contract is described, and the output is simple enough that an output schema may not be needed. However, since all parameters are optional in the schema but logically at least one is needed, the description should clarify that requirement and explain behavior when none is supplied or when the conversation is not found.

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 compensates by explaining all three parameters: conversationId, /c/... URL, and unique title. It also gives precedence guidance ('优先使用 ID'). It does not specify exact URL format or whether exactly one parameter must be provided, but it adds meaningful semantics beyond the bare 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?

The description clearly states a specific verb ('打开' / open), a specific resource ('历史对话' / historical conversation), and a concrete output ('返回最近一条回答' / return the latest answer). This distinguishes it from sibling search/list/new 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?

The intended use is inferable: use this tool when you have a conversationId, /c/ URL, or unique title and need to open a historical conversation. However, it does not explicitly compare itself with alternatives like search_history or list_history, and it gives no when-not-to-use 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, the description carries the behavioral burden; it does disclose a post-selection verification behavior. However, it does not mention side effects of switching modes, error/failure behavior, or whether an active browser page is required.

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?

One tightly worded sentence delivers the action, target, examples, and verification behavior with no filler or repetition. The most decision-relevant information is front-loaded.

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 single-parameter tool with no output schema, the combination of description and input schema covers the selection workflow: list modes, provide the displayed mode name, select, and verify. Minor omissions such as failure handling and browser prerequisites are not material for this simple UI 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 coverage is 100% so the baseline is 3, and the description adds practical meaning beyond the schema by clarifying that mode is a top-page label and providing examples. It reinforces the schema's suggestion to use chatgpt_list_modes, helping the agent supply a valid string.

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 action ('选择') and resource ('ChatGPT 新版页面顶部模式'), gives concrete examples ('聊天' or '工作'), and adds a verification step ('校验选中状态'). This clearly distinguishes it from sibling selectors such as chatgpt_select_model and chatgpt_select_project.

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 identifies the relevant domain (top-page modes) and explicitly recommends calling chatgpt_list_modes first, which gives an actionable precondition. It does not explicitly state when not to use it, but the examples and wording make the intended use case clear.

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 carries the full burden. It does disclose that the tool selects a model and then validates the result ('并校验结果'), and it gives the navigation path. However, it does not explain what happens on failure, whether the previous model selection is overwritten, or what the verification returns, leaving some behavioral 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 densely packed sentence that front-loads the action, includes the relevant navigation path, and states the verification behavior. There is no filler or redundant restatement of the tool name.

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 one-parameter tool, the description plus schema provides enough context to call it correctly: what to select, how to identify the model, and the fact that the result is checked. The only notable omission is explicit output or error behavior, but that is a minor gap for this low-complexity selector.

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 100%, so the baseline is 3. The model parameter is already well documented as the full or unique name shown in the model menu, with a recommendation to call chatgpt_list_models first. The tool description adds no additional parameter-level meaning, so it neither needs to compensate nor adds value here.

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: selecting the model used by the current conversation, following a defined UI path, and then verifying the result. It clearly distinguishes this from sibling selectors such as chatgpt_select_mode, chatgpt_select_thinking_level, and chatgpt_select_answer_tier because the target resource is explicitly the model.

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 clearly establishes the context: use this when you need to choose the model for the current conversation. The parameter schema adds sequencing guidance by recommending chatgpt_list_models first. It does not explicitly name alternative tools or exclusions, but the model-specific wording makes the intended use obvious among the sibling 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. It does disclose that the tool selects the level and then verifies the displayed result, which adds behavioral insight. However, it does not mention side effects, possible failure modes, or whether the page must already be in a particular state, so transparency 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 concise sentence that front-loads the core action and adds the verification step. Every clause earns its place; there is no repetition or filler.

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 single-parameter UI action with no output schema, the description plus schema is nearly complete: it states the action, the verification behavior, and how to determine the value to pass. It does not specify return/error details, but the tool's simplicity limits the impact of that omission.

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 100%, and the schema already explains that thinkingLevel should be the displayed name or a numeric string for slider controls, and recommends calling chatgpt_list_thinking_levels first. The main description adds no parameter-level meaning beyond the schema, so the baseline score of 3 is appropriate.

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 ('选择' / select) with a clear resource ('ChatGPT 网页当前对话的思考强度' / the current conversation's thinking level on the ChatGPT web page) and adds verification behavior ('并校验页面显示的结果'). This clearly distinguishes it from sibling tools like chatgpt_list_thinking_levels, chatgpt_select_mode, and chatgpt_select_model.

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 parameter description provides explicit guidance to call chatgpt_list_thinking_levels first and explains when a numeric string is acceptable (when the control is a slider). It does not explicitly state when not to use this tool versus select_mode/select_model, but the context is clear enough for correct usage.

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 discloses important behavioral traits: Pro tier or model names containing 'Pro' trigger infinite waiting, normal tiers use timeoutMs, and files are only sent when explicitly requested. It also reveals that the tool can start or continue conversations. It omits return format and failure modes, but the added details are meaningful.

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 sentences, front-loaded with the composite-tool claim, followed by a concise capability list and two critical behavioral caveats. Every clause earns its place; no redundant wording.

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 10 parameters and no output schema, the description covers core parameter semantics and key behaviors, but it omits the structure of the returned answer, the exact effect of wait=false, prerequisites, and error/edge cases. It is adequate for basic usage but not fully complete for a complex composite 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 coverage is only 10%, so the description carries the burden of explaining parameters. It successfully maps mode, model, thinkingLevel, answerTier, temporary, newChat, prompt, files, and timeoutMs through the capability list and the Pro/timeout/files caveats. The 'wait' parameter remains under-explained, but overall the description adds substantial semantic context.

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 '组合工具' (composite tool) and lists a full range of capabilities: new/continue chat, mode/model/thinking/tier selection, temporary chat, file upload, prompt writing, sending and receiving answers. This clearly specifies the tool's scope and distinguishes it from the granular sibling 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?

The '组合工具' label implies this is the one-stop tool, and the listed capabilities provide context, but the description never explicitly states when to use this versus the individual chatgpt_* sibling tools, nor does it give exclusions or alternative routes. Guidance is implied, not explicit.

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 behavioral burden. It discloses that the tool toggles temporary mode, validates through page state, and may open a new conversation—useful side-effect information. It does not detail all side effects, but the disclosed behavior is meaningful and non-obvious.

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 two short sentences with no filler. It front-loads the action and target, then adds validation behavior and a side-effect warning; every clause 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?

For a simple one-boolean toggle, the description covers what the tool does, the scope (new conversations), how it validates, and a key side effect. Since there is no output schema, that absence is not a gap. It does not explain the exact meaning of 'temporary mode' relative to other modes, but this is likely sufficient for agent selection and invocation.

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%, but the single boolean parameter 'enabled' maps naturally to the description's '开启或关闭' (turn on/off). The description thereby supplies the semantic meaning of the parameter without repeating the schema. It could be more explicit by naming the parameter, but the behavior clearly implies its role.

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 a specific action—turning temporary conversation mode on or off for new conversations—with an explicit resource target. It reads as distinct from sibling toggles such as select_mode or new_chat, though it does not explicitly name or exclude siblings.

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 some context by saying it applies to new conversations and that switching may open a new chat, but it does not explain when to use this tool versus alternatives like chatgpt_select_mode or chatgpt_new_chat. No when-to-use or when-not-to-use 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 available, the description carries the burden of behavioral disclosure. It does reveal a default behavioral detail (不展开高级菜单) and lists what is inspected, but it stops short of explicitly stating read-only/no side-effect behavior or what the returned status contains.

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?

Two short sentences carry the tool's scope, usage restriction, and default behavior with no filler. The most decision-relevant guidance ('only call when diagnosing') comes first.

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 low-complexity optional-parameter status tool, the description covers purpose, invocation timing, and default behavior. It does not define the output format, but no output schema exists and the status scope is enumerated; the remaining gap is minor.

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 100% for the single includeSettings parameter, and the description's mention of default non-expansion of the advanced menu effectively restates that schema default. No meaningful semantic detail is added 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?

The description names a specific action (检查/check) and the exact scope of what is inspected: dedicated browser, login, current conversation, mode, and temporary conversation state. It is clearly about status inspection, but it does not explicitly contrast itself with sibling diagnostic tools such as chatgpt_network_diagnostics or chatgpt_circuit_breaker_status.

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 explicitly states when to call the tool ('仅在诊断或确需状态时调用') and provides a when-not ('正常发送无需预先调用'). This gives clear context and exclusion, but it does not name sibling alternatives for other diagnostic checks.

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?

Without annotations, the description discloses a valuable behavioral detail: infinite waiting for Pro tiers and timeoutMs only for normal tiers. However, it omits other behavioral aspects such as return value, error handling, or the exact behavior when wait=false.

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 two sentences, front-loaded with the action, and every sentence adds meaningful information. It is concise without redundancy.

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 absence of annotations and an output schema, the description leaves important gaps: it does not explain return values, the behavior when wait=false, or how 'Pro' status is determined. For a mutation tool with two parameters, this is incomplete.

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 no descriptions for the two parameters, and the description only enriches timeoutMs by explaining it applies to normal tiers. The wait parameter's semantics (e.g., whether it controls waiting at all) are not clearly addressed, leaving a gap for one of the two 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 tool sends the prompt currently in the input box and optionally waits for ChatGPT's response, using a specific verb and resource. It distinguishes from write_prompt (which writes) but does not explicitly differentiate from the similar sibling send_message, so sibling differentiation is incomplete.

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 the tool should be used after a prompt has been written to the input box, but it provides no explicit guidance on when to use this tool over alternatives like send_message or get_latest_response. No exclusions or preferred contexts are stated.

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 carries the behavioral burden and discloses key traits: upload only, no automatic prompt submission, and the requirement for absolute paths. It states an authorization constraint ('explicitly authorized by the user'), which goes beyond the basic operation, though it omits details like file-size limits or error behavior.

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 short sentences, each carrying distinct information: the operation, the path constraint, and a critical behavioral caveat. There is no filler or repetition.

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 single-parameter upload tool, the description covers the purpose, invocation constraint, and a key consequence (no prompt is sent). It is complete enough for an agent to select and call it correctly, though the lack of an output schema means return/error behavior is not described.

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% and the schema already describes 'files' as a list of absolute paths. The description reinforces this requirement and adds context about local/user-authorized files, but it does not materially extend the parameter semantics beyond what the schema already provides.

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 verb ('upload'), a precise resource ('current ChatGPT conversation'), and the scope ('local files explicitly authorized by the user'). This distinguishes it from sibling tools like chatgpt_add_file_to_project, which targets projects rather than the active conversation.

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 clearly frames when to use the tool: when the user has authorized local files and the target is the current ChatGPT conversation. The caveat 'will not automatically send a prompt' signals that a separate prompt-sending tool is required if a message must follow, although it does not explicitly name the alternative.

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 carries the burden and does disclose the key behavior: the tool writes without sending. However, it does not mention that it overwrites existing draft text by default unless append=true, though that is already captured in the append parameter schema. Adequate but not richly transparent.

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 sentence that front-loads the core action and non-send behavior, then gives the intended use case. No filler or repetition.

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 two-parameter tool with no output schema and no annotations, the description plus schema covers the main workflow and the overwrite/append distinction. It lacks explicit notes on return values, errors, or browser-state requirements, so it is good but not fully complete.

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 50%: append is well described, and prompt is self-explanatory via its name and minLength constraint. The description itself adds no parameter-level meaning beyond what the schema provides, which is acceptable but not exemplary.

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: writing a prompt into the ChatGPT web input box without sending it. The explicit '但不发送' (but does not send) differentiates it clearly from siblings like chatgpt_submit_prompt and chatgpt_send_message.

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 a concrete usage scenario: suitable for uploading files first or for letting the user review the draft before sending. It does not explicitly name alternative tools or state when not to use it, so it falls short of a 5.

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