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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context — that it surfaces in-progress transfers with progress and recent completed changes — but omits details like auth needs, rate limits, or how the limit interacts with the two result sets.

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. The resource is named first and the two result categories follow immediately.

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 activity tool with an output schema and annotations covering safety, the description is nearly complete on purpose. However, it leaves the boundary with cloudsync_status and cloudsync_logs unresolved, which matters for tool selection in a crowded sibling set.

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 parameter 'limit' is never mentioned in the description. Its name is intuitive, but it is unclear whether the limit applies to in-progress transfers, completed changes, or both, so the description does not compensate for the schema 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?

States a specific resource and scope — live Cloud Sync activity covering in-progress transfers with progress and latest completed changes. It does not name or differentiate from sibling tools like cloudsync_status or cloudsync_logs, so an agent must infer the boundary.

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 or when-not-to-use guidance is provided. The phrase 'live activity' implies real-time monitoring, but the description never mentions alternatives or conditions that select this tool over cloudsync_status or cloudsync_logs.

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 genuinely useful behavior not in the annotations: results are ordered 'newest first' and include deletions and errors. It does not mention pagination behavior despite limit/offset parameters.

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 front-loads the resource and scope before the return content and filtering. No filler, nothing repeated from the name or title.

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 detail is rightly omitted, and the annotations cover the safety profile. The description completes the picture on ordering and content, with only minor gaps around pagination and the required conn_id.

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 only 20%, so the description must carry weight. It does explain the intent of the action and keyword filters ('what was uploaded, downloaded or deleted', 'keyword'), but conn_id, limit and offset get no semantic help, and the enumerable action values 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?

States a specific resource (Cloud Sync log history) scoped to one connection, and enumerates the content: uploads, downloads, deletes and errors. This distinguishes it from siblings like cloudsync_status and cloudsync_activity, though it never names those siblings to sharpen the contrast.

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 trailing clause 'Filter by action or keyword' implies when the tool is useful, but there is no explicit when-to-use/when-not guidance and no routing to alternatives such as cloudsync_activity or logcenter_logs for related log data.

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, openWorldHint=true and destructiveHint=false, covering the safety and scope profile. The description adds real value by disclosing the breadth of data returned (multi-provider, per-connection, quota, ETA), but says nothing about cost, latency, refresh cadence, or authentication requirements.

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, both earning their place: the first front-loads the resource and the data inventory, the second front-loads the use case. No filler or repetition of the tool name.

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 formatting need not be restated, and the description correctly focuses on scope plus the decision cue for when to call it. Only the undocumented estimate_rate flag keeps it from being fully complete for an agent with no prior context.

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 parameter estimate_rate (boolean, default true) is never explained. The description's mention of "throughput and ETA" hints at what rate estimation affects, but it does not define the flag or how setting it false changes the response. With only one optional parameter the practical impact is limited.

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 (Cloud Sync overview) and enumerates exactly what the tool returns: per-connection status, files left, quota, tasks, throughput and ETA. The provider list (Dropbox, Google Drive, OneDrive, S3) further scopes it and separates it from siblings like cloudsync_activity and cloudsync_logs, which are narrower log/activity views.

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?

"Start here for 'is the sync done / how long left'" is an explicit entry-point recommendation that tells the agent which question this tool answers and implies it precedes the detail-oriented siblings. It falls short of naming an alternative or a when-not condition, so it stops at clear context rather than 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, so the safety profile is covered. The description adds the return ordering (newest first) and the unusual shape note that titles are DSM message ids and params are their values, which is genuinely extra context; it says nothing about volume, pagination, or retention limits.

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 no filler, and the core content (what is listed, newest first) is front-loaded before the shape detail. The id/params sentence is terse but somewhat cryptic, slightly reducing clarity for the space it occupies.

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: one optional param, an output schema that carries return shape, and annotations that carry safety. The description covers what is returned and ordering, but leaves limit behavior and any filtering/recency scope unexplained, so it is adequate rather than 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?

There is one parameter (limit, default 20, range 1-200) with 0% schema description coverage, so the schema documents only its type and bounds. The phrase 'newest first' indirectly tells the agent that limit truncates from the newest end, but no meaning is added about what the limit applies to or how to page deeper.

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?

Names a specific resource (DSM desktop notifications) and states the ordering (newest first) plus concrete content examples (Security Advisor, package and DSM updates). It implicitly distinguishes itself from the sibling log tools (logcenter_logs, cloudsync_logs) by scoping to desktop notifications, though it never explicitly contrasts 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 no when-to-use guidance and no exclusions. With siblings like logcenter_logs and cloudsync_logs that also surface messages, an agent gets no signal about which one answers a given question, and nothing indicates whether filtering or paging is expected.

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, covering the safety profile. The description adds only a scope phrase ('specific files or folders') and gives no behavioral context such as what happens for nonexistent paths, whether paths are absolute or DSM-relative, or whether missing entries are omitted or errored.

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, and the most useful information (what metadata is returned) is front-loaded. It is a sentence fragment rather than a structured description, which slightly limits readability but not economy.

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 (one required parameter) and an output schema exists, so the description need not enumerate return values; it sensibly names the fields returned. However, it omits path format conventions and any usage framing, leaving the agent to guess how to construct the input and when this tool is the right choice.

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% for the single required 'paths' parameter, so the description must carry the load but does not: it never says paths are an array of multiple path strings, what format they take, or whether wildcards are accepted. Saying 'specific files or folders' only hints that both file and folder paths are valid.

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 the concrete payload (size, modified time, real volume path) and the target resource (specific files or folders), so an agent knows this is a metadata lookup rather than a listing. The verb is implicit ('info') and it never names filestation_list or filestation_list_shares, so sibling differentiation is left to inference.

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, no indication of when to prefer this over filestation_list, and no note on prerequisites such as the shares needing to be mounted. The agent must infer usage purely from the output fields mentioned.

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 only that results include size and modified time; it says nothing about pagination behavior despite limit/offset parameters, nor about failure modes for invalid paths.

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 is front-loaded. It is efficient, though its brevity is partly under-specification rather than ruthless editing.

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 described, and annotations cover safety. However, for a 6-parameter listing tool with 33% schema coverage, the description omits pagination semantics and sorting behavior, leaving gaps an agent would need before invoking it.

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 only 33% across 6 parameters: only path and pattern are documented (and pattern's glob meaning is better explained in the schema). The description explains none of limit, offset, sort_by, or sort_direction, 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?

States a specific verb ('List') and resource ('a folder's contents') and hints at returned fields (size, modified time). It does not name or differentiate itself from siblings like filestation_list_shares, so an agent must infer the distinction from the name alone.

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 tool versus alternatives such as filestation_list_shares or filestation_info, and no stated prerequisites (e.g. path format, permissions). The only clue is the path example buried in the schema.

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, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds one piece of behavioral context — results are grouped by free space on their volume — but says nothing about ordering, filtering, or rate limits.

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 tight sentence with no wasted words, front-loading the resource before the grouping behavior. Every phrase 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?

This is a simple zero-parameter read tool with an output schema that carries the return structure, so the description need not explain return values. It is adequate, though a note on how shares relate to volumes or siblings would round it out.

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 per the rubric the baseline is 4. The description adds nothing about parameters because there are none to describe.

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 ('Shared folders') and clarifies the concept with 'the top-level paths on the NAS', which meaningfully defines what a share is. However, it never distinguishes itself from the sibling filestation_list, leaving the agent to guess which one to call.

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 alternatives such as filestation_list or filestation_info. The agent must infer usage entirely from the name and the terse description.

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 safety profile (readOnly, non-destructive, openWorld), so the bar is lower, and the description adds a genuinely useful negative capability: DSM does not report whether a disk is currently spun down. That tells the agent not to chase a value that will never be returned, which is real behavioral context beyond the annotations.

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 padding: a dense feature inventory followed by the caveat. It is front-loaded on scope, and the trailing limitation sentence earns its place, though the comma-separated inventory is slightly harder to scan than a structured list.

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 the feature enumeration is arguably redundant with the return structure and the description is not obligated to explain return values. What is missing for an aggregating multi-section tool is any selection guidance and any parameter documentation, leaving it adequate but thin.

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 parameter wake_events is never named or explained. The phrase 'recent disk wake-ups from the system log' gestures at the parameter's subject but gives no hint that it is a count, that it defaults to 10, or that 0 is the floor — an agent cannot tell whether 0 means 'none' or 'unbounded'.

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 enumerates the concrete resources covered (hibernation timers, fan mode, power schedule, WoL, UPS status), which makes the tool's domain clear and separates it from siblings like storage_status and system_utilization. It never states a verb ('retrieves'/'sets'), so the agent has to infer this is a read, but the resource 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?

There is no when-to-use guidance and no alternative named; the agent is not told whether this belongs alongside storage_status or system_utilization. The only usage-adjacent content is the caveat that DSM does not report whether a disk is spun down, which is a scope limitation rather than a selection cue.

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 carry readOnlyHint, destructiveHint, and openWorldHint, so the safety profile is covered. The description adds the meaningful ordering behavior (newest first), which is not in the annotations or schema, but says nothing about pagination semantics, volume limits, or that openWorld means log content is untrusted/user-influenced data.

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 fragments, front-loaded with the resource and ordering. Terse and scannable, though the category clauses are compressed to the point of near-telegraphic style.

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 has an output schema, so return values need not be explained, and annotations cover safety. However, with seven parameters, two enums, and zero required fields, the description should at least clarify default behavior (system log, level any, 50 entries) and how since/until interact with offset for paging. Category definitions alone leave invocation details thin.

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 only 43%, so since/until and keyword have help text but log, level, limit, and offset do not. The description compensates by enumerating the values of the log parameter and describing what each category contains (hardware, sign-ins, SMB paths), which is genuine added meaning beyond the bare enum. level, limit, and offset remain undocumented.

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 the resource (DSM Log Center) and the ordering (newest first), and the three log categories clearly enumerate what can be retrieved. It does not name an alternative log tool, but among the siblings the only close one is cloudsync_logs, whose distinction (cloud sync vs. DSM system logs) is implicit 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?

No when-to-use or when-not-to-use guidance is given. The description does not say how this differs from cloudsync_logs, dsm_notifications, or taskscheduler_runs, so an agent must infer routing from category 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds meaningful context beyond that by clarifying the data is a static configuration snapshot rather than a live reading and by scoping which interface attributes are reported.

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, front-loaded with the resource and its scope, followed by the single most useful redirection. No filler or restatement of the tool name.

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; the description instead supplies the scoping (static config vs live metrics) that an agent needs to pick correctly among the status siblings. Complete for a zero-parameter read 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 per the rubric the baseline is 4. Nothing in the description is needed to explain parameter usage, and it introduces no misleading parameter-like wording.

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 (static network configuration) and enumerates exactly what it covers: hostname, gateway, DNS, per-interface IP/subnet, MAC, link status, speed/duplex, MTU. The parenthetical '(static configuration)' disambiguates it from live-metric tools, and it explicitly names the sibling system_utilization as the place for throughput.

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 a clear routing signal: use system_utilization for live throughput, this tool for static configuration. There is no explicit statement of when this tool is preferred over e.g. system_info or hardware_power, so it stops 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?

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: updates are validated against Package Center's catalogue plus configured third-party feeds, and it explains the edge case where update_to is reported as 'not in catalogue'.

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 dense sentences with no filler; the scope (installed packages + fields) is front-loaded before the catalogue-checking caveat. The second sentence is information-rich but runs long, which slightly hurts scannability.

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 read-only status tool with an output schema already defining the return shape and annotations covering the safety profile, the description covers everything needed: what is listed, where update data comes from, and how the 'not in catalogue' case is represented.

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?

This tool takes zero parameters, so there is nothing to disambiguate and the baseline is 4. The description sensibly spends its budget explaining the returned fields and their provenance instead of parameter syntax.

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 resource precisely (installed packages) and the exact fields returned: version, running/stopped status, and available updates including security-release flags. This clearly separates it from siblings like storage_status or cloudsync_status, though it uses a noun phrase rather than an explicit verb.

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 by the resource ('installed packages'), so an agent can infer this is the tool for package state. However, there is no explicit when-to-use guidance, no statement of prerequisites, and no routing to or away from any alternative 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description contributes the scope of reported metrics, but says nothing about auth requirements, cost, or freshness of the data.

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 compact sentence with the broad category front-loaded ahead of the metric list. Slightly telegraphic (colon-separated fragments) but 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?

An output schema exists, so return values need not be described here, and with zero parameters there are no input semantics to cover. The description adequately frames what diagnostics this read-only tool surfaces for its complexity level.

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 no parameters, so there is nothing for the description to disambiguate; baseline 4 applies. It does not need to explain inputs at all.

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?

Names a specific resource (disk/volume health) and enumerates the concrete data it exposes: usage, free space, drive model, status, SMART, temperature. That lets an agent separate it from siblings like system_utilization and hardware_power, though it reads as a noun phrase with no explicit verb.

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 statement of when to call this versus system_utilization, system_info, or hardware_power, and no prerequisites or exclusions. The agent must infer usage purely from the topic label.

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 safe-read profile needs no restating. The description adds the field inventory, which is useful scope context, but says nothing about permissions, rate limits, or how the data is refreshed.

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 that front-loads the resource and then lists contents without a word of filler. Every element 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?

An output schema exists, so the description need not explain return values, and annotations cover the safety profile. The field list gives enough scope for an agent to know what it will receive, with only minor gaps around caching/refresh behaviour.

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 for this dimension is 4. There is nothing for the description to clarify about inputs, and the enumerated fields relate to outputs rather than 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 names a specific resource (NAS hardware and DSM version) and enumerates exactly which fields it returns: model, CPU, RAM, uptime, temperature, crash/upgrade flags, USB devices. It is clear what the tool does, though it does not explicitly differentiate itself from siblings like system_utilization or hardware_power.

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 or when-not-to-use guidance, and no alternative sibling is named. The usage is only implied by the resource name, leaving the agent to infer how this differs from system_utilization or hardware_power.

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 meaningful context that this is live/current load rather than historical or aggregated data, but says nothing about sampling behavior, cost, or whether values are point-in-time vs averaged.

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 tight sentence with the key qualifier 'Live' front-loaded and an enumerated metric list. Every clause carries information; nothing is padding.

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 an output schema present, the description need not explain return values, and with no parameters there is no input to document. Annotations cover safety, so the only real gap is the absence of guidance on how this relates to sibling status 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 is 4. There is nothing for the description to disambiguate, and it does not confuse matters by implying optional filters that do not exist.

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 metrics returned (CPU %, load average, memory, per-disk and per-network-interface throughput) and the word 'Live' signals a real-time snapshot. It distinguishes this from static siblings like system_info, though it omits an explicit verb like 'retrieve' and never names those siblings 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?

There is no guidance on when to call this versus alternatives such as system_info, storage_status, or network_config, all of which overlap in subject matter. The agent must infer that this is the real-time monitoring tool and the others are static configuration/state 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. On top of that the description discloses useful behavior: results are ordered 'newest first', and that the action/command field only applies to script tasks. It does not mention pagination or rate behavior, but it clears the lower bar set by the annotations.

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, tightly written sentence with the core deliverable front-loaded ('Run history of one scheduled task, newest first') and a useful secondary clause about the action field. No filler or restated boilerplate.

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 detailed, and the tool's complexity is low with just two parameters. The description covers subject, ordering and content well; the only real gap is any hint about limiting result size, which is minor for a read-only history lookup.

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 only 50%: task_id is documented as coming 'from taskscheduler_tasks', but 'limit' (default 10, max 200) carries no description. The prose says nothing about limiting or paging, so it fails to compensate for the coverage gap, and 'newest first' does not explain how to fetch older entries.

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: returns the run history of one scheduled task, with the fields returned named (start time, duration, exit result, action). It is clearly distinct from the sibling taskscheduler_tasks (which lists tasks), though it never names that 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?

Usage is only implied: the description says the history is for 'one scheduled task', so the agent can infer it needs a task_id from the task list. There is no explicit when-to-use statement, no mention of the taskscheduler_tasks sibling, and no guidance on when to prefer taskscheduler_runs over logcenter_logs or cloudsync_logs.

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 one genuinely useful scope disclosure — that root's tasks are included, i.e. privileged entries will appear in the results. It says nothing about auth requirements or result volume, so it is a modest addition rather than a rich one.

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, both earning their place: the first defines the resource and payload, the second front-loads the practical use case. No filler, no repetition of the title, and the scope statement comes before the guidance.

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 zero parameters, a full annotation set and an output schema that carries the return structure, the description only needs to establish scope and intent — which it does. The missing piece is disambiguation from taskscheduler_runs, which an agent choosing between the two task-scheduler tools would need.

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 document and the baseline of 4 applies. The description correctly avoids inventing filtering arguments that the empty schema does not support.

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 (every scheduled and event-triggered task, including root's) and enumerates what each entry carries: schedule, next run, last run result and duration. That is far more than a restated name. It stops short of differentiating itself from the sibling taskscheduler_runs, which an agent would likely confuse it with.

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 a concrete selecting scenario — 'Use to confirm a nightly job (e.g. a backup) succeeded' — which tells the agent when this tool is the right call. It offers no exclusions, prerequisites, or pointer to taskscheduler_runs for run-level history, so it falls short of the 5 bar.

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