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

Annotations only declare readOnlyHint=false and destructiveHint=false. The description goes well beyond that by disclosing that allocation happens inside tmux, that attach enters a compute-node shell, that disconnection does not lose resources, that wait timeout preserves the session, and that return statuses are granted/pending/failed with job_id/node. These are exactly the behavioral traits an agent needs to invoke the tool correctly.

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 front-loaded with the core purpose and then structured into automatic allocation logic, return behavior, and an Args list. Despite being detailed, every sentence earns its place by explaining semantics needed for a 7-parameter tool with no schema descriptions. It is appropriately sized for the complexity.

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 complexity and the 7-parameter schema with 0% description coverage, the definition is complete. It covers purpose, allocation behavior, return statuses, and all parameters, and an output schema exists so return-value details need not be fully expanded. Nothing critical for correct invocation appears 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?

Schema description coverage is 0%, so the description carries the full burden. It documents all 7 parameters in the Args list, including connection meaning, purpose naming, resource enum behavior, default gpus/cpus, partition override, and wait semantics. This fully compensates for the schema's lack of parameter 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 specific verb and resource: it allocates/preempts resources and directly executes, using tmux, salloc, and srun bash. It distinguishes itself from a command-only tool by saying '绝不只返回命令' and clarifies that attach enters a compute-node shell with persistent resources. This gives an agent enough to identify what alloc does versus siblings like exec or submit.

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 clear operational context: allocation selection is automatic ('无需先查询'), resource defaults are explained, and partition overrides are described. However, it does not explicitly name alternatives or state when not to use this tool versus exec, submit, or session_list. The guidance is strong for parameter behavior but lacks direct sibling routing.

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 readOnlyHint=false and destructiveHint=false; the description goes beyond them by disclosing the safety-gate restriction on scancel --all, which is real behavioral context an agent needs. It still doesn't say whether the cancelled job is terminated immediately or irreversibly, or what permissions/connection are required, but the annotation layer covers the basic safety 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 clauses with no filler; the action and its restriction are front-loaded. It is lean to the point of under-specification, but nothing present is wasteful.

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?

An output schema exists, so return values need not be described. However, for a mutation tool with zero schema coverage, the definition omits the 'connection' parameter, any auth/permission notes, and whether cancellation is immediate or reversible, leaving meaningful gaps.

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

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

Schema description coverage is 0% and neither parameter is documented in the schema, so the description must compensate. It implies job_id identifies a single job ('指定作业'), but the required 'connection' parameter is never mentioned or explained, leaving half the interface undocumented.

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 ('取消指定作业' / cancel the specified job) and anchors it to the known scancel single-job operation, so the agent knows exactly what action is performed. It is distinguishable from submit/jobs siblings, though it never names a sibling 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 clear when-not constraint: the bulk variant 'scancel --all' is blocked by a safety gate, which tells the agent this tool only handles one job at a time. No alternative tool is offered for broader cancellation, but for a two-parameter tool the usage context is adequately framed.

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 by structured data. The description adds that connection pool health (label/kind/host/state) is included in the result, which is useful context, but says nothing about pagination, size limits, or auth requirements.

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 that front-loads the resource and appends the returned fields in parentheses. Nothing is wasted or 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?

An output schema exists, so the description need not enumerate return values, yet it helpfully names the key fields. For a zero-argument read-only list tool this is nearly complete; only the alternative-tool routing 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 the baseline of 4 applies. There is no parameter surface that the description needs to explain, and it does not mislead about 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?

Names a specific verb and resource ('列出全部受管连接' = list all managed connections) and clarifies scope as the full set of managed connections plus pool health. It does not distinguish itself from siblings such as session_list or status, which could also return connection-adjacent state, 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?

The description states what is returned but gives no when-to-use guidance, no conditions that select this tool over session_list/session_info/status, and no prerequisites. An agent must infer the use case purely from the name.

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

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

Annotations fix the safety profile (readOnlyHint=false, destructiveHint=false). The description usefully adds that it uses SFTP and that the local parent directory is created automatically — real behavior beyond annotations. However, it omits overwrite behavior on existing local files, auth/permission requirements, and error/partial-transfer handling.

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 core action first and the protocol/auto-mkdir detail in a parenthetical. Appropriately sized with no filler, though necessarily thin given the missing 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?

An output schema exists so return values need not be described, but for a 3-parameter, fully-required file-transfer tool with 0% schema coverage, the description leaves key details unspecified: overwrite semantics, connection expectations, and where files land. Inadequate for the tool's complexity.

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

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

Schema description coverage is 0% and the description adds no meaning for the three required parameters (connection, remote_path, local_path). The names are largely self-explanatory, but nothing clarifies the connection format or path conventions, so the description 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+resource ('下载远端文件到本地') and names the protocol (SFTP), which implicitly distinguishes it from the sibling 'upload'. It does not explicitly differentiate from other siblings like exec, but the direction of transfer is unambiguous.

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

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

No when-to-use or when-not-to-use guidance. The agent must infer that this is for retrieving remote files over SFTP by contrast with 'upload', with no mention of prerequisites (e.g., connection must be established) or alternatives.

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

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

Annotations cover the safety hints (readOnlyHint=false, destructiveHint=false), yet the description adds real behavioral context: dangerous commands and heavy operations on cluster login nodes are rejected server-side, and there is a timeout with an implied default. This is exactly the kind of constraint beyond annotations that an agent needs before invoking.

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-loaded one-line purpose followed by a compact Args block that earns its space given the zero schema coverage. No filler sentences.

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

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

An output schema exists so return values need not be explained, and parameters plus server-side rejection rules are covered. Remaining unknowns (interactivity, working directory, session reuse) are minor for a single-command executor.

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 carry the load, and it documents all three parameters: connection (label, cross-referenced to connection_list), command, and timeout in seconds. One minor discrepancy: the description says default 60 while the schema declares default null.

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: execute a single shell command on a remote connection. The scope (single command, remote connection) is clear enough to distinguish it from batch/job siblings like submit or jobs, though no sibling is named 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?

Usage is implied by the scope statement and it points to connection_list for obtaining a valid connection label, but it never states when to prefer this tool over session-based or job-submission alternatives among the many siblings.

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 usefully adds that results are limited to the current user and are structured, but discloses nothing about the undocumented states filter, result volume, 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?

A single front-loaded sentence packs the verb, scope, and returned fields with no filler. The only slight inefficiency is the parenthetical field list, though it is informative rather than 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?

An output schema exists, so return-value explanation is not required, and the purpose is fully conveyed for a simple listing tool. However, with a required connection and an undocumented states filter, the description leaves the agent guessing about filtering semantics.

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 carry both parameters, yet it says nothing about 'states' (what values are accepted, what filtering it performs) or 'connection'. Since two parameters are entirely undocumented in both schema and description, 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?

The description names a specific verb and resource (列出/列出作业) and scopes it to the current user on a Slurm cluster, enumerating the returned fields (job_id/状态/分区/耗时/资源). It is clearly distinct from write siblings (submit, cancel) but never explicitly contrasts itself with the more proximate read siblings like status or resources.

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 implies a scope ('current user's jobs') but gives no when-to-use/when-not guidance and never names an alternative among siblings such as status, resources, or ledger_query. The agent must infer which read tool fits a job-inspection 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, and destructiveHint=false, so the safety profile is covered. The description adds genuinely new context — cross-session memory scope and time-descending result order — but says nothing about defaults (limit=100), pagination, or result size 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?

A single dense sentence with no filler; the resource, scope, filters, and ordering are all front-loaded. Nothing is wasted, though it is compressed to the point of omitting useful detail.

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?

An output schema exists, so return values need not be described. However, for a 6-parameter tool with zero schema documentation, leaving 'since', 'limit', and the enum-less 'kind' unaddressed leaves real gaps in how an agent would 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% across 6 parameters, so the description must compensate. It names four of them (connection, kind/类型, keyword, job_id), which is meaningful added value, but 'since' and 'limit' remain entirely undocumented and no allowed values for 'kind' are given.

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 (检索/retrieve) and resource (执行留痕 execution ledger), plus its distinguishing scope: cross-session memory. It also names the filter dimensions and sort order. It does not explicitly differentiate itself from the nearest sibling (log), but the '跨会话记忆' qualifier does most of that work.

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 lists filterable fields but gives no when-to-use guidance, no exclusions, and never mentions an alternative (e.g., log or jobs) that an agent might pick instead. Usage is only implied by the filter list.

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 genuinely useful context — that it auto-locates the StdOut path rather than requiring the user to supply one, and that output is tailed — but says nothing about failure modes (e.g., job not yet started, no output file).

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, front-loaded with the action and resource, followed immediately by the operational detail. 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?

An output schema exists, so return values needn't be described. However, for a 3-parameter tool with zero schema documentation, the description leaves how to supply a connection and job identifier, and the meaning of the tail count, to inference — it is adequate but incomplete.

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

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

Schema description coverage is 0% for 3 parameters, so the description must carry the burden, and it doesn't. It hints at the 'tail' concept but never explains that the parameter controls the number of trailing lines, and the 'connection' and 'job_id' parameters are entirely unexplained.

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 ('读取作业 stdout' / read job stdout) and adds a distinguishing behavior (auto-locating the StdOut path and tailing it), which separates it from siblings like exec or jobs. It does not explicitly name an alternative, 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?

There is no statement of when to use this tool versus siblings such as exec, jobs, or status, nor any prerequisite or post-submit context. Usage is only weakly implied by the mention of job stdout.

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, non-destructive semantics, so the bar is lower. The description adds real behavioral context: output is compact/per-partition by default, node-level detail is returned only when a filter or include_nodes is supplied, and large clusters should combine filters to avoid heavy detail payloads.

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 structure is well front-loaded — purpose, then scope filters, then the Args list. There is minor redundancy, since the flt values and their meanings are stated both in prose and again in the Args block.

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?

An output schema exists, so return-shape documentation is not required, and annotations cover the safety profile. The description supplies everything needed to filter and size the query correctly; only marginal details such as connection prerequisites or failure behavior are absent.

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 0% schema description coverage, the description carries the full burden and does so: it enumerates every optional parameter, spells out the accepted flt values with their meanings, notes that gpu_only stacks with other conditions, defines partition scoping, and warns about include_nodes cost on large clusters.

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 opening sentence names a specific verb and resource — querying cluster resource headroom — and enumerates exactly what is returned (per-partition CPU/GPU total/used/free plus node counts). This is clearly distinguishable from siblings like jobs, status, or alloc.

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 explains when to apply each filter (flt=cpu_free / cpu_gpu_free / fully_idle, gpu_only, partition) and explicitly tells the agent not to assemble sinfo/scontrol itself, which routes it toward this tool over exec. It does not, however, contrast against sibling tools such as status or jobs, so the guidance stops just short of fully explicit alternative selection.

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, so the safety profile is fully covered by structured data. The description adds the field list (status, job_id, node, log tail), which largely duplicates the return contract already described by the output schema, and says nothing about auth needs, session lifetime, or error behavior.

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

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

A single front-loaded sentence with no padding. It is appropriately sized for a read-only lookup, though the enumerated return fields are arguably redundant with the output schema.

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

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

The output schema exists, so return values need not be explained, and annotations cover the safety profile. However, with two mandatory parameters at 0% coverage and no parameter or usage explanation anywhere, the definition leaves a real gap in how to invoke the tool correctly.

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

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

Schema description coverage is 0% for two required parameters (connection, purpose), and the description provides no meaning for either. Critically, neither parameter obviously identifies which session is being inspected despite '某个托管会话' implying a session selector — an agent gets no help resolving this ambiguity from the text.

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 (查看某个托管会话详情) and enumerates what is shown: allocation status, job_id, node, log tail. This implicitly distinguishes it from session_list (list vs. single-session detail), but it never names the sibling explicitly, so an agent must infer the routing.

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 when-to-use guidance, no prerequisites, and no alternatives are mentioned. session_list and session_release exist as obvious siblings, yet the description gives no condition for choosing session_info over them.

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 that results include owning connection, purpose, and creation time, which is useful behavioral context, but says nothing about pagination, ordering, or empty result handling.

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 tight sentence that front-loads the action and resource before listing the returned fields. No filler, though it stops short of 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?

An output schema exists, so return values need not be explained, and the description correctly focuses on scope and fields. However, the ambiguous optional 'connection' parameter and the undifferentiated sibling session_info leave an agent with real gaps when choosing the tool.

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

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

Schema description coverage is 0% for the single optional 'connection' parameter, so the schema contributes nothing. The description's mention of '所属连接' (owning connection) implies connection is a filter/attribute axis, adding marginal meaning, but it never states that passing the parameter restricts results to one connection.

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 (列出 tmux 托管会话) and scopes it to alloc resource sessions, so an agent knows this is a listing tool, not a mutation. It does not differentiate from the sibling session_info, which likely returns detail for one session.

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 versus session_info, connection_list, or resources, and no mention of prerequisites or filtering behavior. Usage must be inferred entirely from the name.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the safety profile is partly covered. The description adds real behavioral detail beyond that (tmux is killed, the salloc allocation exits, resources return to the cluster), but says nothing about irreversibility, whether other jobs on the allocation are affected, or any auth/permission requirement for releasing a session you may not own.

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, front-loaded with the verb and resource, with the arrow chain efficiently conveying ordering of effects. No filler whatsoever.

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?

An output schema exists, so return values need not be described. However, for a two-parameter mutation tool with 0% schema documentation and no annotations covering usage, the description is too thin: it never explains what a 'managed session' is, how to obtain the connection value, or what happens if the session is already gone.

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%: neither 'connection' nor 'purpose' has any explanation, and the description never mentions either parameter. For a two-required-parameter tool with no schema documentation, the description is expected to compensate, and it does not — an agent cannot tell whether 'connection' is a cluster, SSH target, or session handle.

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?

Specific verb (释放/release) plus the resource it acts on (托管会话/managed session), with the concrete side effects spelled out as a chain: kill tmux → salloc exits → resources returned. It is clearly distinct from session_list and session_info by virtue of being the tear-down action, though no sibling is named explicitly.

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

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

The description gives no when-to-use guidance, no prerequisites, and never contrasts itself with plausible alternatives such as cancel or session_info. The usage is only inferable from the meaning of 'release a managed 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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered without the description. The description adds only the scope of what is summarized (partitions and queue counts), which is close to restating return content also covered by the 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 front-loaded sentence with no filler; the resource scope comes before the detail. It is appropriately sized for a simple read-only overview tool, though it leans on brevity rather than 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?

For a simple read-only status tool with an output schema, the description is minimally adequate about what is returned. It omits any guidance on the required `connection` argument and gives no hint of freshness, cost, or when the snapshot is useful, which leaves 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 description coverage is 0% and the single required `connection` parameter is completely undocumented. The description says nothing about how a connection is identified or what format it takes, leaving a required input entirely unexplained.

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 concrete resource and scope: a Slurm cluster overview covering partitions (nodes/CPU/memory/GPU) and queue state counts. That is enough to distinguish it from action tools like submit, cancel, or exec. It does not, however, differentiate itself from the sibling `resources`, which plausibly reports similar cluster capacity data.

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 mention of alternatives such as `resources` or `jobs`. The agent must infer from the one-line purpose when this overview is the right call.

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 and destructiveHint=false, so the write/safety profile is covered. The description usefully adds the base64-then-sbatch pipeline, which is real behavioral context beyond the annotations, but it omits auth/permission needs and whether the job persists after submission.

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 verb first, mechanism second, and return value last. No filler or redundancy.

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

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

The presence of an output schema means return-value detail (job_id) is already partly covered, and annotations handle the safety profile. However, the 'connection' parameter is unexplained and there is no usage routing, so the definition is adequate but leaves gaps for a 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 0%, so the description must carry the parameter burden. It clarifies that 'script' is script text that gets base64-encoded on upload, but says nothing about the 'connection' parameter's format or expected value, leaving one of two required params undocumented.

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 (submit a Slurm batch job) and adds mechanism detail (script uploaded as base64, then sbatch) plus the return value (job_id). It is clearly distinguishable from read-only siblings like jobs/status/log, though it does not explicitly contrast itself with exec or alloc.

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

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

No guidance on when to use this over exec (interactive run) or alloc (resource allocation) is provided. The description only says what it does, leaving the agent to infer the selection condition from the tool name.

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

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

Annotations already mark this as a write (readOnlyHint=false) but non-destructive, so the safety profile is covered. The description adds a genuinely useful behavioral fact beyond annotations: the remote parent directory is created automatically, which tells the agent it need not pre-create directories. It omits overwrite semantics for an existing remote file, keeping it short of a 5.

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 states the action first, then protocol and the parent-directory note. No wasted words, though the extreme brevity is close to under-specification rather than ideal conciseness.

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

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

An output schema exists, so return values need not be explained, and annotations cover the write/non-destructive profile. However, for a three-parameter mutation tool with 0% schema coverage, the connection semantics and overwrite behavior are missing, leaving real gaps for correct invocation.

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

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

Schema description coverage is 0%, so all three parameters (connection, local_path, remote_path) are undocumented structurally. The description indirectly conveys local_path and remote_path via 'local file' and 'remote', but says nothing about the 'connection' parameter (format, reference to connection_list, auth expectations), leaving a required parameter unexplained.

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+resource (upload a local file to a remote host) and even specifies the protocol (SFTP), which lets an agent distinguish it from the sibling 'download'. It does not explicitly reference the sibling, but the operation is unambiguous.

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

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

The description implies its use case but gives no when-to-use guidance, no mention of the obvious alternative 'download', and no prerequisites such as valid connection setup. An agent must infer everything about routing.

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