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

Annotations already declare readOnlyHint=false, destructiveHint=false and idempotentHint=true, so safety is covered. The description adds the meaningful side effect (moving the window to the system foreground, i.e. it changes OS focus) and hints at a return value (focused window information), but does not cover failure modes such as no MiniMax window existing or how the returned focus info is shaped (no output schema).

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 action and resource and appends the return information; there is no filler or redundant restatement of the title.

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, non-destructive, idempotent activation tool with annotations carrying the safety profile, the description covers action, effect, and a rough return hint. It is slightly short of full completeness because the returned 'focused window info' is never characterized and edge cases are unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is no parameter meaning to add; the baseline for a no-param tool applies. The description correctly implies no input 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?

States a specific verb (唤醒/activate, bring to system foreground) and a specific resource (the MiniMax window), plus a return payload (focused window info). It is clearly distinguishable from siblings like minimax_windows (which lists windows) or minimax_screenshot, though it never names an alternative.

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 only implied: an agent can infer it should call this when the MiniMax window is not focused or needs to be brought forward. There is no explicit when-to-use/when-not-to-use guidance, no mention of prerequisites, and no pointer to sibling tools such as minimax_windows for discovering the window first.

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 already flag destructiveHint=true and readOnlyHint=false, and the description adds genuinely useful behavioral context beyond them: the tool is two-stage with a default dry-run and an explicit force gate before real submission. It stops short of describing what side effects persist or what the preview returns, keeping it at a 4.

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 clauses, zero filler, and the critical safety rule (the preview/force gate) is front-loaded immediately after the purpose statement.

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 destructive, 6-parameter tool with low schema coverage and no output schema, the description covers the riskiest dimension (how to actually commit) but says nothing about how selections map to steps, what requestId identifies, or what a preview response looks like, leaving real 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 coverage is only 33% across 6 parameters, so the description needs to compensate. It does explain the most consequential parameters (preview default true, force default false, and their conjunction), but requestId, id alias, selections, and at remain undocumented in the description, so compensation is partial.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource: '提交问卷回答' (submit survey answers), which tells an agent exactly what the tool does. It does not name the closest sibling (minimax_draft_answer) or explain how it differs, so it falls short of a 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?

It states the operative precondition clearly: preview=true is the default and only previews the click plan, while actual submission requires preview=false AND force=true. That is concrete when/how-to-use guidance, but it gives no exclusions or alternatives (e.g., when to use minimax_draft_answer or minimax_click instead).

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?

The annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false. The description adds real content beyond those fields by stating exactly what the mutation does: it triggers generation or advances rounds in the target sessions. It does not add much detail about the effects of running repeatedly, but because the annotations already flag the operation as destructive, these gaps are minor.

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?

This is a single compact sentence that leads with the resource and the trigger condition, and the parenthetical explains the mechanism efficiently. It is dense but not padded.

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 three-parameter mutation tool with no output schema, and it has annotations but covers only the safety profile. The description is solid on what the tool does, but it does not say what a scan returns when dryRun=true or what the result looks like after a batch resume, which is the main remaining 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 100%, so the schema already documents all three parameters, including that dryRun defaults to true. The description adds no meaning beyond what the schema provides for limit, dryRun, or sessionId, so the 3 baseline applies.

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 (断点续传 / auto-resume) and a specific target (sessions suspended with quota error code 2056), and it explains the two distinct mechanisms: pressing the play button for native conversations and advancing one round for Bot conversations. That is enough to distinguish it from siblings such as minimax_pending or minimax_get_result, even though it does not name those 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 usage context is explicit: use it for sessions that are suspended because of quota exhaustion (2056) after the quota has been restored. The description gives no guidance on when not to use it, and it does not say where to check for suspended sessions first (for example, by using minimax_pending).

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?

The annotations explicitly set destructiveHint=true and idempotentHint=false, yet the description never explains what is destructive: whether sending is irreversible, whether cancel terminates live work, or what resume_pending restarts. Two of the four enum actions are completely undisclosed behaviourally, so the description adds almost nothing to the safety profile the annotations already flag.

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 front-loaded sentence that wastes no words and puts the resource first. It is efficiently written, though its brevity comes partly from omitting information an agent genuinely needs.

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 four-parameter tool with no output schema and a destructive write path, the description covers the send and read cases but leaves the cancel and resume_pending actions entirely unexplained. An agent could call it for the documented modes, but would be guessing on the two remaining enum values and on what destructive side effects to expect.

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 defines text, limit, action, and chatId, and the baseline is 3. The description reinforces the chatId targeting (group or Bot) and the read-latest-conversation behaviour of limit, but adds no meaning for the cancel and resume_pending enum values beyond what the schema field names 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 names a specific resource (MiniMax Bot team, a group chat, or a Bot) and two concrete verbs (send instructions, read the latest conversation). This is clear enough that an agent can tell what the tool does, but the description does not differentiate it from the sibling tool minimax_send_message, and it never acknowledges that the tool also supports cancel and resume_pending actions.

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 two modes, sending instructions and reading history, but gives no criteria for choosing between them, no mention of the cancel or resume_pending actions that the action enum offers, and no guidance on when to prefer this tool over functionally adjacent tools such as minimax_send_message or minimax_read_session.

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 already declare readOnlyHint, idempotentHint, and destructiveHint=false, so "纯读数据库" largely restates structured data. What the description genuinely adds is the triage ordering of results by urgency, which is real behavioral disclosure. It reveals nothing about the returned shape (fields per session, ordering ties) or about how thresholds interact with the ranking.

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 clauses, purpose and priority ordering front-loaded, nothing padded. Minor waste in "纯读数据库", which duplicates the readOnlyHint annotation rather than adding new 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 read-only snapshot tool with no output schema, an agent still cannot tell what one entry in the snapshot looks like (session id, state, last activity, message excerpt) or how limit interacts with the priority ranking. Everything needed to call it is present; what to expect back is not.

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 all four threshold parameters carry their own meaning and the baseline is 3. The description adds nothing about how activeMinutes, stalledMinutes, and finishedMinutes map onto the four priority buckets, which is the one place extra meaning would have helped.

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 output — a situation snapshot listing sessions that need attention — and states the exact priority ordering (等你决定 > 报错 > 卡住 > 运行中). That ordering distinguishes it from plain list or search siblings even though no sibling is named. It stops short of 5 because the resource being summarized (sessions) is only implicit in the word 会话.

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?

"巡检首选" gives a positive when-to-use signal: routine inspection / patrol. There is no explicit when-not guidance and no named alternative, so an agent must infer whether minimax_pending, minimax_list_sessions, or minimax_status is the better choice for a task other than a general sweep.

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?

The annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the description carries a lower burden. Adding that this is a fallback path (non-CDP) is useful context, but the description does not say what happens when the coordinates fall outside the screen or what the call returns.

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 front-loaded sentence pairs the action with the coordinate semantics and ends with the mode restriction. Nothing is redundant, and the content reads in the right order.

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 three-parameter UI action with annotations and no output schema, the essentials are present: what it does, where it acts, and when it applies. The gaps are the button parameter semantics and any error or out-of-bounds behavior.

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 descriptions cover 0% of the parameters, but the description usefully clarifies that x and y are absolute screen coordinates, not window-relative coordinates. It says nothing about the button parameter or its default, so it only partly compensates for the coverage 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 action (dispatch a mouse click) and a specific target (absolute screen coordinates), so it is distinguishable from reporting-type siblings. It does not name minimax_click_text, the nearest sibling that clicks by text, so it falls short of full discrimination.

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 clause 'only used in non-CDP fallback mode' gives a real precondition for use. It does not explicitly compare against alternatives such as clicking by text or using CDP mode, so the guidance remains implied rather than spelled out.

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?

The description adds real value beyond the annotations by disclosing the resolution mechanism (prefers CDP DOM direct connection) and the robustness property (works despite window occlusion and scaling). However, it omits what happens when CDP is unavailable, whether the click requires the window to be active, and whether multiple matches cause ambiguity; the annotations only give a generic non-destructive mutation profile.

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 with zero filler; the purpose is front-loaded ahead of the mechanism note. Nothing is repeated and every clause carries 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 five-parameter tool with a nested region object, no output schema, and only 40% schema coverage, the description leaves meaningful gaps: no return-value or failure indication, no multiple-match disambiguation, and no fallback path when CDP is unavailable. The mechanism disclosure partly compensates but does not make the definition self-sufficient.

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 only 40%, and the description explains none of the five parameters: it does not explain 'mode' matching semantics, how 'index' resolves multiple matches, that 'query' is an alias of 'text', or what 'region' restricts. The schema does carry descriptions for text and query, but mode, index, and the nested region object are undocumented in both places.

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 and resource ('查找并点击指定文本（按钮/菜单项）') and implicitly separates itself from coordinate-based minimax_click and read-only minimax_find_text by describing a text-targeted click. It never names those siblings explicitly, so the differentiation must be inferred from context.

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 only implied: an agent can infer it should be used when the target text is known but coordinates are not. There is no explicit when-not guidance, no mention of when to prefer minimax_click or minimax_find_text, and no stated preconditions such as a session being active.

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?

The clause '只读无副作用' (read-only, no side effects) merely restates annotations that already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so it adds no new behavioral information. The description says nothing about what a draft answer looks like, whether generation is costly or slow, or whether drafts are persisted anywhere — the details an agent would actually need.

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 tight sentence with the action front-loaded and zero filler. It is appropriately sized for what it conveys, though the brevity comes at the cost of the missing differentiation and output context noted elsewhere.

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 single-parameter read tool this covers the basics, but with no output schema the description should at least indicate what is returned (draft text, number of suggestions, whether it is inline or stored). The drafting-versus-answering boundary with minimax_answer_question is also left unresolved.

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 100% schema description coverage on both parameters (including the note that id is an alias of requestId), the schema already carries the parameter semantics. The description contributes nothing about which identifier to supply or how to obtain a valid requestId, so baseline 3 applies.

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 gives a concrete verb and resource — generating draft answer suggestions for questionnaires awaiting answers — so an agent can understand the operation without opening the schema. However, it never distinguishes this from the sibling minimax_answer_question, which presumably submits an actual answer, leaving the boundary between drafting and answering implicit.

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 '待回答问卷' (questionnaires awaiting answers) implies a usage condition, but there is no explicit when-to-use, no prerequisite such as first locating a pending requestId via minimax_pending, and no guidance on when to prefer this over actually answering. Usage is inferred rather than 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?

'纯读无副作用' merely restates the supplied readOnlyHint=true and destructiveHint=false annotations, so it earns no extra credit. What the description does add is content-level behavior — the five event states that can appear in the queue — but it says nothing about ordering, whether events are consumed/cleared on read, or result shape.

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: the resource plus its state enumeration first, the safety profile second. No filler, no repetition of the tool name, and the key identifying 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 two-optional-parameter read tool with no required args this is close to adequate, but with no output schema the description should say what an event entry looks like (timestamp, session/task reference, message) so the agent knows what it will get back. Pagination and whether events are repeatable across calls are also unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50% (only 'since' is documented, as 起始时间戳; 'limit' has bounds and a default but no description). The description adds no meaning for limit or since beyond the schema, but with only two simple optional parameters the baseline of 4 applies and the gaps are minor.

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 specific verb (读取) and resource (巡检事件队列) and enumerates the event states it surfaces (finished/error/question/stalled/task_failed), which lets an agent distinguish it from minimax_pending or minimax_tasks. It does not explicitly name which sibling to use instead, so it stops short of full 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 list of event categories implies the scenario (polling inspection progress/failures), but there is no explicit 'use this when…' statement, no when-not guidance, and no pointer to alternatives such as minimax_tasks or minimax_pending.

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 already cover read-only, idempotent, non-destructive behavior, yet the description still adds real value beyond them: the DOM-first/OCR-fallback resolution order tells the agent results may come from two different sources with different reliability, and that coordinates are returned. It does not mention what happens when no match is found or how multiple matches are ordered.

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 clauses, front-loaded with the action and the return value, with the mechanism in parentheses and the read-only marker last. No filler, though the telegraphic style leaves no room for the parameter guidance that is missing.

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 6-parameter tool with a nested region object and no output schema, the description covers purpose, mechanism, and the fact that coordinates are returned, which is the minimum an agent needs to call it at all. The parameter surface and no-match behavior remain unexplained, leaving 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 coverage is only 33% across 6 parameters including a nested region object, and the description explains none of them: the mode enum (contains/exact/prefix), index for disambiguating multiple matches, region scoping, or refresh are all left undocumented. It also does not clarify the text/query aliasing, which is the kind of thing a description should disambiguate.

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 specific verb and resource (find text elements in the UI) and adds the return value (coordinates) plus the resolution mechanism (CDP DOM first, OCR fallback). It does not name the closely related sibling minimax_click_text, so an agent must infer the locate-vs-click split itself.

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 trailing '只读' implies this is the locate-only step rather than the clicking step, which is useful context against minimax_click_text, but no explicit when-to-use, when-not-to-use, or 'then call click_text with these coordinates' routing 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds that it looks at only the latest round and reports completion status plus final output, which is useful context. However, it does not explain the polling/waiting behavior implied by timeoutSeconds, nor what happens when the task is not yet complete — notable given idempotentHint=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?

A single compact sentence with the resource and outcome stated up front and no filler. It is efficient, though its brevity is part of why guidance and polling semantics are missing.

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 four optional parameters, no required fields, and no output schema, the description should at minimum clarify what is returned (completion flag plus output) and how timeoutSeconds affects the call. It states the former implicitly but leaves the waiting behaviour and the incomplete-task case unexplained, so it is only adequate.

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 every parameter is already documented in the schema, making the baseline 3. The description's '最近一轮' loosely relates to the sinceMessageId baseline but adds no syntax or semantics beyond the schema. No extra meaning is contributed.

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+resource: fetching the most recent round of task execution results for a given session, plus judging completion and extracting the final output. That is materially more informative than the bare 'get result' title. It stops short of naming a sibling (e.g. minimax_read_session, minimax_status, minimax_watch) that an agent might confuse it with.

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 explicit when-to-use or when-not-to-use guidance. The phrase '判断是否完成' implies this is the tool used to poll for completion, but the description never says that or points to alternatives such as minimax_watch or minimax_events. The agent must infer the routing decision from the name alone.

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 already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=false, so the safety profile is covered. The description adds no behavioral context beyond the bare action — it does not say which window or session receives the keypress, whether focus must be established first (e.g., via minimax_activate), or what happens if the target is not focused.

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 short sentence with the action front-loaded and examples attached; there is no filler. It errs toward under-specification rather than verbosity.

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 keyboard-injection tool inside a multi-window browser automation suite, the crucial missing piece is the target: nothing states that the key is sent to the currently active window or what the caller must do first. With no output schema, the description should have said at least roughly what a successful dispatch returns or how failures surface.

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 both the key name and the modifiers array are already documented in the schema. The 'cmd+n' example loosely illustrates how the two parameters combine, but adds no new syntax or constraint meaning, so the baseline 3 applies.

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 (派发) with a specific resource (keyboard single key or shortcut combination) and gives two concrete examples (Return, cmd+n). It does not name or differentiate itself from near siblings like minimax_type or minimax_click_text, so it stops short of a 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?

There is no guidance on when to use this instead of the sibling text-entry tool minimax_type, or when a shortcut should be a single key vs. a modifier combination. An agent must infer the boundary between typing text and dispatching a keypress entirely on its own.

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 already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's added value is the ordering rule (last-active descending) and the shape of what comes back (session ID plus index) — genuinely useful since there is no output schema. It stops short of saying how the limited result set relates to the full session list.

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 that front-loads the resource, then ordering, then return content. Nothing is redundant, though the density means key cues such as paging are never surfaced.

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 one-parameter read-only listing tool with full annotation coverage, the description supplies purpose, sort order and return fields — enough to call it correctly. The only real gap is the absence of any routing hint among 26 sibling tools.

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 single optional 'limit' parameter is fully documented with default, min and max, so the baseline of 3 applies. The description adds nothing about truncation or how the 20-item default affects the ordered listing.

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 gives a specific verb and resource ('列出 MiniMax 会话列表') plus the ordering and the returned fields (会话 ID 及序号), so the agent knows exactly what the tool produces. It does not distinguish itself from near-siblings such as minimax_tail_sessions or minimax_pending, which keeps it below a 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?

There is no statement of when to use this tool versus the many alternatives (minimax_read_session, minimax_tail_sessions, minimax_search, minimax_pending). Only the implicit 'list sessions' phrasing hints at a discovery/enumeration role.

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 already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the mutation profile is covered. The description adds that the action navigates the UI to a 'new task view' via CDP DOM or keyboard shortcut, which is modestly useful context, but it never says whether a task is actually persisted, whether repeated calls create duplicates, or what happens if the view is already open.

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 with the action stated first and the invocation hint second – well front-loaded and free of padding. The phrasing is terse to the point of being cryptic about what a 'task' is in this product context.

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 zero parameters, no output schema, and annotations covering the safety profile, the remaining burden is small. Still, the description leaves unclear what a created task contains, whether it returns an identifier, and how the UI-navigation behavior interacts with other tools in the set.

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 takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. No misleading parameter language is present.

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 and resource ('新建任务' – create a new task), which is unambiguous on its own. It does not distinguish this from siblings such as minimax_open_session, minimax_tasks, or minimax_send_message, so an agent must infer which entry point to use.

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 second sentence ('优先通过 CDP DOM 触发或快捷键切换至新建任务视图') describes how to trigger the action mechanically, not when to choose this tool over alternatives. There is no statement of preconditions, no exclusion, and no named sibling for comparison.

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 declare this is not read-only, not idempotent, and not open-world, so the agent already knows it mutates UI state. The description adds useful mechanism detail (sidebar matching, DeepLink), but does not say what happens on failure, whether the previously focused session is disturbed, or what the caller observes afterward.

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 front-loaded sentence with the action first, followed by a parenthetical on matching strategies. Nothing extraneous, though the parenthetical is the only part carrying new information and could have been expanded slightly for clarity.

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 only two fully documented parameters, annotations present, and no output schema, the description is close to sufficient. The remaining gap is behavioral: it never clarifies the session/sessionId alias duality or the outcome of a navigation, which matters because the tool changes UI focus state.

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 both properties are documented in the schema, so the baseline applies. The description adds nothing about the relationship between the required sessionId and the optional session alias, which is the one genuinely confusing part of the input contract.

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?

"在 MiniMax 界面中导航至指定会话" states a concrete action (navigate) on a concrete resource (a session) within a named surface (the MiniMax UI). This distinguishes it reasonably from siblings like minimax_read_session or minimax_list_sessions, though it does not explicitly contrast itself with minimax_activate or minimax_windows.

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 only implied: an agent can infer it should call this to bring a specific session into view. There is no explicit when-to-use, no exclusion telling the agent when to use minimax_activate or minimax_read_session instead, and no mention of prerequisites such as the session existing.

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?

The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered elsewhere. The description adds only that the tool is limited to items awaiting human confirmation or reply — useful scoping detail, but nothing about result ordering, volume, or what a pending item 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?

A single sentence that front-loads the verb and the resources and ends with the scoping qualifier. There is no filler, repetition of the title, or restatement of the 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 zero-parameter, read-only list tool with no output schema, the description conveys the essential shape of what comes back (pending questionnaires and approval cards). It could note how to act on a returned item — presumably via minimax_answer_question or minimax_draft_answer — but nothing critical for invoking it is missing.

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 takes zero parameters, so there is no argument semantics for the description to carry. Baseline 4 applies; the description does not need to explain any inputs.

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 clear verb (查询) and two specific resources (问卷与审批卡片), plus a scope qualifier (等待人工确认或答复). That is enough for an agent to distinguish this tool from the action-oriented siblings minimax_answer_question and minimax_draft_answer, although it never names those siblings directly.

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 the usage condition (a pending item that blocks progress and requires human input), but the description does not state when to call this tool instead of siblings such as minimax_tasks or minimax_get_result, and it contains no exclusions or follow-up 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?

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description need not explain safety. Beyond that it adds nothing behavioral: it does not say how the history is ordered, how pagination via before behaves, whether the sessionId alias conflicts with session, or what happens when an unknown index is given (the tool runs in a closed world).

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, and the core purpose comes first. Every clause carries information, with 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?

This is a five-parameter tool with no output schema, so the description should at least sketch the returned messages and the pagination contract. It covers only the purpose and the session-value format, leaving the return shape and the before/limit interaction to inference.

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 every parameter is documented, and 3 is the baseline. The description does add one thing beyond the schema: it states the ID format (mvs_*) and that a list index is accepted, but it never explains sessionId vs session, or what before anchors to, so it adds little beyond the schema descriptions.

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 concrete verb and resource: read the historical messages of a specified session (读取指定会话的历史消息). That is clear enough to separate this tool from list_sessions or send_message, but it never names its closest siblings (minimax_search, minimax_tail_sessions, minimax_events), so the agent has to work out which one retrieves 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?

There is no when-to-use guidance: nothing says whether to prefer this tool when tailing recent activity or when searching across sessions. The only guidance is what value the session parameter accepts, which is about parameters, not 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?

Annotations already declare idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is largely covered elsewhere. The description adds the useful behavior that a screenshot is captured and an image path is returned, but it does not say where the file is written, whether repeats overwrite the prior file, or what happens if the window is minimized or not found.

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 purpose and followed by the mode options and return value. There is no filler and nothing is buried.

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 tool with six entirely undocumented parameters, no output schema, and a coordinate-based capture mode, the description leaves too much unspecified. An agent cannot tell what x/y/width/height mean, whether they are required for region mode, or how name affects the saved file, which risks malformed calls.

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% across six parameters, so the description is the only place semantics could come from. It explains the mode enum values and hints that name relates to the returned image path, but x, y, width, and height are left completely undefined — no coordinate origin, units, or requirement that they be paired with region mode.

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 and resource ("获取 MiniMax 窗口截图") and scopes it to the MiniMax window, so an agent can distinguish it from sibling action tools like minimax_click or minimax_find_text. It does not explicitly compare itself to the other window-related siblings (minimax_windows, minimax_activate), which keeps it below a 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?

It states the two supported modes (screen and region), which implies when region mode is appropriate, but it never says when to prefer this tool over the other MiniMax capture/inspection siblings, nor what x/y/width/height must be supplied for region mode. Usage is implied rather than spelled out.

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 already declare readOnly=true, idempotent=true, destructive=false and closed-world, so the safety profile is fully covered. The description adds only that results come back as highlighted focused context; it says nothing about ordering, pagination, or what happens when no match is found.

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 tight sentence with the scope and return behavior front-loaded and no filler. It is perhaps too terse for the tool's role as the entry point for cross-session lookup, but nothing is redundant.

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 three-parameter read-only search with full schema coverage and no output schema, this is minimally adequate. The gaps are ordering/pagination behavior and how the highlighted context is structured, which an agent would need to interpret results 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 100%, so query, the q alias, and limit (default 10, max 100, token-saving rationale) are all documented in the schema itself. The description adds no meaning beyond it, which matches the baseline 3 for fully covered schemas.

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 specific verb+resource: full-text search over titles and message content across sessions, plus a note on the return shape (highlighted focused context). It is distinguishable from search-adjacent siblings like minimax_find_text and minimax_list_sessions, 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 only usage signal is the scope word '跨会话' (cross-session), which implies it searches globally rather than within a single session. There is no explicit when-to-use, when-not-to-use, or routing to alternatives such as minimax_find_text or minimax_read_session.

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?

The description adds real context beyond annotations by disclosing an active anti-mistouch guard and that CDP mode bypasses coordinates. However, for a tool annotated destructiveHint=true, it never explains what the send can disrupt (e.g. interrupting an in-progress generation or overwriting existing input), so the destructive profile remains unexplained.

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 clauses, front-loaded with the core action and followed by the two most decision-relevant facts. Dense and free of padding, though the semicolon chain is terse enough that intent requires some inference.

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 9-parameter destructive write tool with no output schema, the definition covers the essentials via schema and annotations but leaves gaps: the layout enum is unexplained, the guard/quietSeconds interaction is only in the schema, and return 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 89%, so the schema already documents most parameters including at, send, force, preview, and quietSeconds. The description only restates the send flag and notes that coordinates are auto-resolved in CDP mode, adding little beyond structured fields.

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 specific verb and resource: input or send a message into the current session. The clause about CDP direct connection not needing coordinates implicitly separates it from coordinate-based siblings such as minimax_click or minimax_type, but no sibling is named outright.

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?

Useful implied guidance comes from 'send=true triggers sending', which tells the agent the fill-only vs submit distinction, but there is no explicit when-to-use/when-not-to-use or comparison against alternatives like minimax_type, minimax_draft_answer, or minimax_new_task.

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 already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered and the description does not contradict it. The description adds value beyond the annotations by disclosing the scope of returned information (DB connection, session count, message totals, background tasks), which no output schema provides. It stops short of noting cost, freshness of the counts, or behavior when the database is unreachable.

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 front-loaded sentence with the resource named first and the returned fields enumerated after a colon. Every clause carries information; there is 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?

For a zero-parameter, read-only status tool with no output schema, the description covers the essential question an agent would have: what information comes back. Its only shortfall is not clarifying how this overview differs from the narrower sibling tools that also surface session and task data.

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 takes zero parameters, so the baseline is 4 and there is no parameter semantics the description could add. Nothing in the text misdescribes the input contract, and the empty schema is consistent with a parameterless status probe.

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 gives a specific verb ('获取' / get) and resource ('MiniMax Code 本地状态' / local status), then enumerates the concrete contents: database connection, session count, total messages, and background tasks. An agent can tell this is a health/overview probe rather than a data-fetching tool. It does not explicitly distinguish itself from siblings like minimax_tasks or minimax_list_sessions, which overlap on the 'background tasks' and 'session count' facets.

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 only implied: the word '状态' (status) suggests a diagnostic/health-check context, but there is no explicit statement of when to call this versus minimax_tasks, minimax_list_sessions, or minimax_pending. No prerequisites or exclusions are given. An agent must infer the use case from the enumerated fields.

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?

The annotations declare readOnlyHint=false and idempotentHint=false, but the description does not say what happens to partially produced output, whether the session remains resumable, or what the response reports. destructiveHint=false combined with a "terminate" verb is at minimum worth explaining, and the description adds nothing about it. The only behavioral value added is the scoping to currently running tasks.

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 short sentence with no filler, and the operative scope (currently generating or running) is front-loaded. It is efficient, but the brevity is partly achieved by omitting necessary detail rather than by tight editing.

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 mutation tool with no output schema, no annotations covering side effects, and an undescribed `force` flag, the definition is under-specified. An agent cannot predict the effect on a running session or decide when force should be set to true.

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 documents session and sessionId (alias) but leaves `force` completely undescribed, and the tool description never mentions it either, so the highest-stakes parameter is undocumented in both places. The description adds no meaning to any of the three parameters beyond what the schema already says.

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 gives a specific verb (终止) and a specific target (当前正在生成或运行中的会话任务), so the agent can tell it is not a read or navigation tool like minimax_read_session or minimax_tail_sessions. It does not name any sibling as an alternative or complement, so differentiation relies on inference from the verb.

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?

"正在生成或运行中" implies the trigger condition: the tool is relevant only while a task is in flight. There is no guidance about what to do when no task is running, whether the call is safe to repeat, or which sibling to use instead (e.g. minimax_get_result to collect output, minimax_auto_resume to restart).

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?

The annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world scope, so the safety profile is covered. The description adds almost nothing beyond that: it does not say how "最近" is ordered (last activity vs creation), whether tails are truncated, what the result shape is, or what "快速" costs relative to a full read. Only the lightweight-sampling intent is new 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?

One short sentence, front-loaded with the action and immediately followed by the use case; no filler. It is arguably over-terse for the amount of ambiguity it leaves, but nothing in it is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple (2 optional parameters with defaults, no output schema, full annotation coverage), so most of the burden is already carried by structured fields. However, an agent still cannot tell from the description how sessions are ranked as "recent" or whether the tails are complete messages or truncated previews, which matters for a sampling tool. Adequate but with a clear 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 100% (count = 会话数, perSession = 每会话消息数) with defaults, min and max all declared, so the schema does the heavy lifting. The description's "N 个会话" and "末尾消息" merely restate those parameters at a high level and add no format, ordering, or edge-case semantics. Baseline 3 is the right level.

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?

"快速采样最近 N 个会话的末尾消息" names a specific verb (采样), a specific resource (会话末尾消息), and a scope (最近 N 个). An agent can distinguish this tail-sampling operation from minimax_read_session or minimax_list_sessions. It stops short of 5 because it never names a sibling or states the distinction 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?

"用于并发任务巡检" gives one concrete usage scenario, which is real context, but there is no statement of when to prefer this over minimax_read_session / minimax_list_sessions / minimax_pending, nor any exclusion. Usage is implied rather than specified.

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 already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered and the description does not contradict it. The definition's one real contribution is the status value domain (running/succeeded/failed/canceled), which matters behaviorally. It says nothing about ordering, default scope of returned tasks, or truncation 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 short sentence, front-loaded with the verb and resource, and the parenthetical status list is compact. Nothing is wasted, though the extreme brevity leaves room that could have been spent on routing guidance.

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?

There is no output schema, yet the description never indicates what a task record looks like (id, name, timestamps, status) or how many are returned relative to limit. For a read/list tool where the caller must know what comes back to interpret the result, this is a meaningful 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 coverage is 50%: status has only '按状态过滤' and limit has no description at all. The description compensates partly by enumerating the four valid status strings, which the schema does not do (no enums declared). It still adds nothing about limit's effect, default of 20, or ordering.

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?

It gives a verb+resource (查询 / MiniMax 后台任务状态) and enumerates the possible status values, which is helpful. But it is ambiguous whether this lists tasks or fetches one task's state, and it draws no boundary against siblings such as minimax_status, minimax_pending, and minimax_get_result, which sound like they answer overlapping questions.

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 when-to-use guidance, no prerequisites, and no named alternative. With so many sibling tools covering status, pending work, and results, the definition should say which situations select this tool rather than minimax_pending or minimax_get_result.

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 already declare this is a non-read-only, non-idempotent, non-destructive write. The description adds genuinely useful behavioral context beyond them: it prefers a CDP direct connection and does not require the target window to be foregrounded. It says nothing, however, about what happens when no rich text box is focused or whether existing content is replaced or appended.

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 with the action stated first and the transport detail second; nothing is padded. The CDP sentence is implementation-flavored but still operationally relevant, so it 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?

With no output schema, the description should say what a successful or failed injection looks like, and it does not. It also omits the precondition failure mode (no focused rich text input) and whether injected text replaces or extends existing content—both important for a low-idempotency write 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%, so both `text` and `force` are already documented in the schema. The description adds no further meaning about either parameter—notably it never explains the 'active guard' that `force` bypasses. Baseline 3 applies when the schema already carries the parameter semantics.

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 specific verb (inject) and a specific resource (the current rich text input box), which is enough to separate it from minimax_click (mouse) or minimax_key (keystrokes). It does not explicitly name any sibling to contrast with, so it falls short of a 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?

No explicit when-to-use or when-not-to-use guidance is given. An agent must infer from 'current rich text box' whether to prefer this over minimax_key or minimax_send_message, and '无需前台置顶' only hints at a window/activation trade-off rather than stating one.

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?

The annotations already declare destructiveHint=true, readOnlyHint=false, and idempotent=false, so the agent knows this tool performs writes. The description usefully adds that mutations happen through policy-driven automatic handling of low-risk questionnaires, and that dryRun is a preview. It does not say which actions the tool may take, whether they can be undone, or what limits apply beyond what the schema shows.

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 then the preview flag. Nothing is wasted, but the compactness comes at the cost of under-specification rather than being cleanly 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?

For a destructive, multi-mode tool with five parameters, a nested policy object, and no output schema, the description is too thin. It does not explain the action modes, the policy semantics, the timing thresholds, or what the tool returns.

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 there are 5 parameters, including a nested policy object with mode, riskCeiling, allowSessions, minIdleSeconds, and maxActionsPerTick. The description explains only dryRun; it leaves action, policy, stalledMinutes, and finishedMinutes unexplained. This is a significant gap that the description does not compensate for.

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 calls this a 'periodic inspection' that compares snapshots to produce events, and can auto-handle low-risk questionnaires. That is a concrete verb and object that an agent can understand. However, it only describes the 'tick' behavior, while the schema's 'action' enum also includes status, reset, and config, which the description does not explain. It also does not point to sibling tools such as minimax_events or minimax_pending, which cover adjacent functionality, so the agent cannot easily tell which tool to choose.

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 periodic use and gives one useful cue, that dryRun=true is preview-only. It does not say when to use this tool instead of siblings like minimax_auto_resume or minimax_pending, nor when not to use it. The guidance that does exist is tied only to the dry-run flag.

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 already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds that the returned data is meant for coordinate validation and topmost checks, which is useful framing, but with no output schema it says nothing about the shape of the returned layout data.

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 short sentence with no filler, front-loading the resource retrieved. It is appropriately sized for a trivial no-argument read tool, though the trailing purpose clause is slightly compressed.

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-param, read-only, idempotent tool the description is nearly sufficient, and annotations carry most of the behavioral load. The remaining gap is that there is no output schema and the description does not indicate what the layout/coordinate data looks like, so the agent cannot anticipate the return shape.

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 takes zero parameters, so there is no parameter semantics to explain; the baseline for a no-param tool applies. Nothing in the schema needs compensating for.

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?

Description states a specific verb-plus-resource: 获取 (get) MiniMax 窗口坐标与布局信息 (window coordinates and layout info). That is clearly distinct from siblings like minimax_screenshot, minimax_click, or minimax_find_text, though it doesn't explicitly name an alternative.

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 implied usage context — 用于坐标校验与置顶检查 (for coordinate validation and topmost/pin checks) — which tells the agent the scenario. But it offers no explicit when-not guidance or comparison to siblings such as minimax_screenshot or minimax_find_text, which also surface positional context.

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