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

No annotations are provided, so the description must carry the behavioral disclosure burden. It is transparent that this is a listing operation and explicitly mentions inclusion of system cron files and daily/weekly/monthly summaries. It does not describe the output format or failure behavior, but the permission requirement for all-user listings is present in the schema.

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 sentences with no filler. The main function is front-loaded, and every clause adds a distinct scope or behavior, making it easy for an agent to parse quickly.

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 listing tool with no output schema and no nested objects, the description covers the supported scopes and extra system-file behavior, while the schema covers permissions. It does not specify the exact return shape, but that is not critical for this kind of tool.

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

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

Schema description coverage is 100%, so each parameter is already well documented. The description usefully summarizes the user/all/system modes but largely restates schema semantics rather than adding new meaning, and it provides no format-level detail for the parameters.

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 starts with a clear verb and resource: 'List cron jobs' and then enumerates the exact scopes: current user, specific user, all users, and system files. No sibling tool covers cron jobs, so it is immediately distinguishable.

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 provides clear context by explaining the three user-scope modes and the system-file inclusion behavior. It does not explicitly name alternatives or exclusion conditions, but no sibling tool competes with this function, so the guidance is sufficient.

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 disclosure burden. It clearly states that both space and inode usage are included and that virtual filesystems (tmpfs, devtmpfs) are excluded, which are useful behavioral details beyond a generic 'show disk usage' statement. It does not discuss side effects, but the verb 'Show' implies a read-only 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?

Three sentences with no wasted words. The main purpose is front-loaded, followed by useful behavioral details and a practical use case. Every sentence contributes meaningful 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 simple read-only tool with two optional parameters and no output schema, the description covers the essential behavior: what is measured, what is excluded, and why the tool matters. It could mention the output format, but the tool's purpose and output are predictable enough that the description is largely complete.

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

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

Schema description coverage is 100%, so the schema already fully documents both parameters (path and human). The description does not add additional parameter-level semantics, but the baseline of 3 is appropriate because no compensation is needed when the schema covers everything.

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 clear verb ('Show') and a specific resource ('disk space usage by filesystem/mount point'). It further distinguishes the tool by noting it includes inode usage and excludes virtual filesystems, making it easy to differentiate from sibling tools like memory_info or service_status.

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 provides a clear use case ('Essential for preventing disk-full outages') and the scope of what is shown. It does not explicitly state when not to use it or name an alternative, but the sibling tools are mostly unrelated, so the guidance is sufficient for a simple informational tool.

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 behavioral burden. 'Inspect' signals a read-only intent, and the explicit note about gracefully reporting when Docker is missing or the daemon is stopped is valuable. It could go further by clarifying snapshot vs streaming behavior or potential cost of 'stats', but it is already quite transparent.

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 tight sentences front-load the scope first, then the failure behavior, then the most useful action distinction. Every sentence earns its place and there is no repetition or filler.

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

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

Given a read-only status tool with a self-documenting enum schema and no output schema, the definition is sufficiently complete for an agent to know what it does, what actions are available, and what happens when Docker is unavailable. A brief note on return format or output shape could push it to a 5.

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 of 3 applies. The description's mention of 'overview' and 'stats' mostly restates the schema's own action descriptions, and it adds no additional meaning for the 'filter' parameter beyond what the schema already documents.

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 ('Inspect') and names the full Docker resource scope: containers, images, networks, volumes, and resource usage. This makes it clearly distinguishable from general-purpose sibling tools such as service_status, process_list, and system_health.

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 intended context is clear: use this when you need Docker-related status or resource information. It even handles the edge case of Docker not being installed or the daemon being stopped. However, it does not explicitly name alternatives or state when not to use it, so it just misses the top score.

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 conveys a read-only operation through 'Show', discloses that detailed mode reads /proc/meminfo, and mentions load averages as additional context. It does not specify output format or failure behavior, but for a metrics tool this is a minor 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?

Three concise, front-loaded sentences with no filler. The main purpose comes first, followed by the detailed-mode clarification and the extra load-average 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 simple one-optional-parameter tool, the description covers what it shows, what detailed mode adds, and the extra load-average context. However, with no output schema, it does not describe the return format or structure, which prevents a perfect score.

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 schema already fully describes the only parameter, 'detailed', with 100% coverage. The description adds no new parameter semantics beyond restating that detailed mode includes buffer/cache breakdown, so the baseline score of 3 is appropriate.

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: 'Show RAM and swap usage.' It also explains the detailed-mode behavior and the extra load-average reporting, which clearly distinguishes it from siblings like disk_usage, process_list, and system_health.

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 clear context for when the tool is relevant, but it does not explicitly mention alternatives or when not to use it. Given the sibling system_health could plausibly overlap, some routing guidance would improve this dimension.

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 itself conveys that all actions are non-mutating inspections and identifies the underlying commands (nginx -t, nginx -T) and what each action returns. It does not mention permissions or potential command output size, but it makes operational behavior reasonably clear.

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 states the tool's purpose and then maps each action to a specific behavior. There is no filler or unnecessary repetition beyond what makes the description standalone and useful.

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 tool with four actions and one optional parameter, the description covers each action's behavior and implies what output the agent can expect. It could add permission requirements or error/exit-code behavior, but the core invocation requirements are complete.

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

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

Schema coverage is 100%, so the schema already documents the action enums and the site parameter in full. The description restates action behavior but adds essentially no parameter detail beyond the schema, keeping it at the baseline.

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 specific action verbs (read, validate, inspect) tied to the nginx configuration resource and enumerates the four concrete actions. This clearly distinguishes it from sibling system/service inspection tools.

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 establishes clear context: this tool is for reading, validating, and inspecting nginx configuration, so an agent can recognize when it applies. It does not explicitly name alternatives or when-not-to-use conditions, but the sibling tools are generic system utilities with minimal overlap.

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?

There are no annotations, so the description carries the burden of explaining behavior. It discloses that the tool uses 'ss' with a 'netstat' fallback and is limited to listening ports, which conveys a local read-only inspection rather than an active external scan. It does not mention potential permission requirements or output format, but the core behavioral profile is clear.

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 concise sentences cover the main action, filter options, implementation detail, and use case with no redundant wording. The most important information is front-loaded in the first sentence.

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-required-parameter list tool with full schema coverage, the description is adequate and clearly explains the tool's value. Minor gaps remain, such as not explicitly stating that the scan is local-only or describing the exact output columns, but these are not critical 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?

The input schema already documents both parameters completely, and the description only restates that filtering by port or protocol is possible. No additional semantics beyond the schema are provided, so the baseline score 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?

The description opens with a specific verb and resource, 'List all listening TCP/UDP ports with their associated processes,' which clearly states what the tool does. This also distinguishes it from sibling tools like process_list by emphasizing listening ports and process mapping, so an agent can identify it without inspecting the 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?

It states the intended use case, 'useful for checking what services are exposed,' which gives clear context for when to invoke it. However, it does not explicitly mention when not to use it or compare it to sibling tools such as service_status or process_list.

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 burden of behavioral disclosure. 'List' is a non-mutating verb that strongly implies a read-only operation, and the description reveals that sorting and filtering affect the output. It does not explicitly mention side effects, permissions, or snapshot semantics, but for a simple process-listing tool the description is sufficiently transparent.

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 tight sentences with no filler. The first sentence front-loads the tool's core purpose and output content; the second gives actionable parameter guidance. Every word earns 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?

The tool is simple with three optional parameters and full schema documentation. The description covers the core output (CPU, memory, runtime) and typical use cases. There is no output schema, but the description partially compensates by naming the returned details. Missing explicit default behavior is minor because the schema already documents defaults and enums.

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. The description adds semantic value by tying parameters to goals: sorting by CPU/memory helps find resource hogs, and filtering by process name helps find specific applications. This goes beyond the schema's enum and default descriptions.

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 running processes with CPU, memory, and runtime details.' This clearly distinguishes it from sibling tools like service_status, disk_usage, and system_health, which target different resources. The scope is unambiguous.

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

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

The description gives concrete usage guidance for parameters: 'Sort by CPU or memory to find resource hogs' and 'Filter by process name to find specific applications.' However, it does not explicitly tell the agent when to use this tool versus siblings such as service_status or system_health; the when-to-use is implied rather than stated.

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

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

With no annotations provided, the description carries the full burden. It conveys a read-only fetch operation and lists supported filters, but it does not disclose authorization needs, error behavior (e.g., unknown service), or whether it queries only the current boot. These are meaningful gaps for a log 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 three sentences with no fluff: the first states what it does, the second lists capabilities, and the third gives use cases. It is front-loaded and every sentence earns 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?

Given the tool's moderate complexity (6 parameters, no output schema, no annotations), the description covers purpose, filters, and use cases. It lacks explicit mention of return format and privilege requirements, but these are partially inferable from 'logs' and 'fetch'.

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 schema already documents all six parameters. The description summarizes filtering by time range, priority, and grep, which maps directly to since, priority, and grep parameters but adds no additional semantic detail beyond 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 ('Fetch') and a clear resource ('recent journal logs for a systemd service'), making the tool's purpose immediately obvious. It also lists filtering capabilities, distinguishing it from sibling tools like service_status, which report status rather than logs.

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 provides clear usage context: 'debugging service issues and monitoring application output.' It does not explicitly state when not to use it or name alternatives, but the context is strong enough for an agent to select it over process_list or service_status.

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 clearly frames the operation as read-only ('Check', 'Shows') and discloses that output comes from 'systemctl status,' including the specific fields displayed. It does not mention permission requirements or behavior for unknown services, but the key behavioral traits are 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?

A single sentence that is front-loaded with the action and resource, followed by a compact list of output categories. Every clause adds information and there is 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 simple read-only status tool with two well-documented parameters and no output schema, the description names the main output categories and makes the purpose clear. It does not specify output formatting or error behavior, but those are less critical for a low-complexity tool like this.

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 score applies. The schema already documents both parameters fully, including the optional '.service' suffix and the meaning of the user flag. The description adds no additional parameter-level meaning beyond what the schema provides.

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 ('Check the status') and a specific resource ('systemd service'), then enumerates the concrete information returned: active/inactive/failed state, enabled state, PID, memory usage, and recent log lines. This clearly distinguishes it from siblings like service_logs and process_list in practice, even without naming 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 explains what the tool does but gives no guidance on when to choose it over alternatives. It does not mention sibling tools such as service_logs or process_list, nor does it state any exclusions like 'use service_logs for full log history.'

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 behavioral disclosure burden and does so well: it lists the subsystems checked and the return format (HEALTHY/ISSUES DETECTED with specific warnings and thresholds). It does not explicitly state that the operation is read-only and makes no changes, but a health check strongly implies that.

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 sentences, each earning its place: purpose, checked subsystems, and output behavior. The final sentence reinforces the primary use case without redundancy. Information is front-loaded and skimmable.

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 aggregate health tool with no output schema and no annotations, the description gives enough context for an agent to decide and call it: inputs, scope, status format, and use case. It stops short of listing the actual thresholds, but explicitly states that thresholds and warnings exist, which is sufficient for a 'quick check' 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% and the only parameter, verbose, already has a clear description in the schema. The tool description adds context about the overall report but no additional meaning for the parameter itself, so the baseline of 3 is appropriate.

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 ('Run an aggregate health check'), a clear resource ('entire system'), and enumerates exactly what it checks: load averages, memory/swap, disk space with inode check, failed systemd services, and listening port count. It distinguishes itself from subsystem-specific siblings by clearly positioning itself as an aggregate check.

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 explicitly frames this as the 'go-to tool for a quick is everything OK? check,' which tells an agent when to select it. It does not explicitly say when to prefer the sibling tools for deeper subsystem investigation, but the contrast with the sibling names is implied.

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