Anabolic

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is partly covered, but the description adds nothing about what the block actually changes, whether it is reversible, or whether elevated privileges are required. The one behavioral fact it does add (firewalls on Linux filter by address/port/user, so the call always refuses there) is useful but narrow given this is a destructive mutation.

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?

It is a single sentence with no padding, but it front-loads the failure case rather than the capability, so a skimming agent may read the tool as impossible rather than platform-limited. The structure would be stronger with the action stated first and the Linux caveat second.

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, state-changing tool the definition omits the essentials: what blocking does on supported platforms, how to reverse it, and privilege requirements. The schema and annotations cover the parameter and the danger level, but the description leaves the operational picture incomplete.

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

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

Only one parameter exists and the schema describes it fully at 100% coverage, including the hint that get_process supplies the path. The description adds no meaning beyond that, so the baseline 3 for schema-covered parameters 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 phrase "Blocking a program from the network" does name a verb and resource, but the sentence is framed entirely as a Linux limitation and never states what the tool actually does on supported platforms or what the resulting state is. An agent can infer it blocks a program's network access, yet the definition reads more like documentation for a refusal than for the operation.

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 supplies a genuine exclusion – do not call this on Linux because it always refuses – which prevents a wasted destructive call. It gives no positive when-to-use context (platforms that work, prerequisites) and never names the sibling unblock_program as the inverse operation, so an agent must infer the counterpart.

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 destructiveHint=true, openWorldHint=true and idempotentHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: only a single connection is affected, the process survives, and the peer will typically re-establish the connection. It omits whether administrative rights are required and what happens when the connection is already gone.

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 scope qualifier comes before the caveat. The 'as TCPView does' analogy leans on external knowledge and 'the process is not opened' is slightly awkward phrasing, which keeps it just short of ideal.

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, non-idempotent mutation with four required parameters and no output schema, the description covers the conceptual behavior well but leaves out permissions, failure modes, and confirmation that the target connection was actually closed. Adequate but with clear gaps an agent would want filled.

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% — pid and remote are documented, while local_port and remote_port carry no descriptions anywhere. The description adds no parameter meaning at all (it doesn't even say the four fields must together identify one unique connection), so it fails to compensate for the coverage gap on a fully-required 4-param 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 verb ('Closes') and a tightly scoped resource ('one TCP connection (IPv4) of a process'), which no sibling performs — list_connections only enumerates. The parenthetical clarification that the process is not opened/terminated separates it cleanly from end_process.

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 'program usually reconnects' note hints that the effect is transient, which nudges an agent away from using it as a durable block. There is no explicit when-to-use vs. end_process/block_program, and no stated prerequisites such as needing the connection to exist or elevated privileges.

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?

Adds substantial behavior beyond the destructiveHint annotation: the escalation signal sequence, the two-second grace window, the ordering guarantee that children die first under tree=true, the data-loss caveat, and the refusal list including init, the kernel, the compositor, and Anabolic. These are exactly the operational facts an agent needs before invoking a destructive 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?

Dense and mostly front-loaded, with the escalation behavior first, the danger warning second, and the refusal/force rules last. The clause "or with tree=true it and every process under it (those first)" is grammatically elliptical and takes a second read, which is the main structural blemish.

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

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

For a three-parameter destructive tool with no output schema, the description covers the danger, the escalation timing, the subtree ordering, and the refusal/force policy — everything needed to call it correctly and safely. Return shape need not be explained absent an output schema, and error behavior is adequately implied by the refusal list.

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, but the description adds meaning the schema does not: it names the concrete class of programs (games, anti-cheat) that require force=true, and restates the tree ordering constraint. The pid parameter's semantics (liveness, reuse, what happens if the process already exited) are not elaborated.

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 precise verb and resource ("Ends a process") and immediately specifies the mechanism (SIGTERM, then SIGKILL after two seconds) plus the tree variant. An agent can tell this apart from siblings like suspend_process, limit_process, or why_process_will_not_end without opening any 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?

Gives clear conditional guidance: tree=true for the subtree, force=true only after user agreement for games/anti-cheat, and notes which processes will be refused. It stops short of naming an explicit alternative (e.g., why_process_will_not_end when a kill is refused, or suspend_process when termination is not wanted), so routing to siblings is left implicit.

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 safe read-only, idempotent, non-destructive profile. The description adds useful behavioral context by explaining that trace_seconds > 0 also returns who ran on each core from a context switch trace, which goes beyond what the annotations declare.

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

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

The description is two dense, front-loaded sentences with no wasted wording. It first enumerates the CPU metrics and then cleanly appends the optional trace behavior.

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

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

For a one-parameter read-only tool with rich annotations, the description covers the key returned data and the optional tracing effect. It does not describe output shape or units, but that is a minor gap given the absence of an output schema and the otherwise clear metric listing.

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 parameter is already documented in structured data. The description still adds meaning by clarifying that trace_seconds > 0 yields per-core thread and process attribution with their share, which helps an agent understand the output impact of the parameter.

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 clearly identifies the resource as CPU and lists the specific metrics returned: total and per logical processor, user, kernel, DPC, interrupt, clock, interrupt/context switch rates, name, and topology. It is easy to distinguish from siblings like get_memory or get_gpus by resource, though it does not explicitly contrast itself with alternatives such as get_system_overview.

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 metric list and the optional trace_seconds behavior, but the description does not state when to use get_cpu versus siblings like get_system_overview or get_process. No explicit exclusions or alternative-routing guidance is provided.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description goes beyond that by disclosing the conditional tracing behavior: with trace_seconds > 0 the result is extended with per-process and per-file read/write attribution, which materially changes the cost and shape of the call. It does not discuss result size or duration limits, but the schema covers the 0-30 second bound and self-termination.

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 primary return payload and then the conditional tracing mode. The enumeration is dense but every item is a distinct returned field rather than padding; a short lead-in verb would cost nothing and aid scanning.

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 one optional parameter, no output schema and no nesting, the description carries the job of explaining the return shape and does so thoroughly, including the conditional trace output. The only gap is the absence of any pointer to sibling tools when the caller actually wants GPU, display or general hardware information.

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, and the description earns an extra point by concretizing what the parameter buys: 'which processes read and write each disk and which files.' The schema only says 'who uses the resource'; the description makes the added dimension of the result explicit, which is real interpretive value.

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 exactly what the tool returns — physical disks, partitions with type, file system, mount point and space, plus volumes, activity, throughput, IOPS, response time, queue and temperature. That is specific enough to separate it from get_hardware and get_system_overview, though it opens with a bare noun ('Disks:') rather than a verb, so the action is implied rather than stated.

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

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

Usage is only implied: an agent can infer this is the tool for per-disk inventory and performance metrics. There is no explicit when-to-use guidance, no statement of how it differs from get_hardware or get_system_overview, and no guidance on when trace_seconds is worth the CPU cost versus a plain snapshot.

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, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds one genuinely useful behavioral fact beyond that: the tool does analysis, not just enumeration — it compares each monitor against its best supported mode and points out underperformance. It does not say how that judgement is surfaced (flag field, message, ordering) or whether it covers the whole machine or a single adapter.

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, no filler, and the diagnostic behavior is placed last as the payoff. The first sentence is a long comma-separated field list that reads more like a schema dump than prose, but every item is informative and nothing is redundant.

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 no output schema, the description carries the burden of explaining what comes back, and it does so by enumerating the reported fields plus the comparison/flagging behavior. The main remaining gap is the shape of the returned data and how the 'below its best' finding is expressed, which an agent would still have to discover by calling 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?

The tool takes no parameters, so there is nothing for the description to disambiguate; the baseline for a zero-parameter tool applies. The description spends its wording on return content instead, which is the right choice here.

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 makes clear this reports per-monitor display data: name, GPU, connection, position, mode, refresh rate, native resolution, HDR and scaling. That is specific enough to separate it from siblings like get_gpus or get_system_overview, though it never uses an explicit verb (e.g. 'list'/'report') and opens with a bare noun, 'Monitors:'.

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 explicit when-to-use or when-not-to-use guidance and no named alternative, even though get_gpus and get_system_overview are plausible overlapping choices. The phrase about flagging a monitor below its refresh rate or resolution hints at a diagnostic use case, but that is inference rather than instruction.

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?

The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and closed-world, so the safety profile is fully covered. The description adds the useful behavioral detail that results are per-adapter and include the top processes per GPU, but says nothing about behavior when no GPU exists, error cases, or cost of the call.

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 that front-loads the resource and then lists the payload fields in a scannable order. Nothing is padded, though the fragmentary style (no verb, trailing '...') reads more like a field label than a tool contract.

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 no input parameters and no output schema, the description's main job is to convey what comes back, and it does so field by field (usage, engines, memory types, temperature, consuming processes). Only the edge cases — multi-GPU ordering, behavior on machines without GPUs — are unaddressed.

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 nothing for the description to compensate for and the baseline of 4 applies. The description correctly implies a full, unfiltered snapshot rather than a filtered query.

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 identifies the resource (GPUs) and enumerates the data fields returned — per-adapter usage, engines, dedicated/shared memory, temperature, top processes — so a reader knows what they'd get. But it is a noun-phrase fragment with no verb, and it does not distinguish this tool from siblings like get_hardware or get_system_overview, which plausibly overlap.

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 at all: no condition that selects this over get_hardware, get_system_overview, or get_sensors. The agent must infer that this is the GPU-specific view purely from the name and field 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered and the description owes nothing there. The description's real contribution is enumerating the returned fields, which matters because no output schema exists, but it says nothing about whether values are a live snapshot, how expensive the call is, or how it relates to the specialized sibling readers.

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

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

A single dense sentence with no filler, front-loaded with the 'Hardware:' label followed by the enumerated sub-resources. The parenthetical lists are compact and each item earns its place as return-value documentation, though the fragment style is terse rather than instructive.

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, annotation-covered read tool, the description does the heavy lifting of documenting return content in the absence of an output schema, which is the main thing an agent needs. The remaining gap is the unresolved overlap with get_cpu and get_memory, already reflected in the usage 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 tool takes zero parameters, so there is no parameter semantics to convey and the baseline of 4 applies. The schema is an empty object, consistent with the parameterless 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 names a specific resource and enumerates its contents precisely (processor model/cores/caches/clocks/features/virtualisation, board and BIOS, memory modules with size/speed/maker/part number, core topology), so an agent knows exactly what data this returns. It stops short of a clear verb and never distinguishes itself from overlapping siblings like get_cpu and get_memory, which cover portions of the same ground.

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 at all: no statement of when to prefer this aggregate hardware call over the narrower get_cpu or get_memory, and no guidance on when it is unnecessary. The sibling list makes this omission consequential, since a naive agent may call this and get_cpu redundantly.

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?

The annotations already declare this to be a safe read (readOnly, idempotent, non-destructive), so the description's job is to describe substance. It does that by enumerating the metrics and the process categories per sample, which is real added context beyond the annotations. Pagination/truncation semantics live only in the schema's 'limit' description, so the description is not fully self-contained.

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 content is front-loaded: what is returned comes before the sample contents and the motivating question. The first sentence is very dense with a long comma-separated inventory, but every element describes the payload, so little is wasted.

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?

There is no output schema, so the description must convey the return shape, and it does so in reasonable detail, which is the right call for a five-parameter read tool with sensible defaults. What is missing is guidance on volume (samples per request, default 120/max 2000), which matters for how an agent scopes a query.

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%, with date, from/to, top and limit all documented in the schema itself, so the baseline is 3. The description's phrase 'a day (or part of one)' loosely mirrors the date and from/to parameters but adds no format, default or range detail beyond that.

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 concrete verb and resource: it returns the history's samples for a day or part of a day, and spells out what each sample contains (CPU, memory, commit, disk, network, GPU, top/started/exited/hung processes). That is far more specific than the bare name 'get_history'. It never names a sibling (e.g. list_history_days for picking a date), so there is no explicit sibling differentiation, keeping it at 4.

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 closing line 'Answers "why was the PC slow at 14:32"' gives a clear, concrete situation in which to reach for this tool, and 'the history's samples' positions it as the historical companion to the live-status tools. It does not say when NOT to use it or point at alternatives, which is the one gap.

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 establish that this is a safe, idempotent, closed-world read. The description adds genuinely useful behavior beyond that: the sampling cadence (every minute), the observation window (two hours), and the flagging threshold (ten minutes or more of growth). It does not say what fields come back per process or whether it requires prior recording activity.

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 with no filler, and the core concept (growth in a straight line) is front-loaded. The heavy parenthetical is dense but each clause carries real detection detail.

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 no parameters and no output schema, the description covers the detection criteria well but leaves the return shape unspecified (which processes, what metrics, over what interval). It also does not note any prerequisite such as the two hours of recorded activity needing to already exist.

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 nothing for the description to disambiguate. The baseline of 4 applies; the implicit per-minute/two-hour window is fixed rather than configurable, which is consistent with the empty 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 identifies a specific resource class (processes with linearly growing handles, private memory, or threads) and the signal it represents (a leak), which distinguishes it from generic siblings like get_process or list_processes. It is written as a noun phrase rather than a verb+resource statement, so an agent must infer that it returns such processes.

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 explicit when-to-use guidance: nothing says to call this when investigating suspected memory/handle growth versus calling get_memory, get_process, or list_handles directly. No alternatives or exclusions are named.

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 readOnly, idempotent, closed-world, non-destructive, so the safety profile is covered structurally. The description adds real content value by disclosing which memory subsystems are sampled, but says nothing about whether this is a point-in-time snapshot, how many processes appear in the 'most private memory' list, or how large the returned payload is.

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

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

A single dense sentence-fragment with the resource label front-loaded followed by the payload contents; no filler or marketing language. It reads slightly as a bare field dump rather than prose, which is acceptable here but keeps it from a 5.

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 no output schema, the description carries the full burden of describing return content, and the enumeration helps considerably. However, it does not indicate the shape of the response (nested sections, counters, list sizes) or whether values are bytes, so an agent still cannot predict the structure it will parse.

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 nothing beyond the schema to explain; the empty schema itself fully constrains invocation. Baseline 4 applies since no parameter documentation burden exists.

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 (memory) and enumerates the exact data categories reported: commit charge and limit, file cache, pools, standby/modified/free lists, page files, and top private-memory processes. That enumeration cleanly separates it from siblings like get_cpu, get_disks, and get_system_overview. It lacks an explicit verb, but the intent 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 statement of when to call this versus get_system_overview (which presumably also includes memory) or get_process for per-process memory. No prerequisites, no exclusions, no alternative named. The agent must infer routing from the field list 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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds that destination data requires a trace and takes trace_seconds, implying a blocking wait, but it never states the default 5s cost or that the trace prerequisite ('Turn kernel traces on') comes from the schema, not the description. Modest added value.

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, front-loaded with what you get (per-program rates/totals) before the conditional destination data. It is slightly run-on with the trailing 'with the programs talking to each', but nothing is redundant.

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?

No output schema exists, so the description must convey return structure, and it does: per-program rates/totals plus destination-name grouping. The main omission is the latency cost of the trace and that the trace prerequisite must be enabled beforehand, which an agent needs in order to avoid a surprise delay.

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?

With one parameter at 100% schema coverage, the schema already documents trace_seconds fully, including the 0-30 range, default 5, and the kernel-traces prerequisite. The description only adds that the trace gates the destination-name output, which is a small semantic gain over the schema text.

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 specific resource and the shape of the result: per-program receive/send rates and totals, plus destination breakdown by name. That is far more concrete than a generic 'get network usage'. It does not name the sibling tools it overlaps with (list_connections, list_dns_lookups), so 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?

Usage is implied: call it for per-program bandwidth, and the destination breakdown only appears after a trace. There is no explicit when-to-use versus list_connections or list_dns_lookups, and no statement of when the trace is worth the wait beyond the parenthetical condition.

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 establish readOnly/idempotent/non-destructive, and the description adds genuinely new behavioral facts: 'Nothing is injected; its files in /proc are only read', and the note that ancestors are named even after they exited. It stops short of disclosing cost or what happens for an invalid/reused pid.

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

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

One front-loaded sentence with the core claim first ('One process in full') followed by a scoped enumeration, plus a short safety sentence. The list is long but every item names a distinct returned data class rather than padding, so it earns its length despite being dense.

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 no output schema, the description carries the return-value burden and does so thoroughly by enumerating what comes back. It lacks only failure behavior (unknown/zombie pid) and performance expectations for a tool that inspects many /proc surfaces.

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% and the single pid parameter is documented in-schema, so the description adds no parameter meaning beyond it. Baseline 3 applies when the schema does the heavy lifting.

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 'One process in full' and then enumerates the exact resource contents (counters, files, ancestry, connections, growth trends), which clearly separates it from list_processes or get_process_tree. It never names a sibling explicitly, so the differentiation is by implication rather than by direct 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?

Usage is only implied: an agent can infer this is the deep-dive-for-a-single-pid tool, but nothing states when to prefer it over get_process_tree, list_processes, get_thread_stacks or get_leaks, nor any cost/cadence guidance for what is clearly a heavy lookup. No when-not or prerequisite guidance is given.

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 readOnly, idempotent and non-destructive, so safety needs no restating. The description instead adds real behavioral context the annotations cannot: exited parents are omitted from the tree, PID reuse is guarded against so no false parent is reported, and the payload carries CPU and private memory figures.

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: the payload and scope come first, then the correctness caveats. Nothing is repeated and every clause carries information an agent would otherwise have to guess.

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 no output schema, the description does the necessary work of naming the returned fields and the tree semantics, and the schema handles depth limits. The one unresolved gap is output shape (nested tree versus flat rows with parent ids) and ordering, which would matter when reasoning over the result.

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 both parameters are documented in the schema, including depth's default of 6 and cap of 20, so the baseline of 3 applies. The description's 'from a process down (or the whole machine)' mirrors the pid semantics rather than adding syntax or edge-case detail beyond it.

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 the resource and its distinctive shape: a parent-child process tree with CPU and private memory, rooted either at a given process or the whole machine. That implicitly separates it from flat-list siblings like list_processes and single-record get_process, but it never names an alternative, so differentiation is inferable rather than explicit.

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 scoping phrase 'from a process down (or the whole machine)', which hints at when to pass a pid versus omit it. There is no explicit when-to-use guidance, no when-not, and no pointer to get_wait_chain or get_process for other lineage questions.

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 establish read-only, idempotent, non-destructive, closed-world behaviour, yet the description still adds real substance: on Windows the processor temperature depends on vendor drivers, firmware thermal zones substitute when present and are often absent on desktops, and processor power comes from the energy meter. That tells the agent to expect missing or partial readings. It does not say how missing sensors are surfaced (omitted vs. null vs. error), which keeps it off a 5.

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 content is packed into one front-loaded sentence, with the payload (what is returned) first and the platform caveat second. It is dense with nested parentheticals, which costs a little readability, but no sentence is 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?

For a zero-parameter, read-only tool with no output schema, the description covers the return contents, the threshold context and the platform caveats well. The remaining gap is that it never explains how individual sensors are keyed or grouped in the response, which matters for a tool that can return many sensors.

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 a 4. There is nothing for the description to disambiguate about inputs, and it correctly spends no words on arguments.

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 concretely what the tool returns: temperatures, fan speeds and power draw for every sensor, enumerated by location (package/cores, GPUs, disks, memory, NICs, thermal zones, fans) plus high/critical marks. That is far more specific than the name alone. It never distinguishes itself from the overlapping siblings get_cpu, get_gpus, get_disks or get_hardware, so it falls short of a 5.

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

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

Usage is only implied: mentioning the hardware's high and critical marks suggests the tool is for thermal/throttling headroom checks rather than raw inventory. There is no explicit when-to-use or when-not-to-use, and no routing advice against the many overlapping per-component siblings, which an agent selecting among get_cpu, get_gpus, get_disks and get_hardware genuinely needs.

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, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds substantive context the annotations do not: the exact set of attributes returned, including dependency relationships in both directions and whether a trigger starts the service, which is genuinely useful given there is no output 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?

A single front-loaded sentence that spends every clause on a distinct returned attribute, with no filler or restatement of the tool name. Tight and purposeful.

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

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

For a one-parameter read tool with no output schema, describing the returned fields is precisely the missing piece and it is done thoroughly, including dependencies. It stops short of noting not-found/error behavior or whether dependency lookups can be slow, which would have made it fully 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% and the schema's own 'name' documentation is quite rich (sshd.service format, the "(user)" suffix, and the warning not to pass the description). The description adds no additional meaning about the parameter, so the baseline 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?

"One service in full" states a specific singular resource and enumerates the returned facets (state, process, startup type, account, dependencies), which reads clearly as a detail lookup rather than a listing. The singular framing implicitly separates it from list_services, but the description never names or contrasts 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: 'One service' versus the sibling list_services suggests this is the follow-up call once a service name is known, but there is no explicit when-to-use, no mention of prerequisites, and no statement about what happens with an unknown or ambiguous name.

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?

Beyond the read-only and non-destructive annotations, it discloses that the tool may first watch for watch_seconds when a trace is not already running and that no game is opened. It does not further explain trace startup behavior, privilege requirements, or how inactivity affects the usefulness of the measurements.

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 compact sentences front-load the measurements and then cover timing and the absence of game-launching side effects. The opening fragment and long first sentence are somewhat dense, while phrases such as "every program that draws (games)" could be expressed more clearly.

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 one optional parameter, the definition supplies enough information to invoke it with defaults, anticipate a possible wait, and understand the broad result categories despite the absence of an output schema. It remains less complete about stutter thresholds, trace prerequisites, and data-quality expectations when little rendering or interrupt activity occurs.

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 documents watch_seconds, including its range, default, and sampling rationale. The description adds useful semantics beyond that schema by explaining that the watch period applies conditionally when the trace was not already running.

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 clearly identifies the diagnostic data: frame rate, 1% lows, frame times and stutter counts for rendering programs, recent stutters, and per-driver DPC/ISR spikes. This scope implicitly distinguishes it from generic CPU, GPU, and process tools, but it lacks an explicit collection verb or direct sibling comparison.

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 focus on games and LatencyMon-style driver timing provides clear context for diagnosing rendering stutters and driver-latency spikes. It does not explicitly state when to prefer it over tools such as get_history, record_activity, get_cpu, or get_gpus, or mention that representative workload activity may be needed.

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 readOnly, idempotent, non-destructive, closed-world behavior, so safety is covered. The description adds real value beyond that by disclosing the diagnostic content of the response (hung windows, unendable processes, memory pressure, leaks) that an agent could not infer from the schema. It does not mention snapshot cost or latency for a whole-system sweep.

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 content inventory is front-loaded in the first sentence and the routing cue closes it in four words. The single sentence is dense and run-on, but every listed item conveys a distinct capability rather than 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 no output schema, the description carries the burden of describing return content, and it does so comprehensively by category, including the attention/anomaly section. It omits response shape and any note about the expense of a full-system snapshot, which is the only remaining 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?

There is a single optional parameter and the schema documents it at 100% coverage with a default of 5. The description never references `top`, so it adds no meaning beyond the schema; baseline 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?

Names a concrete resource (the whole PC) and enumerates exactly what is returned: CPU, memory, disks, network, GPUs, process/thread/handle counts, uptime, busiest processes, and attention items. This clearly separates it from the single-resource siblings (get_cpu, get_disks, get_memory) as the aggregate view.

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 place to start" is an explicit entry-point directive that tells the agent to call this before drilling into per-resource tools. It stops short of naming specific follow-up siblings or stating when not to use it, so it falls just short of a 5.

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?

Discloses behavior the annotations cannot convey: the tool OPENS the process and SUSPENDS every thread for a few milliseconds, and the first call is refused with a risk explanation requiring force=true after user consent. This side-effect-and-consent protocol is exactly the kind of context the readOnly/destructive hints do not capture.

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 front-loaded with the highest-value information: what you get first, the side effect and consent gate second. Every clause carries weight and nothing is repeated from the schema.

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?

Covers the essentials for a 4-parameter diagnostic tool with no output schema: what is returned (module!function frames), what it does to the target process, and the consent gate. It leaves the exact return shape (number of frames, depth, multi-thread layout) unstated, which an agent must discover at call 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 coverage is 100%, so the baseline is 3, but the description adds real meaning: tid vs. threads is framed as 'one thread, or its busiest ones,' and force is tied to a concrete sequencing rule ('call again with force=true only if the user agreed'). It stops short of explaining what counts as 'busiest' or the sampling depth.

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 ('call stacks of a process' threads') plus the payload shape ('module!function names where they can be read') and the diagnostic intent ('where it spends its time or is stuck'). This clearly separates it from siblings such as get_process, get_wait_chain, or list_modules.

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 a clear diagnostic context (finding where a process spends time or is stuck) and an explicit two-step protocol for the risky first call. It does not, however, name alternatives — e.g., when to prefer get_wait_chain for blocking analysis or get_process for basic inspection — so the agent must infer the routing.

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?

Adds substantial behavior beyond the annotations: the tool opens the target process' threads, the first invocation is deliberately refused with a risk explanation, the retry requires force=true with user consent, and the call can take seconds. These access, consent, and latency traits are exactly what annotations cannot convey (readOnlyHint=true alone would hide the thread-opening risk).

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 the purpose, then the risk protocol, then the latency caveat — a sensible order with no filler sentences. The opening sentence is dense with a long enumerated list, but every clause earns its place by narrowing scope.

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 no output schema, the description still tells the agent what comes back conceptually (wait chain across processes, deadlocks first) and what to expect on the first call. The only gap is that the return structure of a wait chain is not sketched, though the self-refusal protocol is well explained.

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 both parameters are already documented, and the schema for force is nearly identical to the prose. The description still adds the operational meaning of force — it is the second-call escape hatch after a deliberate refusal and requires user consent — which is more actionable than the schema's 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 verb and resource (what a process' threads wait for) and enumerates the scope precisely: locks, threads, processes, COM/ALPC calls, with deadlocks surfaced first. It also frames the diagnostic question it answers ("why is it not responding"), which distinguishes it cleanly from siblings like get_thread_stacks and why_process_will_not_end.

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 clear context for when to reach for it (a non-responding process) and a mandatory two-step protocol: the first call is refused, force=true only after user agreement. What it does not do is name an alternative sibling (e.g. why_process_will_not_end) or state when the cheaper tools should be tried 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?

Beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true), the description usefully discloses that rule-imposed limits survive this call. However, the schema's force parameter refers to 'the risk this tool described', and the description never describes any risk, leaving the behavioral consequence of removal unexplained.

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 short sentences, with the core action front-loaded and the rule-limit caveat placed as a qualifier. The wording is slightly clumsy ('limit limit_process') but there is no padding or repetition.

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 two-parameter, non-output-schema tool with annotations covering safety, this is close to sufficient, but the dangling reference to a risk the description never states leaves a real informational hole. It also says nothing about failure conditions, such as what happens when the process has no limit 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 100% and both parameters are documented inline, including the consent condition on force, so the baseline for a low-burden description applies. The description adds only indirect context (that removing a limit relates to limit_process) and nothing specific about pid or force, so it does not exceed the baseline meaningfully.

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 ('Takes away the CPU and memory limit') and explicitly names the sibling that applied it, limit_process, so the inverse relationship is unambiguous. The awkward phrasing 'limit limit_process ... put on a process' costs a little clarity, but the operation is identifiable without opening 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?

Usage is implied through the reference to limit_process and the carve-out that 'a rule's limit stays', which steers the agent away from expecting this to undo rule-based limits. There is no explicit statement of prerequisites or of when an alternative (e.g., rule management) should be used instead.

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?

Well beyond the annotations: it discloses the job-object enforcement model, that exceeding the memory cap makes allocation requests fail and typically crashes the program, the lifetime of the limit, and that protected processes are rejected. That is substantial added context on top of readOnlyHint=false / destructiveHint=false / idempotentHint=true — the near-crash side effect in particular is not implied 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?

Single dense paragraph, front-loaded with the action, and no filler sentences. A couple of clauses ('and most programs then stop with an error') could be tightened, but each carries information about consequences.

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 mutating, no-output-schema tool this covers the essentials: scope, duration, undo path, side effects, and refusal cases. The remaining gap is the unexplained `force` parameter and any hint about what the call reports back, which is minor since no output schema exists.

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 50% (memory_gb and cpu_percent are documented; pid and force are not). The description does add real meaning the schema lacks — that limits propagate to processes started later — but it never explains what `force` changes, which is exactly the undocumented parameter an agent most needs guidance on.

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 — holds a process (and its future children) to a CPU share and private-memory amount — and pins down the mechanism ('Windows job objects: a cap the scheduler keeps, whatever the priority'). That phrasing implicitly separates it from priority-tuning siblings like set_priority and set_efficiency_mode.

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 clear operational context: the limit persists until the process exits or the app quits, and lift_limit removes it. It also names the cases where the tool will refuse to act (core processes, anti-cheat programs). It stops short of an explicit 'use this rather than set_priority when...' routing statement.

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 establish that this is a safe, read-only, idempotent operation, so the bar is lower. The description adds valuable context about how remote names are resolved (program lookups else reverse DNS) and that trace_seconds > 0 includes per-connection traffic, beyond what annotations provide.

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 compact sentences with the primary scope front-loaded, followed by the trace enhancement and filtering capability. No unnecessary wording is present.

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 no output schema, the description usefully explains what data is returned (program, remote address/name, ports, TCP state, optional traffic). It is nearly complete, though it could clarify whether listening TCP ports are included, given the separate list_listening_ports sibling.

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 four parameters in detail. The description adds marginal meaning for the filter and trace_seconds parameters but does not mention pid or limit, leaving the schema to do the heavy lifting.

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 scope: every TCP connection and UDP endpoint with program, remote address/name, ports, and TCP state, plus optional traffic details. It does not explicitly distinguish this tool from siblings like list_listening_ports or get_network_usage, leaving some potential overlap ambiguous.

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 implies usage by specifying filtering by process or text and the trace option, but it gives no explicit when-to-use guidance or exclusions relative to sibling tools such as list_listening_ports or close_connection.

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 establish readOnlyHint, idempotentHint, non-destructive and closed-world behavior, so safety is fully covered elsewhere. The description's real contribution is the platform limitation: lookups are not recorded system-wide on Linux, which is context the annotations do not carry. It stops short of describing result shape, retention window, or how results relate to the kernel trace requirement.

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 short sentences with no padding, and the platform caveat is placed immediately after the purpose statement. The phrasing is slightly clumsy ('DNS lookups programs made') but nothing is wasted.

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 four optional parameters, no output schema, and a trace-watching mode that changes what the tool returns, the description should say what a lookup record contains and what changes when trace_seconds is set. Neither is covered, and the interaction with the network trace is only implied.

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%, including the pid, filter, limit and trace_seconds semantics and the 'Turn kernel traces on' prerequisite, so the schema does the heavy lifting. The description adds nothing about parameter behavior, making the baseline 3 correct.

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 says the tool covers 'DNS lookups programs made', which identifies the resource but with awkward grammar and no explicit verb-plus-scope framing. It does not distinguish itself from related siblings such as list_connections or get_network_usage, so an agent must infer the boundary from the noun phrase 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?

There is no guidance on when to reach for this tool versus list_connections or get_network_usage, and no mention of prerequisites beyond a passing hint. The one usage-adjacent signal is the Linux unavailability note, which tells the agent when the tool will not work but not when it should be chosen.

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?

Beyond the read-only and idempotent annotations, it discloses that the target process is opened and that handles are duplicated out of it to read their names. The initial refusal, risk disclosure, and explicit consent gate surface important potentially intrusive behavior that the annotations alone would conceal.

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 front-load the returned information and then the critical operational risk and consent workflow. The capitalization emphasizes the surprising behavior, and every clause earns its place without 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?

Despite having no output schema, the description supplies the essential result content: handles by type, object names, and process-handle targets, while the schema documents filtering and truncation controls. Together with the risk-discovery and consent sequence, this gives an agent enough context to invoke the tool correctly; exact risks are intentionally supplied by the first call.

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

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

All five parameters already have schema descriptions, including the filters, result limit, and force consent condition. The description usefully places force within the two-call workflow, but otherwise adds little parameter-specific meaning or syntax beyond the fully documented 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 identifies the resource precisely: handles held by a process, grouped by type, with file, registry-key, event, and other object names, plus the targets of process handles. This naturally distinguishes it from general process-inspection siblings, although it does not explicitly contrast it with tools such as get_process or list_modules.

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 provides a concrete invocation protocol: the first call is refused and returns the risks, then the agent may retry with force=true only after the user agrees. It does not explain when handle inspection is preferable to sibling tools, so its guidance is stronger for safe invocation than for tool selection.

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, idempotentHint, and non-destructive behavior, so safety is covered. The description adds genuinely useful context beyond them: sampling cadence of every 10 seconds while Anabolic runs, and that coverage includes machine totals and process attribution. It omits retention limits, how many days are typically returned, and what happens when recording was not running.

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 short sentence, front-loaded with the resource being listed, with no padding. The trailing clause 'the processes that led' is grammatically incomplete and adds ambiguity rather than information, which is the only real inefficiency.

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 list tool this is nearly adequate, but with no output schema the description should state the return shape (a list of dates, and in what format or ordering) so the agent can chain into get_history. The cadence context helps, but the missing return-format detail and the absent link to get_history leave a 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The prose does not misrepresent any input expectations.

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 identifies a specific resource: the set of days for which history (flight recorder) data exists, plus the sampling scope. It is distinguishable from the sibling get_history, which presumably returns the entries themselves, though the description never names that relationship explicitly and is phrased as a noun fragment rather than a verb-led statement.

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: nothing says this is the discovery step to call before get_history to pick a valid day, and no exclusions or alternatives are named. The agent must infer the call ordering from the sibling list 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, idempotentHint=true and openWorldHint=false, so safety is covered. The description adds value beyond that by disclosing the content of each result entry — the owning program and the reachability scope (every network / this computer only / one network), which is a behavioral detail not encoded in any structured field. It stops short of noting whether elevated privileges are needed to attribute ports to programs.

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

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

A single front-loaded sentence that defines the resource first and then enumerates the result fields, with zero filler. The colon-and-list construction is dense but readable; nothing is redundant.

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 no-parameter, read-only listing with no output schema, the description does the necessary work by stating what each returned row contains (program and reachability). The only meaningful omission is any note about privilege requirements or result ordering, which is minor for a safe 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 and the schema is an empty object, so there is no parameter meaning to add; the description correctly refrains from inventing any. The baseline for a 0-param tool applies, with no extra semantics to earn a higher mark.

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 (ports open on this PC) and narrows it precisely to TCP listening and UDP bound sockets, plus what accompanies each entry (owning program, reachability scope). It is clearly distinct from a connections listing by emphasizing 'listening' and 'for others to connect to', though it never names the sibling list_connections it must be distinguished from.

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 stated: the phrase 'for others to connect to' frames the tool as an exposure/what-is-listening check, which hints at when it is appropriate. There is no explicit when-to-use, no exclusion, and no pointer to list_connections for established sessions versus listening sockets, so the agent must infer the routing.

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 declare a safe, idempotent read, but the description adds a crucial trait they do not convey: the tool opens the target process, which is refused on the first call and requires an explicit force=true retry after user consent. That two-step consent flow is exactly the kind of behavioral context annotations cannot express, though the nature of the risk itself is left to the refusal message.

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, zero waste: the return contents come first and the safety-critical consent flow second, with the capitalised 'OPENS THE PROCESS' drawing the eye to the risk. Nothing is repeated from the schema and 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 no output schema, the description compensates by listing the returned fields, and it fully covers the two-parameter consent workflow. Only minor gaps remain, such as behaviour on an invalid or already-exited pid.

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 both pid and force are already documented, establishing a baseline of 3. The description goes beyond the schema by explaining the call sequence that makes force meaningful (refused first call, then retry with force=true), which adds real semantic value.

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 concretely ('The DLLs and the program a process has loaded') and even enumerates the returned fields (paths, base addresses, sizes), so an agent knows exactly what it gets. It does not explicitly contrast itself with nearby siblings like list_handles or get_process, so it stops short of a 5.

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

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

It gives clear operational guidance for the force parameter: the first call is refused and returns the risks, and force=true should be used only after the user agrees. That is an explicit when-to-use rule, though it offers no guidance on choosing this tool over alternative views of a process.

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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds useful behavioral detail (the health flag 'whether it is not responding' and the exact per-line column set) but says nothing about default result size, truncation, or whether system/kernel processes are included.

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

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

A single dense sentence, front-loaded with the action and scope before the column list and the filter/sort note. The column enumeration is long but earns its place since there is no output schema.

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 read-only list tool the definition is largely complete: it conveys what a row contains, that filtering and sorting exist, and the process-health flag. Only limits around result size and inclusion scope are left entirely to the schema.

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 is 3. The description only restates filtering and ordering, and its phrase 'order by a resource' actually under-sells the schema's non-resource sort keys (name, pid, started) without adding new meaning.

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 ('processes running now, one line each') and enumerates the returned columns, which lets an agent distinguish it from get_process or get_process_tree, though those siblings are never named 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: 'Filter by name or PID, order by a resource' hints at typical calls, but there is no statement of when to prefer this over get_process (single-process detail) or get_process_tree, and no exclusion 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 this a safe, idempotent, closed-world read, so the bar is lower. The description still adds real context beyond them: it discloses that both system and user units are included, that user units are tagged '(user)', and what attributes each row carries. It says nothing about pagination behavior beyond the schema's own limit note.

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

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

A single dense sentence with the resource front-loaded, followed by the returned attributes and then the filtering capability. No filler, no repetition; the parenthetical '(user)' marker is a genuinely load-bearing detail.

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 no output schema, the description carries the burden of describing return values and does so adequately by listing the per-service attributes. Combined with the full schema coverage of inputs and the read-only annotations, an agent has what it needs to call this correctly; only the sibling-routing question remains open.

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 all three parameters (limit, state, filter) are fully documented in the schema, establishing a baseline of 3. The description's 'Filter by text and state' restates the schema rather than adding format, matching rules, or edge-case behavior.

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 (systemd services) and enumerates the returned fields (unit name, description, state, startup type, process), so an agent knows exactly what it gets. It does not explicitly distinguish itself from the singular sibling get_service or from list_startup_items, leaving that distinction 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?

Usage is only implied: the phrase 'Filter by text and state' suggests a browsing/inspection use case, but there is no statement of when to choose this over get_service (single unit detail) or list_startup_items. No exclusions or prerequisites are given.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that by disclosing what each entry reports: command, enabled/disabled state, whether the backing program is missing, and current runtime cost. It does not say whether output covers other users or requires elevation.

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 front-loads the resource before the source list and the reported fields. It is dense with colon-separated clauses but every clause adds information. Slightly list-heavy phrasing costs it a perfect score.

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 no output schema, the description carries the return-value burden and does so by enumerating the reported fields. No parameters need explaining. Minor gap: it does not state scope (current user vs. all users) or ordering/format, which matters for a system-inventory call.

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

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

The tool takes zero parameters, so the schema has nothing to explain and the baseline of 4 applies. The description correctly does not invent parameter behavior, keeping it a pure enumeration tool.

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 (startup items) and enumerates the concrete sources it covers: autostart entries, systemd user units, and Plasma scripts. That detail distinguishes it from generic siblings like list_services or get_system_overview. It never states the verb or names an alternative sibling explicitly, so it stops short of a 5.

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

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

Usage is only implied: an agent infers you call this to inspect what launches at session start. There is no statement of when to prefer it over list_services or set_startup_item, and no mention that modification goes through the sibling set_startup_item. No prerequisites (e.g., root/system scope) are given.

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 readOnly/idempotent/non-destructive, and the description reinforces this with "Nothing is opened, stopped or injected", which is the precise reassurance an agent needs about a monitoring tool. Beyond that it discloses privilege requirements, progress reporting every second, the returned artifacts (counts plus kept steps), and a load warning that syscalls can produce hundreds of thousands per second.

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?

Everything is packed into two sentences with no filler, and the core action leads. The first sentence is long and clause-stacked, and the Process Monitor / strace / strace -c analogies repeat information already conveyed, but no sentence is wasted.

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 11-parameter tool with no output schema, the description covers the essential gaps: what events are captured, permission limits, duration and heaviness of recording, and that the return value is counts plus kept steps. It could say more about how the returned steps are shaped, but nothing needed to call it correctly is missing.

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 every one of the 11 parameters is already precisely documented. The closing sentence does little more than restate the schema when it says to filter with kinds, filter, only_failures and only_changes, and the syscalls count-collapsing detail is also present in the schema, so added meaning is marginal beyond 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 opens with a specific verb+resource: it records what a process (or all processes of a name, or the whole machine) does for some seconds, step by step. It enumerates the captured event classes (process starts/ends, modules, file reads/writes/renames/deletes, TCP connections, optional syscalls), which makes it unmistakable from any sibling such as get_process_tree or list_modules.

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

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

It gives clear context for each invocation mode (single pid, all processes of a name, everything) and states the prerequisite for the richest data: "only when Anabolic has full access" and "(full access)" for syscalls. It does not name a specific alternative tool or an explicit when-not-to-use condition, so it stops short of a 5.

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=false, destructiveHint=false, idempotentHint=true, and openWorldHint=false, so the safety profile is largely covered and the description is consistent with it. However, the schema's 'force' parameter says it is true 'only after the user agreed to the risk this tool described' — yet the description describes no risk and no failure modes, so a behavioral gap remains that annotations do not fill.

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 wasted words; nothing is buried. Its brevity edges into under-specification, which is penalized elsewhere rather than here.

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 (2 params, no output schema, annotations present), but the description omits the risk referenced by the force parameter, what happens on failure (process not found, already running), and whether resuming has side effects. An agent could call it, but could not confidently decide when to escalate to force.

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 both pid and force are already documented in the schema, giving a baseline of 3. The description adds no meaning beyond the schema and does not explain when the force escalation is warranted, despite the schema hinting at an undescribed risk.

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 (resumes) and resource (a suspended process), which makes the intent unambiguous and clearly the inverse of the sibling suspend_process. It does not explicitly reference that sibling or scope which processes qualify, so it stops short of full differentiation.

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 word 'suspended' implies a precondition (the process must currently be suspended) and thereby the pairing with suspend_process, but no when-to-use guidance, no exclusions, and no mention of what to do if the process is not suspended are given. Usage is inferable 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?

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds only a definition of affinity — nothing about whether the change takes effect on already-running threads, whether elevation or process ownership is required, or what happens on invalid CPU indices.

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 clean, front-loaded sentence with zero filler, but it is undersized for the job: the space saved is space the agent needed for the 'force' parameter and usage conditions.

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 3-parameter mutation tool with low schema coverage, no output schema, and an undocumented 'force' flag, the description should carry more weight. It leaves the agent guessing about prerequisites and the effect of the optional parameter.

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%: only 'cpus' is documented in the schema, while 'pid' and especially 'force' are bare. The description does not compensate at all — the meaning of 'force' (force past permissions? force termination of threads?) is nowhere explained, which is a real ambiguity for a mutation 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?

States a concrete verb and resource: 'Sets which logical processors a process may run on (its affinity).' The parenthetical clarifies the technical term, so an agent can distinguish it from set_priority or limit_process without opening the schema. It stops short of explicitly naming the nearest sibling (set_priority) as an alternative.

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. There is no mention that get_cpu or get_process should be consulted first, no note about required privileges per process, and no pointer to set_priority for the closely related scheduling concern.

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 the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), and the description usefully explains what the mode actually does at the scheduler and I/O level. It omits failure behavior (nonexistent pid, permission requirements) and never explains the effect of the `force` flag or whether the change survives process restart.

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

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

One sentence, front-loaded with the action, with the mechanism as a trailing clarification — no filler. It could be slightly tighter, but nothing is wasted.

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 system-level mutation with three parameters, a third of them undocumented, no output schema, and no stated permission or failure semantics, the description leaves real gaps an agent would need in order to call it correctly and interpret the result.

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%: `on` is documented in the schema, while `pid` and `force` are bare. The description implies a target process but never clarifies pid semantics or what `force` overrides, leaving the most operationally interesting parameter undocumented in both places.

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+resource ("Turns efficiency mode on or off for a process") and goes further by explaining the mechanism (idle scheduling class, idle disk I/O). It does not, however, distinguish itself from nearby siblings such as set_priority or limit_process, which also throttle a process.

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 choose this over set_priority, set_affinity, or limit_process, nor any mention of prerequisites (admin rights, OS support, whether the process must be running). The agent must infer the use case purely from the phrase "efficiency mode".

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 the mutation profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), so the description is only asked to add context. The starvation warning for realtime is a genuinely useful side-effect disclosure that a bare schema would not convey, though it says nothing about required privileges or what the undocumented force flag changes.

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: the verb and resource come first, the valid values follow, and the most important caveat closes it. No filler and the safety warning is placed where it will be read before invocation.

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 3-parameter mutation tool with no output schema, the description covers what is changed and the main risk, but leaves force, privilege requirements, and the effect on other processes undocumented. Given the low schema description coverage, the agent still lacks enough information to invoke this confidently in edge cases.

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

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

Schema coverage is only 33%: the priority string is already documented in the schema, and the description merely repeats those values. The pid and force parameters are unexplained in both places, and force being a boolean defaulting to false on a mutation tool leaves the agent guessing what it overrides and when it is needed.

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 the operation (set) and the resource (a process' priority class) and enumerates the accepted values, so the agent can tell it apart from set_affinity, set_efficiency_mode, or limit_process. It stops short of explicitly contrasting with those siblings, but the purpose itself 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 explicit when-to-use or when-not-to-use guidance and no prerequisite or permission information. The parenthetical warning that realtime can starve the rest of the system is the only implied guidance, warning against one extreme value rather than routing the agent to an 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 destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is covered. The description adds real context by defining 'disabled' as masked ('cannot be started'), which signals a stronger state change than a mere stop. It still omits whether the change applies immediately, whether a running service is stopped, and whether privileges are required.

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, front-loaded with the core purpose and followed by the mode semantics and the platform caveat. No filler; the only weak spot is that the automatic_delayed caveat appears without first saying the tool is Linux/systemd-only beyond the implicit 'systemd' word.

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, idempotent configuration mutation with no output schema, the description covers what each target state means but not side effects (does disabling stop a running unit?), privilege requirements, or failure behavior. Adequate to call correctly, but not complete enough to predict consequences.

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 50%: 'startup' is documented in the schema while 'name' is not. The description adds genuine semantics by mapping each mode to its systemd meaning (automatic=enabled, manual=disabled-on-demand, disabled=masked) and by warning that 'automatic_delayed' is not valid on Linux. It leaves 'name' underspecified — no example like 'nginx.service' — so it only partially compensates 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 and resource ('Sets how a systemd service starts') and enumerates the three resulting states, so the agent knows exactly what the mutation does. It does not name or differentiate itself from plausible siblings such as control_service or set_startup_item, which would have pushed it to a 5.

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

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

Usage is implied by the phrase 'systemd service', which scopes it away from get_service/list_services (read operations) and set_startup_item (likely OS startup items rather than systemd units). However, there is no explicit when-to-use versus control_service, no stated prerequisites such as root privileges, and no guidance on choosing among the modes beyond their definitions.

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 idempotent, non-destructive, closed-world mutation. The description adds real content beyond them: the exact side effect per item type (hide vs. disable), where the override lives, and the reassurance that 'Nothing is deleted'. It stops short of stating permissions needed or whether changes apply immediately.

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 the action first, then the per-type mechanics in a parenthetical, then the non-destruction guarantee. Dense but every clause carries information; only the colon-and-parenthetical nesting slightly slows parsing.

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 3-parameter mutation tool with no output schema, the definition explains the mechanism well but says nothing about return values (prior state? new state?) or error behavior for unknown names. The potential overlap with set_service_startup is left unresolved.

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

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

Schema coverage is 67% and both 'name' and 'location' already carry descriptions referencing list_startup_items. The description adds the distinction between 'hidden' and 'disabled' but gives no extra meaning to the 'enabled' boolean or to what happens when neither autostart nor unit variant matches.

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?

Specific verb and resource: 'Turns a startup item on or off', with the two concrete mechanisms spelled out (autostart entry hidden via a user-folder override; systemd user unit disabled). It does not name a sibling, so an agent must infer how this differs from set_service_startup, which also manipulates systemd units.

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: you need an item name 'as list_startup_items gives it', which nudges the agent to list first, and the location param hints at disambiguating duplicates. There is no explicit statement of when to prefer this over set_service_startup, or of preconditions and failure cases.

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?

Beyond the destructive/non-readonly annotations, it discloses exactly what suspension affects: all threads stop using the CPU and windows stop responding. It also discloses refusal conditions and the special force=true requirement for games or anti-cheat programs.

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 front-loaded with the core action and effect, then adds the key exceptions and force requirement. It is compact with no 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?

For a two-parameter mutation tool with full schema coverage and meaningful annotations, the description covers effects, refusals, and the force condition well. A minor gap is that it does not mention privilege/elevation requirements, and the term 'Anabolic' is not explained.

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 already 100%, so the schema carries the basic parameter documentation. The description adds meaningful force semantics by explaining that game or anti-cheat processes require force=true, going beyond the schema's generic consent 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?

The description states a specific verb and resource: suspend every thread of a process. It also clarifies the reversible effect ('until resumed') and user-visible impact ('windows stop responding'), which distinguishes it from termination tools such as end_process and from resume_process.

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

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

It gives clear usage context: critical processes and Anabolic are refused, and game/anti-cheat processes require force=true. It does not explicitly compare this tool to end_process, limit_process, or resume_process, so the when-to-choose guidance is not fully exhaustive.

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 the safety profile (readOnly=false, destructive=false, idempotent=true, openWorld=false), so the bar is lower. The description adds useful scope detail by naming exactly which rules are removed and who created them. It does not say whether removal takes effect immediately, whether other firewall rules for the program are preserved, or what is returned.

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

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

One sentence with no filler, and the key fact (which rules are removed) is front-loaded. The parenthetical about the Network page makes the middle clause slightly clunky but it earns its place by covering the non-tool origin of the rules.

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

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

For a one-parameter tool with annotations and no output schema, the description covers what it does and what it acts on. It leaves gaps around post-call state and the no-op case, which matter for an agent verifying that an unblock actually happened.

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% and the single parameter is already documented as the program's full path obtained from get_process. The description adds no path format, matching, or error semantics beyond that, so the baseline 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?

States a specific verb (removes) and resource (firewall rules) and explicitly ties them to the sibling tool that created them (block_program) or the Network page. An agent can tell this is the inverse of block_program without opening either schema. It stops short of a 5 only because it describes provenance rather than stating the end effect on the program itself.

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 reference to block_program and the Network page, so an agent can infer this is the undo path after blocking. There is no explicit when-to-use statement, no when-not guidance, and no note about what happens if called for a program that was never blocked.

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 read-only, idempotent, and non-destructive behavior. The description adds that the process is 'only read about, not opened' and details the diagnostic checks, which usefully clarifies that no handle is opened and what categories of answers to expect. It stops short of discussing performance or permissions, but that is minor given 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?

The description is front-loaded with the core question and then enumerates the specific checks in a compact list. It is dense but every clause contributes diagnostic meaning, and the closing sentence reinforces the read-only nature without waste.

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

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

For a one-parameter, read-only diagnostic with no output schema, the description covers what the tool determines and explicitly states it does not open the process. Annotations handle safety, so no important behavioral or usage information is missing 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 single pid parameter is fully documented in the schema as 'The process ID.' The description refers to 'a process' but adds no format, range, or handling details beyond the schema. With 100% schema coverage, 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 precise diagnostic purpose: explaining why a process persists, enumerating zombie/parent status, kernel wait, whether Anabolic may end it, and whether it is a system process. This is highly specific and distinguishes it from general process-listing or termination tools, though it does not name a 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?

The phrasing 'Why a process does not go away' implies the use case, but the description does not state when to choose this over get_process or end_process, nor does it list exclusions. The usage context is clear but alternatives are left to inference.

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 only declare readOnlyHint=false, destructiveHint=false and non-idempotent; the description adds the material facts an agent needs: the target process is cloned so it pauses only briefly, a full dump captures credentials and keys, lsass.exe is off-limits, and the first call is deliberately refused with a risk explanation. The destructiveHint=false is not contradicted — the risk here is confidentiality and process access, not data destruction.

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-loads what it writes and where, then the mode tradeoff, then the safety constraints in escalating order. Every sentence — including the lsass and force sentences — carries decision-relevant information, with no 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?

Covers safety, side effects, and the confirmation gate thoroughly, which is the hard part for a high-risk tool. It does not say what is returned (e.g., path/filename of the created dump) and there is no output schema, so the agent must infer the result shape; that is the one remaining 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 already 100%, so baseline is 3, but the description adds the consequence of each value (full dump contains passwords and keys) and the operational meaning of force (the second call in a gated confirmation flow). The pid parameter gets no extra treatment, which is fine for an unambiguous integer.

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 ("Writes a memory dump of a process") plus a destination ("Anabolic's dumps folder") and the two modes with their contents. No sibling tool in the list does anything similar, so the agent can distinguish it immediately.

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?

Explicitly frames the purpose ("for a debugger"), defines the small-vs-full choice with tradeoffs (few MB vs whole address space, including secrets), states a hard exclusion ("Never for lsass.exe"), and describes the two-call confirmation protocol with force=true. This is the when/when-not/alternatives bar fully met.

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