estado_servidor

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

With no annotations provided, the description carries the full behavioral burden, and it discharges it thoroughly. It discloses that the call performs no network I/O and creates no index, that settings are read at startup and changing them requires a server restart, that it surfaces warnings for invalid and risky values ('explícale al usuario el riesgo de bloqueo'), and that some state files are shared across all processes. This is rich, honest 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?

The purpose is front-loaded in the first sentence and the content is organized with bullets, but the description is extremely verbose — a dense wall of near-exhaustive field detail. While every item is arguably relevant given there is no output schema, the length pushes past 'concise' toward reference documentation; a more compressed summary would serve most callers.

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

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

Given zero parameters, no annotations, and no output schema, the description is the sole source of information, and it is exceptionally complete. It enumerates every returned configuration group (sync pacing, courtesy pauses, site guard, legacy portal state) with exact variable names, defaults, and shared-file details, leaving an agent with nothing missing 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 tool takes zero parameters, so the schema carries no burden and the baseline is 4. The description instead invests heavily in explaining the return content — every config field, env var, warning category, risk class, and guard-state element — which more than compensates for the absence of an output 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 names a specific resource and verb combination: it reports server configuration and state ('Configuración y estado del servidor'), and immediately disambiguates what it is not — 'sin tocar la red ni crear el índice'. This clearly separates it from sibling tools like sincronizar_indice or buscar_articulos, giving an agent a precise sense of scope before any schema is consulted.

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 rather than explicit. The negative constraint ('sin tocar la red ni crear el índice') signals that this is a safe, side-effect-free status read, which hints at when an agent would prefer it over network-touching siblings. However, it never names an alternative tool or states an explicit when/when-not condition, leaving some inference to the agent.

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