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

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing. It does not state whether the connection is persistent/stateful, what happens on authentication failure, whether a prior session is replaced, or how long the session survives — all critical for an RCON session 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?

A single short sentence with no filler and the action front-loaded. It is efficient, though its brevity borders on under-specification given the stateful nature of the operation.

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 session-establishing tool that many siblings depend on, and with no annotations or output schema to lean on, the description leaves key context unstated: session persistence, prerequisite ordering, and failure behavior. Only the bare action is communicated.

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

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

Schema description coverage is 100%: host, port (with default 27015) and password are all documented in the schema, including the typical port value. The description adds no additional meaning beyond that, so the baseline 3 for high schema coverage applies.

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

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

The description states a specific verb (подключиться/connect) and a specific resource (Garry's Mod server via RCON), which distinguishes it from the sftp_* siblings and the other gmod_* tools. It does not, however, explicitly relate itself to gmod_disconnect or gmod_execute_rcon as its counterpart operations.

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

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

No when-to-use guidance is given: it does not say this must be called before gmod_execute_rcon/gmod_execute_lua/console commands, nor that gmod_disconnect ends the session. The agent must infer the ordering from the 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?

With no annotations, the description carries the full burden and does a lot: [Windows only] platform limit, [Experimental] stability warning, the focus-stealing UI-automation sequence, and the Russian-layout caveat. Missing only failure/return behavior, but the operational risk profile is well disclosed.

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?

Platform and experimental flags are front-loaded, followed by the action, the mechanism, the caveat, and the alternative. Dense and largely waste-free, though the step-by-step mechanism sentence is slightly verbose relative to what an agent needs to invoke the tool.

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

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

For a one-parameter tool with no annotations and no output schema, the description covers platform scope, stability risk, mechanics, a known failure mode, and sibling routing. Return behavior is unspecified, but that is minor here.

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

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

Schema description coverage is 100% and the single parameter is already documented with examples in the schema itself. The description adds no syntax, format, or constraint detail beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb and resource ('Выполнить команду через консоль Garry's Mod') and describes the exact mechanism used (focus window, open console, type, Enter, close). It also names which sibling it is not and why ('Для серверных команд лучше использовать gmod_execute_rcon'), so the agent can route correctly without opening a schema.

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

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

Gives an explicit alternative and the condition that selects it: server-side commands should go to gmod_execute_rcon. It also warns about the Russian keyboard layout failure mode. It does not spell out the positive case (which client-side commands suit this tool), but the routing guidance is clear.

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

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

With no annotations, the description carries the full behavioral burden, yet it discloses nothing about side effects: whether the session state is lost, whether in-flight rcon/lua operations are terminated, or whether the action is reversible by reconnecting. For a state-destroying action this is a meaningful gap.

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

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

A single short sentence that front-loads the action and names the target, with no filler. Nothing could be trimmed without losing meaning.

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

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

For a zero-parameter, no-output-schema action tool the description is minimally sufficient to select and call it. It stops short of covering prerequisites or post-disconnect state, which an agent managing a session would benefit from knowing.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. No parameter-level detail is needed or missing.

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 (disconnect) and resource (Garry's Mod server), so the action is unambiguous. It does not explicitly name or contrast with gmod_connect, but the inverse naming makes the distinction obvious.

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 stated context for when to invoke this, no prerequisite (e.g. must be connected first), and no mention of alternatives such as sftp_disconnect or gmod_execute_rcon. The use case is only inferable from the verb itself.

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

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

With no annotations, the description carries the full burden and does well: it discloses the semicolon-splitting behavior, that local variables do not persist across calls, the required global-variable workaround, and a ~180-character per-statement limit. It omits auth/permission requirements and error/failure behavior, so it stops short of a 5.

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

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

Front-loaded purpose followed by three high-value constraints in as many clauses, with no filler. The 'ВАЖНО' marker correctly emphasizes the non-obvious local-variable pitfall.

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

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

For a single-parameter code-execution tool with no output schema, the description covers the critical operational gotchas an agent must know to succeed. It leaves open what the tool returns (e.g., whether print output is captured) and whether special privileges are needed.

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

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

Schema description coverage is 100%, so the single 'code' parameter is already fully documented, including an example. The description adds the statement limit and the global-variable rule, which is meaningful framing, but the baseline of 3 applies when the schema does the heavy lifting.

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

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

States a specific verb and resource (execute Lua code on the Garry's Mod server) and even names the underlying mechanism (splitting into lua_run calls). It is clearly distinct from gmod_execute_rcon by the resource type, though it never explicitly names the sibling to route between them.

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

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

The description gives how-to-write-code guidance (global variables, statement limit) but no guidance on when to pick this tool over gmod_execute_rcon or gmod_console_command, and no preconditions or exclusions. An agent must infer the selection criteria from the name alone.

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

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

No annotations are provided, so the description carries the full behavioral burden for an arbitrary remote command execution tool. It does not state that RCON must be enabled/authenticated on the server, that commands can mutate or destroy server state, or what happens on failure or timeout.

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

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

A single short sentence that is front-loaded and wastes no words. Its brevity, however, reflects under-specification rather than disciplined concision, since behavioral context is missing.

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

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

For an execution tool with no annotations and no output schema, the description is too thin: it omits prerequisites (RCON enabled, server connected), the destructive potential of arbitrary commands, and how results are returned or observed. An agent cannot safely call it on this text alone.

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

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

Schema description coverage is 100% and there is only one parameter, whose schema description ('RCON команда для выполнения') mirrors the tool description. The description adds no syntax, formatting, or quoting guidance beyond what the schema already provides, so the baseline 3 applies.

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

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

States a specific verb (Выполнить) and resource (RCON команда) on a named target (Garry's Mod server), so an agent immediately knows what the tool does. However, it gives no differentiation from closely related siblings such as gmod_console_command or gmod_execute_lua, which also run server-side commands.

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

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

There is no guidance on when to use RCON execution versus gmod_console_command, gmod_execute_lua, or gmod_connect. The agent must guess which command channel is appropriate based on 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?

With no annotations, the description carries the full burden. It usefully discloses two behavioral traits: a Windows-only platform restriction and the required running-game state. It omits what happens on failure (error vs no-op) and any return behavior, so coverage is partial.

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

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

Two short clauses with the platform constraint front-loaded in brackets, followed by the precondition. Every word earns its place with no filler.

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

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

For a zero-parameter, no-output-schema window action, the description covers the platform caveat and the required game state, which is most of what an agent needs. Failure behavior is the only notable 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?

The tool takes zero parameters and the schema is empty, so there is nothing for the description to clarify. Baseline 4 applies; no parameter meaning is missing.

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

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

The description states a specific action and resource: restore and bring the Garry's Mod window to the foreground. This is unambiguous and distinct from every sibling (connect, rcon, lua, screenshot, zoom, keys, console), though it does not explicitly name those alternatives.

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 supplies one concrete precondition, 'Требуется запущенная игра' (the game must be running), which tells the agent when the call is valid. It gives no guidance on alternatives or on what to do when the precondition fails, so usage is implied rather than fully framed.

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

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

No annotations are provided, so the description carries the behavioral burden. It discloses the platform restriction, the automatic open-screenshot-close sequence, and the PNG return format—useful automation details. It omits prerequisites like game running or window focus, and does not state whether opening the console alters game state.

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 critical [Windows only] constraint, then the action sequence, then the return type. No wasted words.

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

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

For a simple zero-parameter screenshot tool with no output schema, the description sufficiently explains the output as a PNG image of console contents. It could be slightly more complete by specifying how the image is returned (e.g., inline content vs. file path) or noting focus prerequisites, but overall it is adequate.

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

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

The tool takes zero parameters, so the baseline is 4. There are no parameter semantics to clarify beyond what the empty schema already communicates.

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

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

States a specific verb+resource: screenshot of the Garry's Mod client console, with automatic open/close and PNG output. Clearly distinguishes from generic gmod_screenshot and from gmod_console_command, which sends commands rather than reading console output.

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

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

The description implies the tool is for viewing console output and notes the Windows-only constraint, but gives no explicit when-to-use guidance, no alternatives (e.g., gmod_console_command or gmod_screenshot), and no exclusions. Usage is inferable but not stated.

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

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

With no annotations, the description carries the full burden and mostly succeeds: it discloses the return type (PNG image), two side effects on system state (the target window is maximized and brought to the foreground), and a runtime prerequisite (game must be running). It stops short of saying what happens on failure or how the resulting image is delivered.

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?

Four short sentences, each earning its place: platform gate, action, return value, side effect, and prerequisite. Front-loaded with the platform restriction and with no filler or redundancy.

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

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

For a parameterless tool with no output schema, the description supplies everything needed to invoke it correctly: platform, required game state, side effects, and return format. The main gap is the absence of any failure-mode or ordering guidance relative to the other gmod_* 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?

The tool takes zero parameters, so the baseline of 4 applies; there is no parameter surface for the description to explain. The description correctly implies the capture target is implicit (the GMod window) rather than configurable.

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 — take a screenshot of the Garry's Mod window — and adds distinguishing constraints (Windows only, game must be running). It does not name any sibling explicitly, but 'screenshot of the GMod window' is unmistakably distinct from gmod_focus_window, gmod_zoom, or gmod_execute_lua.

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

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

It gives real preconditions — Windows-only platform and a running game instance — which tells the agent when the call is valid. However, it never routes the agent between alternatives (e.g. gmod_focus_window for bringing the window forward without capturing, or gmod_zoom for a scaled view), so selection guidance is only 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?

No annotations are provided, so the description carries the full burden and does disclose the Windows-only platform constraint plus the accepted key syntax. However, it omits behavioral preconditions such as whether the target window must be focused first (a sibling gmod_focus_window exists) and whether the call blocks or requires the game to be running.

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 compact sentences, with the platform constraint and purpose front-loaded before the format details. Efficient, though the format/modifier list partly duplicates the schema's parameter description.

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

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

For a single-parameter, no-annotation, no-output-schema tool, the description covers purpose, platform and syntax adequately. It still leaves the focus/precondition question open, which is the main thing an agent would need before invoking it correctly.

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

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

Schema coverage is already 100%, so the baseline is 3; the description earns a bump by supplying a concrete worked example ('status{ENTER}') that shows how to mix literal text and special keys, which the schema does not demonstrate.

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

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

States a specific verb+resource: sending key presses into the Garry's Mod window, with a platform qualifier ([Windows only]) and the exact SendKeys format. It is distinguishable from gmod_execute_rcon / gmod_execute_lua / gmod_console_command, though it never names those siblings to make the boundary explicit.

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 'Windows only' note is a real usage condition and the SendKeys example implies UI-level input, but there is no explicit when-to-use-this-vs-alternatives guidance. An agent must infer that this is for simulating keyboard input rather than issuing commands via the console/rcon tools.

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

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

No annotations exist, so the description carries the full behavioral burden. It usefully discloses the Windows-only platform constraint and the coordinate interpretation rule, but says nothing about required window state/focus, whether it is a read-only capture, or rate/performance implications.

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

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

A single compact sentence block with the critical platform constraint front-loaded in brackets, then the coordinate rule, then the use case. 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?

No output schema exists, so the description ideally should note the return form, but 'Screenshot + zoom' implies an image result. The main omission is whether the target window must be focused/visible for the capture to succeed, which is material for a screen-capture tool.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning the schema omits: that values are percentages of window size, and that values >100 are interpreted as pixels. This disambiguation rule is genuinely useful for correct invocation.

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

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

States a specific verb+resource: capture and zoom a region of the Garry's Mod window, with an explicit Windows-only scope. It is clearly distinguishable from gmod_screenshot because it adds a zoom/region capability, though it never explicitly contrasts itself with that sibling.

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

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

Gives concrete usage context — 'useful for reading small text, UI elements, console' — which tells the agent when this tool is the right choice. It does not name an alternative or state when-not to use it, so it stops short of full 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?

No annotations are provided, so the description must carry the full behavioral burden. It says nothing about authentication requirements (password/privateKey), session persistence, error handling, or that a connection should be closed via sftp_disconnect. It also doesn't disclose any rate limits or side effects.

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

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

A single sentence that is front-loaded and free of filler. It earns its place but could be expanded slightly to include essential context; as written, it is efficient but minimal.

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 5-parameter connection tool with no annotations and no output schema, the description is too sparse. It omits authentication mode, whether the connection persists, and the need to call sftp_disconnect, leaving significant gaps for correct invocation.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-level information; the schema already documents host, port, username, password, and privateKey with descriptions and default.

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

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

States a specific verb+resource: 'Подключиться к серверу по SFTP' (connect to SFTP server). It clearly conveys establishing an SFTP connection, and the sibling set includes sftp_disconnect and file operations, but the description does not explicitly differentiate itself from those alternatives.

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

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

No explicit when-to-use, when-not, or alternative guidance. The phrase 'для управления файлами' implies a prerequisite for file management operations, but it does not instruct the agent to use sftp_disconnect afterward or contrast with other connection tools.

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

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

No annotations and the description doesn't disclose whether deletion is permanent, requires elevated permissions, or fails on non-existent files. Only the operation is stated without rich behavioral context.

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 zero waste.

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

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

For a destructive operation with no annotations and no output schema, the description omits critical context: required connection state, error conditions, and deletion irreversibility.

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?

Single parameter with 100% schema coverage; description's mention of 'full path' aligns with schema but adds no extra syntax details, which is acceptable for one param.

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 (file on remote server via SFTP), clearly distinguishing from siblings like sftp_write_file or sftp_read_file.

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 context given about when to use this versus alternatives, prerequisites (e.g., must be connected via sftp_connect), or whether it works on directories.

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

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

With no annotations provided, the description carries the full behavioral burden but offers only the bare action. It does not say whether the call is idempotent, what happens if no session exists, whether the connection handle is released, or whether errors are raised — all relevant for a teardown 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?

A single short sentence with no filler and the action front-loaded. It is appropriately sized for a trivial operation, though it is arguably too terse to carry any extra context.

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

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

For a zero-parameter, no-annotation disconnect with no output schema, the description covers the essential action but omits teardown semantics such as error-on-no-connection or session-release behavior. Adequate but with clear gaps.

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

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

The tool takes zero parameters, so there is nothing for the description to document; baseline 4 applies. No parameter meaning is missing.

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 (disconnect, 'Отключиться') and resource (SFTP server), so the agent immediately knows the operation. It does not explicitly differentiate itself from sftp_connect, but the pairing is unambiguous given the sibling names.

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

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

There is no statement of when to call this versus leaving the session open, no prerequisites (e.g., an existing connection), and no reminders about cleanup ordering relative to sftp_read_file/sftp_write_file. Usage is only inferable from the verb.

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

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

No annotations are provided, so the description carries the full burden. It implies a read-only listing but never states it, nor does it mention that a connection must already exist, what happens for a missing/invalid path, or whether results are paginated or sorted.

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 efficient, though extremely terse given the tool has room to say more.

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

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

For a one-parameter listing tool with no output schema this is minimally adequate, but with a sibling sftp_connect present, the omission of the session prerequisite and any return-shape hint leaves a real gap.

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

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

Schema description coverage is 100% and there is a single required 'path' parameter with its own description, so the schema already does the work. The tool description adds no format or semantic detail (relative vs absolute path, trailing slash behavior) beyond it.

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 (list) and resource (files in a directory) plus the transport (SFTP on a remote server), which cleanly separates it from sibling writes/deletes like sftp_write_file or sftp_delete. It stops short of naming alternatives, but the purpose is unambiguous.

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

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

No guidance on when to use this versus sftp_read_file or other siblings, and no prerequisite noted (e.g., an active session from sftp_connect). The agent must infer all context.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does not state permission/auth requirements, whether the file is read as text or binary, encoding, size limits, or what happens on a missing path — all of which matter for a remote file read.

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

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

A single short sentence with no filler; the action and resource are front-loaded. It is efficient, though arguably under-specified rather than optimally concise.

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

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

With no output schema, the description should tell the agent what comes back (file contents? encoding? error shape?) and that a connection must exist first. Neither is present, leaving the agent guessing about the most important outcome of the 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?

Schema description coverage is 100% and the single 'path' parameter is fully documented in the schema as 'Полный путь к файлу на сервере'. The description adds no further parameter meaning, so the baseline of 3 applies.

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

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

States a specific verb ('Прочитать') and resource ('файл') plus the transport ('через SFTP'), which cleanly separates it from siblings like sftp_write_file and sftp_delete. It does not, however, say anything about scope or format (text vs binary) that would fully distinguish it from the other SFTP read-adjacent siblings such as sftp_list_dir.

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 and no mention of the obvious precondition that an SFTP session must already be established (sftp_connect is a sibling). The agent must infer all routing and sequencing on its own.

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

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

With no annotations provided, the description carries the full behavioral burden. It implies a mutation but never states whether an existing file is overwritten, whether parent directories are created, what permissions/authentication are required, or what happens on failure. For a write operation this is a significant gap.

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 action front-loaded and no filler. It is efficient, though its brevity borders on under-specification rather than tight writing.

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

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

For a two-required-parameter mutation tool with no annotations and no output schema, the description omits key context: connection prerequisites, overwrite semantics, and failure/return behavior. The schema covers the parameters, but the behavioral picture an agent needs is 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 100% - 'path' and 'content' are both documented directly in the schema - so the baseline is 3. The description adds no syntax, format, or encoding detail beyond what the schema already provides (e.g. whether content is text or base64).

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

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

The description states a specific verb+resource ('Записать/загрузить файл', write/upload a file) plus the transport (via SFTP) and target (remote server), which cleanly separates it from siblings like sftp_read_file and sftp_delete. It is clear without being explicitly differentiated from siblings in prose.

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

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

There is no guidance on when to use this tool versus alternatives, no prerequisites (e.g. that sftp_connect must run first), and no mention of related siblings such as sftp_delete or sftp_read_file. Usage is only inferable from the name.

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