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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered by structured data rather than the description. The description adds nothing beyond that: it does not say whether an unknown group errors, whether the result is static metadata, or how large the output is, and the output schema covers the return 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?

A single tight sentence with the purpose front-loaded and no filler. It is efficient, though the brevity comes at the cost of the missing details noted above.

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 relieves the description of explaining return values, but for a required-identifier introspection tool the description should at least say how to obtain a group name and what an invalid group does. With 0% schema coverage on the only parameter, neither the schema nor the description closes that 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% for the single required 'group' parameter, and the description offers no compensating meaning — it does not say whether 'group' is a name, slug, or ID, or where a valid value comes from. The word 'group' is merely echoed from the parameter name.

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 verb 'describe' and the resource 'command group' are stated, and 'actions and parameters' hints at an introspection tool. However, 'specialized command group' is never defined, and nothing distinguishes this from the sibling remote_command_groups (which presumably enumerates groups) or remote_command_group_run (which executes 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?

There is no when-to-use guidance, no mention of calling remote_command_groups first to discover a valid group name, and no statement that remote_command_group_run is the follow-up action. An agent must infer the entire workflow from tool names.

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, openWorldHint=true, idempotentHint=false, so the risk profile is known from structured data. The description adds genuine value by disclosing that dry_run returns the generated command without executing it — the only safe preview path for a destructive tool. It does not say what side effects occur, whether confirmation is required, or how errors on a multi-host group are reported.

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 action and followed by the connection and dry_run notes — no filler or repetition. Slight redundancy in the example list, but it does earn its place by hinting at the action domain.

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. But for a destructive, open-world, 9-parameter tool with 0% schema coverage and no enum hints, the description leaves the two required parameters and three optional ones undefined, which is thin for the complexity involved.

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 9 parameters, so the description carries the full burden and largely fails it: only session_name/profile/connection (as an either/or) and dry_run are addressed. The two required parameters, group and action, get no explanation of valid values or format, and parameters, timeout, and output_limit are never mentioned.

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 verb+resource ("Build and run a specialized action") and concrete examples (user management, services, reboot, system inventory), which is more than a tautology. However, "specialized action" is fuzzy and it never explains what a "group" is or how this differs from siblings like remote_execute, remote_run_program, or remote_run_script, so an agent cannot reliably route between them from the text 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 states one real selection rule — "Use either session_name or profile/connection" — and explains what dry_run does, which is actionable. It gives no guidance on when to choose this tool over remote_execute or remote_run_script, and no mention that group/action values likely come from remote_command_groups / remote_command_group_describe, so usage is only partially implied.

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

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

Annotations declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, which alone would leave it unclear why a 'list' tool is not read-only. The description fills that exact gap by explaining that the optional flags create a persistent local plug-in directory and reload modules, and the 'once' wording reinforces idempotency. It stops short of saying where the directory lives or what permissions are needed.

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

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

Three short sentences with no filler, and the per-flag instructions are split cleanly. The opening sentence is slightly ambiguous in pairing 'list command groups' with 'and the persistent local plug-in directory,' which makes the object of the listing unclear.

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, the central concept, the persistent local plug-in directory, is left unexplained (no location or scope), and the relationship between listing command groups and toggling these flags is not fully coherent for an agent deciding how to call 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?

With schema description coverage at 0%, both parameters would otherwise be bare booleans with defaults. The description gives each one operational meaning (create_directory creates the plug-in folder; reload refreshes after module edits), which meaningfully compensates. It does not explain what 'reload' actually reloads or the consequence of leaving it false, leaving a small residual 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: listing command groups plus the persistent local plug-in directory. It is clear enough to distinguish this listing/inspection tool from siblings such as remote_command_group_run or remote_execute, though it never explicitly contrasts itself with the closely related remote_command_group_describe.

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 stated only for the two flags: create_directory=true 'once' to create the folder, and reload=true 'after adding or editing a module.' There is no guidance on when to call this tool instead of remote_command_group_describe or the other command/group tools, so the agent must infer the 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 already declare destructiveHint=true, openWorldHint=true, non-idempotent, and non-read-only, so the safety profile is covered. The description adds the inbound data-flow direction and the directory/recursive requirement, which annotations do not express, but it stays silent on overwrite semantics for an existing local_path — the most important unknown for a destructive transfer.

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 action and scoped by the destination. Nothing is redundant, though the size is arguably too small for a five-parameter tool rather than overly verbose.

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 the tool has five parameters with zero schema coverage, a destructive transfer, and an open-world remote target. The description never addresses authentication/profile selection, connection overrides, or what happens to pre-existing local files.

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 five parameters, so the description must compensate and largely does not. It explains only 'recursive' for directories and implicitly the two paths; 'profile' and 'connection' get no explanation at all, leaving the agent to guess how the remote endpoint is selected.

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 ('Copy a remote file or directory') and pins the destination as 'the MCP server', which separates it in direction from the sibling remote_upload. It stops short of naming an alternative tool, 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?

There is no when-to-use or when-not-to-use guidance, no mention of prerequisites (a profile or connection must presumably be supplied), and no reference to the obvious counterpart remote_upload. The only conditional sentence is about a parameter, not about tool 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 destructiveHint=true and openWorldHint=true, so safety is covered, and the description adds genuinely non-structured context: an ad-hoc target can be supplied instead of a profile, self-signed WinRM HTTPS requires ssl=true with cert_validation=false, WinRM shells may be powershell or cmd, and SSH runs through the remote user's shell. It still omits what happens on timeout expiry and whether output is truncated or lost.

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 core action plus mechanism is front-loaded in one sentence, followed by the connection example, which is the single most valuable detail given the opaque `connection` object. Some compression is possible in the SSL/WinRM sentences, and a trailing blank-line artefact exists, but overall it is tight.

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, and annotations cover the safety profile. Still, for a destructive, open-world execution tool with eight undocumented parameters, the description leaves timeout behavior, output truncation via output_limit, cwd/env application, and error semantics 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 description coverage is 0% across 8 parameters, so the description carries the burden and only partially meets it: it defines the shape of `connection` with a concrete JSON example, explains `shell` values for WinRM, and mentions `profile` as the fallback. It says nothing about cwd, env, timeout (default 300s), or output_limit, leaving four parameters undocumented in both schema and description.

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

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

States a specific verb and mechanism: 'Execute one command using a short-lived SSH or WinRM connection.' The word 'short-lived' implicitly contrasts with the session-oriented siblings (remote_session_execute, remote_session_open), and 'one command' separates it from remote_run_script/remote_job_start. However, no sibling is named explicitly, so the agent must 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?

Usage is only implied by 'one command' and 'short-lived connection'; there is no explicit statement of when to prefer this over remote_run_program, remote_session_execute, or remote_job_start. The connection-vs-profile paragraph is operational guidance for a chosen path rather than tool-selection guidance. An agent can guess the intent but is not routed.

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, idempotent=true, and destructive=false, so the description needs to add the risk detail — yet it never mentions what the overwrite option does to an existing inventory. An agent could plausibly wipe inventory data without any warning from the description, which is the key behavioral fact for this tool.

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

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

Two short sentences, front-loaded with the actual action, so it is compact. But the second sentence addresses server startup rather than this tool's behavior, making it a non sequitur that consumes space without informing invocation.

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, and safety annotations are present. Still, for a mutating initialization tool with an undocumented overwrite flag, the description omits the one detail an agent must know before calling it: what happens to an existing inventory.

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 parameter (overwrite, default false) has no description anywhere in the definition. The description instead mentions a "config path" that is not a parameter at all, so it neither documents overwrite nor clarifies that no config input exists.

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 first sentence gives a specific verb and resource ("Create an empty local inventory"), which distinguishes it from the inventory_status and inventory_validate siblings. The second sentence about config paths dilutes the focus but does not obscure the core action.

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 verb "create" implies first-time setup, and the note that a config path isn't required hints at a bootstrap context, so usage is inferable. However, there is no explicit statement of when to use this versus remote_inventory_status/validate, nor when a new inventory is or isn't needed.

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

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

The readOnlyHint and openWorldHint=false annotations already establish that this is a safe, local read operation. The description adds the specific facts being reported but does not explain permissions, whether the path is created, or other behavioral caveats.

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

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

The definition is a single front-loaded sentence with no unnecessary wording. It states the core reported values immediately.

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 status query, the description plus output schema and read-only annotations provide enough context to invoke it correctly. The main remaining gap is routing guidance relative to the inventory init and validate siblings.

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?

This tool takes zero parameters, so parameter semantics are inherently trivial. The empty schema is fully described, and there is nothing the description needs to 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 uses a specific verb ('Show') and clearly identifies the reported facts: the automatic local inventory path and whether it exists. It does not mention sibling tools, so it lacks the explicit differentiation that would make it 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 implies a status-check use case by asking whether the inventory path already exists. However, it does not say when to use this instead of remote_inventory_init or remote_inventory_validate, nor does it state any exclusions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description usefully adds that validation covers *every* stored profile, not just one, but does not say what happens when validation fails (error thrown vs. report returned) or whether it touches the network to probe profiles.

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. It is arguably too terse for a tool whose failure mode matters, 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?

An output schema exists, so return values need no explanation here, and a zero-parameter read-only validation tool is inherently simple. The only real gap is the failure/error semantics, which is a modest omission rather than a blocking one.

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?

Zero parameters, so there is no parameter semantics to explain; baseline 4 applies. It is slightly confusing that 'the inventory JSON' is mentioned as an object of validation when the tool accepts no input, though the schema makes clear nothing is passed in.

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 ('Validate') and two specific resources (inventory JSON and all stored SSH/WinRM profiles), which distinguishes it from remote_inventory_status and remote_inventory_init in the sibling list. It does not explicitly name those alternatives, but the scope 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 a pre-flight/health-check use case but never says when to call this instead of remote_inventory_status or before/after remote_inventory_init or remote_profile_create. No prerequisites or exclusions are stated.

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

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

The annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is known. The description does add something the annotations cannot: SSH cancellation closes the named shell session, which is an important side effect. It still does not say what happens to job output, whether 'interrupt' is a graceful phase before 'cancel', or how a finished or unknown job_id is handled.

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 action verb, with no filler. 'Interrupt and cancel' is mildly redundant but may be an intentional distinction between the two phases.

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 no explanation, and the tool is simple at one required parameter. However, a destructive mutation with no annotation-independent detail about permissions, reversibility, or job_id provenance leaves the agent under-informed for a state-changing call.

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 single job_id parameter has 0% schema description coverage, so the description carries the full burden and does not compensate: it never says where a job_id comes from (presumably remote_job_list or remote_job_start) or what form it takes. The baseline of 3 for simple parameter sets is not earned here because the coverage gap is total.

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: 'Interrupt and cancel a running job.' That is enough to separate it from remote_job_start, remote_job_status, and remote_job_list without opening a schema. It stops short of naming any sibling it should be preferred over, so it is clear but not fully differentiated.

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 'a running job' implies the precondition, but there is no explicit when-to-use guidance, no statement about what to do for an already-finished job, and no pointer to the alternative tools such as remote_session_close. With 28 sibling tools in this family, the absence of routing guidance is a real gap.

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 and openWorldHint=false, so the safety profile is covered. The description adds that the listed entities are asynchronous jobs and that filtering is optional, but says nothing about ordering, pagination, or whether completed/cancelled jobs are included. With annotations carrying the safety burden, this is a modest but real contribution.

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 first and the optional filter second; every word carries information and there is no filler.

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

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

An output schema exists, so return values need not be explained, and only one optional parameter exists. Still, for a listing tool the description omits ordering, pagination/limits, and the treatment of finished jobs, which are the details an agent needs to use 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 0%, so the description must compensate for the single undocumented parameter, and it does explain the semantic role: session_name restricts the listing to one session and is optional. However, it gives no hint about accepted identifier format (name vs id) or whether an unknown session yields an error or empty results.

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+resource ('List asynchronous jobs') and adds a scoping note about sessions, so the agent knows this is the enumeration counterpart to the job_start/job_status/job_result family. It does not name any sibling explicitly, 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 guidance on when to call this versus remote_job_status, remote_job_result, or remote_session_list, and no exclusions or prerequisites. The only usage-adjacent information is that the session filter is optional, which is really parameter semantics rather than routing guidance.

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

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

With readOnlyHint and openWorldHint already declared, the description's main additional value is disclosing blocking behavior via wait and timeout, which annotations do not cover. It does not say what happens when the timeout expires (error, empty result, or partial output) or whether waiting holds a session, which matters for an agent deciding whether to block.

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 action and followed by the modifier behavior. No filler, though it is terse enough that some needed detail is omitted rather than trimmed.

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?

Because an output schema exists, the description need not describe return values, which lowers the bar. Still, for a blocking retrieval tool with three undocumented parameters, the missing timeout-default semantics and timeout-expiry behavior leave gaps an agent would want closed.

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 explains wait and that timeout bounds the wait, but leaves job_id undefined and does not clarify that the timeout default of 0 means no timeout.

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 ('Get a job result'), which is clear enough to act on. It does not explicitly distinguish itself from close siblings such as remote_job_status or remote_job_list, leaving the result-vs-status distinction to inference.

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 mention of wait=true implies this is called to retrieve output after a job has been started, which gives useful implied usage. However, there is no explicit when-to-use versus remote_job_status or remote_job_list, and no stated prerequisites such as whether the job must be finished 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 declare destructiveHint=true, openWorldHint=true, idempotentHint=false, and readOnlyHint=false, so the risk profile is covered structurally. The description adds that the call is non-blocking and yields a job ID, which is genuinely useful, but it says nothing about the timeout parameter's effect (default 86400s), what happens to the job when it expires, or that cleanup/cancel siblings exist.

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 async contract and return value are packed into one clause. Nothing here is redundant or 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?

An output schema exists, so return-value explanation is not required, and the description is adequate for identifying the tool. However, with 0% schema coverage across three parameters and a destructive annotation, the missing timeout semantics and job-lifecycle guidance (list/status/result/cancel) leave 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%, so the description must carry the burden, and it only glosses 'session_name' as 'a named session' and 'command'. The 'timeout' parameter — with a 24-hour default on a destructive, non-idempotent tool — is never mentioned, leaving a consequential parameter 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 and resource ('Start a long-running command in a named session') plus the key behavioral differentiator 'return immediately with a job ID'. This implicitly separates it from synchronous siblings like remote_execute and remote_run_program, but 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 'long-running' and 'return immediately' — the agent can infer this is the async/non-blocking path — but there is no explicit when-to-use vs. when-not statement and no pointer to remote_execute for blocking calls or to remote_job_status/remote_job_result for follow-up.

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 and openWorldHint=false, so the safety profile is covered and the bar is lower. The description adds only the notion that this targets jobs that are still running, saying nothing about whether status is terminal, whether the call blocks, or whether the job record expires — context an agent polling a job would want.

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, front-loaded sentence with no filler. It is efficient, though the terseness is part of why parameter and usage detail are absent.

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 safety. Still missing is the origin of job_id and any hint about polling behavior or terminal states, which for a status-check tool is the one piece of guidance an agent genuinely needs.

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 parameter job_id has no description at all, so the description must carry the burden of explaining it. It never states that job_id is the identifier returned by remote_job_start or what format it takes, leaving the only required argument semantically undefined.

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 ('Get') and resource ('current state of a long-running job'), which is concrete enough to act on. It does not differentiate itself from close siblings such as remote_job_result or remote_job_list, so an agent must infer that 'state' means progress status rather than output or enumeration.

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 'long-running job' implicitly signals this is a polling tool to use after remote_job_start, and 'current state' weakly distinguishes it from remote_job_result. However, there is no explicit when-to-use statement, no mention of polling cadence or terminal states, and no named alternative for retrieving results.

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 and openWorldHint=false, so the safety profile is covered. The description still adds meaningful context by disclosing that the response exposes an operator-imposed policy (host allowlist, env-var read scope, confined working directory) that constrains what other tools in the family can do — information not present in the annotations.

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

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

A single sentence, front-loaded with the two main things returned (server version, security policy), followed by a compact colon-separated enumeration. No filler and no restatement of the tool name.

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

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

With an output schema present, the description does not need to document return shape, and it nonetheless summarizes the returned fields. The only minor gap is that it does not say the call is cheap/safe to make freely or indicate when in a workflow it should be consulted.

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 to explain and the baseline applies. The description correctly spends no words on arguments and instead characterizes the output content.

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 concrete verb ('Show') and a concrete resource ('server version and the operator's security policy'), then enumerates the exact facts returned: allowed hosts, ad-hoc connection allowance, *_env variable read scope, and the sandbox directory. That enumeration makes it unmistakable against execution-oriented siblings like remote_execute or remote_test.

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 statement and no named alternative, but usage is strongly implied: this is the tool to consult before attempting ad-hoc connections, reads of *_env variables, or file/script operations that a restrictive policy could block. The guidance is inferable 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?

Annotations already cover the safety profile (not read-only, idempotent, non-destructive, closed-world), so the description only needs to add context. It does add one useful piece: credentials should be supplied as environment references rather than inline secrets. It says nothing about what happens when a profile with the same name already exists, despite the idempotent hint.

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 no filler, and the security guidance is front-loaded. However, the brevity is under-specification rather than efficiency, since the settings object needs explanation.

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 are covered. But a mutation tool that persists a secret-bearing profile, with an unconstrained settings object and no mention of failure modes or duplicate-name behavior, leaves the agent guessing on the parts that matter.

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 two parameters are named only. The critical parameter is a free-form nested settings object with additionalProperties, so the description is the only place that could enumerate valid keys, yet it names just two of them (password_env, passphrase) without format or placement. Most of the parameter surface remains opaque.

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?

"Create a saved profile" states a specific verb and resource, and the remote_profile_* sibling set makes the target clear. It doesn't explicitly contrast with remote_profile_update or remote_profile_get, but the create semantics are 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?

"Prefer password_env and passphrase environment references" is a parameter preference, not when-to-use guidance. Nothing tells the agent when to create a profile versus updating an existing one, or what prerequisites (e.g., inventory initialized) apply.

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=false, so the description's only job is to add context — yet it adds nothing. It does not say whether deletion is permanent, whether the profile must be inactive, what happens if the name does not exist, or whether related sessions/credentials are affected.

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 wasted words and the destructive verb front-loaded. Its brevity is efficient rather than padded, though it borders on under-specification.

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 and full annotation coverage reduces the burden, but for a destructive single-parameter tool with 0% parameter coverage, the description should at least clarify the identifier semantics and the permanence of deletion. Neither is provided.

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?

There is one parameter at 0% schema description coverage: 'name' carries only a type, no meaning. The description never explains that this is the profile name, whether it is case-sensitive, or whether it must match an existing profile exactly, so the single undocumented parameter is left entirely ambiguous.

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 ('Delete') and resource ('saved connection profile'), which an agent can easily distinguish from sibling operations like remote_profile_rename, remote_profile_create, or remote_profile_update. However, it does not explicitly reference any sibling to sharpen 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?

No guidance on when to use this versus alternatives such as remote_profile_rename or remote_profile_update, and no prerequisites or cautions are stated despite the operation being destructive.

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 and openWorldHint=false, and the description is consistent with a safe read. It adds genuinely new context by noting that secrets are redacted, which tells an agent not to expect credentials back; it does not cover behavior on a missing profile, but the output schema exists so return values need not be described.

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 ten-word sentence that front-loads the operation and ends with the most important caveat (secrets redacted). Every word earns its place; nothing is 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?

For a simple read tool with annotations and an output schema, the description covers the essentials, but the sole required parameter remains unexplained and there is no guidance on error behavior for an unknown profile. Adequate, with clear remaining 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?

With one parameter and 0% schema description coverage, the description carries the burden, and it only implicitly conveys that 'name' identifies the profile to fetch; it does not state the expected format, case sensitivity, or whether the name is a session/host alias. Partial compensation only.

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 ('Read') and a precisely scoped resource ('one saved connection profile'), and the word 'one' implicitly separates it from the sibling remote_profile_list. It stops short of naming that sibling explicitly, so an agent must infer the singular/plural split.

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: 'one saved connection profile' suggests fetching a known profile by identifier, and by contrast remote_profile_list would be used to discover names. There is no explicit when-to-use statement, no prerequisite (e.g. profile must exist), and no mention of 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 already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds a genuinely non-obvious behavioral fact beyond the annotations: secrets are redacted in the output, so the agent knows it cannot read credentials from this tool. It says nothing about pagination, result ordering, or the behavior when a filter matches nothing.

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 semicolon-joined sentence with zero filler, and the core action is front-loaded ahead of the redaction note and the filters. Nothing repeats the schema or annotations.

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 simple read-only list tool with an output schema available, so return-value detail is not required here. The main remaining gap is filter matching semantics, which matters because the schema supplies no parameter descriptions at all.

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, and it only restates the parameter names as "filter by protocol or tag." It does not say whether matching is exact or case-insensitive, whether both filters combine with AND, or what valid protocol values look like. That is a partial compensation, not a full one.

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 ("List saved profiles") and adds two scoping facts: secrets are redacted, and results can be narrowed by protocol or tag. That separates it from the mutation siblings (remote_profile_create/update/delete) and from remote_profile_get. It never names a sibling, so the differentiation is inferred rather than stated.

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 "optionally" tells the agent that both filters are non-mandatory, which is useful. There is no statement about when to prefer this over remote_profile_get for a single profile, nor any prerequisite or exclusion 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 this is a non-read-only, idempotent, non-destructive mutation, so the description adds nothing on the safety profile. Critically, the behaviorally significant 'overwrite' flag (default false) is never mentioned, so the agent cannot tell whether an existing target name causes a failure, a silent replacement, or an error response.

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 single sentence is front-loaded and wastes no words, which is good, but its brevity comes from under-specification rather than economy. There is room for one more clause about overwrite behavior without bloat.

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, and annotations cover the safety profile. Nevertheless, for a three-parameter mutation with zero schema documentation, the definition leaves the overwrite semantics and failure conditions entirely unspecified, which is not enough to invoke it confidently.

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

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

Schema description coverage is 0% across three parameters, so the description carries the full burden and delivers none of it. It never clarifies that 'name' identifies the existing profile while 'new_name' is the replacement, nor does it explain the optional 'overwrite' flag or its default-false consequence.

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 (Rename) plus a specific resource (saved profile), which is clearer than the bare name and distinguishes the action from create/delete/list siblings. It stops short of explicitly differentiating from remote_profile_update, which is the nearest alternative and covers overlapping intent.

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 at all: no statement of prerequisites, no mention of when to prefer this over remote_profile_update, and no indication of what happens on name collision. The agent must infer all routing decisions from the tool 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?

The description says replace=true fully replaces the profile and remove_fields deletes optional settings, which is destructive behavior. This contradicts the destructiveHint=false annotation, so the description conflicts with structured safety metadata despite adding useful merge/replace details.

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

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

The description is two concise sentences with the primary update modes front-loaded. Every sentence contributes useful information without repetition or filler.

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

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

It covers the key update modes and required-field validity constraint, which is helpful for a nested-object update tool. It remains incomplete because the changes payload is undocumented and the destructive replacement behavior is not reconciled with the annotations.

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

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

The description adds meaning for replace and remove_fields, explaining full replacement and field deletion. With 0% schema description coverage, however, it still does not explain the required name identifier or the structure and accepted keys of the changes object.

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: update a profile with either merge or full replace semantics. It is clear, but it does not explicitly distinguish this tool from sibling operations like remote_profile_rename or remote_profile_create.

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 use replace=true and remove_fields, which is useful mode-selection guidance. However, it does not say when to choose this tool over siblings such as remote_profile_rename, remote_profile_create, or remote_profile_delete.

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, open-world, and non-idempotent behavior, so the description is not responsible for the full safety profile. It adds useful context that arguments are safely quoted, but it does not explain execution side effects, output handling, permission requirements, or how saved versus ad-hoc targets behave.

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

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

The description is a single front-loaded sentence with no wasted wording. However, its compression sacrifices clarity around what 'target' means and how it maps to profile or connection.

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 remote execution tool with eight parameters, zero schema descriptions, and many similarly named siblings, the definition is too thin. It does not explain target selection, timeout behavior, output limits, environment handling, or when this tool should be used instead of related execution 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 0%, so the description must carry parameter meaning. It mentions the program, an argument list, and a target, but leaves cwd, env, timeout, output_limit, profile, and connection semantics unexplained, which is a significant gap for an 8-parameter execution 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 gives a specific verb and resource: run an executable with a safely quoted argument list. It also clarifies the execution target as saved or ad-hoc, which separates it from purely script- or session-oriented siblings, though it does not explicitly distinguish itself from remote_execute or remote_run_script.

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 provides no explicit when-to-use, when-not-to-use, or alternative-tool guidance. The phrase 'saved or ad-hoc target' gives some context, but an agent must infer whether to choose this over remote_execute, remote_run_script, remote_session_execute, or remote_command_group_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 destructiveHint=true, openWorldHint=true, and idempotentHint=false, so the risk profile is covered. The description adds real context by disclosing the upload mechanic (the script lands on the remote host) and the supported language matrix, but says nothing about cleanup deleting the uploaded file, the 600s default timeout, or output 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?

Two short sentences with the core action front-loaded and the language support enumerated compactly. Nothing is redundant, though the second sentence could have carried operational detail instead of just a format list.

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. However, for a destructive, open-world execution tool with 11 undocumented parameters and several close siblings, the description leaves critical gaps around target selection and cleanup 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% across 11 parameters, so the description must compensate and it largely does not. The language list loosely maps to the language parameter and "inline or local" maps to script/local_path, but cleanup, timeout, output_limit, profile, connection, interpreter, remote_path, and args are left entirely undefined.

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 pair ("Upload and run") and resource ("inline or local script"), which is concrete enough for an agent to know the operation. It does not differentiate from siblings like remote_execute, remote_run_program, or remote_session_execute, which occupy similar space.

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 mention of "inline or local script" implies two input modes but gives no guidance on when to pick this tool over remote_execute, remote_run_program, or remote_session_execute. No prerequisites, no exclusions, no conditions are stated.

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

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

Annotations already flag destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the risk profile is known. The description adds the useful semantic that only *named* sessions are candidates and only those past the idle cutoff, but it never says what the sessions or their pending work lose, whether active-but-idle sessions are skipped, or whether partial failure is possible — meaningful gaps for a destructive bulk operation.

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

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

One sentence, front-loaded with the action and immediately qualified by the selection criterion; no filler. Its only weakness is that the brevity leaves behavioral gaps rather than any padding or awkward ordering.

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 no explanation, and annotations cover the destructive profile. Still, for a non-idempotent bulk teardown of sessions, the definition says nothing about scope limits, side effects on running work, or how the eligible-session set is determined — a few more clauses would make it safely callable.

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 one parameter at 0% schema description coverage, the description carries the load: 'idle for at least the requested number of seconds' gives the unit and the inclusive-threshold semantics, which the schema alone does not. It omits the 3600-second default and the fact the parameter is optional, so an agent cannot tell from prose what happens when it 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 plus resource plus the qualifying condition: close named sessions that have been idle for at least N seconds. That clearly separates it from remote_session_close (unconditional close) and remote_session_close_all, 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?

The idle threshold implies when to reach for this tool (periodic housekeeping) versus a targeted close, but there is no explicit when-to-use or when-not-to-use statement and no mention of remote_session_close / remote_session_close_all as alternatives. The agent must infer the 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 already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the risk profile is covered structurally. The description adds the useful detail of what is torn down (the remote shell/runspace), but says nothing about behavior when the named session does not exist or whether partial teardown can occur.

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 with no filler, and the key scope qualifier ('one named session') is front-loaded. Nothing could be removed without losing 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?

An output schema exists, so return values need not be described, and annotations cover the destructive nature of the call. What remains missing for a destructive single-target operation is failure behavior (unknown name, already-closed session) and whether the close waits for teardown to complete.

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

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

Schema description coverage is 0% for the single 'name' parameter, so the description carries the burden; it does add that the name identifies the session to be closed. However, it gives no format hints (exact vs. prefix match, case sensitivity) for resolving the session name, which is the main ambiguity.

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 ('Close') and resource ('one named session and its remote shell/runspace'), and the phrase 'one named session' implicitly separates it from the bulk sibling remote_session_close_all. It does not explicitly name that sibling, so the differentiation is inferable rather than stated.

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: close a single identified session, as opposed to close_all or cleanup_idle. There is no explicit when-to-use, when-not-to-use, or named alternative, leaving the agent to infer the choice from the word '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?

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered structurally. The description adds nothing beyond that: it does not say whether other users' sessions are affected, whether in-flight jobs are aborted, or whether confirmation is required for this irreversible bulk action.

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, appropriate for a no-argument tool. It is efficient but so terse that a caution clause could have been added without bloat.

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, and there are no parameters to document. However, for a destructive, non-idempotent bulk operation, the description omits blast-radius detail such as multi-user impact and job interruption, leaving the agent under-informed before an irreversible call.

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 and the baseline applies. Nothing in the description misleads 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?

"Close every active session" names a specific verb and resource, and the word "every" signals bulk scope versus the singular remote_session_close sibling. It stops short of naming that sibling explicitly, so the differentiation is inferable rather than stated.

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 all-or-nothing scope is implied, but there is no explicit when-to-use guidance, no pointer to remote_session_close for single-session shutdown, and no mention of remote_session_cleanup_idle as a less aggressive alternative. The agent must infer the choice from tool names 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 destructiveHint=true, openWorldHint=true, idempotentHint=false, and readOnlyHint=false, so the safety profile is covered structurally. The description adds genuinely useful behavior beyond that: the call blocks until the command finishes. It does not disclose what a timeout does to a running command, whether output is truncated, or what privileges the command runs under.

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 sentence, front-loaded with the action and target, with the blocking semantic appended where it matters. 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?

An output schema exists, so return values need not be explained. But for a destructive, open-world tool with 0% schema coverage on two optional parameters, the definition is too thin: an agent cannot know what timeout means in practice or how output_limit affects results, which directly impacts 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% across 4 parameters, so the description must compensate and largely fails. It clarifies that 'name' refers to a session name and that 'command' is what gets executed, but 'timeout' (default 3600) and 'output_limit' (default null) are never mentioned, leaving their units and truncation behavior undocumented anywhere.

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 ('Run a command') and a specific target ('a named persistent session'), plus the blocking behavior ('wait for completion'). This distinguishes it implicitly from one-shot execution siblings like remote_execute and async siblings like remote_job_start, though it never names an alternative explicitly.

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

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

'Inside a named persistent session' implies the prerequisite that a session must already exist (via remote_session_open), and 'wait for completion' implies synchronous use. However, there is no explicit when-to-use/when-not guidance and no routing to remote_execute, remote_job_start, or remote_run_program, leaving the agent to infer the choice.

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 and openWorldHint=false, so the safety profile is covered. The description adds useful scoping context (only active sessions, only named ones, health included), but leaves ambiguous what "health" means and whether the result is bounded or paginated.

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 the resource and scope front-loaded and no filler. Nothing in it is redundant with the annotations or 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?

For a zero-argument read tool with an output schema, the description covers what is returned and which sessions qualify, so an agent has enough to invoke it correctly. The only gap is the undefined notion of "health," which the output schema presumably details.

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 nothing for the description to disambiguate. The description adds no misleading parameter language and correctly implies no filtering input is accepted.

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 ("List") and a specific resource ("active named sessions") plus the payload attribute ("health"), so an agent can distinguish it from session mutation siblings like remote_session_open/execute/close. It stops short of explicitly contrasting with remote_job_list or other enumerating tools, but the scope is clear.

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 statement, no prerequisites, and no named alternative. The word "active" implies it will not return closed sessions, but an agent is left to infer that this is the discovery step before remote_session_execute or remote_session_close.

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, openWorldHint=true and non-idempotent, so the safety profile is covered; the description adds genuinely new behavior — session lifetime ends only on close or server process exit, SSH shell state (cwd, exported variables) persists, and WinRM reuses a single PSRP runspace. What is still missing is what happens on a name collision and whether connection/credentials are required at open time.

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

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

Three short sentences, front-loaded with the action and followed by the persistence semantics that actually matter for deciding to call it. No filler, though the trailing sentence about WinRM is terse enough that it reads slightly as an implementation note rather than agent-facing 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 annotation set covers the risk profile, leaving the description to carry lifetime and state-persistence semantics — which it does. The remaining gap is parameter-level (profile and connection), which materially affects correct invocation of a session-opening 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 carries the full burden, yet it only indirectly explains two of four parameters — 'named' maps to name and 'SSH shell or WinRM' maps to shell. The profile and connection parameters, including the connection object that presumably carries host and credentials, get no explanation at all, leaving the most consequential input 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?

The description opens with a specific verb and resource — 'Open a named persistent SSH shell or WinRM PowerShell runspace' — which tells an agent exactly what is created and the two transport modes supported. It does not explicitly name a sibling like remote_session_execute or remote_session_close to sharpen the boundary, 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?

Usage is only implied: the word 'persistent' and the note that cwd/exported variables persist tell an agent this is for stateful, multi-step work rather than one-shot commands. There is no explicit 'use this instead of remote_execute when…' statement, and no mention of when a persistent session is unnecessary or what to do if one already exists.

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 and openWorldHint=true, so safety and network scope are covered. The description adds that a harmless marker command is executed, confirming the probe is non-destructive, but says nothing about authentication requirements, timeouts, or what constitutes success versus failure on an unreachable host.

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 purpose is front-loaded in one sentence and the SSL guidance follows as secondary detail with no filler. The line break mid-sentence is cosmetic; overall it is tight and earns its length.

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

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

Error behavior on failure and the exact nature of the marker command are not spelled out, but for a diagnostic probe with an output schema and safety annotations this is a minor omission. An agent has enough to select and call it correctly, including the tricky SSL/cert cases.

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

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

Schema coverage is 0%, so the description carries the load. "Saved or ad-hoc" implicitly maps to the profile and connection parameters, and the SSL notes document nested connection fields (ssl, cert_validation) that the schema leaves entirely bare, but the top-level parameters are never named or described, leaving a real gap at 0% coverage.

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

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

Uses a specific verb ("Test") on a specific resource ("a saved or ad-hoc connection") and distinguishes the two connection modes (profile vs. inline connection). It doesn't name any sibling tool or explain where this fits relative to remote_execute or remote_session_open, 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?

Usage is only implied: you call it to verify a connection before doing real work. The SSL paragraph does give conditional guidance (port 5986 -> ssl=true, self-signed -> cert_validation=false, ssl=false means plain HTTP not disabled verification), which is genuinely useful, but there are no exclusions, prerequisites, or alternatives named.

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=false, and openWorldHint=true, so the risky profile is known. The description adds nothing about the most important behavioral unknown for an upload: whether existing remote files are overwritten, whether parent directories are created, or what happens on partial transfer failure. For a destructive, non-idempotent write, that is a real gap beyond the 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?

Two short sentences, front-loaded with the core action and followed by the one non-obvious flag. Nothing is padded, though the extreme brevity contributes to the parameter and behavior gaps 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?

An output schema exists, so return values need not be explained, but this is a destructive open-world write with five parameters and no schema descriptions. Key facts an agent needs before calling — overwrite semantics, what profile/connection do, and directory prerequisites — 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?

Schema description coverage is 0%, so the description must compensate, and it only covers two of five parameters implicitly (local_path/remote_path) plus recursive explicitly. The profile and connection parameters, which likely control authentication and target host selection, are completely undocumented in both schema and description.

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

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

The description gives a specific verb and resource ("Copy a local file or directory to a remote host"), which cleanly distinguishes it from the sibling remote_download. It stops short of naming a sibling explicitly, but the directionality (local to remote) makes the distinction 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?

Usage is implied by the phrase "to a remote host" plus the operational hint "Set recursive=true for directories," which is genuinely actionable. However, there is no guidance on when to prefer this over remote_download, remote_run_script, or the session-based tools, and no prerequisites (profile/connection selection) are described.

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