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

Annotations already declare destructiveHint=true and openWorldHint=true, so the risk profile is known. The description adds genuinely non-obvious behavior: it will hang or fail on any prompt for input and hit the timeout. It still doesn't mention privilege level of the remote shell or that output of destructive commands is unrecoverable.

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 with purpose and return values, then a short second paragraph for the non-interactive caveat. Two sentences plus one, every one earning its place.

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 structurally. But for a destructive open-world tool with 0% parameter coverage, the description leaves meaningful gaps: the timeout parameter is unexplained and there is no signal about the privileges the remote command runs with.

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% — none of the three parameters is documented anywhere. The description only obliquely references 'el servidor' and says nothing about timeout_segundos, which is exactly the parameter most relevant to the timeout behavior it describes. Given the coverage gap, the description needed to compensate and does not.

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

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

States a specific verb and resource ("Ejecuta un comando de shell en el servidor") and even names the return payload (exit code, stdout, stderr). It never positions itself against the more specific siblings (leer_archivo, ver_logs, estado_sistema), so the agent must infer that this is the generic escape hatch.

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 operational guidance (must be non-interactive, use -y/--no-pager) but no selection guidance: nothing says when to prefer this over escribir_archivo or ver_logs, or when it should be avoided. Usage is implied rather than directed.

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, readOnlyHint=false and openWorldHint=true, so the safety profile is known. The description adds real context beyond that: existing files are replaced, a backup named '<ruta>.bak.<fecha>' is made when respaldo=True, and writes require SSH-user permissions because sudo is not used. It does not explicitly warn that respaldo=False makes the overwrite irreversible.

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 lines, front-loaded with the core action, followed by the backup condition and the permission constraint. No filler sentences; each line 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 destructive file-write tool with annotations and an output schema present, the description covers the key operational facts: overwrite semantics, backup behavior, and permission requirements. The main gaps are the meaning/format of 'servidor' and any encoding or size notes for 'contenido'.

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 does well for 'respaldo' (default true, backup naming convention) and implies 'ruta' is the target path, but 'servidor' and 'contenido' are left unexplained 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 states a specific verb and resource: 'Crea o reemplaza un archivo de texto en el servidor.' That clearly distinguishes it from the read-oriented siblings like leer_archivo and listar_servidores. It stops short of naming a sibling or clarifying boundaries against ejecutar_comando, which could also write files.

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 conditional 'Si el archivo existe y respaldo=True' gives a concrete behavioral rule for the backup path, and the sudo note implies a permission prerequisite. But there is no explicit when-to-use vs. alternatives guidance, such as when to prefer ejecutar_comando or leer_archivo 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 readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the breadth of collection (systemd + Docker + process sampling), which hints at a potentially slow aggregation call, but it never says so outright, nor does it mention auth or failure behavior for unreachable hosts.

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 that front-loads the purpose ('Resumen de salud') and then lists payload contents; nothing is redundant. The comma-spliced list is slightly harder to scan than a structured breakdown but wastes no 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?

An output schema exists, so return values need not be spelled out, and annotations cover the read-only profile. What remains missing is the only input parameter's semantics and any note about cost/latency of a multi-subsystem probe — a real gap for a one-required-param tool with 0% schema coverage.

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

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

Schema description coverage is 0% and the single required parameter 'servidor' is documented nowhere — the schema only carries the title 'Servidor'. The description never mentions the parameter, so an agent gets no help on expected format (hostname vs. IP vs. alias from listar_servidores) for the one input it must supply.

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 resource (health summary) and enumerates exactly what is gathered: uptime/load, memory, disk, top processes, failed systemd services and Docker containers. That inventory distinguishes it well from siblings like ver_logs or leer_archivo, 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?

The enumerated data categories imply the use case (a diagnostic snapshot of a machine), but there is no explicit 'use this when…' statement, no exclusion of when to prefer ver_logs or ejecutar_comando, and no prerequisites such as needing a reachable server.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the meaningful behavioral detail that reads are truncated to a first-or-last N-line window rather than returning the whole file. It does not mention behavior on a missing/unreadable path, encoding, or size limits, so it is additive but not rich.

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 zero filler and the key scoping detail in parentheses. It is efficient, though the extreme brevity shifts work into the undocumented parameters rather than being optimally sized for a 4-parameter 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?

An output schema exists, so return values need no explanation, and annotations cover safety and open-world behavior. Still, for a tool with 4 parameters at 0% schema coverage and a crowded sibling set (ver_logs, ejecutar_comando), the description lacks the routing guidance and parameter semantics an agent needs to call it correctly the first time.

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 explanatory burden, and it does map conceptually onto all four parameters (servidor, ruta, lineas as N, desde_el_final as first-vs-last). However, it adds nothing about path format (absolute vs relative), what a valid servidor identifier looks like, or that lineas affects how desde_el_final behaves, leaving gaps the agent must infer.

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 and resource ("Lee un archivo de texto del servidor") plus a clear scope qualifier ("las primeras o últimas N líneas"), so an agent knows exactly what operation this performs. It does not name or differentiate itself from siblings such as ver_logs, which is the closest ambiguity in the set.

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 contains no when-to-use or when-not-to-use guidance; nothing tells the agent to prefer leer_archivo over ver_logs or ejecutar_comando for inspecting remote content. The only usable cue is the implicit read-only nature of the operation, which the annotations already state.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the useful behavioral detail that it reports live SSH session state, but says nothing about whether it actively probes each server, latency, or permission requirements for a network-touching (openWorld) 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 front-loaded sentence with zero waste that names both the resource and the key returned signal. Nothing to trim and nothing buried.

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

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

An output schema exists, so return-value explanation is not required, and with zero parameters and clear read-only annotations the description is nearly sufficient. The only missing piece is a hint about when to reach for this versus estado_sistema, which is minor for such a simple 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?

The tool takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. The description correctly implies no input is needed to obtain the server list.

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 ("Lista los servidores registrados") and adds the returned attribute (whether the SSH session is open). This is clearly a discovery/enumeration tool, distinguishable from execution siblings like ejecutar_comando or escribir_archivo, though it never names them 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 explicit when-to-use, when-not-to-use, or prerequisite guidance is given. The usage is only implied by the purpose: an agent would infer it should call this first to discover available servers before invoking ejecutar_comando. The routing 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?

Annotations already cover the read-only, non-destructive, open-world profile, and the description adds non-obvious behavior: filtro is applied as grep -iE, and the time format differs per tipo (docker wants "1h" while others accept "1 hour ago" or a timestamp). It does not say what happens with an invalid nombre or whether lineas truncates output, so it stops short of full disclosure.

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?

Purpose is front-loaded in one line, followed by compact per-parameter notes with no filler. The only structural weakness is that the tipo notes and the target-name examples are merged into one line, which is where the ambiguity comes from.

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 6-parameter tool with a required "nombre"/"servidor" pair and zero schema descriptions, the definition leaves too much unsaid. The output schema excuses it from explaining return values and annotations cover safety, but the missing meaning of nombre, lineas and servidor is a genuine 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 coverage is 0%, so the description carries the whole burden, and it only documents tipo, filtro and desde. Worse, it attaches the unit/container/path examples (nginx, /var/log/nginx/error.log) to "tipo", which is an enum — it never explains that those values belong in the required "nombre" parameter. "lineas" and "servidor" are left entirely undefined, inviting a malformed call.

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?

"Últimas líneas de logs" states a concrete verb+resource (tail recent log lines) and the tipo enumeration makes the scope of log sources explicit. It is distinguishable from siblings like leer_archivo or estado_sistema, though it never names those alternatives directly.

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 useful per-tipo guidance and correctly restricts "desde" to servicio/sistema/docker (implying archivo ignores it), which is real usage guidance. However, it never says when to prefer this over leer_archivo or estado_sistema, nor does it state preconditions such as the server needing to be reachable.

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