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

Annotations only cover the safety triad (readOnlyHint=false, destructiveHint=false, idempotentHint=false). The description adds real behavioral context: the authorization is reusable, expires when the process ends, does not grant dangerous permissions, and must not receive source-code content. It stops short of describing failure modes or how to revoke/inspect the granted authorization.

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 dense sentence that front-loads the critical gating condition before the behavioral details. Every clause carries information, though the density makes it slightly harder to scan than a two-sentence split would.

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 2-parameter tool with no output schema and thin annotations, the description adequately covers calling condition, scope, lifetime, and the forbidden payload. It does not state what the issued authorization returns or how the agent subsequently consumes it, which is a modest 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 0%, so the description must compensate: it explains that both read-only and workspace-write pass only location and scope and never source text, which clarifies the purpose of the `permission` enum values and constrains `workspace`. It still does not define the expected format of `workspace` (path vs. identifier) or the default when `permission` is omitted.

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 (issue/bind authorization) and resource (a precise workspace) and clarifies it binds the current MCP conversation to that workspace. An agent can distinguish it from siblings like reauthenticate_cursor or doctor, though the description never names those siblings explicitly to sharpen the distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

"仅当用户在当前对话明确要求...时调用" gives a clear, explicit gating condition for when to invoke the tool. It does not name alternative tools or state when *not* to use it beyond the user-request precondition, but the precondition is unambiguous.

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 destructiveHint=true and idempotentHint=true. The description's note about 'stable results on repeated cancellation' merely restates the idempotency hint without adding new behavioral context, such as what happens to the run, side effects, or permissions required. It adds no value beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence with no fluff. It states the core action and the idempotency property efficiently. The structure is front-loaded with the primary purpose.

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 low complexity (one parameter, no output schema), the description is minimal. It omits key contextual details like the effect on the run lifecycle (e.g., will it stop emitting events?), whether cancellation is reversible, or any return value. An agent would have to infer behavior from the annotations alone, making the description insufficient for full understanding.

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

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

Schema description coverage is 0%, so the parameter 'relayRunId' is not documented in the schema, and the description does not explain it. Although the name is somewhat self-explanatory, the description fails to compensate for the lack of schema documentation, providing no clarification on its format, purpose, or expected values.

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 'cancel a still-running Cursor SDK run', specifying the verb (cancel) and resource (run). It is distinct from sibling tools like start_run, get_run, etc., though it does not explicitly name alternatives. The purpose is unambiguous and sufficiently specific.

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 is for runs that are still executing ('仍在执行'), but it provides no explicit guidance on when to use it versus alternatives like wait_run or how it relates to other lifecycle operations. No exclusions or conditions are given beyond the implicit 'still running' state.

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, covering the safety profile. The description adds valuable behavioral context by specifying the exact items checked (config, auth, persistence) and explicitly stating it does not invoke the Cursor model, which goes beyond the annotation hints.

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 with no extraneous words. It front-loads the core purpose and includes an explicit exclusion, making it concise and highly scannable for an agent.

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, read-only diagnostic tool, the description covers purpose, scope, and the explicit non-action. It lacks detail on the output format, but given the simple nature and no output schema, this is a minor gap. The description is sufficiently complete for an agent to decide when to invoke it.

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 the baseline is 4. The description provides context on what the tool inspects without needing to explain parameters, which is appropriate for this parameterless diagnostic tool.

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

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

The description clearly states the tool checks Cursor Relay configuration, authentication, and persistence directory, and explicitly notes it does not call the Cursor model. This distinguishes it from sibling run-management tools that interact with models, providing a specific verb and resource scope.

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 diagnostic role by listing what it checks and what it avoids, but it does not explicitly state when to use this tool versus alternatives. It lacks guidance on pre-flight checks or when to prefer it over other operations, leaving usage context to inference.

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 establish readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuine behavioral context beyond that: it discloses that the local executor exiting does not auto-restart the model and that an unknown state signals a diagnostic situation.

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 dense sentence with the core action front-loaded and the caveat trailing. No wasted words, though cramming three distinct ideas (read, re-attach, diagnose) into one clause slightly muddies the structure.

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?

No output schema exists, so the description should convey more about the run state it returns, but it only gestures at execution.state=unknown. Annotations cover the safety profile, but the missing parameter documentation and thin return guidance leave gaps for a diagnostic tool.

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

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

Schema description coverage is 0% and the single required parameter relayRunId is undocumented in both schema and description. The description never explains what the run identifier is, where to obtain it, or its format, so it fails to compensate 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?

States a specific verb (读取) and resource (持久运行), plus the secondary effect of re-attaching event observation. This distinguishes it from list_runs and read_events, though it does not clearly separate it from close siblings like view_run and open_run.

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 read-and-observe context and notes that execution.state=unknown warrants diagnosis, which is weak guidance on when to use it. It never names an alternative (view_run, open_run, read_run_progress) or states a when-not condition, so routing among the many run-observation siblings is left to inference.

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 readOnly, idempotent, and non-destructive hints. The description adds context about using the current account and the ordering requirement relative to start_run, which is useful behavioral information beyond the annotations. No contradictions.

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 purpose and usage. Every word earns its place; 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 simple, zero-parameter, read-only listing tool, the description adequately specifies what it returns (models, aliases, parameters) and when to call it. With no output schema, it does not explain return structure in detail, but the listed items suffice for an agent to understand the outcome.

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 the baseline is 4. The description correctly implies no inputs are needed; it adds no parameter-specific information because there are none.

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 ('discover') on a specific resource ('available models, aliases, and parameters') from the current Cursor account. It also distinguishes itself from siblings by explicitly referencing start_run, making the tool's role unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit timing guidance ('should be called before start_run'), establishing when to use it. It does not mention when not to use it or alternatives, but the context is clear and the directive is direct.

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?

注释已声明readOnlyHint=true和destructiveHint=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?

描述仅有一句话，简洁明了，没有任何冗余内容。它直接陈述了核心功能和排序方式，结构清晰。虽然省略了部分细节，但就所包含的信息而言，做到了精炼。

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?

该工具参数简单（单可选limit），注释齐全，且无输出schema要求。描述提供了排序行为，但未提及如何设置limit或默认行为。对于这样一个基本工具，描述基本足够，但缺少参数使用说明使上下文略有缺口。

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中只有一个可选参数limit，带有最小/最大约束，但schema描述覆盖率为0%。描述完全未提及limit参数的含义或用法，因此代理必须自行推断。虽然'limit'直观代表数量限制，但描述未明确说明，使得参数语义不清晰。

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?

描述明确说明了工具的功能：按创建时间倒序列出运行记录。动词'列出'和资源'运行'清晰，且排序方式提供了具体行为。虽然未与其他兄弟工具明确区分，但该描述足以让代理理解基本用途。

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?

描述未提供任何关于何时使用该工具与替代工具（如get_run、cancel_run）的明确指导。代理无法从描述中得知适用的场景或与其他列表类工具的区别，仅能通过名称推断。

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real context beyond that: the link is a local read-only URL, it does not depend on the Codex MCP sandbox, and calling it should never trigger a resubmission. It stops short of describing link lifetime or any rate limits.

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?

Front-loads the purpose (obtain the progress link) before the usage conditions, and every clause carries information. It is a bit dense with three semicolon-joined ideas in one sentence, but nothing is wasted.

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

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

For a simple read-only tool whose annotations already cover safety and whose output (a link to hand to the user) is stated in prose, the definition is largely self-sufficient. The only meaningful gap is the undocumented relayRunId, which is the tool's sole input.

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 single required parameter relayRunId is never explained in the description, including where the agent obtains the id (presumably from start_run/reply_run responses). With one undocumented parameter and no compensation in prose, the agent is left guessing about the identifier's origin and format.

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

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

States a specific verb+resource: obtain the local read-only progress link for an existing task and surface it to the user as a clickable URL. It is clearly not a mutation or event-reading tool. However, it does not differentiate itself from lookalike siblings such as get_run, view_run, or read_run_progress, which an agent must disambiguate on its own.

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 explicit triggers and a prohibition: call it after start_run/reply_run succeed, and also call it when the sandbox errors to inspect the original task. It further states the agent must NOT resubmit as a result. This is textbook when-to-use plus when-not 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the increasing-order behavior and the fact that the number of events is capped, which goes beyond annotations. However, it does not disclose whether reading consumes events, how pagination works, or the exact nature of the persisted stream.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence with no filler. It front-loads the action and the ordering, which is efficient. However, it is under-specified, so conciseness comes at the cost of completeness, but for what it says, there is zero waste.

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 three parameters, no parameter descriptions in the schema, and no output schema, this tool requires more context. The description omits critical usage details: how to obtain relayRunId, the meaning and effect of afterSequence, how the limit is applied, and what the returned events look like. It is far from complete for an agent to call correctly without additional context or trial-and-error.

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

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

Schema description coverage is 0%, so the description must compensate for the three parameters (limit, relayRunId, afterSequence). It fails to explain any of them. The only hint is 'events have a limit,' which loosely relates to the limit parameter but is not explicit. No mention of what relayRunId identifies or how afterSequence controls incremental reading.

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

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

The description clearly states the action (read), the resource (persisted Cursor SDK stream events), and the ordering (in increasing sequence number). This is specific and distinct from the sibling tools like get_run (run state) or list_runs (list of runs), so an agent can tell it apart.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It does not mention that it should be used after starting a run or polling for streamed events, nor does it exclude cases where get_run or wait_run would be more appropriate. No alternatives are referenced.

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/idempotent/non-destructive/non-open-world, but the description adds real behavior beyond them: it does not invoke the SDK, does not reconnect, does not block on timeout convergence, caps events at 200, and warns that the snapshot is not liveness evidence. This is exactly the kind of consequence-level context annotations cannot carry.

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 dense clause front-loads the purpose, then the operational exclusions, then the routing caveat — no filler and nothing repeated from the name or schema. Sized appropriately for a two-parameter read tool.

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

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

For a low-complexity read tool with no output schema and strong annotations, the description covers behavior and the liveness caveat well, and loosely characterizes what comes back (state plus bounded events). The remaining gap is the absence of any parameter guidance, which is the one thing an agent still needs to call 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?

Schema description coverage is 0%, so the description must explain the two parameters, and it does not: neither relayRunId's meaning/format nor afterSequence's role as an incremental-event cursor is described. The phrase about 'up to 200 incremental events' hints at incremental semantics but never connects it to afterSequence, leaving the agent to guess how to page.

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 pair (read-only retrieval of a run's persisted state) and bounds the payload explicitly ('up to the most recent 200 incremental events'). It also differentiates itself from the sibling wait_run by stating that live monitoring belongs to that tool rather than this one.

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 an explicit when-not rule ('the snapshot is not proof the task is alive; for actual monitoring use wait_run') and names the alternative tool, so an agent can route between a point-in-time snapshot and a blocking wait without inference. It additionally rules out side effects (no SDK call, no reconnect, no timeout convergence).

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=false, destructive=true, openWorld=true, and idempotent=true. The description adds useful context beyond that: it opens the system browser, replaces SDK local credentials, does not read or return the API key, and requires a validation call afterward. It still omits auth prerequisites and failure 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?

Dense and front-loaded: it states the trigger before the action, then adds security and follow-up constraints in a compact format. No sentence is wasted, though the parameter omission slightly weakens overall density.

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?

Covers the trigger, the browser-based action, credential replacement, API key handling, and the required validation step. It leaves the 'confirmed' parameter unexplained and does not contrast with authorize_workspace, but annotations already carry the safety profile, so it is nearly complete for a reauthentication tool 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 sole parameter 'confirmed' has no description in the schema (0% coverage) and is never mentioned in the description. The const:true constraint implies a required confirmation, but the definition does not explain why or when to pass it. Since schema coverage is low, the description should compensate but does not.

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 action (open system browser to re-login and replace SDK local credentials) and a clear trigger condition. However, it does not explicitly differentiate itself from the sibling authorize_workspace, which also handles an auth-related task.

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 an explicit trigger (stored login inconsistent with user-confirmed Cursor account or plan) and a required follow-up (re-call list_models). It does not state when not to use this tool or name an alternative sibling such as authorize_workspace.

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 destructive=true, idempotent=true, openWorld=true, so the safety profile is partly covered. The description adds two useful facts: the agentId is retained and source code must not be inlined (Cursor reads it). It says nothing about permissions, approval tokens, or what a continuation actually mutates.

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 dense sentence, front-loaded with the core action and followed by the key constraint. No filler, though the semicolon-packed style condenses several ideas that could be separated for scanability.

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, open-world tool with 10 parameters, nested objects, permission modes, an approval token and a danger-confirmation flag, and no output schema, the description is far too thin. It leaves permission handling, idempotency behavior and danger escalation entirely undescribed.

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 40% across 10 parameters, and the description touches only implicitly on task and targetLocations. Critical parameters (permission, workspaceApprovalToken, confirmedDangerousPermission, codexAllowedTools inheritance, idempotencyKey) get no explanation in either the description or the schema, so it does not compensate 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?

States a specific verb+resource: '续接运行' on an '已结束的 Cursor Agent 会话', and names a distinguishing trait (retains agentId). It is clearly separable from start_run/open_run by the 'already-ended session' scope, though it never names those siblings 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 a condition of use (only for already-ended sessions) and a content rule (pass only locations/scope, never source code). It does not, however, say when to prefer a sibling like start_run or open_run, nor state any exclusion beyond the source-code prohibition.

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 destructiveHint=true, idempotentHint=true, readOnlyHint=false and openWorldHint=true, so the safety profile is covered. The description usefully adds the 'no embedded source code' scoping rule and the mandatory model/idempotency key, but says nothing about the danger-full-access path, the approval token, or what destruction actually entails.

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 compact sentences, the core action front-loaded and constraints following. No filler, though it could be organized slightly more clearly around the parameter groups.

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, open-world tool with 10 parameters, nested objects and no output schema, the description covers the required fields and a key constraint but omits the escalation/permission machinery (danger-full-access, approval token, dangerous-permission confirmation) an agent needs to call it safely.

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 only 40% schema description coverage, the description must compensate and does partially: it explains that workspace/targetLocations/task carry scope and that model and idempotencyKey are mandatory. But permission, timeoutMs, codexAllowedTools, workspaceApprovalToken and confirmedDangerousPermission get no coverage in either place.

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 and resource – '启动持久 Cursor Agent 运行' (start a persistent Cursor Agent run) – so the agent knows exactly what the tool does. However, it does not explicitly distinguish this from siblings such as open_run or wait_run, leaving the agent to infer the boundary.

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 prerequisites (must explicitly select model and idempotency key) and a constraint (read-only/workspace-write only accept workspace, target locations, task scope), which implies usage context. But there is no explicit when-to-use / when-not-to-use guidance versus the many sibling run 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?

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuine behavior beyond that: this opens an interactive real-time panel and reveals a live event timeline rather than returning a static record, which materially changes how an agent should treat the result.

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 front-loaded sentence states the purpose, the payload it shows, then the exclusions via a semicolon clause. No filler; 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 simple one-parameter view tool with rich annotations and no output schema, the description covers what the agent needs to select and expect. The only real gap is the undocumented parameter, which is minor given the tool's simplicity.

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% for the single required relayRunId, so the description must compensate and largely does not. 'The specified Cursor Relay run' only restates that some run is targeted — it gives no hint about ID format, where to obtain it, or behavior for an invalid ID.

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?

Names a specific verb and deliverable (opens a read-only real-time panel for a run) and enumerates exactly what it surfaces: status, event timeline, final output. It is clearly distinct from mutating siblings, though it doesn't explicitly distinguish itself from read-oriented siblings like get_run, read_events, or read_run_progress.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit negative routing — it does not start, resume, cancel, or modify runs — which tells the agent when NOT to pick it. However, it names no positive alternative (e.g., use get_run for a static snapshot), so the when-to-use side is left to inference.

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, open-world, non-destructive behavior, so the bar is lower. The description adds the 30-second wait bound, polling decision semantics for `mustCallAgain`/`needsAttention`, and a diagnostic warning about unknown states — useful context beyond the structured fields.

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 dense sentences with no filler. The 30-second cap and polling conditions are front-loaded, making the key constraints immediately visible.

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 no output schema, the description should orient the agent to the return values; it names `mustCallAgain` and `needsAttention` but never defines their semantics or origin. Combined with no `relayRunId` explanation, this leaves gaps, though annotations cover the safety profile.

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

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

Schema description coverage is 0%, so the description must explain both parameters. It effectively restates the waitMs upper bound as '30 seconds' but says nothing about `relayRunId`, the required run identifier, nor any meaning for `waitMs` beyond the schema maximum.

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 the core action — wait up to 30 seconds and continue polling under specific conditions — which clearly identifies a bounded polling tool. However, it never names the run/resource being waited on and does not distinguish itself from siblings like get_run or view_run, so differentiation relies on the tool name alone.

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 conditional instructions for acting on `mustCallAgain` and `needsAttention`, and warns against treating unknown states as failure or completion. It does not say when to choose this tool over `get_run`, `read_run_progress`, or other siblings, so initial-call guidance is absent.

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