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

With no annotations, the description carries the burden of behavioral disclosure. It usefully reveals that a tar.gz archive and sha256 file are created under a date-tag directory, but it omits important operational details such as permissions, whether existing backups are overwritten, and failure behavior.

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

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

The description is two tightly written sentences with no wasted text. The core operation and destination are front-loaded, followed by a concise usage note.

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

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

For a three-parameter tool with no output schema, the description covers the essential purpose, destination layout, and invocation context. Minor gaps remain around host semantics and backup-overwrite behavior, but the definition is largely sufficient to call the tool correctly.

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

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

Schema description coverage is 67%, and the description adds some meaning by showing that tag is embedded in the backup directory name and that path refers to a remote file or directory. However, host remains unexplained in both schema and description, leaving a notable 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 states a specific verb and resource: backing up a remote file or directory. It also specifies the archive format (tar.gz), destination pattern, and accompanying sha256 file, making the operation distinct from sibling tools like exec or file_write.

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 explicitly says to use this before editing via exec, giving a clear triggering context and naming the relevant sibling tool. It does not describe when not to use it or mention alternative backup approaches, so it falls short of full when/when-not guidance.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses shell wrapping and automatic quoting, but omits permissions/security implications, container-running preconditions, output truncation behavior, timeout behavior, and mutation 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?

One front-loaded sentence with no wasted words. The execution mechanism and quoting behavior are stated efficiently.

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 arbitrary container command-execution tool with no annotations and no output schema, the description is too sparse. It should at least clarify host/container targeting, timeout/output-cap behavior, and the fact that commands may mutate container state.

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

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

Adds useful meaning for `cmd` by explaining it is shell text and that the tool handles quoting. However, schema coverage is only 60%, and `host` is undocumented in both schema and description; timeout and max_chars are also not addressed in the 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 resource: running a command inside a container via `sh -c`. This clearly separates it from docker_ps/docker_logs, though it does not explicitly distinguish it from the sibling `exec` tool.

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?

Explains how to phrase the command but not when to use this tool instead of `exec` or other command-running siblings. No preconditions, exclusions, or alternative-selection guidance are provided.

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 usefully states that stdout and stderr are merged, but it does not disclose whether the call streams/follows, blocks, requires Docker permissions, is read-only, or how output is capped.

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 words. Its brevity is efficient, though it is arguably too sparse for a tool with five parameters.

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

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

For a five-parameter tool with no annotations and no output schema, the description is incomplete. It does not explain return behavior, whether logs are followed, permission requirements, or the roles of the remaining parameters.

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 no parameter meaning beyond the schema. With only 60% schema description coverage, important parameters such as host and tail are undocumented in both the schema and the description, and the description does not compensate.

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 ('Tail') and resource ('container's logs') and clarifies that stdout and stderr are merged. It does not differentiate this from sibling tools such as docker_exec or exec, so it stops short of a 5.

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

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

There is no guidance on when to use this tool instead of docker_exec, exec, or other siblings, nor are prerequisites or exclusions mentioned. The intended use is only implied by the word 'Tail'.

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 discloses the tab-separated output format, but does not mention permissions, read-only nature, error behavior, or how host connectivity 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?

A single, front-loaded sentence that states the action, resource, and output shape with 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 read-only listing tool, the description covers the output columns but leaves the required host parameter ambiguous and does not explain defaults or filtering behavior. It is minimally adequate but misses important context 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 coverage is 67%, but the required 'host' parameter has no description in either the schema or the description. The description adds output formatting but does not clarify what 'host' expects, nor does it explain how 'filter' interacts with the returned line format.

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

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

The description states a specific verb and resource ('List containers on a host') and specifies the returned fields. It is clear what the tool does, though it does not explicitly differentiate itself from siblings like docker_logs or docker_exec.

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 such as docker_logs or docker_exec. The default behavior of including stopped containers is only visible in the schema, not explained in usage terms.

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 must carry the full behavioral disclosure burden. It says this is equivalent to SSH and explains command quoting, but it does not disclose permissions, destructive potential, side effects, authentication requirements, or output behavior for an arbitrary remote shell execution 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?

The description is short and front-loads the key invocation model, which is good. However, the trailing incomplete fragment 'Hosts: ' is a structural defect that wastes space and leaves promised host information 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?

This is a high-risk arbitrary command execution tool with no annotations and no output schema, so the description should be more complete. It omits safety implications, host list details, permissions context, and output behavior, leaving the agent without enough information to invoke it confidently in a multi-tool environment.

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 50%, so the description needs to compensate for the undocumented `host` and `cmd` parameters. It partially does so by mapping them to the SSH analogy and specifying that `cmd` should be written without outer quotes, but the host enumeration is truncated at 'Hosts: ' and `timeout`/`max_chars` are left entirely to the schema.

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 and resource: 'Run a shell command on a host,' and clarifies the execution model with the `ssh <host> '<cmd>'` analogy. It hints at sibling alternatives with 'Prefer a dedicated tool when one fits,' but does not name any sibling tool, so differentiation is only partial.

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 a minimal usage rule: prefer a dedicated tool when one fits, implying `exec` is the fallback for arbitrary shell commands. However, it does not name which siblings fit which cases, nor does it state when-not to use this tool beyond that vague preference.

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, yet it discloses only that the target must be a text file. It says nothing about truncation behavior, the max_chars cap, permission/error behavior, or what happens when the file is large or binary.

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 the terseness pushes detail burdens onto other dimensions rather than being a structure flaw.

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 remote-read tool with no annotations and no output schema, the description omits return shape, truncation signaling, and binary/encoding handling. An agent can guess how to call it but not what to expect back.

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 60%, and 'optionally a line range' loosely maps to start_line/lines, but the interaction between lines and start_line is not explained. The host and max_chars parameters get no added meaning from the 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+resource ('Read a remote text file') and scopes it to text files with an optional line range. It is easy to distinguish from the sibling file_write, but the description never names or contrasts with any sibling explicitly.

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

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

No guidance on when to use this versus alternatives such as exec or http_probe for retrieving content, and no prerequisites (host reachability, auth) are stated. Usage is only implied by 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?

With no annotations, the description carries the full burden and does most of it well: it discloses the backup location (~/ops-backups/<date>-auto/), atomic replacement, preserved mode and owner, and that append appends rather than replaces. Missing are prerequisite/privilege requirements on the remote host and failure behavior — the main remaining gaps for an unannotated mutation 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 dense sentence with the core write guarantee front-loaded, followed by the mode-specific behavior. No filler, and each clause adds operational information.

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

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

For a five-parameter mutation tool with no annotations and no output schema, the description covers the risky parts (backup, atomicity, permissions preservation) well. It stops short of explaining the host parameter and error/return behavior, which an agent would still need to guess at.

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

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

Schema coverage is only 40%, so the description must compensate. It does explain mode values and the backup-before-overwrite behavior, and clarifies that content is written without escaping, but it says nothing about the 'host' parameter (SSH target? inventory name?) or path semantics, leaving two undocumented params unaccounted 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?

States a specific verb and resource ('Write content to a remote file') plus a distinctive behavioral qualifier ('verbatim, no escaping') that separates it from shell-based alternatives like exec. An agent can tell immediately this is a direct remote file writer.

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 implicitly tells you to pick overwrite vs append, and the existence of file_read and backup_file siblings implies the read/backup split. But it never states when to prefer this over exec or whether it should be used for new files, so usage is only implied rather than explicit.

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 does disclose the returned payload and that the probe performs an outbound call (egress IP lookup), which hints at an external dependency, but it says nothing about request method, redirect handling, failure/timeout behavior, or what privileges the 'host' requires.

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, zero filler, with the host scope and the proxy option front-loaded and the outputs listed last. Nothing repeats the title and nothing could be cut 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?

With five parameters, no annotations, and no output schema, the description should be doing more work. It summarizes the return values, which is helpful, but omits error behavior, request method, and what the timeout actually bounds, so an agent cannot fully predict what a call will do or return in edge 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 40%: proxy and egress_ip are already documented in the schema, and the description only restates them ('optionally via a proxy', 'report ... the egress IP'). It does add one useful semantic — that 'host' is the machine the fetch originates from — but leaves url format and the timeout parameter (default 15, max 120) entirely to the schema.

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 pairs a specific verb (fetch) with a specific resource (a URL) and a scoping qualifier ('from a host'), then names the outputs. That is far more precise than a generic 'run command', though it never explicitly contrasts itself with the sibling exec tool, which could also perform an HTTP fetch.

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: 'from a host' and 'via a proxy' suggest remote connectivity testing, so an agent can infer this is the structured probe rather than a shell command. There is no explicit when-to-use, no when-not-to-use, and no named alternative among exec/docker_exec/xui_api.

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 it does disclose the return payload (state fields plus journal lines), which is valuable since there is no output schema. However it says nothing about read-only semantics, required privileges, whether the host must be reachable, or behavior when the unit is missing or the journal is empty.

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

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

A single compact sentence with no filler; the returned data is front-loaded. It is perhaps overly terse given the missing guidance, but nothing in it is wasteful.

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

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

For a 4-parameter remote-execution tool with no annotations and no output schema, the description should clarify host addressing, privilege requirements, and unit naming. It provides only a one-line summary of what comes back, leaving the agent to guess how to construct a valid 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?

Only half the schema has descriptions (`lines` and `since`), while `host` and `unit` are bare. The description does not clarify what `host` accepts (hostname vs. SSH target vs. localhost) or that `unit` expects a systemd unit name like `nginx.service`, so it fails to compensate for the coverage gap.

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

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

The description names a specific resource (a systemd unit) and the exact data returned (load/active/enabled state plus recent journal lines). That is enough to separate it from siblings such as docker_logs or exec. It lacks an explicit verb and never names the sibling it substitutes for, so it stops short of a 5.

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

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

There is no statement of when to use this versus exec or docker_logs, no prerequisites such as SSH access or sudo, and no exclusions. The agent must infer usage entirely from the tool name and required parameters.

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 of behavioral disclosure. It implies a read-only metrics collection, but says nothing about how the 'host' is reached (SSH? agent? credentials?), whether it requires the host to be reachable, or what happens on failure — significant omissions for a remote-host 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?

One dense sentence with zero filler; the enumerated metrics are front-loaded and the scope ('of a Linux host', 'in one call') is clear. It is appropriately sized for a single-parameter tool, though it could spend one more clause on the host parameter.

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, no-output-schema tool, the enumeration of returned metric categories does double duty as a return-value summary, which is genuinely useful. However, the ambiguity about the host parameter's format and connection semantics leaves a real gap for an agent trying to invoke 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?

The single required parameter 'host' has 0% schema description coverage and the description never clarifies its expected format (hostname, IP, user@host, SSH alias). With the only parameter undocumented in both schema and prose, the agent is left guessing at the most important input.

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 the exact resource set (memory, root disk, load, listening TCP ports) scoped to a Linux host, which is specific enough that an agent can tell it apart from siblings like service_status or http_probe. It lacks an explicit verb ('gathers'/'reads'), so the operation is implied 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?

There is no guidance on when to call this versus alternatives such as exec or service_status. The phrase 'in one call' hints at consolidation value but never names a competing tool or exclusion, so the agent must infer usage 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?

With no annotations, the description carries the full burden, and it does disclose meaningful behavior: the Bearer token is injected server-side and the panel address is read from x-ui.db, so the agent does not need to supply credentials. However, it says nothing about the consequences of POST/PUT/DELETE on a live panel, whether changes are applied immediately, or how errors and truncation (max_chars) surface in the 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?

A single sentence plus inline examples, front-loaded with the core action and the auth/address-resolution detail. Nothing is wasted, though the parenthetical about x-ui.db slightly interrupts the flow before the path examples.

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

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

For a five-parameter tool with no annotations, no output schema, and write-capable methods, the description covers the auth/resolution mechanics but omits return-shape expectations, what max_chars truncation looks like, and error behavior. It is adequate to start an invocation but not to predict outcomes safely.

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

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

Schema coverage is only 40% (host, path, and method are undocumented in the schema), so the description needs to compensate. It clarifies that path is relative to the panel base path and supplies two examples, but leaves host's accepted format, method's semantics, and body expectations to inference — 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?

States a specific verb (call) and resource (the host's x-ui/3x-ui panel API), and gives two concrete path examples that make the target unambiguous. It implicitly separates itself from the generic http_probe sibling by handling auth and resolving the panel address from x-ui.db, though it never names http_probe 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: reach for this when you need the x-ui panel API rather than a raw HTTP probe, since tokens and panel address are handled for you. There is no explicit when-to-use/when-not statement, no mention of prerequisites (a running x-ui instance, a configured panel base path), and no guidance on choosing between this and http_probe.

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